SSL vs TLS vs STARTTLS

Mathieu — Mon, 13 Jun 2016 17:03:00 +0200

Cet article est une traduction libre de https://www.fastmail.com/help/technical/ssltlsstarttls.html

J'ai réalisé cette traduction pour fournir à mes clients une explication simple mais complète sur le pourquoi du comment de SSL/TLS/STARTTLS lors de la configuration de leur client mail.

Attention, l'article original date de 2012.

Définitions

Protocole : un protocole de communication est un format de données, un "langage" permettant à deux machine de communiquer entre elles. Les deux machines doivent être en capacité de parler le même protocole pour pouvoir échanger des données. SSL est un protocole de communication sécurisé ("chiffrés"), popularisé par le célèbre "cadenas" visible sur les pages web.
Port : un port est un numéro de service sur lequel les logiciels vous pouvoir communiquer entre eux. La plupart des numéros de port sont associés à des protocoles précis.

Introduction

Il y a souvent de la confusion autour des différents termes SSL, TLS and STARTTLS.

SSL et TLS fournissent tous deux un moyen de chiffrer le canal de communication entre deux ordinateurs (par exemple votre ordinateur et votre serveur mail). TLS est le successeur de SSL et les termes SSL et TLS sont interchangeables, à moins que vous ne fassiez référence à une version particulière du protocole.

STARTTLS est un moyen de prendre une connexion non chiffrée existante, et la "mettre à jour" vers une connexion sécurisée en utilisant SSL/TLS. Notez que même s'il contient TLS dans son nom, STARTTLS ne signifie pas que vous devez obligatoirement utiliser TLS, vous pouvez utiliser SSL.

Numéros de version SSL/TLS

La numérotation des versions du protocole est inconsistante entre SSL et TLS. Lorsque TLS a remplacé SSL comme protocole préférentiel pour les communications chiffrées, il a commencé avec une nouvelle numérotation de versions, et a également commencé à utiliser des sous-versions. L'ordre des versions des protocoles du plus ancien au plus récent est donc : SSL v2, SSL v3, TLS v1.0, TLS v1.1, TLS v1.2.

Lorsque vous vous connectez sur un port chiffré avec SSL/TLS, ou que vous utilisez STARTTLS pour convertir la connexion en connexion chiffrée, les deux systèmes vont négocier quel protocole et quelle version utiliser, en se basant ce qui a été configuré et sur ce que chaque système supporte.

Le support pour SSL/TLS est "virtuellement" universel de nos jours, mais le support des versions est variable. Pratiquement tous les systèmes supportent SSL v3 (à part quelques rares appareils Palm Treo comme nous avons pu le constater). La plupart des systèmes supportent TLS v1.0. À la date de Mai 2012, le support pour TLS v1.1 et TLS v1.2 est beaucoup plus restreint.

Dénomination incorrecte TLS vs STARTTLS

Pour compliquer les choses, certains logiciels de mail utilisent incorrectement le terme TLS à la place de STARTTLS. Les plus vieilles versions de Thunderbird en particulier utilisent "TLS" pour dire « utiliser STARTTLS pour chiffrer la connexion dès que possible et abandonner si STARTTLS n'est pas supporté » et « TLS, si disponible » signifie « utiliser STARTTLS pour chiffrer la connexion dès que possible si le serveur déclare le supporter, sinon utiliser simplement une connexion non chiffrée ».

Numéros de ports SSL/TLS vs plaintext/STARTTLS

Le problème du dessus est particulièrement problématique lorsque vous devez configurer des ports différents pour chaque protocole.

Pour ajouter de la sécurité à certains protocoles (e.g. IMAP, POP, etc.), il a été décidé d'ajouter nativement une couche de chiffrement SSL/TLS dans le protocole. Cependant, pour identifier que le logiciel doit parler la version nativement chiffrée du protocole au lieu de la version non chiffrée, un port différent a été déclaré pour chaque protocole. Vous avez donc :

IMAP utilise le port 143, mais IMAP avec SSL/TLS utilise le port 993.
POP utilise le port 110, mais POP avec SSL/TLS utilise le port 995.
SMTP utilise le port 25, mais SMTP avec SSL/TLS utilise le port 465.

Au bout d'un moment, il a été décidé qu'utiliser deux ports pour chaque protocole était du gaspillage, et qu'à la place il devrait y avoir un seul port sur lequel commencer la communication de manière non chiffrée, puis proposer au système distant de mettre à jour vers la version chiffrée. C'est ce pour quoi STARTTLS a été créé.

Il y a eu quelques problèmes avec cette proposition. Il y avait déjà des logiciels qui utilisaient les numéros de port alternatifs avec une connexion SSL/TLS native. Les logiciels clients peuvent avoir une durée de vie très longue, donc vous ne pouvez pas juste désactiver les ports chiffrés avant que tous les logiciels ne soient remplacés ou mis à jour.

Des mécanismes ont été mis en place sur chaque protocole pour dire aux systèmes que le protocole non chiffré supportait STARTTLS, et qu'ils ne doivent pas essayer de se connecter avant de démarrer la négociation STARTTLS. Cela créa deux situations malheureuses :

Certains logiciels ignoraient simplement l'instruction « login désactivé jusqu'à ce que la connexion soit convertie en SSL avec STARTTLS » et essayaient de se connecter tout de même, envoyant leur login et mot de passe à travers la connexion non chiffrée. Même si le serveur à ce moment là rejette le login, les informations sont déjà passées en clair sur Internet.
D'autres logiciels voyaient l'annonce « login désactivé jusqu'à conversion en SSL », mais ne mettaient pas à jour leur connexion automatiquement, et renvoyaient des erreurs « mot de passe incorrect » à l'utilisateur, ce qui provoqua de la confusion sur ce qui était incorrect dans la configuration.

Ces deux problèmes causèrent finalement d'importantes incompatibilités entre les logiciels existants, et la plupart des administrateurs systèmes continuèrent d'utiliser les connexions exclusivement non sécurisés sur le port d'origine, et les connexions SSL natives sur un port alternatif.

C'est donc devenu de fait le standard que tout le monde utilise. IMAP SSL/TLS chiffré sur le port993 ou POP SSL/TLS chiffré sur le port 995. Beaucoup de sites (dont FastMail) désactive à présent le port IMAP non sécurisé (port 143) et le port POP non sécurisé (port 110) pour que les utilisateurs utilisent obligatoirement une connexion chiffrée SSL/TLS. En désactivant les ports 143 et 110, cela supprime également complètement STARTTLS, même en tant qu'option pour les connexions IMAP/POP.

SMTP STARTTLS comme une exception

La seule vraie exception à ce qui précède est SMTP. Cependant, c'est pour une raison différente. La plupart des logiciels email utilisent utilisaient le port 25 pour soumettre des messages à envoyer au serveur mail. Cependant, SMTP a été créé à l'origine comme un protocole d'échange de messages, et non de soumission. Un autre port (587) a donc été déclaré pour la soumission de messages. Bien que le port 587 ne nécessite pas explicitement STARTTLS, l'utilisation du port 587 est devenu populaire au même moment où l'utilisation de SSL/TLS était devenue un enjeu important de sécurité et de confidentialité.

Le résultat c'est que dans la plupart des cas, les systèmes qui proposent la soumission par le port 587 nécessitent que les logiciels utilisent STARTTLS pour chiffre la connexion, et nécessitent aussi un login et un mot de passe pour s'identifier. Il y a plusieurs avantages à cette approche. En écartant les utilisateurs du port 25, les FAI ont été en mesure de bloquer le port 25 pour prévenir les envois automatiques de SPAM causés par l'infection des postes de leurs utilisateurs.

Actuellement, les choses semblent encore aléatoires, divisées entre les gens qui utilisent SMTP SSL/TLS chiffré sur le port 465, et les gens qui utilisent SMTP avec STARTTLS sur le port 587.

NDLR : SMTPS sur le port 465 est aujourd'hui définitivement obsolète.