En bref, MTA-STS est un moyen de protéger davantage les e-mails contre l'interception (c'est-à-dire les attaques de l'homme du milieu, également appelées MitM) lorsqu'ils sont transmis entre des serveurs de messagerie. Il résout en partie les 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 sur RuNet à implémenter cette norme. Et cela est décrit plus en détail sous la coupe.

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

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

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

Historiquement, une attaque MitM était possible partout où le courrier circule.

La RFC 8314 nécessite l'utilisation de TLS entre l'application utilisateur de messagerie (MUA) et le serveur de messagerie. Si votre serveur et les applications de messagerie que vous utilisez sont conformes à la RFC 8314, vous avez (en grande partie) éliminé la possibilité d'attaques de type Man-in-the-Middle entre l'utilisateur et les serveurs de messagerie.

Le respect des pratiques généralement acceptées (normalisées par la RFC 8314) élimine les attaques à proximité de l'utilisateur :

Les serveurs de messagerie Mail.ru étaient conformes à la RFC 8314 avant même l'adoption de la norme ; en fait, elle capture simplement les pratiques déjà acceptées et nous n'avons rien eu à configurer de plus. Mais, si votre serveur de messagerie autorise toujours les utilisateurs utilisant des protocoles non sécurisés, veillez à mettre en œuvre les recommandations de cette norme, car Très probablement, 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 des utilisateurs non sécurisés (c'est exactement ce qu'exige la RFC 8314). C'est parfois difficile, mais faisable. Le trafic entre les serveurs de messagerie est encore plus compliqué. Les serveurs appartiennent à différentes organisations et sont souvent utilisés en mode « définir et oublier », ce qui rend impossible le passage immédiat à un protocole sécurisé sans rompre la connectivité. SMTP fournit depuis longtemps l'extension STARTTLS, qui permet aux serveurs prenant en charge le cryptage de passer à TLS. Mais un attaquant capable d'influencer le trafic peut « supprimer » les informations sur la prise en charge de cette commande et forcer les serveurs à communiquer à l'aide d'un protocole en texte brut (ce qu'on appelle l'attaque par rétrogradation). Pour la même raison, STARTTLS ne vérifie généralement pas la validité du certificat (un certificat non fiable peut protéger contre les attaques passives, et ce n'est pas pire que d'envoyer un message en texte clair). Par conséquent, STARTTLS ne protège que contre les écoutes passives.

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

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 parvient à obtenir un certificat de domaine valide auprès de l'une des autorités de certification publiques.

Comment fonctionne MTA-STS

destinataire

Configure la prise en charge de STARTTLS avec un certificat valide sur le serveur de messagerie.
Publie la politique MTA-STS via HTTPS ; un domaine mta-sts spécial et un chemin spécial connu sont utilisés pour la publication, par exemple 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.
Publie un enregistrement TXT spécial _mta-sts dans DNS avec la version de la stratégie. Lorsque la politique change, cette entrée doit être mise à jour (cela signale à l'expéditeur de réinterroger 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 disponible, effectue une demande de stratégie via HTTPS (en vérifiant le certificat). La politique résultante est mise en cache (au cas où un attaquant en bloquerait l'accès ou usurperait l'enregistrement DNS).

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

le serveur auquel le courrier est remis est dans la politique ;
le serveur accepte le courrier via TLS (STARTTLS) et dispose d'un certificat valide.

Avantages du 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 du côté destinataire, aucun support logiciel spécial pour la norme n'est requis.

Inconvénients du MTA-STS

Il est nécessaire de surveiller la validité du certificat du serveur Web et de messagerie, la correspondance des noms et son renouvellement dans les délais. Des problèmes avec le certificat entraîneront l’impossibilité de livrer le courrier.

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

MTA-STS utilise une liste d’autorités de certification racine approuvées.

MTA-STS ne protège pas contre les attaques dans lesquelles l'attaquant utilise un certificat valide. Dans la plupart des cas, MitM à proximité 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 MTA-STS moins sécurisé que la norme DANE concurrente pour SMTP (RFC 7672), mais plus fiable techniquement, c'est-à-dire pour MTA-STS, il existe une faible probabilité que la lettre ne soit pas livrée en raison de problèmes techniques causés par la mise en œuvre de la norme.

Norme concurrente - DANE

DANE utilise DNSSEC pour publier les informations de certificat et ne nécessite pas de confiance dans des autorités de certification externes, ce qui est beaucoup plus sécurisé. Mais l'utilisation du DNSSEC conduit beaucoup plus souvent à des pannes techniques, sur la base de statistiques sur plusieurs années d'utilisation (bien qu'il existe généralement une tendance positive dans la fiabilité du DNSSEC et de son support technique). Pour implémenter DANE dans SMTP côté destinataire, la présence de DNSSEC pour la zone DNS est obligatoire, et une prise en charge correcte de NSEC/NSEC3 est essentielle pour DANE, avec lequel il existe des problèmes systémiques dans DNSSEC.

Si DNSSEC n'est pas configuré correctement, cela peut entraîner des échecs de livraison 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 une norme plus ancienne et plus sécurisée et qu'elle soit déjà prise en charge dans certains logiciels serveur du côté de l'expéditeur, sa pénétration reste en fait insignifiante, de nombreuses organisations ne sont pas prêtes à la mettre en œuvre en raison de la nécessité de mettre en œuvre DNSSEC. cela a considérablement ralenti la mise en œuvre de DANE pendant toutes ces années d'existence de la norme.

DANE et MTA-STS n'entrent pas en conflit et peuvent être utilisés ensemble.

Qu'en est-il du support MTA-STS dans Mail.ru Mail ?

Mail.ru publie depuis un certain temps une politique MTA-STS pour tous les principaux domaines. Nous implémentons actuellement la partie client de la norme. Au moment de la rédaction, 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 rechange » sans appliquer de politiques), puis le mode blocage sera forcé pour une petite partie du trafic SMTP sortant, progressivement pour 100 % du trafic, l'application des politiques 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 elles protègent néanmoins déjà un volume important de trafic de messagerie, car La norme est soutenue par les principaux acteurs - Google, Comcast et en partie Verizon (AOL, Yahoo). De nombreux autres services postaux ont annoncé que la prise en charge de la norme serait mise en œuvre dans un avenir proche.

Comment cela va-t-il m'affecter ?

Non, sauf si votre domaine publie une politique MTA-STS. Si vous publiez la politique, les e-mails des utilisateurs de votre serveur de messagerie seront mieux protégés contre l'interception.

Comment implémenter MTA-STS ?

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

Il suffit de publier la politique via HTTPS et les enregistrements dans DNS, de configurer un certificat valide de l'une des autorités de certification de confiance (Let's encrypt est possible) pour STARTTLS dans le MTA (STARTTLS est pris en charge dans tous les MTA modernes), aucun support spécial de la part du Le MTA est requis.

Pas à pas, cela ressemble à ceci :

Configurez STARTTLS dans le MTA que vous utilisez (postfix, exim, sendmail, Microsoft Exchange, etc.).
Assurez-vous que vous utilisez un certificat valide (émis par une autorité de certification de confiance, non expiré, le sujet du certificat correspond à l'enregistrement MX qui délivre le courrier pour votre domaine).
Configurez un enregistrement TLS-RPT via lequel les rapports d'application de stratégie seront fournis (par les services prenant en charge l'envoi de rapports TLS). Exemple d'entrée (pour le domaine example.com) :
```
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»
```
Cette entrée demande aux expéditeurs de courrier d'envoyer des rapports statistiques sur l'utilisation de TLS dans SMTP à [email protected].

Surveillez les rapports pendant plusieurs jours pour vous assurer qu’il n’y a pas d’erreurs.
Publiez la stratégie MTA-STS via HTTPS. La politique est publiée sous forme de fichier texte avec des terminateurs de ligne CRLF par 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 STSv1), Mode définit le mode d'application de la politique, testing — mode test (la politique n'est pas appliquée), appliquer — mode « combat ». Publiez d'abord la stratégie avec mode : testing, s'il n'y a aucun problème avec la stratégie en mode test, après un certain temps, vous pouvez passer en mode : apply.

Dans mx, une liste de tous les serveurs de messagerie pouvant accepter le courrier de votre domaine est spécifiée (chaque serveur doit avoir un certificat configuré qui correspond au nom spécifié dans mx). Max_age spécifie le temps de mise en cache de la politique (une fois que la politique mémorisée sera appliquée même si l'attaquant bloque sa livraison ou corrompt les enregistrements DNS pendant le temps de mise en cache, vous pouvez signaler la nécessité de demander à nouveau la politique en modifiant le DNS mta-sts enregistrer).
Publier un enregistrement TXT dans DNS :
```
_mta-sts.example.com. TXT “v=STS1; id=someid;”
```
Un identifiant arbitraire (par exemple, un horodatage) peut être utilisé dans le champ id ; lorsque la politique change, elle devrait changer, cela permet aux expéditeurs de comprendre qu'ils doivent redemander la politique mise en cache (si l'identifiant est différent de l'identifiant mis en cache).

Prise en charge MTA-STS du côté de l'expéditeur

Jusqu'à présent, ça va mal avec elle, parce que... norme 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 décrit en détail sur Habré https://habr.com/en/post/424961/

En guise de postface sur le « TLS obligatoire »

Dernièrement, les régulateurs se sont intéressés à la sécurité du courrier électronique (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 exigé dans le secteur financier, la pénétration de la norme atteignant 90 % dans les domaines réglementés. Désormais, certains régulateurs exigent la mise en œuvre du « TLS obligatoire » avec des domaines individuels, mais le mécanisme permettant de garantir le « TLS obligatoire » n'est pas défini et, dans la pratique, ce paramètre est souvent mis en œuvre d'une manière qui ne protège même pas de manière minimale contre les attaques réelles déjà existantes. prévues dans des mécanismes tels que DANE ou MTA-STS.

Si le régulateur exige la mise en œuvre d'un « TLS obligatoire » avec des domaines séparés, nous recommandons de considérer MTA-STS ou son analogue partiel comme le mécanisme le plus approprié, cela élimine le besoin de définir des paramètres sécurisés pour chaque domaine séparément. Si vous rencontrez des difficultés pour implémenter la partie client de MTA-STS (jusqu'à ce que le protocole reçoive un large soutien, ce sera probablement le cas), nous pouvons vous recommander cette approche :

Publiez une politique MTA-STS et/ou des enregistrements DANE (DANE n'a de sens que 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. pour configurer TLS obligatoire 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 « analogue » de MTA-STS via des paramètres de transport distincts pour chaque domaine, ce qui corrigera le MX utilisé pour le relais de courrier et nécessitera la vérification obligatoire d'un certificat TLS pour celui-ci. Si les domaines publient déjà une politique MTA-STS, cela peut probablement être fait sans problème. En soi, activer TLS obligatoire pour un domaine sans réparer le relais et vérifier le certificat correspondant est inefficace du point de vue de la sécurité et n'ajoute rien aux mécanismes STARTTLS existants.

Source: habr.com

Le courrier Mail.ru commence à appliquer les politiques MTA-STS en mode test