MTA-STS et TLS-RPT : des e-mails reçus vraiment chiffrés
Pourquoi le chiffrement entre serveurs de messagerie peut sauter sans bruit, comment MTA-STS et les rapports TLS l’empêchent et le révèlent, et leur mise en place.
Quand un serveur envoie un e-mail à votre domaine, il cherche vos enregistrements MX et se connecte à votre serveur de messagerie. Il demande alors « peut-on chiffrer ? » avec une commande appelée STARTTLS, et si votre serveur répond oui, la suite de l’échange est chiffrée. La faiblesse est dans cette question. Quiconque peut intervenir sur la connexion peut effacer le « oui » de votre serveur, et la plupart des serveurs d’envoi livrent alors le message en clair plutôt que de ne pas le livrer. Le même attaquant peut aussi répondre avec un faux certificat, que la plupart des expéditeurs acceptent.
MTA-STS (RFC 8461) comble ce trou. TLS-RPT (RFC 8460) vous dit quand quelque chose ne va pas.
Comment fonctionne MTA-STS
Vous publiez, en HTTPS, un court fichier de politique qui dit : « les e-mails pour ce domaine doivent être livrés en TLS, avec un certificat valide, à ces serveurs ». Les serveurs d’envoi qui connaissent MTA-STS (dont Gmail, Outlook.com et Microsoft 365) le récupèrent, le gardent en cache et refusent de livrer s’ils ne peuvent pas le respecter. Comme la politique vient d’un site HTTPS au certificat valide, un attaquant placé sur le chemin réseau ne peut pas la falsifier.
Il faut trois choses.
1. Le fichier de politique, servi exactement à cette adresse :
https://mta-sts.votredomaine.fr/.well-known/mta-sts.txt
avec ce contenu :
version: STSv1
mode: testing
mx: votredomaine-fr.mail.protection.outlook.com
max_age: 604800
mx liste vos serveurs de messagerie (une ligne chacun, les jokers comme *.mail.protection.outlook.com sont permis). max_age dit combien de temps les expéditeurs peuvent garder la politique en cache, en secondes ; une semaine est un bon début.
2. Un hébergement pour lui. Le sous-domaine mta-sts doit avoir un certificat valide. N’importe quel hébergement statique convient : une petite page chez votre hébergeur actuel, GitHub Pages, Cloudflare Pages ou un Worker.
3. Un enregistrement DNS qui annonce la politique :
_mta-sts.votredomaine.fr. TXT "v=STSv1; id=20261112"
Changez id à chaque modification du fichier de politique, pour que les expéditeurs récupèrent la nouvelle version.
Commencer en test, puis appliquer
En mode: testing, les expéditeurs livrent comme avant mais vous signalent les échecs. Laissez ce mode deux à quatre semaines en lisant les rapports, puis passez en mode: enforce et changez l’id. En mode appliqué, un expéditeur qui n’obtient pas de connexion chiffrée valide vers un serveur listé garde le message dans sa file et réessaie, au lieu de le livrer en clair.
TLS-RPT : les rapports
Un seul enregistrement DNS :
_smtp._tls.votredomaine.fr. TXT "v=TLSRPTv1; rua=mailto:rapports-tls@votredomaine.fr"
Des expéditeurs comme Google et Microsoft vous envoient alors un rapport JSON quotidien : combien de connexions à vos serveurs ont réussi en TLS, et les échecs avec leur cause (certificat expiré, nom qui ne correspond pas, politique introuvable, STARTTLS non proposé). Sans ces rapports, un certificat expiré sur votre serveur de messagerie peut bloquer la livraison pendant des jours avant que quelqu’un ne s’en aperçoive.
Les erreurs courantes
- Les lignes
mxne correspondent pas aux vrais MX. En mode appliqué, les e-mails s’arrêtent. Vérifiez-les avecdig MX votredomaine.frà chaque changement de messagerie. - Le certificat du site de la politique expire. Les expéditeurs qui l’ont déjà en cache la gardent jusqu’à
max_age; les nouveaux ne peuvent plus la lire. Utilisez un renouvellement automatique. - Oublier l’
id. Les expéditeurs gardent l’ancienne politique jusqu’à son expiration. - Passer directement en mode appliqué sans avoir lu un seul rapport.
Et DANE ?
DANE fait le même travail avec DNSSEC au lieu de HTTPS : les certificats de vos serveurs MX sont épinglés dans des enregistrements DNS signés. Il est très utilisé en Allemagne et aux Pays-Bas, et Microsoft le prend en charge dans Exchange Online. Si votre DNS est signé, DANE et MTA-STS peuvent cohabiter (voir DNSSEC et CAA).
Ce que vérifie Perimetry
Chaque audit récupère votre politique MTA-STS, vérifie qu’elle est lisible, que le mode est fixé, que les lignes mx couvrent vos vrais enregistrements MX et que le certificat du site est valide, et lit votre enregistrement TLS-RPT. Perimetry Cloud peut aussi recevoir lui-même vos rapports TLS et montrer, jour après jour, si les e-mails qui vous sont envoyés arrivent chiffrés. Le générateur d’enregistrements DNS gratuit écrit pour vous le fichier de politique et les deux enregistrements.
Pour vérifier un domaine, le vérificateur MTA-STS et TLS-RPT gratuit lit l’enregistrement, récupère le fichier de politique comme le ferait un expéditeur et le compare à vos serveurs MX.