En bref, MTA-STS est un moyen de protéger en plus les e-mails contre les interceptions (c'est-à-dire les attaques d'attaquant au milieu, également appelées MitM) lorsqu'ils sont transférés entre des serveurs de messagerie. Il résout partiellement les problèmes architecturaux hérités des protocoles de courrier électronique et est décrit dans la norme relativement récente RFC 8461. Mail.ru Mail est le premier service postal majeur de l'Internet russe à implémenter cette norme. Et il est décrit plus en détail sous la coupe.

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

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



À quoi ressemble le mécanisme de remise d'une lettre d'un utilisateur à un autre:







Historiquement, l'attaque MitM était possible partout où le courrier allait.



La RFC 8314 requiert 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 que vous utilisez sont conformes à la RFC 8314, alors vous avez (en grande partie) éliminé la possibilité d'attaques Man-in-the-Middle entre l'utilisateur et les serveurs de messagerie.



Le respect des pratiques courantes (normalisées par RFC 8314) élimine les attaques des utilisateurs proches:







Les serveurs de messagerie Mail.ru étaient conformes à la RFC 8314 avant même que la norme ne soit adoptée, en fait, elle capture simplement les pratiques déjà acceptées, et nous n'avons rien eu à configurer davantage. Mais, si votre serveur de messagerie autorise toujours les utilisateurs via des protocoles non sécurisés, assurez-vous de mettre en œuvre les recommandations de cette norme, car il est fort probable qu'au moins certains de vos utilisateurs travaillent avec du courrier sans cryptage, même si vous le prenez en charge.



Le client de messagerie fonctionne toujours avec le même serveur de messagerie de la même organisation. Et vous pouvez forcer tous les utilisateurs à se connecter de manière sécurisée, puis rendre techniquement impossible la connexion non sécurisée (c'est exactement ce qu'exige la RFC 8314). C'est parfois difficile, mais réalisable. Le trafic entre les serveurs de messagerie est encore plus compliqué. Les serveurs appartiennent à différentes organisations et sont souvent utilisés dans un mode «définir et oublier», ce qui rend impossible le passage à un protocole sécurisé à la fois sans interrompre la connectivité. SMTP a longtemps fourni l'extension STARTTLS, qui permet aux serveurs prenant en charge le chiffrement de passer à TLS. Mais un attaquant qui a la capacité d'influencer le traficpeut "couper" les informations sur le support de cette commande et forcer les serveurs à communiquer en utilisant un protocole de texte brut (l'attaque dite de rétrogradation - une attaque pour rétrograder la version du protocole). Pour la même raison, pour STARTTLS, la conformité des certificats n'est généralement pas vérifiée (un certificat non approuvé peut protéger contre les attaques passives, et ce n'est pas pire que d'envoyer un e-mail en texte clair). Par conséquent, STARTTLS protège uniquement contre les écoutes passives.



MTA-STS élimine partiellement le problème de l'interception des messages entre les serveurs de messagerie, lorsqu'un attaquant a la capacité d'influencer activement le trafic. Si le domaine du destinataire publie la stratégie MTA-STS et que le serveur de l'expéditeur prend en charge le MTA-STS, il enverra uniquement l'e-mail via une connexion TLS, uniquement aux serveurs définis par la stratégie et uniquement avec le certificat de serveur vérifié.



Pourquoi partiellement? MTA-STS ne fonctionne que si les deux parties ont pris soin de 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 de domaine valide dans l'une des CA publiques.

Comment fonctionne MTA-STS

Bénéficiaire

1. Configure la prise en charge de STARTTLS avec un certificat valide sur le serveur de messagerie. 
2. Publie la stratégie MTA-STS via HTTPS, un domaine mta-sts spécial et un chemin d'accès bien connu, par exemple, sont utilisés pour la publication https://mta-sts.mail.ru/.well-known/mta-sts.txt. La stratégie contient une liste de serveurs de messagerie (mx) qui ont le droit de recevoir du courrier pour ce domaine.
3. Publie un enregistrement TXT _mta-sts spécial dans DNS avec la version de la stratégie. Lorsque la stratégie change, cet enregistrement doit être mis à jour (cela indique à l'expéditeur de demander à nouveau la stratégie). Par exemple,_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Expéditeur L'



expéditeur demande l'enregistrement DNS _mta-sts, s'il est disponible, effectue une demande de stratégie via HTTPS (vérification du certificat). La stratégie résultante est mise en cache (au cas où un attaquant en bloque l'accès ou modifie l'enregistrement DNS).



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

• le serveur auquel le courrier est livré figure dans la stratégie;
• le serveur accepte le courrier en utilisant TLS (STARTTLS) et dispose d'un certificat valide.

Avantages de MTA-STS

MTA-STS utilise des technologies déjà implémentées dans la plupart des organisations (SMTP + STARTTLS, HTTPS, DNS). Pour la mise en œuvre côté destinataire, aucune prise en charge logicielle spéciale pour la norme n'est requise.

Inconvénients de MTA-STS

Il est nécessaire de surveiller la validité du certificat du serveur Web et de messagerie, la correspondance des noms et le renouvellement en temps opportun. Des problèmes avec le certificat rendront impossible la livraison du courrier.



Du côté de l'expéditeur, un MTA prenant en charge les stratégies MTA-STS est requis, actuellement hors de la boîte MTA-STS n'est pas pris en charge dans le MTA.



MTA-STS utilise une liste d'autorités de certification racines de confiance.



MTA-STS ne protège pas contre les attaques dans lesquelles l'attaquant utilise un certificat valide. Dans la plupart des cas, MitM près du serveur implique la possibilité d'émettre un certificat. Une telle attaque peut être détectée grâce à la transparence des certificats. Par conséquent, 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 le MTA-STS moins sûr que le standard concurrent DANE pour SMTP (RFC 7672), mais plus sécurisé techniquement, c.-à-d. pour le MTA-STS, il y a une faible probabilité que la lettre ne soit pas livrée en raison de problèmes techniques causés par la mise en œuvre standard.

Norme concurrente - DANE

DANE utilise DNSSEC pour publier les informations de certificat et ne nécessite pas de confiance dans les autorités de certification externes, ce qui est beaucoup plus sécurisé. Mais l'utilisation de DNSSEC est nettement plus susceptible d'entraîner des pannes techniques, si l'on s'appuie sur des statistiques sur plusieurs années d'utilisation (bien qu'il y ait une tendance positive dans la fiabilité de DNSSEC et de son support technique en général). Pour implémenter DANE dans SMTP côté destinataire, la présence de DNSSEC pour la zone DNS est obligatoire, et pour DANE il est essentiel d'avoir un support correct pour NSEC / NSEC3, avec lequel DNSSEC a des problèmes systémiques.



Si DNSSEC est configuré avec des erreurs, cela peut conduire à des refus de remise du courrier si le côté expéditeur prend en charge DANE, même si le côté destinataire n'en sait rien. Par conséquent, malgré le fait que DANE soit un standard plus ancien et plus sécurisé et qu'il soit déjà pris en charge dans certains logiciels serveur du côté de l'expéditeur, en fait sa pénétration reste insignifiante, de nombreuses organisations ne sont pas prêtes à l'implémenter en raison de la nécessité de mettre en œuvre DNSSEC, ce qui a considérablement ralenti la mise en œuvre de DANE. toutes ces années que la norme existe.



DANE et MTA-STS ne sont pas en conflit l'un avec l'autre et peuvent être utilisés ensemble.

À quoi sert la prise en charge MTA-STS dans Mail.ru Mail

Mail.ru publie depuis un certain temps déjà la politique MTA-STS pour tous les principaux domaines. Nous mettons actuellement en œuvre le côté client de la norme. Au moment de la rédaction de cet article, les politiques sont appliquées en mode non bloquant (si la livraison est bloquée par une politique, la lettre sera livrée via un serveur de «sauvegarde» sans appliquer de politiques), puis le mode de blocage sera forcé pour une petite partie du trafic SMTP sortant, progressivement pour 100% du trafic l'application de la politique est prise en charge.

Qui d'autre soutient la norme

Jusqu'à présent, les politiques MTA-STS publient environ 0,05% des domaines actifs, mais, néanmoins, elles protègent déjà un grand volume de trafic de messagerie, car la norme est prise en charge par les principaux acteurs - Google, Comcast et partiellement Verizon (AOL, Yahoo). De nombreux autres services postaux ont annoncé que le soutien de la norme sera mis en œuvre dans un proche avenir.

Comment cela m'affectera-t-il?

Rien si votre domaine ne publie pas la stratégie MTA-STS. Si vous publiez la stratégie, les messages destinés aux utilisateurs de votre serveur de messagerie seront mieux protégés contre les interceptions.

Comment implémenter MTA-STS?

Prise en charge du MTA-STS côté destinataire



Il suffit de publier la stratégie via les enregistrements HTTPS et DNS, de configurer un certificat valide de l'une des autorités de certification de confiance (chiffrons) pour STARTTLS dans le MTA (STARTTLS est pris en charge dans tous les MTA modernes), aucune prise en charge spéciale du MTA n'est requise ...



Étape par étape, cela ressemble à ceci:

1. Configurez STARTTLS dans le MTA que vous utilisez (postfix, exim, sendmail, Microsoft Exchange, etc.).
2. , ( CA, , MX-, ).
3. TLS-RPT , ( TLS). ( example.com):
   
   
   
   

   smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:tlsrpt@example.com»

   
   
   TLS SMTP tlsrpt@exmple.com.
   
   
   
   , .
4. MTA-STS HTTPS. CRLF .
   
   
   
   

   https://mta-sts.example.com/.well-known/mta-sts.txt
   

   
   
   :
   
   
   
   

   version: STSv1
   mode: enforce
   mx: mxs.mail.ru
   mx: emx.mail.ru
   mx: mx2.corp.mail.ru
   max_age: 86400
   

   
   
   version ( STSv1), Mode , testing — ( ), enforce — «» . mode: testing, , mode: enforce.
   
   
   
   mx , ( , mx). Max_age ( DNS- , mta-sts DNS).
5. Publiez l'enregistrement TXT sur DNS: 
   
   
   
   

   _mta-sts.example.com. TXT “v=STSv1; id=someid;”
   

   
   
   Dans le champ id, vous pouvez utiliser un identifiant arbitraire (par exemple, un horodatage), lors du changement de politique, il doit changer, cela permet aux expéditeurs de comprendre qu'ils doivent redemander la politique mise en cache (si l'identifiant est différent de celui mis en cache).

Prise en charge du MTA-STS chez l'expéditeur



Alors qu'il est mauvais, car la norme est fraîche.

• Exim - pas de support intégré, il existe un script tiers https://github.com/Bobberty/MTASTS-EXIM-PERL 
• Postfix - il n'y a pas de support intégré, il existe un script tiers qui est décrit en détail sur Habré https://habr.com/fr/post/424961/

Comme postface sur "TLS obligatoire"

Les régulateurs se sont penchés récemment sur la sécurité des e-mails (et c'est une bonne chose). Par exemple, le DMARC est obligatoire pour toutes les agences gouvernementales aux États-Unis et est de plus en plus nécessaire dans le secteur financier; dans les zones réglementées, la pénétration de la norme atteint 90%. Maintenant, certains régulateurs exigent la mise en œuvre de "TLS obligatoire" avec des domaines séparés, mais en même temps, le mécanisme pour garantir le "TLS obligatoire" n'est pas défini, et dans la pratique, ce paramètre est souvent mis en œuvre de telle manière que même de manière minimale ne protège pas contre les attaques réelles, qui sont déjà prévues dans des mécanismes tels DANE ou MTA-STS.



Si le régulateur exige la mise en œuvre de "TLS obligatoire" avec des domaines séparés, nous vous recommandons de considérer MTA-STS ou son équivalent partiel comme le mécanisme le plus approprié, il élimine le besoin de faire des réglages sécurisés pour chaque domaine séparément. Si vous rencontrez des difficultés avec la mise en œuvre du côté client de MTA-STS (jusqu'à ce que le protocole ait reçu une prise en charge généralisée, elles le seront probablement), vous pouvez recommander cette approche:

1. Publiez la politique MTA-STS et / ou les enregistrements DANE (il est logique d'ajouter DANE uniquement si DNSSEC est déjà activé pour votre domaine, et MTA-STS dans tous les cas), cela protégera le trafic dans votre direction et éliminera le besoin de demander à d'autres services de messagerie de configurer le TLS obligatoire pour votre domaine si le service postal prend déjà en charge MTA-STS et / ou DANE.
2. «» MTA-STS , MX TLS-. MTA-STS, , , . TLS STARTTLS.