En résumé, MTA-STS est un moyen de protéger davantage les courriers électroniques contre l'interception (c'est-à-dire les attaques de type homme du milieu, aka MitM) lors de leur transmission entre serveurs de messagerie. Il aborde partiellement des problèmes architecturaux hérités des protocoles de messagerie et est décrit dans la norme relativement récente RFC 8461. Mail.ru est le premier service de messagerie majeur en Runet à mettre en œuvre cette norme. Une explication plus détaillée est fournie ci-dessous.

Quel problème MTA-STS résout-il ?

Historiquement, les protocoles de messagerie (SMTP, POP3, IMAP) transmettaient des informations en clair, ce qui permettait de les intercepter, par exemple lors de l'accès au canal de communication.

Comment se déroule le mécanisme de livraison d'un courrier d'un utilisateur à un autre :

Historiquement, les attaques de type MitM étaient possibles à tous les endroits où circulent les courriers.

La norme RFC 8314 impose l'utilisation obligatoire de TLS entre le programme de messagerie de l'utilisateur (MUA) et le serveur de messagerie. Si votre serveur et les applications de messagerie utilisées respectent la RFC 8314, vous avez (dans une large mesure) éliminé la possibilité d'attaques de type homme du milieu entre l'utilisateur et les serveurs de messagerie.

Le respect des pratiques communes (normes RFC 8314) élimine l'attaque à proximité de l'utilisateur :

Les serveurs de messagerie Mail.ru respectaient la RFC 8314 bien avant l'adoption de la norme, en fait, elle ne fixe que des pratiques déjà établies, et nous n'avons rien dû configurer de plus. Cependant, si votre serveur de messagerie permet toujours aux utilisateurs d'accéder via des protocoles non sécurisés, assurez-vous de mettre en œuvre les recommandations de cette norme, car il est probable qu'une partie de vos utilisateurs travaille avec leur messagerie sans cryptage, même si vous le supportez.

Le client de messagerie travaille toujours avec le même serveur de messagerie de la même organisation. Il est possible d'obliger tous les utilisateurs à se connecter de manière sécurisée, rendant ainsi techniquement impossible la connexion de manière non sécurisée (c'est précisément ce que requiert la RFC 8314). Cela peut parfois être difficile, mais réalisable. La gestion du trafic entre les serveurs de messagerie est encore plus complexe. Les serveurs appartiennent à différentes organisations et sont souvent utilisés en mode « installé et oublié », ce qui rend impossible un basculement immédiat vers un protocole sécurisé sans rompre la continuité. Le protocole SMTP prévoit depuis longtemps une extension STARTTLS, permettant aux serveurs prenant en charge le chiffrement de basculer vers TLS. Cependant, un attaquant qui peut influencer le trafic peut « couper » les informations relatives à la prise en charge de cette commande et forcer les serveurs à communiquer par le protocole texte normal (ce qu'on appelle une attaque de rétrogradation). Pour cette même raison, la conformité du certificat n'est généralement pas vérifiée pour STARTTLS (un certificat non fiable peut protéger contre les attaques passives, ce qui n'est pas mieux que d'envoyer un message en texte clair). Ainsi, STARTTLS ne protège que contre l'écoute passive.

MTA-STS atténue partiellement le problème d'interception des e-mails entre les serveurs de messagerie lorsque l'attaquant a la possibilité d'influencer activement le trafic. Si le domaine du destinataire publie une politique MTA-STS et que le serveur expéditeur prend en charge MTA-STS, il n'enverra l'e-mail que par une connexion TLS, uniquement vers les serveurs spécifiés par la politique et uniquement après vérification du certificat serveur.

Pourquoi partiellement ? MTA-STS fonctionne uniquement si les deux parties ont veillé à mettre en œuvre cette norme, et MTA-STS ne protège pas contre les scénarios dans lesquels un attaquant a la possibilité d'obtenir un certificat valide pour le domaine auprès d'une autorité de certification publique.

Comment fonctionne MTA-STS

Destinataire

Configure le support de STARTTLS avec un certificat valide sur le serveur de messagerie.
Publie une politique MTA-STS via HTTPS, un domaine spécial mta-sts et un chemin bien connu sont utilisés pour la publication, par exemple https://mta-sts.mail.ru/.well-known/mta-sts.txt. La politique contient une liste des serveurs de messagerie (mx) autorisés à recevoir des e-mails pour ce domaine.
Publie un enregistrement TXT spécial _mta-sts dans le DNS avec une version de politique. Lorsque la politique change, cet enregistrement doit être mis à jour (cela signale à l'expéditeur qu'il doit redemander la politique). Par exemple, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Expéditeur

L'expéditeur demande l'enregistrement DNS _mta-sts, et s'il est présent, effectue une requête de politique via HTTPS (en vérifiant le certificat). La politique obtenue est mise en cache (au cas où un attaquant bloquerait l'accès ou substituerait l'enregistrement DNS).

Lors de l'envoi de courriels, il est vérifié que :

le serveur sur lequel le mail est livré est dans la politique ;
le serveur accepte les mails en utilisant TLS (STARTTLS) et a un certificat valide.

Avantages de MTA-STS

MTA-STS utilise des technologies déjà mises en œuvre dans la plupart des organisations (SMTP+STARTTLS, HTTPS, DNS). Aucune prise en charge logicielle spéciale du standard n'est requise du côté du destinataire.

Inconvénients de MTA-STS

Il est nécessaire de surveiller la validité du certificat des serveurs web et mail, la correspondance des noms et les mises à jour en temps voulu. Des problèmes de certificat empêcheront la livraison du mail.

Du côté de l'expéditeur, un MTA prenant en charge les politiques MTA-STS est requis, pour l'instant MTA-STS n'est pas pris en charge par défaut dans le MTA.

MTA-STS utilise une liste de CA racines de confiance.

MTA-STS ne protège pas contre les attaques où l'attaquant utilise un certificat valide. Dans la plupart des cas, un MitM près du serveur implique la possibilité de délivrer un certificat. Une telle attaque peut être détectée grâce à la transparence des certificats. Ainsi, en général, MTA-STS atténue, mais n'élimine pas complètement la possibilité d'interception du trafic.

Les deux derniers points rendent MTA-STS moins sécurisé que le standard concurrent DANE pour SMTP (RFC 7672), mais techniquement plus fiable, c'est-à-dire qu'avec MTA-STS, il y a peu de chances que le mail ne soit pas livré en raison de problèmes techniques causés par l'implémentation du standard.

Le standard concurrent est DANE

DANE utilise DNSSEC pour publier des informations sur les certificats et ne nécessite pas de confiance envers des autorités de certification externes, ce qui est beaucoup plus sécurisé. Cependant, l'utilisation de DNSSEC entraîne beaucoup plus souvent des pannes techniques, selon les statistiques des années d'utilisation (bien que la fiabilité de DNSSEC et son support technique aient globalement montré une tendance positive). Pour effectuer DANE dans SMTP, la présence de DNSSEC pour la zone DNS est obligatoire du côté du destinataire, et il est crucial que DANE soit correctement pris en charge par NSEC/NSEC3, avec laquelle DNSSEC rencontre des problèmes systémiques.

Si DNSSEC est configuré de manière erronée, cela peut entraîner des échecs de livraison de mails, si le côté expéditeur prend en charge DANE, même si le côté destinataire n'en sait rien. Donc, bien que DANE soit un standard plus ancien et sécurisé, et déjà supporté dans certains logiciels serveur côté expéditeur, en pratique sa pénétration reste insignifiante, de nombreuses organisations ne sont pas prêtes à l'adopter en raison de la nécessité de mettre en œuvre DNSSEC, ce qui a considérablement retardé l'adoption de DANE toutes ces années durant lesquelles le standard existe.

DANE et MTA-STS ne sont pas en conflit et peuvent être utilisés ensemble.

Quel soutien y a-t-il pour MTA-STS dans Mail.ru

Mail.ru publie déjà depuis assez longtemps la politique MTA-STS pour tous les principaux domaines. Nous nous occupons actuellement de la mise en œuvre de la partie client du standard. Au moment de la rédaction de cet article, les politiques sont appliquées en mode non bloquant (dans le cas où la livraison est bloquée par la politique, le mail sera livré via un serveur de secours sans appliquer de politiques), puis le mode bloquant sera progressivement appliqué pour une petite partie du trafic SMTP sortant, avant que 100 % du trafic ne soit concerné par l'application des politiques.

Qui d'autre prend en charge le standard

Actuellement, environ 0,05 % des domaines actifs publient des politiques MTA-STS, mais néanmoins, elles protègent déjà un grand volume de trafic postal, car le standard est soutenu par de grands acteurs — Google, Comcast et partiellement Verizon (AOL, Yahoo). De nombreux autres services de messagerie ont déclaré que le soutien à ce standard sera mis en œuvre dans un avenir proche.

Comment cela m'affectera-t-il ?

Aucune, si votre domaine ne publie pas de politique MTA-STS. Si vous publiez une politique, les courriers destinés aux utilisateurs de votre serveur de messagerie seront mieux protégés contre l'interception.

Comment mettre en œuvre MTA-STS ?

Support MTA-STS du côté du destinataire

Il suffit de publier une politique via HTTPS et des enregistrements DNS, de configurer un certificat valide émis par l'un des CA de confiance (Let’s Encrypt est une option) pour STARTTLS dans MTA (STARTTLS est pris en charge par tous les MTA modernes), aucune prise en charge spéciale du MTA n'est requise.

En étapes, cela se présente ainsi :

Configurez STARTTLS dans le MTA utilisé (postfix, exim, sendmail, Microsoft Exchange, etc.).
Assurez-vous qu'un certificat valide est utilisé (délivré par un CA de confiance, non expiré, le sujet du certificat correspond à l'enregistrement MX sous lequel les courriers sont livrés pour votre domaine).
Configurez un enregistrement TLS-RPT où seront envoyés les rapports sur l'application des politiques (via des services prenant en charge l'envoi de rapports TLS). Exemple d'enregistrement (pour le domaine example.com) :
```
smtp._tls.example.com. 300 IN TXT "v=TLSRPTv1;rua=mailto:tlsrpt@example.com"
```
Cet enregistrement instructe les expéditeurs de courriers à envoyer des rapports statistiques sur l'utilisation de TLS dans SMTP à l'adresse tlsrpt@exmple.com.
Surveillez les rapports pendant quelques jours, assurez-vous qu'il n'y a pas d'erreurs.
Publiez la politique MTA-STS via HTTPS. La politique est publiée sous forme de fichier texte avec des terminators de lignes CRLF à l'emplacement.
```
https://mta-sts.example.com/.well-known/mta-sts.txt
```
Exemple de politique :
```
version: STSv1
mode: enforce
mx: mxs.mail.ru
mx: emx.mail.ru
mx: mx2.corp.mail.ru
max_age: 86400
```
Le champ version contient la version de la politique (actuellement c'est STSv1), Mode définit le mode d'application de la politique, testing — mode d'essai (la politique n'est pas appliquée), enforce — mode « production ». Publiez d'abord la politique avec mode: testing, s'il n'y a pas de problèmes avec la politique en mode test, vous pourrez ensuite passer au mode: enforce après un certain temps.
Dans mx, indiquez la liste de tous les serveurs de messagerie pouvant recevoir des courriers pour votre domaine (chaque serveur doit avoir un certificat configuré correspondant au nom spécifié dans mx). Max_age définit le temps de mise en cache de la politique (une politique mémorisée sera appliquée même si un attaquant bloque son envoi ou altère les enregistrements DNS pendant la période de mise en cache, la nécessité d'une nouvelle requête pour la politique peut être signalée en modifiant l'enregistrement mta-sts DNS).
Publiez un enregistrement TXT dans DNS :
```
_mta-sts.example.com. TXT "v=STS1; id=someid;"
```
Le champ id peut contenir un identifiant arbitraire (par exemple, un horodatage). Lors de la modification de la politique, il doit être modifié, ce qui permet aux expéditeurs de comprendre qu'il est nécessaire de redemander la politique mise en cache (si l'identifiant est différent de celui qui est mis en cache).

Support de MTA-STS du côté de l'expéditeur

Pour le moment, c'est difficile, car la norme est récente.

Exim — pas de support intégré, il existe un script tiers https://github.com/Bobberty/MTASTS-EXIM-PERL
Postfix — pas de support intégré, il existe un script tiers dont il a été longuement question sur Habré https://habr.com/en/post/424961/

En guise de post-scriptum sur le « mandatory TLS »

Récemment, les régulateurs portent une attention particulière à la sécurité des e-mails (et c'est bien). Par exemple, DMARC est obligatoire pour tous les organismes gouvernementaux aux États-Unis et est de plus en plus requis dans le secteur financier ; dans les secteurs réglementés, l'adoption de la norme atteint 90 %. Actuellement, certains régulateurs exigent l'implémentation du « mandatory TLS » pour des domaines spécifiques, mais le mécanisme d'application du « mandatory TLS » n'est pas défini, et dans la pratique, cette configuration est souvent mise en œuvre d'une manière qui ne protège même pas minimalement contre les attaques réelles, qui sont déjà prises en compte dans des mécanismes tels que DANE ou MTA-STS.

Si un régulateur exige la mise en œuvre du « mandatory TLS » pour des domaines spécifiques, nous recommandons d'envisager MTA-STS ou son analogue partiel comme le mécanisme le plus approprié, car il élimine la nécessité de faire des configurations sécurisées pour chaque domaine individuellement. Si vous rencontrez des difficultés dans l'implémentation de la partie client MTA-STS (tant que le protocole n'a pas obtenu un large soutien, elles seront probablement présentes), une approche recommandée est la suivante :

Publiez une politique MTA-STS et/ou des enregistrements DANE (DANE a un sens n'être ajouté que si votre domaine a déjà DNSSEC activé, tandis que MTA-STS le devra de toute façon), cela protégera le trafic vers votre serveur et évitera de devoir demander à d'autres services de messagerie de configurer le mandatory TLS pour votre domaine, si le service de messagerie prend déjà en charge MTA-STS et/ou DANE.
Pour les grands services de messagerie, implémentez un « équivalent » de MTA-STS via des paramètres de transport distincts pour chaque domaine, qui enregistreront le MX utilisé pour le relayage des courriels et exigeront une vérification obligatoire du certificat TLS. Si les domaines publient déjà une politique MTA-STS, cela peut généralement être effectué sans douleur. Activer simplement le TLS obligatoire pour un domaine sans enregistrer le relayage ni vérifier le certificat n'est pas efficace du point de vue de la sécurité et n'ajoute rien aux mécanismes STARTTLS existants.

Source : habr.com

Mail.ru commence à appliquer en mode test des politiques MTA-STS