STARTTLS est-il moins sûr que TLS / SSL?
Dans Thunderbird (et je suppose que dans de nombreux autres clients aussi), j'ai la possibilité de choisir entre "SSL/TLS" et "STARTTLS".
Si je comprends bien, "STARTTLS" signifie en termes simples "crypter si les deux extrémités prennent en charge TLS, sinon ne cryptez pas le transfert" . Et "SSL/TLS" signifie en termes simples "toujours crypter 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 revenir au texte en clair sans m'en avertir?
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 permettrai au RFC de parler pour lui-même, avec les quatre bits pertinents mis en évidence en [~ # ~] bold [~ # ~] :
Une attaque d'homme au milieu peut être lancée en supprimant la réponse "250 STARTTLS" du serveur. Cela empêcherait le client d'essayer de démarrer une session TLS. Une autre attaque man-in-the-middle consiste à permettre au serveur d'annoncer sa capacité STARTTLS, mais à modifier la demande du client de 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 la négociation TLS réussie d'une suite de chiffrement appropriée pour les hôtes sélectionnés avant les messages peut être transféré avec succès. L'option supplémentaire d'utiliser TLS dans la mesure du possible DEVRAIT également être fournie. Une implémentation [~ # ~] peut [~ # ~] permettre d'enregistrer que TLS a été utilisé pour communiquer avec un pair donné et générer un avertissement s'il n'est pas utilisé dans 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 voir, le RFC lui-même déclare (pas très clairement, mais assez clairement) qu'il n'y a RIEN obligeant les clients à établir une connexion sécurisée et à informer les utilisateurs en cas d'échec d'une connexion sécurisée. Il explicitement donne aux clients la possibilité d'établir silencieusement texte brut connexions.
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 déjà 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 la prise en charge 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 la négociation pour le chiffrement. Tout cela peut se produire (et se produit généralement) sur le port SMTP standard de 25, en partie pour des raisons de compatibilité descendante, mais aussi pour permettre un cryptage opportuniste entre les points de terminaison qui le prennent en charge 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 peut être interprété comme non sécurisé si l'utilisateur ou l'administrateur suppose que la connexion est chiffrée mais ne l'a pas réellement configurée pour exiger le chiffrement. Cependant, le cryptage utilisé est exactement le même que SSL/TLS et donc pas plus ou moins vulnérable à une attaque 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 que "TLS implicite" soit utilisé de préférence au mécanisme STARTTLS pour les soumissions IMAP, POP3 et SMTP.
En bref, cette note recommande maintenant que:
- TLS version 1.2 ou supérieure doit ê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 de protocoles en texte clair pour l'accès au courrier et la soumission de 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 "TLS implicite" (tel que défini ci-dessous), de préférence à connexion au port "cleartext" et négociation de TLS à l'aide de la commande STARTTLS ou une commande similaire.
(pas d'italique dans l'original)
La réponse dépend dans une certaine mesure de ce que vous entendez par "sûr".
Tout d'abord, votre résumé ne saisit pas vraiment la différence entre SSL/TLS et STARTTLS.
- Avec SSL/TLS, le client ouvre une connexion TCP au "port SSL" affecté au protocole d'application qu'il souhaite utiliser et commence à parler TLS immédiatement.
- Avec STARTTLS, le client ouvre une connexion TCP au "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 "okay, utilisons TLS" et les deux commencent à parler TLS.
Si le client est configuré pour nécessiter TLS, les deux approches sont plus ou moins également sûres. 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 STARTTLS d'obtenir ces détails.
D'un autre côté, si le client est configuré pour utiliser TLS uniquement lorsque TLS est disponible et utiliser du texte clair lorsque TLS n'est pas disponible, ce que le client peut faire, c'est d'abord essayer de se connecter au port SSL utilisé par le protocole, et si cela échoue, puis connectez-vous au port en texte clair et essayez d'utiliser STARTTLS, et enfin retombez en texte clair si TLS n'est pas disponible dans les deux cas. Il est assez facile pour un attaquant de faire échouer la connexion du port SSL (il suffit de quelques TCP RST TCP ou blocage du port SSL). C'est un peu plus difficile - mais seulement un petit peu - pour qu'un attaquant puisse déjouer la négociation STARTTLS et faire en sorte que le trafic reste en texte clair. Ensuite, l'attaquant peut non seulement lire votre e-mail, mais également capturer votre nom d'utilisateur/mot de passe pour une utilisation future.
Donc, la réponse simple est que si vous vous connectez à un serveur que vous connaissez déjà prend en charge TLS (comme cela 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 e-mail ne seront pas compromis.
D'un autre côté, 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 en écoute uniquement "passives" é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 une vingtaine d'années, 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 wifi qui y est fourni, vous n'avez aucune idée de ce que ce réseau wifi fait avec votre trafic. Il est très courant que les réseaux wifi acheminent certains types de trafic vers des "proxys" qui s'interposent entre vos applications clientes et les serveurs avec lesquels ils essaient de parler. Il est trivial pour ces mandataires de désactiver à la fois STARTTLS et "essayez un port puis un autre" pour tenter de faire revenir votre client en texte 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 ces attaques ne se limitent pas aux agences à trois lettres soutenues par l'État, elles peuvent être arrachées par un adolescent avec un ordinateur de 35 $ caché quelque part dans un lieu public.
D'accord avec @Greg. Ces attaques sont possibles. Cependant, les MTA peuvent être configurés (selon le MTA) pour utiliser "TLS obligatoire", pas "TLS opportuniste". Cela signifie que TLS et uniquement TLS est utilisé (cela inclut également STARTTLS) pour les transactions par courrier électronique. Si le MTA distant ne prend pas en charge STARTTLS, l'e-mail est renvoyé.
Oui, vous avez les bases. Et oui, STARTTLS est définitivement moins sécurisé. Non seulement il peut être restauré en texte brut sans notification, mais parce qu'il est soumis à des attaques man-in-the-middle. Étant donné que la connexion commence en clair, un MitM peut supprimer la commande STARTTLS et empêcher le chiffrement de se produire. Cependant, je crois que les serveurs de messagerie peuvent spécifier que les transferts ne se produisent qu'après la configuration d'un tunnel crypté. Vous pouvez donc contourner ce problème.
Alors pourquoi une telle chose existe-t-elle même? Pour des raisons de compatibilité. Si l'un ou l'autre côté ne prend pas en charge le cryptage, vous souhaiterez peut-être que la connexion se termine correctement.
Non, c'est pas moins sûr, lorsque votre application le gère correctement.
Il existe 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 uniquement TLS)
- Utiliser TLS si disponible (Tries
starttls, utilise une connexion non cryptée en cas d'échec) - Utilisez toujours 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 solution de rechange 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 pourrait 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ûrs. Et les programmes doivent utiliser des valeurs par défaut sûres.