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


45

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?

Réponses:


46

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 .


5
Votre point est certainement valable, mais en l'absence de toute spécification RFC ou officielle concernant SMTPS (c'est-à-dire SMTP + "SSL / TLS implicite" où SSL / TLS est établi en premier), les clients SMTP / SMTPS pourraient également décider de revenir à une connexion simple. S'ils ne parviennent pas à établir une connexion SSL / TLS sur le port 465. C'est toujours un choix d'implémentation.
Bruno

2
Il existe de nombreux RFC pour établir des connexions TLS. "Autoriser la connexion en texte brut" n'existe nulle part en tant qu'option pour se conformer à la RFC (du moins, ce serait une nouvelle pour beaucoup de gens). Ainsi, SMTPS ne nécessite pas de RFC distinct pour être plus sécurisé que STARTTLS.
Greg

1
Il existe des RFC sur TLS (RFC 5246 et ses prédécesseurs), PKI (RFC 5280), la vérification du nom (RFC 6125), mais rien ne permet de décrire l’interaction entre SMTP et SSL / TLS dans SMTPS officiellement, autant que possible. spécification pour HTTPS: RFC 2818. On peut dire «c’est évident, établissez d’abord la connexion SSL / TLS», mais tout n’est pas aussi évident (en particulier l’aspect vérification d’identité, récemment formalisé dans la RFC 6125).
Bruno

23

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.


2
Si la connexion est cryptée, SSL / TLS et STARTTLS sont identiques, oui. Mais ce n'est pas ce que j'ai demandé. Je voulais dire: si j'utilise STARTTLS, comment puis-je (en tant qu'utilisateur) savoir si ma connexion est vraiment sécurisée? Si j'essaie d'utiliser SSL / TLS, je ne peux tout simplement pas me connecter si le serveur ne le prend pas en charge, mais au moins rien n'est envoyé en clair. Mais si STARTTLS retombe dans le texte en clair, mon courrier est envoyé en texte en clair sans que je sache qu'il a été envoyé en texte en clair (ce qui me fait penser que je suis en sécurité alors que je ne suis pas réellement).
Foo Bar

6
Je ne sais pas pourquoi cette réponse a été choisie comme correcte. C'est faux. Comme le souligne Christopher, STARTTLS est moins sécurisé que TLS car il donne un faux sentiment de sécurité aux clients.
Greg

4
@greg il n'y a rien de mal avec le protocole. La faille concerne les clients qui ne suivent pas le rfc et ne préviennent pas l'utilisateur lorsque la connexion n'est pas cryptée.
longneck

1
@ longneck alors ... c'est peut-être une question de sémantique, mais les clients ne peuvent pas "ne pas suivre" le protocole TLS et faire passer un courrier électronique, un point c'est tout. c'est donc une différence significative.
Greg

2
@Bruno "Ce n'est que moins sécurisé si le client est mal implémenté" <= vous ne faites que me faire comprendre. S'il existe quelque chose que le client peut faire pour rendre la connexion non sécurisée tout en établissant une connexion fonctionnelle, STARTTLS est moins sécurisé qu'un TLS explicite (lorsque cela n'est pas possible).
Greg

8

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)


4

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,


1

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.


Donc, un serveur capable de STARTTLS sera aussi toujours capable de SSL / TLS, non? Donc, il est toujours préférable d'essayer d'abord SSL / TLS et de voir si cela fonctionne?
Foo Bar

2
@FooBar non, l'un n'implique pas que l'autre est disponible. En fait, ils pourraient être configurés avec des domaines d'authentification complètement différents.
Longneck

3
STARTTLS n'est pas vulnérable à MitM sauf si vous ne validez pas les certificats ou n'en utilisez pas de faibles. Le certificat est toujours présenté comme toujours, et le client peut exiger que la mise à niveau TLS réussisse avant de continuer. Il est à noter que c'est exactement la même situation que SSL / TLS.
Falcon Momot

1
Je ne sais pas pourquoi les gens votent vers vous, c'est la bonne réponse, STARTTLS est moins sécurisé que TLS et donne un faux sentiment de sécurité. Les fournisseurs de services Internet peuvent simplement le préciser: arstechnica.com/tech-policy/2014/11/…
Greg

1
En ce qui concerne le protocole lui-même, STARTTLS est moins sécurisé que TLS car il autorise explicitement la communication en texte brut sans avertir l'utilisateur: serverfault.com/a/648282/207987
Greg

1

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é.


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.