En 2015, des chercheurs ont démontré quelque chose qui aurait dû terrifier toute entreprise traitant des emails sensibles : ils pouvaient intercepter des emails entre de grandes entreprises en exploitant une faiblesse fondamentale dans la façon dont les serveurs de messagerie négocient le chiffrement. L’attaque était d’une élégance simple. Quand deux serveurs de messagerie se connectent, ils tentent de passer à une connexion chiffrée via STARTTLS. Mais si un attaquant s’interpose entre eux, il peut simplement supprimer l’offre de chiffrement, forçant les deux serveurs à communiquer en texte en clair.
Les serveurs ne se plaignent pas. Ils n’alertent personne. Ils haussent les épaules et envoient vos contrats confidentiels, dossiers médicaux et relevés financiers sur Internet en texte en clair, lisibles par quiconque observe le trafic.
MTA-STS—Mail Transfer Agent Strict Transport Security—existe précisément pour empêcher ce scénario.
Le problème de STARTTLS
Pour comprendre pourquoi MTA-STS est important, vous devez comprendre comment le chiffrement des emails fonctionne généralement — et pourquoi il est étonnamment fragile.
Quand votre serveur de messagerie veut livrer un email à un autre domaine, il se connecte au serveur de messagerie du destinataire sur le port 25. Cette connexion initiale n’est pas chiffrée. Les serveurs négocient alors : « Hé, supportes-tu le chiffrement ? » Si les deux parties sont d’accord, elles passent à TLS et poursuivent de manière sécurisée.
C’est ce qu’on appelle le chiffrement opportuniste, et il a une faille fatale. La négociation se fait sur un canal non chiffré. Un attaquant menant une attaque de type man-in-the-middle peut intercepter le message « Je supporte TLS » et le remplacer par « Je ne supporte pas TLS ». Les deux serveurs pensent que l’autre ne peut pas faire de chiffrement, et ils poursuivent en texte en clair.
Ce n’est pas théorique. Des chercheurs en sécurité ont documenté des FAI et des États-nations pratiquant activement ces attaques de rétrogradation. Dans certains pays, c’est routinier. Votre email peut être chiffré quand il quitte votre serveur et chiffré quand il arrive à destination, mais quelque part au milieu, quelqu’un a lu chaque mot.
Comment MTA-STS corrige le problème
MTA-STS adopte une approche simple : il permet aux propriétaires de domaines de publier une politique disant « exigez toujours TLS lors de la livraison de courrier vers nous, et voici exactement quels serveurs doivent être utilisés ».
La politique est publiée à deux endroits. D’abord, un enregistrement DNS annonce que le domaine utilise MTA-STS. Ensuite, un fichier de politique hébergé via HTTPS précise les exigences exactes. La partie HTTPS est cruciale — cela signifie que la politique elle-même est livrée sur un canal chiffré et authentifié qui ne peut pas être altéré.
Lorsqu’un serveur de messagerie expéditeur veut livrer vers un domaine avec MTA-STS activé, il commence par vérifier la présence de l’enregistrement DNS. S’il est présent, il récupère le fichier de politique via HTTPS. La politique lui dit : exiger TLS version 1.2 ou supérieure, vérifier que le certificat correspond à ces modèles, et ne se connecter qu’à ces serveurs de messagerie spécifiques.
Si l’une de ces exigences ne peut pas être satisfaite — si la connexion ne peut pas être chiffrée, si le certificat est invalide, si le nom du serveur ne correspond pas — le serveur expéditeur refuse de livrer l’email. Il ne revient pas au texte en clair. Il échoue de manière visible.
Mettre en place MTA-STS
Implémenter MTA-STS nécessite trois composants : un enregistrement DNS, un fichier de politique et un serveur web pour héberger cette politique.
L’enregistrement DNS est un enregistrement TXT à _mta-sts.yourdomain.com. Il ressemble à ceci : "v=STSv1; id=20240115". Le champ 'id' est un identifiant de version — vous le modifiez chaque fois que vous mettez à jour votre politique, ce qui indique aux serveurs expéditeurs de récupérer la nouvelle version.
Le fichier de politique se trouve à https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Notez le sous-domaine — vous avez besoin d’un certificat HTTPS valide pour mta-sts.yourdomain.com. Le fichier contient votre politique au format texte simple.
Une politique typique spécifie la version, le mode (testing ou enforce), la durée maximale en secondes pendant laquelle les expéditeurs doivent mettre en cache la politique, et les noms d’hôte MX valides pour votre domaine. Le max_age est important — des valeurs plus longues offrent une meilleure protection contre les attaques mais une récupération plus lente si vous devez changer quelque chose.
Testing vs enforcing mode
MTA-STS prend en charge deux modes, et la différence est énorme.
En mode test, les serveurs expéditeurs récupèrent et évaluent votre politique, mais ne l’appliquent pas réellement. Si une connexion échouerait à la politique, ils livrent l’email quand même — mais ils envoient un rapport expliquant ce qui s’est passé. Cela vous permet d’identifier les problèmes avant qu’ils ne causent des échecs de livraison.
En mode d’application, la politique est obligatoire. Les connexions qui ne répondent pas aux exigences échouent, et l’email n’est pas livré. C’est une protection réelle, mais c’est aussi un vrai risque si votre politique est erronée.
L’approche intelligente consiste à commencer en mode test avec un max_age court. Surveillez les rapports pendant quelques semaines. Repérez les serveurs de messagerie légitimes qui ne peuvent pas répondre à vos exigences — peut-être un ancien système partenaire avec une implémentation TLS obsolète, ou un MX de secours mal configuré. Corrigez ces problèmes, puis passez en mode d’application avec un max_age plus long.
Le volet reporting : TLSRPT
MTA-STS fonctionne de concert avec TLSRPT — TLS Reporting. Il s’agit d’un enregistrement DNS séparé qui indique aux serveurs expéditeurs où envoyer les rapports sur les tentatives de connexion TLS.
Les rapports incluent les succès et les échecs : quels serveurs se sont connectés, quelle version de TLS ils ont utilisée, si la validation du certificat a réussi, et en cas d’échec, pourquoi. Cette visibilité est inestimable. Sans elle, vous avancez à l’aveugle — vous ne saurez pas si des attaquants tentent des rétrogradations, ou si des expéditeurs légitimes rencontrent des problèmes.
La mise en place de TLSRPT est simple : ajoutez un enregistrement TXT à _smtp._tls.yourdomain.com indiquant où envoyer les rapports. Vous pouvez les recevoir par email ou via HTTPS POST. Plusieurs services agrègent et visualisent ces rapports pour vous, ce qui facilite grandement la détection de tendances.
Erreurs d’implémentation courantes
L’erreur MTA-STS la plus fréquente concerne les certificats. Votre sous-domaine mta-sts a besoin d’un certificat valide, et vos serveurs de messagerie ont besoin de certificats valides avec des noms d’hôte qui correspondent à votre politique. Let's Encrypt facilite cela, mais vous devez penser à inclure le sous-domaine mta-sts dans votre processus de renouvellement de certificats.
Un autre problème courant est la discordance des enregistrements MX. Votre politique MTA-STS liste des noms d’hôte spécifiques, et vos enregistrements MX doivent correspondre exactement. Si votre MX pointe vers mail.example.com mais que votre politique liste mx1.example.com, les connexions échoueront en mode d’application.
Oublier de mettre à jour l’ID de la politique piège aussi beaucoup de monde. Lorsque vous modifiez votre fichier de politique, vous devez également mettre à jour l’ID dans votre enregistrement DNS. Les serveurs expéditeurs mettent en cache les politiques sur la base de l’ID — si vous ne le changez pas, ils ne récupéreront pas vos mises à jour.
Enfin, définir un max_age trop élevé trop tôt est risqué. Si vous publiez une politique avec un max_age d’un an et que vous découvrez ensuite un problème, les serveurs expéditeurs appliqueront la politique défaillante pendant un an. Commencez par des heures ou des jours, pas des mois.
MTA-STS vs DANE
Vous avez peut-être entendu parler de DANE (DNS-based Authentication of Named Entities) comme d’une autre solution au même problème. Les deux empêchent les attaques de rétrogradation TLS, mais ils fonctionnent différemment.
DANE utilise DNSSEC pour authentifier les certificats TLS. C’est sans doute plus élégant — tout vit dans DNS, pas besoin de serveur web. Mais l’adoption de DNSSEC reste limitée, et de nombreux fournisseurs DNS le supportent mal. MTA-STS a été conçu comme une alternative plus déployable qui fonctionne avec l’infrastructure existante.
En pratique, MTA-STS a connu une adoption beaucoup plus large. Google, Microsoft et la plupart des grands fournisseurs d’email le supportent. Si vous devez choisir entre eux, MTA-STS est le choix pragmatique. Si vous êtes axé sécurité et avez déjà DNSSEC, implémenter les deux offre une défense en profondeur.
Cela en vaut-il la peine ?
MTA-STS demande plus de configuration qu’un simple enregistrement DNS. Vous devez héberger un fichier de politique, maintenir des certificats, surveiller des rapports. Est-ce que ça vaut le coup ?
Si vous traitez des emails sensibles — services financiers, santé, juridique, ou toute activité où l’interception d’emails serait catastrophique — oui, absolument. L’attaque qu’il empêche est réelle et activement exploitée. Le coût de mise en place est de quelques heures ; la protection est continue.
Pour les petites organisations avec des emails moins sensibles, c’est une question de jugement. La bonne nouvelle, c’est qu’à mesure que davantage de domaines adoptent MTA-STS, l’écosystème devient plus sûr pour tout le monde. Les attaquants ne peuvent pas rétrograder sélectivement des connexions quand la majorité d’Internet refuse les rétrogradations.
Frequently asked questions
MTA-STS protège-t-il le contenu des emails de bout en bout ?
Non. MTA-STS protège les emails en transit entre serveurs de messagerie, mais l'email est déchiffré à chaque serveur. Pour un chiffrement véritablement de bout en bout, vous avez besoin de S/MIME ou PGP. MTA-STS et le chiffrement de bout en bout résolvent des problèmes différents et peuvent être utilisés ensemble.
Que se passe-t-il si mon fichier de politique MTA-STS est indisponible ?
Si les expéditeurs ne peuvent pas récupérer votre politique via HTTPS, ils reviennent au chiffrement opportuniste — comme si vous n'aviez pas du tout MTA-STS. C'est pourquoi la fiabilité de l'hébergement est importante. Envisagez d'utiliser un CDN ou un hébergement redondant pour le fichier de politique.
Tous les fournisseurs d'email prennent-ils en charge MTA-STS ?
La plupart des grands fournisseurs, dont Gmail, Outlook, Yahoo et d'autres, le prennent en charge. Toutefois, certains serveurs de messagerie plus petits ou plus anciens ne le font pas. Consultez les rapports TLSRPT pour voir quels expéditeurs évaluent votre politique.
MTA-STS peut-il provoquer des échecs de livraison d'email ?
En mode d'application, oui — c'est le but. Si un serveur expéditeur ne peut pas établir une connexion sécurisée conforme à vos exigences de politique, l'email ne sera pas livré. C'est pourquoi le mode test et la surveillance sont essentiels avant l'application.