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

Dans Thunderbird (et je suppose également dans de nombreux autres clients), j'ai la possibilité de choisir entre "SSL / TLS" et "STARTTLS".

Autant que je sache, "STARTTLS" signifie en termes simples "chiffrer si les deux extrémités prennent en charge le protocole TLS, sinon ne chiffrez pas le transfert" . Et "SSL / TLS" signifie en termes simples "toujours chiffrer ou ne pas se connecter du tout" . Est-ce correct?

Ou en d'autres termes:

STARTTLS est-il moins sécurisé que SSL / TLS, car il peut basculer en texte brut sans me notifier?

La réponse, basée sur le STARTTLS RFC pour SMTP ( RFC 3207 ) est:

STARTTLS est moins sécurisé que TLS.

Au lieu de parler moi-même, je vais permettre à la RFC de parler d'elle-même, avec les quatre bits pertinents mis en évidence en gras :

Une attaque intercepteur peut être lancée en supprimant la réponse "250 STARTTLS" du serveur. Cela empêcherait le client de démarrer une session TLS. Une autre attaque interceptée consiste à autoriser le serveur à annoncer sa capacité STARTTLS, mais à modifier la demande du client pour démarrer TLS et la réponse du serveur. Afin de se défendre contre de telles attaques, les clients et les serveurs DOIVENT pouvoir être configurés pour exiger une négociation TLS réussie d'une suite de chiffrement appropriée pour des hôtes sélectionnés avant que les messages puissent être transférés avec succès. L' option supplémentaire d'utiliser TLS dans la mesure du possible DEVRAIT également être fournie. Une mise en œuvre peut permet d’enregistrer que TLS a été utilisé pour communiquer avec un homologue donné et générer un avertissement s’il n’est pas utilisé lors d’une session ultérieure.

Si la négociation TLS échoue ou si le client reçoit une réponse 454, le client doit décider quoi faire ensuite. Il y a trois choix principaux: aller de l'avant avec le reste de la session SMTP , [...]

Comme vous pouvez le constater, le RFC lui-même indique (pas très clairement, mais suffisamment clairement) que rien n'oblige les clients à établir une connexion sécurisée et à informer les utilisateurs en cas d'échec de la connexion sécurisée. Il donne explicitement aux clients la possibilité d’établir en silence des connexions en texte brut .

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. Cela doit se produire sur un port sur lequel aucun serveur SMTP non SSL / TLS n'est en cours d'exécution; Il est impossible de configurer un seul port pour gérer à la fois le texte brut et les connexions chiffrées en raison de la nature des protocoles.

• STARTTLS démarre la transaction SMTP et recherche une prise en charge de l'autre côté pour TLS dans la réponse à EHLO. Si le client voit STARTTLS dans la liste de commandes prise en charge, il envoie STARTTLS et commence la négociation pour le chiffrement. Tout cela peut (et se produit généralement) sur le port SMTP standard à 25, en partie pour des raisons de compatibilité ascendante, mais aussi pour permettre un cryptage opportuniste entre les points d'extrémité qui le prennent en charge mais ne l'exigent pas nécessairement.

En règle générale, SSL / TLS est uniquement utilisé entre les clients finaux et les serveurs. STARTTLS est plus couramment utilisé entre les MTA pour sécuriser le transport entre serveurs.

Étant donné ces deux implémentations, STARTTLS pourrait être interprété comme non sécurisé si l'utilisateur ou l'administrateur supposent que la connexion est cryptée mais ne l'a pas réellement configurée pour exiger un cryptage. Cependant, le cryptage utilisé est exactement le même que 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, la RFC 8314 a été publiée en janvier 2018 , qui recommande explicitement que "TLS implicite" soit utilisé 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 peut être utilisé pour tout le trafic entre les MUA et les serveurs de soumission de courrier, ainsi qu'entre les MUA et les serveurs d'accès au courrier.
• MUA et fournisseurs de services de messagerie (MSP) (a) découragent l'utilisation 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 établies à l'aide de "TLS implicite" (tel que défini ci-dessous), de préférence à la connexion au port "en texte clair" et à la négociation du TLS à l'aide de la commande STARTTLS ou d'une commande similaire.

(emphase ajoutée)

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

Premièrement, votre résumé ne rend pas vraiment 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 souhaite utiliser et commence à parler immédiatement à TLS.
• Avec STARTTLS, le client ouvre une connexion TCP sur le "port en texte clair" associé au protocole d'application qu'il souhaite utiliser, puis demande au serveur "quelles extensions de protocole prenez-vous en charge?". Le serveur répond ensuite avec une liste d'extensions. Si l'une de ces extensions est "STARTTLS", le client peut alors dire "d'accord, utilisons TLS" et les deux personnes commencent à parler TLS.

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

Par ailleurs, si le client est configuré pour utiliser TLS uniquement lorsque ce dernier est disponible, et en texte clair lorsque TLS n’est pas disponible, le client peut commencer par essayer de se connecter au port SSL utilisé par le protocole. échoue, puis connectez-vous au port en texte clair et essayez d’utiliser STARTTLS, puis retenez-vous en texte clair si TLS n’est pas disponible dans les deux cas. Il est relativement facile pour un attaquant de faire échouer la connexion du port SSL (il suffit simplement de quelques paquets RST TCP bien synchronisés ou du blocage du port SSL). C'est un peu plus difficile - mais seulement un peu - qu'un attaquant vaince la négociation STARTTLS et fasse en sorte que le trafic reste en clair. Et ensuite, l'attaquant non seulement lira votre courrier électronique, mais capturera également votre nom d'utilisateur / mot de passe pour une utilisation ultérieure.

La réponse simple est donc que si vous vous connectez à un serveur dont vous savez déjà qu'il prend en charge le protocole TLS (comme cela devrait être le cas lorsque vous envoyez ou lisez du courrier électronique), vous devez utiliser SSL / TLS. Si la connexion est attaquée, la tentative de connexion échouera, mais votre mot de passe et votre courrier électronique 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" utilisant uniquement l'écoute étaient très courantes, les attaques "actives" dans lesquelles l'attaquant injectait du trafic pour tenter de réduire la sécurité étaient moins courantes. Depuis environ 20 ans, 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 essayez de lire votre courrier via le réseau wifi fourni, vous ne savez pas du tout ce que le réseau wifi fait avec votre trafic. Il est très courant que les réseaux wifi acheminent certains types de trafic vers des "mandataires" qui s'interposent entre vos applications clientes et les serveurs auxquels ils tentent de parler. Il est facile pour ces mandataires de désactiver STARTTLS et "essayer un port puis un autre" pour tenter de faire revenir votre client en texte en clair. Oui, cela se produit, et ce n'est qu'un exemple de la façon dont votre trafic peut être espionné par un réseau. Et de telles attaques ne se limitent pas aux agences à trois lettres soutenues par l'État,

Oui, vous avez les bases bonnes. Et oui, STARTTLS est nettement moins sécurisé. Non seulement il peut restaurer le texte en clair sans notification, mais il est également sujet aux attaques de type "man-in-the middle". Comme la connexion commence en clair, un MitM peut supprimer la commande STARTTLS et empêcher le chiffrement de se produire. Cependant, je pense que les serveurs de messagerie peuvent spécifier que les transferts ne sont effectués qu’après la configuration 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 ou l’autre côté ne prend pas en charge le cryptage, vous souhaiterez peut-être quand même que la connexion se termine correctement.

D'accord avec @Greg. Ces attaques sont possibles. Cependant, les MTA peuvent être configurés (selon le MTA) pour utiliser "TLS obligatoire" et non "TLS opportuniste". Cela signifie que TLS est utilisé et que seul TLS est utilisé (ceci inclut également STARTTLS) pour les transactions par courrier électronique. Si le MTA distant ne prend pas en charge STARTTLS, le courrier électronique est renvoyé.

Non, il n’est pas moins sécurisé, lorsque votre application le gère correctement.

Il y a quatre façons de gérer TLS et de nombreux programmes vous permettent de choisir:

• Pas de TLS
• TLS sur le port dédié (essaie seulement TLS)
• Utiliser TLS si disponible (Essaie starttls, utilise une connexion non chiffrée en cas d'échec)
• Toujours utiliser TLS (Utilise starttlset échoue si cela ne fonctionne pas)

L'avantage de TLS sur un port dédié est que vous pouvez être sûr qu'il n'y a pas de repli lorsque vous utilisez un programme que vous ne connaissez pas encore ou qui n'expose pas les paramètres de détail pour la gestion des erreurs dans son assistant de premier démarrage.

Mais en général, la sécurité dépend du traitement des erreurs de sécurité. Un programme peut décider de basculer vers le port en texte brut lorsque TLS sur le port TLS échoue également. Vous devez savoir ce qu’il fera et choisir des paramètres sécurisés. Et les programmes doivent utiliser des valeurs par défaut sûres.