Livraison chiffrée : TLS, MTA-STS et DANE

Module 5: Réputation et les grands destinataires · Temps de lecture : 10 minutes

Objectif d'apprentissage : à l'issue de cette leçon, vous saurez expliquer comment les serveurs de messagerie se chiffrent entre eux, pourquoi ce n'est pas imposable par défaut, et ce que MTA-STS, TLS-RPT et DANE changent à cela. Vous saurez rechercher et lire ces enregistrements.

Notions clés : STARTTLS entre serveurs, chiffrement opportuniste, attaque par rétrogradation (downgrade), MTA-STS (RFC 8461), enregistrement _mta-sts, fichier de politique, mode testing/enforce/none, TLS-RPT (RFC 8460), enregistrement _smtp._tls, DANE pour SMTP (RFC 7672), enregistrement TLSA, DNSSEC

Deux types de connexions

Dans la leçon 1.4, il était question de la connexion entre votre programme de messagerie et le serveur de messagerie de votre fournisseur : port 587 avec STARTTLS, ou 465 avec TLS direct, avec authentification. Là, vous gardez le contrôle. Votre programme sait quel serveur il attend, vérifie le certificat et refuse de se connecter si quelque chose ne va pas.

Cette leçon porte sur l'étape suivante : la connexion entre le serveur expéditeur et le serveur destinataire, sur le port 25. Elle se déroule différemment.

Opportuniste : chiffrer quand c'est possible

Lorsqu'un serveur livre un e-mail, il se connecte au MX du destinataire. Après EHLO, il vérifie si le serveur destinataire propose STARTTLS. Si oui, il bascule vers une connexion chiffrée. Si non, il livre simplement l'e-mail sans chiffrement.

C'est ce qu'on appelle le chiffrement opportuniste : chiffrer quand c'est possible, sinon pas. Et généralement, le serveur expéditeur ne vérifie pas strictement le certificat. Un certificat expiré ou auto-signé n'est alors pas une raison de s'arrêter.

Pourquoi ainsi ? Parce que l'e-mail doit toujours continuer à fonctionner, même avec d'anciens serveurs. Un expéditeur ne peut pas savoir si un destinataire est censé disposer de TLS. Cela rend possibles deux attaques :

1. Rétrogradation (downgrade). Quelqu'un capable de modifier le trafic en chemin retire le mot STARTTLS de la réponse du destinataire. L'expéditeur pense qu'il n'y a pas de chiffrement et livre sans chiffrement. L'attaquant lit au passage.
2. Faux MX. Quelqu'un capable de falsifier les réponses DNS indique son propre serveur comme MX. Comme le certificat n'est pas vérifié, l'expéditeur ne remarque rien.

Aujourd'hui, presque tous les grands serveurs de messagerie chiffrent, et Gmail exige des expéditeurs qu'ils utilisent TLS (leçon 5.3). Mais « généralement chiffré » est différent de « toujours, et avec le bon serveur ». Il existe deux solutions pour cela : MTA-STS et DANE. Elles sont toutes deux configurées par le destinataire : vous indiquez ainsi que le courrier à destination de votre domaine doit toujours être chiffré, vers un serveur disposant d'un certificat valide.

MTA-STS : une politique via une page web

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) fonctionne avec deux éléments.

Un enregistrement TXT qui indique qu'une politique existe :

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20261108T120000;"

Et un fichier de politique à un emplacement fixe, via https avec un certificat valide :

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

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

L'astuce : un expéditeur mémorise la politique pendant la durée de max_age. Un attaquant qui, plus tard, retire le mot STARTTLS ou indique un faux MX est alors démasqué : la politique indique que le chiffrement est obligatoire et quels serveurs sont valides. Lors de la toute première connexion (avant que la politique soit connue), MTA-STS ne protège pas ; c'est la faiblesse connue.

Un exemple réel est gmail.com : l'enregistrement TXT _mta-sts.gmail.com existe, et le fichier de politique sur https://mta-sts.gmail.com/.well-known/mta-sts.txt est en mode: enforce.

TLS-RPT : rapports sur les échecs de chiffrement

Avec MTA-STS en enforce, un e-mail peut rester bloqué si quelque chose ne va pas avec votre certificat. Vous voulez le savoir. C'est à cela que sert TLS-RPT (RFC 8460) :

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

Les expéditeurs qui prennent en charge TLS-RPT (notamment Google et Microsoft) envoient alors chaque jour un rapport au format JSON : combien de connexions ont réussi et lesquelles ont échoué, avec la raison (par exemple un certificat expiré ou un nom absent de la politique). Comme pour les rapports DMARC (leçon 4.5), vous pouvez les faire traiter par un service de rapports.

Ordre de mise en place : d'abord TLS-RPT, ensuite MTA-STS en testing, quelques semaines de lecture des rapports, et seulement après enforce. Cela ressemble à la ligne de conduite progressive de DMARC : d'abord observer, ensuite se montrer strict.

DANE : le certificat dans le DNS, sécurisé par DNSSEC

DANE (DNS-based Authentication of Named Entities) procède différemment. Vous placez dans le DNS un enregistrement TLSA pour chaque serveur MX, avec une empreinte du certificat ou de la clé :

_25._tcp.mx1.example.com.  3600  IN  TLSA  3 1 1 0d5a5c8f3d8aab82bba32bf8d711fa2433e4fe5fa4828b0443364d3ab5cdc1d5

_25._tcp signifie : pour SMTP sur le port 25. Les trois chiffres indiquent comment la valeur doit être lue. Pour les serveurs de messagerie, 3 1 1 est le plus utilisé : « ceci est l'empreinte SHA-256 de la clé publique de précisément ce serveur ». On trouve aussi 2 1 1 : l'empreinte d'un certificat intermédiaire y figure alors.

Un expéditeur qui prend en charge DANE voit l'enregistrement TLSA, exige le chiffrement et vérifie que le certificat du serveur correspond. Si ce n'est pas le cas, il ne livre pas.

Pourquoi DANE est-il sûr face aux réponses DNS falsifiées ? Parce qu'il ne fonctionne qu'avec DNSSEC (cours DNS, leçon 8.1). Sans chaîne DNSSEC valide, les enregistrements TLSA sont ignorés. C'est précisément le seuil d'entrée : à la fois votre domaine (pour le MX) et la zone du serveur de messagerie doivent être signés.

DANE n'a pas la faiblesse de la « première fois » comme MTA-STS, et il est très répandu aux Pays-Bas et en Allemagne. internet.nl le teste. Microsoft prend en charge DANE pour le courrier entrant dans Exchange Online. Les serveurs MX d'internet.nl disposent également d'enregistrements TLSA.

Piège à éviter : si vous remplacez le certificat d'un serveur de messagerie protégé par DANE par une nouvelle clé, l'enregistrement TLSA doit changer en même temps, et ce au préalable : ajoutez d'abord le nouvel enregistrement, attendez que le TTL soit écoulé, puis seulement mettez en service la nouvelle clé. Sinon, les expéditeurs utilisant DANE refuseront votre courrier. Avec 3 1 1, cela ne pose problème que si la clé change, pas à chaque renouvellement avec la même clé.

MTA-STS ou DANE ?

Vous pouvez les utiliser l'un à côté de l'autre. La RFC 8461 indique qu'un expéditeur qui prend en charge DANE fait passer DANE avant, si des enregistrements TLSA valides existent.

Qui s'en charge ?

Vous configurez cela pour le courrier entrant sur votre domaine. Si votre messagerie fonctionne chez un hébergeur ou un service de messagerie, cela dépend de ce prestataire :

• DANE n'est possible que si le fournisseur publie des enregistrements TLSA pour ses serveurs de messagerie et que votre domaine dispose de DNSSEC. Chez WebOké, vous pouvez par exemple activer DANE au même endroit que DNSSEC (voir l'article internet.nl ci-dessous) ; chez d'autres fournisseurs, cela fonctionne de manière comparable ou c'est réglé par défaut.
• MTA-STS peut parfois être configuré par vous-même, mais il faut alors que mta-sts.example.com soit un site web avec un certificat valide et que vous connaissiez les noms MX de votre fournisseur.
• TLS-RPT peut toujours être configuré par vous-même : il s'agit uniquement d'un enregistrement TXT avec une adresse de rapport.

Pour votre courrier sortant, vous n'avez rien à faire : c'est le serveur de votre fournisseur qui détermine s'il respecte MTA-STS et DANE des destinataires.

Résumé

• Entre serveurs de messagerie, TLS est par défaut opportuniste : chiffré quand c'est possible, sans vérification stricte du certificat. Cela rend possibles la rétrogradation et le faux MX.
• MTA-STS : TXT _mta-sts plus fichier de politique sur https://mta-sts.<domaine>/.well-known/mta-sts.txt ; mode testing ou enforce.
• TLS-RPT : TXT _smtp._tls avec une adresse de rapport, pour des rapports quotidiens sur les échecs de chiffrement.
• DANE : enregistrement TLSA sur _25._tcp.<serveur-mx>, ne fonctionne qu'avec DNSSEC et protège aussi la première connexion.
• Mettez en place comme pour DMARC : d'abord des rapports (TLS-RPT, testing), ensuite la rigueur.

Quiz

Exercice

Exercice Z5.4 : Rechercher MTA-STS, TLS-RPT et DANE. Recherchez pour gmail.com l'enregistrement MTA-STS et l'enregistrement TLS-RPT, ouvrez le fichier de politique et indiquez le mode (enforce, testing ou none). Recherchez ensuite, pour un serveur MX de internet.nl, l'enregistrement TLSA sur _25._tcp.<serveur-mx> et indiquez les trois premiers chiffres de l'un des enregistrements. Facultatif : les mêmes questions pour votre propre domaine (la réponse peut y être « aucun »). Le programme interroge tout en direct et compare.

Pour aller plus loin

Les étapes décrites dans ces articles s'appliquent aux panneaux de WebOké ; chez d'autres fournisseurs, le fonctionnement est comparable.

• Checklist internet.nl
• Qu'est-ce que le DNSSEC ?
• Cours DNS gratuit 8.1: DNSSEC en langage simple
• internet.nl, testez votre e-mail (test indépendant de STARTTLS, DANE et plus) : https://internet.nl/
• RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT), RFC 7672 (DANE pour SMTP)