Publier MTA-STS et TLS-RPT d'abord en mode testing

SPF, DKIM et DMARC empêchent des tiers d'usurper votre nom (vous pouvez vérifier votre enregistrement DMARC), mais aucun des trois n'empêche un serveur émetteur de vous livrer du courrier en clair. MTA-STS vous permet de publier une politique indiquant que vos serveurs de messagerie prennent en charge TLS avec authentification, et TLS-RPT vous signale quand des expéditeurs n'ont pas pu l'obtenir. Vous pouvez déployer les deux avec deux enregistrements DNS et un fichier texte, et vous pouvez démarrer dans un mode conçu pour un déploiement progressif.

Ce que STARTTLS laisse ouvert

Le chiffrement du courrier entre serveurs repose sur l'extension STARTTLS, et il est opportuniste. La RFC 8461 décrit le point faible : un attaquant capable de supprimer la réponse « 250 STARTTLS » de la session SMTP, ou de rediriger la session en écrasant l'enregistrement MX résolu, peut forcer un downgrade ou intercepter la session.

DANE est l'autre parade, définie dans la RFC 7672, mais elle exige DNSSEC. MTA-STS s'appuie à la place sur les autorités de certification et ne nécessite pas DNSSEC, « au prix du risque de downgrades malveillants » selon les termes mêmes de la RFC. Si vous exploitez déjà DANE, les deux ne sont pas en conflit : les expéditeurs qui implémentent MTA-STS ne doivent pas le laisser primer sur l'échec d'une validation DANE.

Le guide du NCSC sur la sécurité des e-mails indique que votre service doit être capable d'envoyer et de recevoir des e-mails en TLS, et que vous devez protéger tous vos domaines, y compris ceux hébergés chez des fournisseurs cloud comme Google G Suite et Microsoft O365.

Étape 1 : la politique, en mode testing

MTA-STS comporte deux éléments. Un enregistrement TXT à _mta-sts.example.com annonce qu'une politique existe et en indique la version :

_mta-sts.example.com. IN TXT "v=STSv1; id=20250101000000Z;"

L'id est composé de lettres et de chiffres, sur 32 caractères au maximum, et doit identifier de façon unique cette version de la politique. Aucun ordre n'est sous-entendu : un horodatage est donc une habitude, pas une obligation. Publiez un seul enregistrement de ce type : les expéditeurs ignorent les enregistrements qui ne commencent pas par v=STSv1;, et si le nombre d'enregistrements restants n'est pas égal à un, ils considèrent que vous n'avez pas de politique.

La politique elle-même est récupérée en HTTPS à une adresse fixe, construite en plaçant mta-sts devant votre domaine :

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

Servez-la en text/plain, car les expéditeurs ont pour consigne de vérifier le type de média. Le fichier ressemble à ceci :

version: STSv1
mode: testing
mx: mail.example.com
mx: *.example.net
max_age: 604800

Chaque ligne mx: est une entrée à part, soit un nom d'hôte complet, soit un suffixe générique tel que *.example.net. Listez tous les hôtes de vos enregistrements MX actifs, y compris ceux d'un fournisseur cloud.

Les trois modes sont enforce, testing et none. La RFC présente testing comme un mode facultatif qui permet des déploiements progressifs pour détecter les échecs de politique, d'où l'intérêt de commencer par lui.

Le max_age est exprimé en secondes, jusqu'à 31557600, et 604800 (une semaine) est l'exemple donné par la RFC. Celle-ci attend des valeurs de production typiquement de l'ordre de quelques semaines ou plus. Mon conseil : gardez une semaine ou moins pendant la phase de test, afin qu'une politique corrigée parvienne vite aux expéditeurs, puis augmentez la valeur une fois enforce stable.

Étape 2 : activer TLS-RPT

La détection ne fonctionne que si les expéditeurs vous disent ce qu'ils ont observé. Vous publiez un enregistrement TXT à _smtp._tls.example.com :

_smtp._tls.example.com. IN TXT "v=TLSRPTv1;rua=mailto:tlsrpt@example.com"

Le rua peut aussi être une URI https, auquel cas les expéditeurs envoient le rapport en POST, et une liste séparée par des virgules est autorisée. Comme pour l'enregistrement MTA-STS, un seul enregistrement TXT doit commencer par v=TLSRPTv1;, faute de quoi les expéditeurs supposent que vous n'implémentez pas TLS-RPT.

Si vous choisissez mailto, utilisez une boîte aux lettres dédiée. Les expéditeurs livrent ces rapports même lorsque TLS échoue : un rapport peut donc arriver en clair. Les rapports envoyés par e-mail doivent porter une signature DKIM valide du domaine émetteur, et la RFC précise que les destinataires doivent ignorer ceux qui n'en ont pas. Écartez les rapports non signés au lieu d'agir en fonction de leur contenu.

Vérifier ce que voient les expéditeurs

Interrogez les deux enregistrements et récupérez le fichier de politique depuis l'extérieur de votre réseau :

dig TXT _mta-sts.example.com
dig TXT _smtp._tls.example.com
curl -si https://mta-sts.example.com/.well-known/mta-sts.txt

La sortie de dig doit montrer un enregistrement pour chacun, avec le préfixe v= en premier. Celle de curl doit afficher un 200, Content-Type: text/plain et le corps de la politique ; vérifiez donc que mode et chaque ligne mx: correspondent à ce que vous avez prévu. Corrigez toute erreur de certificat signalée par curl avant de publier l'enregistrement TXT.

Lire les rapports

Les rapports sont des fichiers JSON couvrant une période donnée, avec un résumé de livraison indiquant les nombres de succès et d'échecs. La RFC classe les échecs en quatre catégories : négociation, politique, général et transitoire. Les rapports peuvent arriver compressés (la RFC définit application/tlsrpt+gzip), il faut donc les décompresser d'abord :

gzip -dc report.json.gz | jq .

Les noms de champs sont définis à la section 4.4 de la RFC 8460. Lisez d'abord les compteurs du résumé, puis les entrées d'échec.

Un rapport avec un taux de succès élevé et aucun échec est ce que vous espérez voir. La RFC note qu'un rapport peut servir de heartbeat montrant que TLS est négocié comme prévu, et une série régulière de rapports sans anomalie constitue votre preuve pour passer à l'étape suivante. Des échecs qui mentionnent l'un de vos propres hôtes MX signalent un certificat ou un motif mx à corriger. Un expéditeur dont l'implémentation est défaillante, c'est son affaire.

Une hausse des échecs STARTTLS que vous ne pouvez rattacher à aucun changement doit être transmise à la personne qui traite les incidents, ou à notre équipe de réponse à incident si vous n'avez personne.

Passer en enforce

Attendez que les rapports soient propres sur l'ensemble de vos flux de courrier habituels, y compris les expéditeurs discrets tels que les systèmes de facturation mensuelle. Changez ensuite mode: testing en mode: enforce et modifiez l'id dans l'enregistrement TXT, car les expéditeurs le comparent à leur copie en cache pour savoir que quelque chose a changé.

Les expéditeurs peuvent conserver une politique en cache pendant max_age au maximum à partir de la dernière récupération : une erreur peut donc persister. Supprimer l'enregistrement TXT ne retire pas non plus une politique en cache, comme le souligne la RFC. La section 8.3 de la RFC 8461 traite du retrait, et il vaut mieux la lire avant d'en avoir besoin.

Par où commencer

1. Listez vos hôtes MX actifs, y compris ceux d'un éventuel fournisseur cloud, et vérifiez que chacun présente un certificat valide correspondant à son nom.
2. Mettez en place l'hôte mta-sts en HTTPS et servez le fichier de politique en text/plain avec mode: testing.
3. Publiez l'unique enregistrement TXT _mta-sts avec un id neuf, puis lancez les vérifications dig et curl ci-dessus.
4. Publiez l'enregistrement TXT _smtp._tls pointant vers une boîte aux lettres dédiée ou un point de terminaison HTTPS, et contrôlez l'ensemble de votre configuration avec notre outil de vérification de la sécurité e-mail.
5. Examinez les rapports pendant au moins un cycle d'activité complet, y compris les traitements de fin de mois (pour la plupart des organisations, un mois). Corrigez chaque échec dont vous êtes responsable, puis passez en enforce et changez l'id.