STARTTLS est-il moins sûr que TLS/SSL ?

Il n'y a pas de différence de sécurité entre les deux options.

• SSL/TLS ouvre d'abord une connexion SSL/TLS, puis commence la transaction SMTP. Cette opération doit avoir lieu sur un port sur lequel un serveur SMTP non-SSL/TLS n'est pas déjà en cours d'exécution ; il est impossible de configurer un port unique pour gérer à la fois les connexions en texte brut et les connexions cryptées en raison de la nature des protocoles.

• STARTTLS lance la transaction SMTP et recherche le support de l'autre extrémité pour TLS dans la réponse à EHLO. Si le client voit STARTTLS dans la liste des commandes prises en charge, il envoie STARTTLS et commence à négocier le cryptage. Tout ceci peut se produire (et se produit généralement) sur le port SMTP standard de 25, en partie pour des raisons de rétrocompatibilité, mais aussi pour permettre un cryptage opportuniste entre des points d'extrémité qui le supportent mais ne l'exigent pas nécessairement.

En général, SSL/TLS n'est utilisé qu'entre les clients finaux et les serveurs. STARTTLS est plus couramment utilisé entre les MTA pour sécuriser le transport inter-serveur.

Compte tenu de ces deux implémentations, STARTTLS pourrait être considéré comme peu sûr si l'utilisateur ou l'administrateur suppose que la connexion est chiffrée mais n'a pas réellement configuré celle-ci pour qu'elle le soit. Cependant, le cryptage utilisé est exactement le même que celui de SSL/TLS et n'est donc pas plus ou moins vulnérable à une attaque de type Man-in-the-Middle au-delà de ce type d'erreur de configuration.

Pour le courrier électronique en particulier, en janvier 2018 RFC 8314 a été publié, qui recommande explicitement d'utiliser "Implicit TLS" de préférence au mécanisme STARTTLS pour les soumissions IMAP, POP3 et SMTP.

En bref, ce mémo recommande maintenant que :

• TLS version 1.2 ou supérieure doit être utilisé pour tout le trafic entre les MUAs et les serveurs de soumission de courrier, ainsi qu'entre les MUA et les serveurs d'accès au courrier. et les serveurs d'accès au courrier.
• Les AUM et les fournisseurs de services postaux (FSP) (a) découragent l'utilisation des services suivants des protocoles en texte clair pour l'accès au courrier et la soumission du courrier et (b) déconseillent l'utilisation de protocoles en texte clair à ces fins dès que possible.
• Les connexions aux serveurs de soumission de courrier et aux serveurs d'accès au courrier doivent être effectuées en utilisant "Implicit TLS" (tel que défini ci-dessous), de préférence à en se connectant au port "cleartext" et négocier TLS en utilisant la commande commande STARTTLS ou une commande similaire.

(accentuation ajoutée)

La réponse dépend dans une certaine mesure de ce que vous entendez par "sûr".

Tout d'abord, votre résumé ne rend pas bien compte de la différence entre SSL/TLS et STARTTLS.

• Avec SSL/TLS, le client ouvre une connexion TCP sur le "port SSL" attribué au protocole d'application qu'il veut utiliser, et commence immédiatement à parler TLS.
• Avec STARTTLS, le client ouvre une connexion TCP sur le "port en clair" associé au protocole d'application qu'il veut utiliser, puis demande au serveur "quelles sont les extensions de protocole que vous prenez en charge ?". Le serveur répond alors avec une liste d'extensions. Si l'une de ces extensions est "STARTTLS", le client peut alors dire "OK, utilisons TLS" et les deux commencent à parler TLS.

Si le client est configuré pour exiger TLS, les deux approches sont plus ou moins aussi sûres. Mais il existe certaines subtilités sur la façon dont STARTTLS doit être utilisé pour être sûr, et il est un peu plus difficile pour l'implémentation de STARTTLS d'obtenir ces détails correctement.

D'autre part, si le client est configuré pour utiliser TLS uniquement lorsque TLS est disponible, et pour utiliser le texte clair lorsque TLS n'est pas disponible, le client pourrait d'abord essayer de se connecter au port SSL utilisé par le protocole et, en cas d'échec, se connecter au port texte clair et essayer d'utiliser STARTTLS, et enfin revenir au texte clair si TLS n'est pas disponible dans les deux cas. Il est assez facile pour un attaquant de faire échouer la connexion au port SSL (il suffit de quelques paquets TCP RST au bon moment ou de bloquer le port SSL). Il est un peu plus difficile - mais seulement un peu - pour un attaquant de faire échouer la négociation STARTTLS et de faire en sorte que le trafic reste en clair. Dans ce cas, l'attaquant peut non seulement lire votre courrier électronique, mais aussi capturer votre nom d'utilisateur et votre mot de passe pour une utilisation ultérieure.

La réponse simple est donc la suivante : si vous vous connectez à un serveur dont vous savez déjà qu'il prend en charge TLS (comme ce devrait être le cas lorsque vous envoyez ou lisez des e-mails), vous devez utiliser SSL/TLS. Si la connexion est attaquée, la tentative de connexion échouera, mais votre mot de passe et votre courriel ne seront pas compromis.

D'autre part, si vous vous connectez à un service dont vous ne savez pas s'il prend en charge TLS, STARTTLS peut être légèrement meilleur.

Lorsque STARTTLS a été inventé, les attaques "passives" par écoute seulement étaient très courantes, les attaques "actives" dans lesquelles l'attaquant injectait du trafic pour tenter de diminuer la sécurité étaient moins courantes. Au cours des quelque 20 années qui se sont écoulées depuis, les attaques actives sont devenues plus réalisables et plus courantes.

Par exemple, si vous essayez d'utiliser un ordinateur portable dans un aéroport ou un autre lieu public et que vous essayez de lire votre courrier via le réseau wifi qui y est fourni, vous n'avez aucune idée de ce que ce réseau wifi fait de votre trafic. Il est très courant que les réseaux wifi acheminent certains types de trafic vers des "proxies" qui s'interposent entre vos applications clientes et les serveurs avec lesquels elles tentent de communiquer. Il est facile pour ces proxies de désactiver STARTTLS et "essayer un port puis un autre" afin d'inciter votre client à revenir au texte clair. Oui, cela arrive, et ce n'est qu'un exemple de la façon dont votre trafic peut être espionné par un réseau. Et ces attaques ne sont pas limitées aux agences étatiques en trois lettres, elles peuvent être réalisées par un adolescent avec un ordinateur à 35 dollars caché dans un lieu public quelque part.

Oui, vous avez les bases correctes. Et oui, STARTTLS est définitivement moins sécurisé. Non seulement il peut revenir au texte en clair sans notification, mais il est sujet à des attaques de type "man in the middle". Comme la connexion commence en clair, un MitM peut supprimer la commande STARTTLS et empêcher le cryptage de se produire. Cependant, je crois que les serveurs de messagerie peuvent spécifier que les transferts ne se produisent qu'après la mise en place d'un tunnel crypté. Vous pouvez donc contourner ce problème.

Alors pourquoi une telle chose existe-t-elle ? Pour des raisons de compatibilité. Si l'un des deux côtés ne prend pas en charge le cryptage, vous pouvez quand même vouloir que la connexion se fasse correctement.