Forum ThiWeb.com

Bonjour,

Je suis entrain de faire quelques tests depuis Outlook et l'application Courrier de Windows afin de connaître le protocole utilisé pour l'envoi des mails.

Depuis Outlook 2016, pas de mystère, on peut choisir le protocole SSL (465) ou TLS (587) pour son serveur SMTP.
Tests effectués avec Gmail et OVH.
Jusque là tout va bien et tout fonctionne, mais pour pousser plus loin l'aventure, en inversant les ports : SSL 587 et/ou TLS 465
Plus rien ne fonctionne. Normal ! Bref, tout est cohérent.

Maintenant, j'aimerais savoir quel protocole est utilisé au moment de l'envoi/réception.
Avec les bons paramètres et en utilisant un sniffer réseau (Wireshark), ce dernier m'annonce l'utilisation du TLS v1.2 quelque soit le protocole utilisé !
En effet, même lorsque je demanda à Outlook de passer par le SSL 465, Wireshark m'annonce l'utilisation du TLS v1.2 alors que ce n'est pourtant pas le cas.

Etrange non ? Des explications seraient les bienvenues... :$

Ensuite, je me pose ces questions existentielles pour la raison suivante :
L'application Courrier de Windows 10 est identique sur Windows 10 for Phone.
Et l'option TLS n'existe tout simplement pas !
On ne peut que modifier le port de connexion du SMTP sur une simple ligne, mais quid du TLS ?

Bref, voilà pourquoi j'aimerais connaître le protocole utilisé au moment de l'envoi d'un mail et m'assurer que c'est bien le TLS qui est utilisé et non le SSL.

Merci d'avance pour votre attention,

ThiWeb

@ThiWeb:
Salut,

Tu te mélanges les crayons mon ami...

SSL et TLS, même combat.
SSL s'est arrêté à la version 3.0. On parle de "SSL v3".
TLS a commencé avec la version 1.0, puis 1.1 et 1.2. D'un point de vue protocolaire, TLS 1.0 == SL 3.01. La version 1.0 du TLS apparait sous 3.01 sous WireShark.
SSL c'est fini, il n'y a plus que du TLS.
D'un point de vue sécuritaire, il faut du TLS 1.2.

1.0 :
1.2 :

La question du port n'a rien à voir. Tu peux envoyer du SSL sur du port 80 même si ce n'est pas trop fin.
Tu te mélanges avec les ports par défaut. Exemple : SSL port 443

Pour "ton" SMTP, je pense que tu utilises du SMTPS.
Et là, on nage en plein délire : https://en.wikipedia.org/wiki/SMTPS

Pouer la question du port 587, -> la RFC

Amicalement.

@LaDidi : SSL c'est fini, il n'y a plus que du TLS... Ok.
Donc, lorsque je configure mon SMTP en SSL (port 465), ce dernier utilise en fait le TLS 1.2 c'est ça ?
Mais alors, à quoi correspond le TLS (port 587).

Pour ce qui est du port 465, je ne me pose pas la question de savoir à quoi il correspond, je sais juste que c'est le port sécurisé correspondant.
Pour ce qui est du port 587, je sais qu'il correspond à une connexion authentifiée.
Certains SMTP réclament d'ailleurs un changement d'adresse : auth.smtp.monsite.fr

Concernant le port, même si il n'a probablement rien à voir, les serveurs mails n'acceptent généralement pas de fantaisie à ce niveau.
En effet, Google et OVH par exemple, n'accepteront que l'utilisation des ports 465 et 587...
Dans l'absolu, je veux bien admettre que du SSL sur le port 80 soit possible, mais dans les faits, impossible avec les serveurs mails conventionnels.

Concernant le port SSL 443, sauf erreur, il s'agit du port Web et pas du port utilisé par le SMTP d'un client mail traditionnel.
En effet, le port 465 semble être recommandé un peu partout, mais on ne parle jamais du 443 pour les mails...

Enfin, je ne comprend donc toujours pas la différence entre les options proposées par Outlook :
Pourquoi proposer du SSL et du TLS sachant que théoriquement, le SSL est aujourd'hui du TLS ?
Et du coup, quel port utiliser ?... 465 ou 587 ?...

Sachant que pour OVH et Gmail, le TLS 465 ou SSL 587 ne fonctionnent pas, la question est on ne peut plus simple :
Que sélectionner sur son client mail ? SSL ou TLS ?! Et pourquoi les deux options existent ?

Merci à toi pour tes éclaircissements.

ThiWeb

@ThiWeb:
:ugeek: Parler réseau, sans voir de trace, c'est un peu de la br..lette de spécialiste OSI.

Fini, fini, c'est vide dit... On est dans l'informatique, donc...

Il peut utiliser du TLS 1.x. Le choix définif est fait lors de l'échange et selon la configuration de chaque terminaison. Mon serveur peut n'autoriser que du TLS 1.2 et tant pis pour les clients qui ne le supportent pas (ex. : IE8 / XP).
Tu as lu la RFC ?

Port 587 is reserved for email message submission as specified in
this document. Messages received on this port are defined to be
submissions. The protocol used is ESMTP [SMTP-MTA], with additional
restrictions or allowances as specified here.

Although most email clients and servers can be configured to use port
587 instead of 25, there are cases where this is not possible or
convenient. A site MAY choose to use port 25 for message submission
by designating some hosts to be MSAs and others to be MTAs.

L'exemple SSL sur du :443 est pour l'https par défaut. Mais rien n'interdit d'y faire passer autre chose ce que les IPS n'apprécieront pas et vireront sûrement...
Les serveurs externes acceptent rarement les ports exotiques pour diminuer leur surface d'attaque mais surtout parce que c'est filtré, avant, par différents pare-feu.
Ça peut même passer par des reverse-proxy...
On peut aussi refuser les ports exotiques car on veut, peut-êre, tout faire passer par le port unique d'un proxy... Dans mon exemple, je fais du TLS 1.0 ou 1.2 au travers d'un port 3128 d'un proxy.

Outlook propose SSL ou TLS pour ne pas perturber l'utilisateur et parce qu'effectivement il existe les 2 dans les RFC.
Certains ne font pas la diférence, par abus de langage, considérant TLS 1.0 comme un SSL 3.01...
Tu as déjà essayé : http://www.motobit.com/util/gmail-smtp-pop-outlook.asp ?

GMAIL :

• POP :
  • pop.gmail.com
    port: 995
    TLS Protocol
  SMTP :
  • smtp.gmail.com
    Port: 587 si TLS, 465 si SSL
    SSL/TLS
  IMAP :
  • imap.gmail.com
    port : 993
    SSL

N'oublie pas que pour GMail, il y a des trucs à paramétrer chez Google : https://support.google.com/a/answer/105694?hl=fr

Pour OVH, je n'ai pas regardé mais http://www.commentcamarche.net/faq/893- ... ux-fai#ovh

Je ne parle effectivement pas du HTTPS SSL 443 qui est un hors sujet par rapport à mes interrogations.

Tu cites Gmail, on va donc rester dessus pour bien cibler ce qui m'intéresse.
Le POP, on oublie, c'est le mal. Je me demande d'ailleurs pourquoi on interdit pas tout bonnement ce protocole archaïque, bref.

Donc, concernant le SMTP de Google, tu spécifies toi-même ce que je sais déjà : TLS 587 ou SSL 465.
Ma question est donc, lorsqu'on est en TLS 587, c'est mieux que du SSL 465 ?
Ou bien, le SSL 465 n'est qu'un abus de langage et correspond en réalité à du TLS 1.2 ?

Ensuite pour l'IMAP, même chose : On est sur du SSL 993.
C'est du TLS qui transite derrière ou c'est bien du SSL ?

Encore merci à toi.

ThiWeb

@ThiWeb:
Comme indiqué précédemment, faire du réseau sans trame à regarder, c'est du pipeau.

le vade mecum : https://www.fastmail.com/help/technical ... rttls.html
le map des ports : https://www.iana.org/assignments/servic ... umbers.xml

SMTPS, et son port associé 465, ne devrait plus exister que pour des raisons historiques.

LaDidi21 a écrit :SMTPS, et son port associé 465, ne devrait plus exister que pour des raisons historiques.

Bon ok on avance !
Donc le SMTP 465 est à oublier au profit du TLS 587.

Maintenant l'IMAP ! Tu as posté plus haut celui de Google qui est SSL 993.
Pourquoi le TLS n'est pas mis en avant pour les connexions entrantes alors que l'option existe ?
Je n'ai d'ailleurs jamais vu de serveur recommander le TLS en IMAP, c'est toujours du SSL. Pourquoi ?

Google : IMAP 993
Microsoft : IMAP 993

Wikipedia a écrit :IMAP utilise le port TCP 143. L'utilisation de TLS permet l'accès sécurisé au serveur. La RFC 2595, qui décrit le fonctionnement de TLS avec IMAP, déconseille l'utilisation du port 993 qui avait été préalablement enregistré pour IMAPS (IMAP over SSL).

https://fr.wikipedia.org/wiki/Internet_ ... s_Protocol

Si même les instances déconseillent l'utilisation du port 993, comment se fait-il que les grands noms d'Internet le recommandent ?
Quel serait le port IMAP du protocole TLS si on le sélectionne à la place du SSL pour l'IMAP ?

ThiWeb

@ThiWeb:
:$ Toi qui habituellement es très pragmatique, tu te poses des questions philosophiques...

IMAP : Pourquoi SSL au lieu de TLS ?

• Peut-être parce que les libs des serveurs ne sont pas à jour ?
  Peut-être parce que les gestionnaires ne veulent pas racheter de certificats ?
  Peut-être parce que les gestionnaires craignent un afflux des demandes de support : "Pourquoi marche plus ?" ?
  Peut-être parce qu'il n'y a pas de RFC ? En fait, si -> RFC2595 updaté par -> RFC4616
  Peut-être que tout le monde s'en fout ?

ThiWeb a écrit :Pourquoi ?

Et pourquoi pas ?
Comme le dit si bien http://wiki.dovecot.org/SSL :

Originally SSL support was added to protocols by giving them a separate "SSL port" (imaps, pop3s, etc.), where the SSL handshake starts immediately when client connects, and only after the session is encrypted the regular protocol handling begins. Using two separate ports for plaintext and SSL connections was thought to be wasteful and adds complexity for clients which may wish to make use of SSL when it is advertised, so STARTTLS command was added and intended to deprecate the SSL ports. Clients using STARTTLS work by connecting to the regular unencrypted port and immediately issue a STARTTLS command, after which the session is encrypted. After SSL handshake there is no difference between SSL port initiated connections and STARTTLS initiated connections.
SSL port deprecation never really happened, probably because of a few reasons:

• Some admins don't even know about STARTTLS.
• Some admins want to require SSL/TLS, but don't realize that this is also possible with STARTTLS (Dovecot has disable_plaintext_auth=yes and ssl=required settings).
• Some admins understand everything, but still prefer to allow only SSL ports (maybe with a firewall). This could be because it makes it easier to ensure that no information is leaked, because SSL/TLS handshake happens immediately. Some clients unfortunately try to do plaintext authentication without STARTTLS, even when IMAP server has told the client that it won't work. Besides, it requires fewer round-trips if you begin SSL upon connection when you know you want it, instead of connect, negotiate capabilities, insist on TLS, then start all over again inside the encrypted session.

:| Cela t'étonne encore que des grands noms de l'Internet s'assoient sur des RFCs ?
De plus, l'IANA continue d'indiquer :

...
imaps 993 tcp imap4 protocol over TLS/SSL
imaps 993 udp imap4 protocol over TLS/SSL
...

Par ailleurs, on ne souhaite plus de port dédié aux communications chiffrées (http:80 vs https:443) parce qu'il n'existe pas une infinité de ports et qu'on veut de plus en plus de services...
Ne pas oublier que c'est un integer sur 16 bits. 2^16 = 65536 => 32768 services si on sépare chiffré/non chiffré...

Pense à bien lire -> https://www.fastmail.com/help/technical ... rttls.html

Un article intéressant : https://luxsci.com/blog/ssl-versus-tls- ... rence.html

Haha ! Je suis effectivement pragmatique sur les questions que je maitrise, mais là, bons nombres d'éléments m'échappent.
Donc effectivement, ces questions sont très philosophiques.

Mais ne t'en fais pas, dès que j'auras fait le tour de ces questions, je redeviendrais catégorique et dans une moindre mesure, pragmatique
Dans tes réponses, je lis beaucoup de "peut-être"... Ce qui ne m'aide pas à être pragmatique...
On semble nager dans un océan d'incertitude.
Et quand je lis que "tout le monde s'en fout", je perd complètement espoir...

J'ai lu ton article, ce dernier rappelle ce qui est déjà largement connu, et continue de me plonger dans une grande perplexité :

"IMAP uses port 143, but SSL/TLS encrypted IMAP uses port 993"
Avec ça, on ne sait toujours pas si l'IMAP devrait utiliser du TLS plutôt que du SSL.
Ils se contentent de fusionner les deux : SSL/TLS sans répondre à ma/la question.

Concernant le SMTP par contre, il continuent de fusionner les deux :
SMTP uses port 25, but SSL/TLS encrypted SMTP uses port 465
Mais il précisent que le port à utiliser est le 465.
Or, le port 465 ne correspond que à du SSL et pas au TLS qui utilise lui, le port 587.
Si l'on en croit ton article, le "SSL" 465 serait donc à privilégier au TLS 587 ?...
Plus de catégorisme serait le bienvenue.

Je me suis amusé à regarder les recommandations des grands nom du Web, même si comme tu le rappelles avec justesse, ce ne sont pas nécessairement des exemples.
Toujours est-il que Google ne recommande RIEN (de manière catégorique) !
Au contraire, ils proposent de passer par le port, 25, 465 ou 587 en SSL ou en TLS au choix :
https://support.google.com/a/answer/176600

Quand à Microsoft, là par contre, le choix n'existe (presque) plus.
En effet, même si ils autorisent encore l'utilisation du port 25, le port 587 est également proposé.
Et quelque soit le port choisi, le TLS est le seul protocole proposé ET obligatoire :
http://windows.microsoft.com/fr-fr/wind ... e-from-app

Voilà qui me plait déjà beaucoup plus, mais alors qui a raison ? La tolérance de Google ou le catégorisme de Microsoft ?
Si c'est Microsoft, fin des débats, on DOIT utiliser le TLS 587 et plus de discussions !
J'attend simplement une affirmation ferme et intangible d'une autorité incontestable.

Une fois la question du SMTP tranchée, je m'attaquerais (toujours philosophiquement) à l'IMAP

Merci à toi,

ThiWeb

@ThiWeb:
:ugeek: Je ne peux pas affirmer car je n'ai jamais regardé de trames pour ces 3 protocoles.
Je n'affirme QUE ce que je vérifie.

Comme indiqué au début, d'un strict point de vue sécuritaire, c'est TLS 1.2.
Tout le reste, -> poubelle.

LaDidi21 a écrit :Comme indiqué au début, d'un strict point de vue sécuritaire, c'est TLS 1.2.
Tout le reste, -> poubelle.

Oui oui, ça on est d'accord sur ce point depuis le début...
Mais :

Le SSL 465 indiquant utiliser du TLS 1.2, Cf. Wireshark, ça me parrait bizarre.
Le TLS 587 c'est par définition du TLS...
Alors pourquoi utiliser plus l'un que l'autre sachant qu'apparemment, ça semble utiliser quoiqu'il arrive du TLS 1.2 ?
Elle est là ma question fondamentale...

Je te l'accorde, c'est de la branlette psycho-philosophique, mais ça me tient à cœur

ThiWeb

@ThiWeb:
:ugeek: Comme je te l'ai dit, attention aux raccourcis (trop) rapides entre les ports et les protocoles.
Si c'est possible, "fais péter les sniffs WireShark" par MP .

Bizarre, "la branlette... qui me tient à cœur", c'est plutôt "tire sur le cœur" ?