MTA-STS expliqué : principe, TLS-RPT et faut-il l'activer ?

MTA-STS (RFC 8461) permet à un domaine de dire aux serveurs de messagerie qui lui écrivent : « livrez mon courrier uniquement en TLS, uniquement avec un certificat valide, et uniquement à ces hôtes MX ». Sans lui, le chiffrement entre serveurs de messagerie est opportuniste, et n'importe qui placé sur le chemin peut le supprimer. Le dispositif se compose d'un enregistrement TXT, d'un petit fichier texte servi en HTTPS et, idéalement, d'un second enregistrement TXT (TLS-RPT, RFC 8460) qui vous vaut des rapports quotidiens sur ce que les expéditeurs ont constaté. Si votre messagerie est hébergée chez un grand fournisseur, cela coûte une après-midi ; si vous recevez quoi que ce soit de sensible par e-mail, cela en vaut la peine.

Le problème : STARTTLS est opportuniste

Entre deux serveurs, SMTP démarre en clair. Le serveur destinataire annonce STARTTLS, l'expéditeur bascule la connexion en TLS, et la suite est chiffrée. Deux faiblesses sont inhérentes à ce mécanisme :

Le déclassement (downgrade). Un attaquant placé sur le chemin peut supprimer la ligne STARTTLS de la réponse du serveur. L'expéditeur en conclut que TLS n'est pas proposé et livre le message en clair.
L'absence d'authentification. Les expéditeurs ne valident généralement pas le certificat qu'on leur présente, parce que pendant des décennies beaucoup de serveurs de messagerie avaient des certificats auto-signés ou ne correspondant pas au nom. Un attaquant capable de falsifier la réponse à votre requête MX, ou d'intercepter la connexion, peut présenter n'importe quel certificat.

Les trois éléments

1. L'enregistrement TXT `_mta-sts`

$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=20260921000000"

id est une chaîne quelconque de 32 lettres et chiffres au plus. Son seul rôle est de changer à chaque modification de la politique, pour que les expéditeurs sachent qu'ils doivent aller rechercher le fichier.

2. Le fichier de politique

Il est servi à une URL fixe, sur le nom d'hôte fixe mta-sts :

$ curl https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: mx1.mail.example.net
mx: mx2.mail.example.net
max_age: 86400

Champ	Signification
`version`	Toujours `STSv1`
`mode`	`enforce`, `testing` ou `none`
`mx`	Une ligne par hôte MX autorisé. Un joker comme `*.mail.example.net` est admis et correspond exactement à une étiquette la plus à gauche
`max_age`	Durée pendant laquelle les expéditeurs peuvent garder la politique en cache, en secondes. Maximum 31557600 (environ un an)

Le serveur HTTPS doit présenter un certificat reconnu publiquement et valable pour mta-sts.example.com. Les expéditeurs ne suivent pas les redirections HTTP quand ils récupèrent la politique : le fichier doit donc être servi exactement à cette URL.

3. Des hôtes MX qui réussissent le test

Chaque hôte listé doit proposer STARTTLS avec un certificat non expiré, rattaché à une autorité de certification reconnue par l'expéditeur, et dont le nom correspond au nom d'hôte MX.

$ openssl s_client -starttls smtp -connect mail.example.com:25 \
    -servername mail.example.com </dev/null 2>/dev/null \
    | openssl x509 -noout -subject -enddate -ext subjectAltName

Si le certificat de votre propre MX est arrivé à échéance, commencez par là : certificat SSL expiré, que faire traite du renouvellement.

Comment un expéditeur applique la politique

Avant de livrer à example.com, l'expéditeur interroge _mta-sts.example.com.
S'il n'a aucune politique en cache, ou si l'id diffère de celui qu'il connaît, il récupère le fichier de politique en HTTPS.
Il conserve la politique en cache pendant max_age secondes.
Il résout les enregistrements MX comme d'habitude, écarte tout hôte MX qui ne correspond à aucune ligne mx:, et exige un TLS valide sur les autres.

Ce qui se passe en cas d'échec dépend du mode :

Mode	En cas d'échec TLS ou d'hôte MX non conforme
`testing`	Le message est livré quand même ; l'échec est signalé via TLS-RPT
`enforce`	L'expéditeur ne livre pas à l'hôte en échec. Si aucun hôte ne passe, le message est mis en file d'attente, réessayé, puis finit par rebondir
`none`	Le domaine déclare n'avoir aucune politique active. Sert au retrait

C'est le cache qui fait la force de MTA-STS. Un attaquant qui bloque aujourd'hui la requête TXT ou la récupération HTTPS ne peut pas faire oublier à un expéditeur la politique qu'il a mise en cache la semaine dernière. Le moment fragile est la toute première récupération, avant que quoi que ce soit ne soit en cache.

TLS-RPT : savoir ce que voient les expéditeurs

$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

rua accepte une adresse mailto: ou un URI https:. Les expéditeurs qui participent envoient un rapport JSON agrégé par jour : combien de sessions vers votre domaine ont réussi, combien ont échoué, et pourquoi (certificat expiré, nom d'hôte non concordant, STARTTLS non proposé, MX absent de la politique). Les rapports couvrent à la fois MTA-STS et DANE. Sans eux, le mode testing ne teste rien, puisque personne ne vous communique le résultat.

Ordre de déploiement

Vérifiez que chaque hôte MX possède un certificat valide, concordant et reconnu publiquement (commande ci-dessus).
Publiez d'abord l'enregistrement TLS-RPT et laissez les rapports commencer à arriver.
Hébergez le fichier de politique en mode: testing avec un max_age court, par exemple 86400.
Publiez l'enregistrement TXT _mta-sts.
Lisez les rapports pendant quelques semaines. Cherchez les échecs venant d'expéditeurs légitimes et les hôtes MX manquants dans la politique.
Passez en mode: enforce, changez l'id, et gardez un max_age court les premiers jours.
Montez max_age à quelques semaines une fois que tout est calme.
Placez le certificat de l'hôte mta-sts et ceux des MX sous surveillance d'expiration.

Pour consulter l'enregistrement _mta-sts et la politique publiés par un domaine, utilisez le vérificateur MTA-STS ; pour l'enregistrement de rapport, le vérificateur TLS-RPT.

Messagerie hébergée

Si vos enregistrements MX pointent vers un fournisseur de messagerie, les certificats relèvent de ce fournisseur, et les grands fournisseurs les tiennent en ordre. Votre part du travail :

Indiquez les noms MX du fournisseur dans la politique exactement tels qu'ils figurent dans vos enregistrements MX, ou sous la forme à joker que le fournisseur documente.
Hébergez vous-même le fichier de politique sur mta-sts.example.com. Un hébergeur de pages statiques suffit.

Changer de fournisseur de messagerie

Une fois en enforce, l'ordre des opérations compte. Les expéditeurs détiennent une politique en cache qui ne liste que les anciens hôtes MX. Si vous changez d'abord les enregistrements MX, ces expéditeurs voient de nouveaux hôtes que la politique n'autorise pas, et refusent de livrer.

Ajoutez les noms MX du nouveau fournisseur au fichier de politique (en conservant les anciens) et changez l'id.
Laissez aux expéditeurs le temps de remarquer le nouvel id et de récupérer la politique ; quelques jours constituent une marge prudente.
Basculez les enregistrements MX.
Plus tard, retirez les anciens noms de la politique et changez de nouveau l'id.

C'est aussi pour cela qu'il ne faut pas passer trop tôt à un max_age d'un an.

Retirer une politique

Supprimer l'enregistrement TXT et le fichier n'est pas un retrait. Les expéditeurs qui ont une politique enforce en cache continuent de l'appliquer jusqu'à l'expiration de leur cache. La méthode propre : publier mode: none avec un nouvel id, laisser l'enregistrement et le fichier en place jusqu'à ce que le précédent max_age se soit entièrement écoulé, puis les retirer.

MTA-STS et DANE

DANE pour SMTP (RFC 7672) résout le même problème autrement : le certificat ou la clé de l'hôte MX est épinglé dans un enregistrement TLSA, et cet enregistrement est digne de confiance parce que la zone est signée avec DNSSEC.

	MTA-STS	DANE pour SMTP
Ancre de confiance	PKI web (AC publiques) plus HTTPS	Chaîne DNSSEC
Nécessite DNSSEC	Non	Oui : les enregistrements TLSA des hôtes MX doivent se trouver dans une zone signée
Faiblesse au premier contact	Oui, jusqu'à la mise en cache de la politique	Non

Les deux peuvent coexister, et TLS-RPT rend compte des deux. Avec une messagerie hébergée, DANE dépend de la signature ou non de la zone MX par votre fournisseur ; MTA-STS, lui, est entre vos mains. Voir DNSSEC expliqué.

Ce que MTA-STS ne fait pas

Il protège uniquement le courrier entrant vers votre domaine. Votre courrier sortant est protégé par les politiques des destinataires, si votre serveur d'envoi respecte MTA-STS.
Il ne fonctionne qu'avec les expéditeurs qui l'implémentent. Les autres continuent de livrer de façon opportuniste.
C'est un chiffrement du transport, saut par saut, pas un chiffrement de bout en bout. Le courrier est lisible sur chaque serveur qu'il traverse.
Il ne dit rien du spam, de l'usurpation ni de l'authentification de l'expéditeur. C'est le rôle de SPF, DKIM et DMARC : voir MX, SPF, DKIM et DMARC expliqués.

En avez-vous besoin ?

Domaine sur une grande messagerie hébergée : coût faible, risque faible. Les certificats du fournisseur sont entretenus ; vous ajoutez deux enregistrements TXT et un fichier statique.
Domaine qui reçoit du courrier sensible (contrats, santé, finance, réinitialisations de compte) : utile même si vous exploitez votre propre MX, à condition de surveiller les certificats.
Pas prêt à vous engager : le mode testing accompagné de TLS-RPT ne fait courir aucun risque à la livraison et vous dit si enforce poserait problème.

Erreurs fréquentes

Passer directement en enforce sans TLS-RPT, et apprendre les échecs par les personnes dont le courrier a rebondi.
Modifier le fichier de politique sans changer l'id. Les expéditeurs gardent l'ancienne politique jusqu'à la fin de max_age.
Indiquer le domaine (example.com) sur la ligne mx: au lieu des noms d'hôte MX.
Un fichier de politique accessible seulement à travers une redirection, ou sous un certificat qui ne couvre pas mta-sts.example.com.
Laisser expirer le certificat de l'hôte mta-sts : les nouveaux expéditeurs ne peuvent plus récupérer la politique.
Basculer les enregistrements MX avant de mettre à jour la politique, ou tout supprimer d'un coup pour « désactiver » le dispositif.

Vérifiez avec OrbitProbe

Commencez par la recherche MX d'OrbitProbe : elle liste les hôtes MX d'un domaine avec leurs préférences, ainsi que les enregistrements SPF et DMARC. Les noms d'hôte qu'elle affiche sont ceux que vos lignes mx: doivent reproduire caractère pour caractère : lancez-la avant d'écrire la politique, puis de nouveau après tout changement de fournisseur de messagerie. Une recherche DNS montre ce qui est publié à cet instant ; savoir si les expéditeurs ont réellement pu négocier TLS, c'est le rôle des rapports TLS-RPT, alors continuez de les lire après le passage en enforce.