Pourquoi STARTTLS est-il utilisé alors qu'il peut être déclassé très facilement?
Les gens s'embarrassent de la façon dont vous devez absolument désactiver SSLv3 car TLS peut être rétrogradé en SSLv3 et il n'y a pratiquement plus de serveur sur Internet qui parle SSLv3.
En même temps, presque tous les serveurs de messagerie prendront volontiers en charge STARTTLS, qui peut être trivialement (comme: 3 lignes de code environ) rétrogradé en texte brut.
Qu'est-ce que je rate?
Le problème que vous décrivez n'est pas l'utilisation de STARTTLS en soi mais l'utilisation facultative de STARTTLS. Les systèmes de messagerie peuvent être configurés de sorte que TLS soit requis auquel cas le courrier ne sera pas remis si STARTTLS échoue ou si l'homologue n'offre pas de support pour STARTTLS dans EHLO. STARTTLS requis est aussi sûr que TLS requis dès le début.
La raison pour laquelle STARTTLS n'est pas obligatoire dans la plupart des configurations est qu'il existe encore suffisamment de systèmes qui ne prennent pas en charge TLS. Le rapport de transparence actuel de Google affiche seulement 90% de tous les courriers envoyés de Google par TLS, ce qui signifie que 10% des courriers sont livrés à un MTA qui ne prend pas en charge TLS.
En dehors de cela, même avec TLS obligatoire, le courrier n'est pas livré de manière suffisamment sécurisée. TLS n'est utilisé qu'entre les différents tronçons lors de la remise du courrier et ne fournit pas la sécurité de bout en bout que TLS fournit dans HTTPS. Cela signifie que chaque serveur de messagerie sur le chemin a accès au texte brut du courrier et peut le lire et le modifier, à moins que le courrier ne soit en outre protégé par des protections de bout en bout comme PGP ou S/MIME.
Les attaques de déclassement sont des attaques actives.
Les attaques actives sont beaucoup plus faciles à détecter et sont généralement plus difficiles à exécuter que leurs homologues passifs.
Le chiffrement opportuniste, tel que STARTTLS en option dans SMTP, protège principalement contre surveillance passive où le trafic est indétectablement analysé pendant le transit ou stocké pour une analyse ultérieure. Vous avez parfaitement raison de dire que le chiffrement opportuniste ne protège pas contre les attaques actives. Le chiffrement opportuniste en général n'essaie tout simplement pas de se protéger contre une attaque où l'attaquant est capable et désireux de modifier les données en transit; cela dépasse sa portée. De même, STARTTLS opportuniste ne protège pas contre un serveur de messagerie non autorisé transmettant les données à un tiers; cela dépasse sa portée.
Au moins certains serveurs SMTP (le plutôt populaire Postfix étant l'un d'eux ) peuvent être configurés pour exiger TLS lors de l'envoi ( ou réception ) de courrier, globalement ou manuellement sur une base par MX pour le courrier sortant. Lorsqu'il est configuré comme cela, si STARTTLS échoue ou n'est pas disponible (quelle que soit la raison pour laquelle c'est le cas), la session SMTP peut être rejetée, en fonction de la stratégie configurée localement.
Bien que des attaques actives se produisent certainement, il y a de bonnes raisons de croire que la surveillance passive du trafic est répandue sur Internet aujourd'hui. La surveillance omniprésente est une attaque qui peut souvent, et devrait certainement si possible, être atténuée.
Par conséquent, même si le chiffrement opportuniste ne fait rien pour protéger contre les attaquants actifs, c'est une victoire car il empêche la surveillance passive du trafic et surveillance de l'apprentissage plus que nécessaire sur les données communiquées. Le même argument serait s'applique aux HTTPS non authentifiés également, dans la mesure où même s'il ne protège pas contre chaque attaque, ce serait quand même une amélioration par rapport à une communication entièrement en clair du point de vue de la confidentialité des communications. .
Il existe une norme, RFC 8461 SMTP MTA Strict Transport Security (MTA-STS) , qui peut être utilisée pour spécifier le trafic du serveur de messagerie pour un domaine donné requiert TLS. Cette norme est encore assez nouvelle (le RFC est daté de septembre 2018), donc je m'attends à ce que le support soit irrégulier, mais encore une fois, tant que tout est correctement configuré, publier une politique MTA-STS, au pire, n'entraîne aucune amélioration de la confidentialité des communications (car un MTA qui n'implémente pas MTA-STS agira simplement comme si aucune politique MTA-STS n'était publiée, tandis qu'un MTA qui le fait implémente MTA- STS pourra correctement prendre en compte la politique MTA-STS publiée pour les décisions de politique).
De plus, il existe une extension SMTP de suivi des normes, REQUIREETLS , qui peut être utilisée pour spécifier que la sécurité de la couche de transport doit être prioritaire sur la livraison des messages.
Même si des attaques de déclassement sont possibles avec un chiffrement purement opportuniste, cela ne signifie pas que le chiffrement purement opportuniste ne vaut rien. Cela signifie simplement qu'il existe des menaces qui purement le chiffrement opportuniste ne répond pas; ce qui n'est pas différent du fait qu'il existe des menaces que le cryptage requis ne résout pas.