Comment fonctionne la sécurité du transport des e-mails

Le courrier voyage de serveur en serveur par SMTP. Le chiffrement entre serveurs est distinct de l'authentification de l'expéditeur d'un message (SPF, DKIM et DMARC, voir L'authentification e-mail : SPF, DKIM et DMARC). STARTTLS fait passer une connexion SMTP en clair vers TLS, mais les expéditeurs acceptent en silence l'échec de cette montée en sécurité ; un attaquant peut donc la supprimer. MTA-STS (RFC 8461) permet à un domaine d'exiger que son courrier soit livré par TLS vérifié. Construisez les enregistrements avec le générateur de politique MTA-STS ; l'entrée du glossaire est MTA-STS et les codes de réponse figurent dans Aide-mémoire des codes de réponse SMTP.

Le maillon faible : STARTTLS opportuniste

• La livraison de serveur à serveur sur le port 25 commence en clair ; l'expéditeur demande STARTTLS et, si la réponse manque ou si TLS échoue, il livre généralement quand même sans chiffrement.
• Les certificats ne sont souvent pas vérifiés ; même une montée en sécurité réussie peut donc ne pas arrêter un homme du milieu.
• Les ports 465 (TLS implicite) et 587 (soumission avec STARTTLS) sont destinés à votre propre client de messagerie, pas à la livraison entre serveurs.

MTA-STS en trois pièces

• Un enregistrement TXT DNS à _mta-sts.example.com signale l'existence d'une politique : v=STSv1; id=20261028T000000Z. Changez l'id à chaque modification de la politique.
• Un fichier de politique servi en HTTPS à https://mta-sts.example.com/.well-known/mta-sts.txt :

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

• La politique liste les hôtes MX autorisés, le mode (testing, enforce ou none) et la durée pendant laquelle les expéditeurs peuvent la mettre en cache (max_age, en secondes ; 604800 correspond à une semaine).

TLS-RPT : savoir quand cela échoue

Un enregistrement TLS-RPT (RFC 8460) demande aux serveurs expéditeurs de signaler les échecs. Publiez un enregistrement TXT à _smtp._tls.example.com : v=TLSRPTv1; rua=mailto:[email protected]. Des rapports JSON quotidiens montrent alors quels expéditeurs n'ont pas pu négocier TLS ou valider votre certificat.

Déploiement

• Commencez en mode testing avec un max_age court et surveillez les rapports TLS.
• Vérifiez que chaque hôte MX a un certificat valide, non expiré, dont le nom correspond à celui de l'hôte MX (voir Comment vérifier un certificat SSL).
• Passez à enforce et augmentez max_age (une semaine, puis des mois).
• MTA-STS ne protège la livraison vers votre domaine que si les expéditeurs le prennent en charge ; DANE (enregistrements TLSA avec DNSSEC) en est une alternative.