← RFC Reference

Sécurité TLS et Email

Comment TLS protège le courrier électronique en transit — STARTTLS, TLS implicite, MTA-STS, DANE, TLSRPT — et pourquoi le chiffrement opportuniste n'est pas suffisant.

Le problème : SMTP est né non chiffré

SMTP a été conçu en 1982 (RFC 821) comme un protocole en texte brut. Chaque commande, chaque réponse, chaque en-tête, chaque octet du contenu du message a traversé le réseau sans chiffrement. Les mots de passe envoyés via AUTH étaient effectivement criés à travers la pièce.

TLS (Transport Layer Security) a été ajouté à SMTP pour corriger cela. Mais contrairement à HTTPS — où TLS est obligatoire et universel — TLS pour le courrier électronique a évolué à travers une série de compromis imparfaits qui se résolvent encore aujourd'hui.

STARTTLS : chiffrement opportuniste

STARTTLS (RFC 3207) améliore une connexion SMTP existante en texte brut en TLS. Le processus :

Points clés à propos de STARTTLS :

• La connexion commence en texte brut et s'améliore en flux. Les commandes EHLO et STARTTLS elles-mêmes ne sont pas chiffrées.
• Après la réussite de STARTTLS, le client doit renvoyer EHLO. Le serveur peut annoncer des capacités différentes sur la connexion chiffrée.
• STARTTLS est utilisé sur le port 25 (serveur à serveur) et le port 587 (soumission client).
• STARTTLS sur le port 25 est opportuniste par défaut : si le serveur n'annonce pas STARTTLS, ou si la négociation TLS échoue, la plupart des MTA d'envoi reviennent au texte brut et envoient le message de toute façon.

L'attaque par suppression STARTTLS

Parce que STARTTLS commence en texte brut, un attaquant intermédiaire peut modifier la réponse EHLO du serveur pour supprimer l'annonce STARTTLS. L'MTA d'envoi pense que le serveur ne supporte pas TLS et procède en texte brut. L'attaquant peut alors lire et modifier le message.

Ce n'est pas une attaque théorique. Elle a été observée en pratique, notamment dans les pays qui mènent une surveillance de masse. STARTTLS opportuniste ne protège pas contre les attaquants actifs — elle protège uniquement contre l'écoute passive.

TLS implicite : chiffrement dès le premier octet

RFC 8314 recommande TLS implicite pour la soumission de courrier (client vers serveur). Au lieu de commencer en texte brut et de s'améliorer, la connexion est TLS dès le premier octet.

• Port 465 : TLS implicite pour la soumission de messages. Le client ouvre une connexion TLS immédiatement. Pas d'étape STARTTLS. Aucune possibilité de suppression.
• Port 993 : TLS implicite pour IMAP.
• Port 995 : TLS implicite pour POP3.

RFC 8314 déclare explicitement que la soumission SMTP en texte brut sur le port 587 sans TLS est obsolète, et que TLS implicite sur le port 465 est le chemin de soumission préféré. En pratique, le port 587 avec STARTTLS reste largement déployé, mais la direction est claire : TLS implicite est l'avenir.

Cependant, TLS implicite s'applique uniquement au chemin de soumission (votre client vers votre serveur). La livraison serveur à serveur sur le port 25 utilise toujours STARTTLS car il n'y a pas de mécanisme universellement déployé pour que les serveurs sachent à l'avance que le MX du destinataire supporte TLS implicite. C'est là que MTA-STS et DANE interviennent.

MTA-STS : application des politiques TLS

MTA-STS (RFC 8461) résout le problème de suppression STARTTLS en permettant à un domaine de publier une politique qui dit « toujours exiger TLS lors de la livraison de courrier à mes serveurs MX ». La politique est publiée via HTTPS (pas DNS), ce qui fournit sa propre authentification via la PKI Web.

Comment fonctionne MTA-STS

1. Le domaine publie un enregistrement DNS TXT signalant qu'une politique MTA-STS existe :

2. L'MTA d'envoi récupère la politique via HTTPS à partir d'une URL bien connue :

3. Le fichier de politique spécifie le mode et les noms d'hôte MX valides :

4. L'MTA d'envoi met en cache la politique (pendant max_age secondes) et l'applique à toutes les connexions futures. Il va :
   • Exiger STARTTLS sur le port 25 (ne jamais revenir au texte brut)
   • Valider le certificat TLS du serveur par rapport au nom d'hôte MX
   • Ne livrer que aux noms d'hôte MX énumérés dans la politique

Modes MTA-STS :

• enforce : Exiger TLS et des certificats valides. Échouer la livraison si TLS ne peut pas être établi.
• testing : Tenter TLS mais livrer quand même si cela échoue. Envoyer les rapports d'échec via TLSRPT.
• none : Pas de politique. Utilisé pour révoquer explicitement une politique antérieure.

MTA-STS a le même modèle de confiance que le Web : il repose sur les autorités de certification. Si une CA est compromise, un attaquant pourrait forger un certificat pour votre MX. DANE fournit un modèle de confiance alternatif basé sur DNSSEC.

DANE : vérification de certificat basée sur DNS

DANE (RFC 7672) utilise des enregistrements TLSA signés par DNSSEC pour associer un certificat TLS (ou sa clé publique) directement à un nom d'hôte MX. Ceci supprime la dépendance aux autorités de certification.

Les champs de l'enregistrement TLSA :

• 3 (usage de certificat) — Certificat émis par le domaine (aucune CA requise)
• 1 (sélecteur) — Correspondance par rapport à la clé publique du sujet
• 1 (type de correspondance) — Hachage SHA-256 de la clé publique
• a]b2c3d4e5f6... — La valeur de hachage

Comment fonctionne DANE pour le courrier électronique

1. L'MTA d'envoi résout l'enregistrement MX et obtient mx1.example.com.
2. Il requête un enregistrement TLSA à _25._tcp.mx1.example.com.
3. Si un enregistrement TLSA validé par DNSSEC existe, l'MTA sait :
   • TLS est obligatoire (pas de retour au texte brut).
   • Le certificat du serveur doit correspondre à l'enregistrement TLSA.
4. L'MTA se connecte, effectue STARTTLS et valide le certificat du serveur par rapport à l'enregistrement TLSA plutôt que (ou en plus de) le système d'autorité de certification.

La force de DANE : elle ne dépend pas des autorités de certification. Sa faiblesse : elle requiert DNSSEC, que de nombreux domaines n'ont pas déployé. Sans DNSSEC, les enregistrements DANE ne peuvent pas être fiables (un attaquant qui peut manipuler DNS peut manipuler les enregistrements TLSA aussi).

DANE vs. MTA-STS

Les deux mécanismes peuvent coexister. Un domaine peut publier des politiques MTA-STS et DANE. Les expéditeurs qui supportent DANE l'utilisent ; ceux qui ne le font pas peuvent revenir à MTA-STS.

TLSRPT : rapports TLS

SMTP TLS Reporting (RFC 8460) permet à un domaine de recevoir des rapports sur les échecs de connexion TLS des serveurs d'envoi. C'est l'équivalent TLS des rapports globaux DMARC.

Les MTA d'envoi qui supportent TLSRPT enverront des rapports JSON quotidiens détaillant :

• Nombre total de tentatives de connexion à votre MX
• Négociations TLS réussies
• Négociations TLS échouées (et pourquoi : erreurs de certificat, échecs STARTTLS, violations de politique MTA-STS)
• Connexions qui sont revenues au texte brut

TLSRPT est essentiel lors du déploiement de MTA-STS. Commencez avec mode: testing dans votre politique MTA-STS et surveillez les rapports TLSRPT. Quand vous voyez zéro (ou des échecs acceptables), passez à mode: enforce.

Gestion des certificats

TLS requiert des certificats, et la gestion des certificats est l'un des points de défaillance opérationnelle les plus courants dans la sécurité du courrier électronique.

Certificats pour les serveurs de courrier

• Le certificat doit correspondre au nom d'hôte MX. Si votre enregistrement MX pointe vers mx1.example.com, le certificat doit être valide pour mx1.example.com. Un certificat pour example.com ou www.example.com ne fonctionnera pas.
• Utilisez des certificats d'une CA publique. Let's Encrypt fonctionne parfaitement pour les serveurs de courrier. Les certificats auto-signés causeront des échecs de validation TLS pour les expéditeurs qui vérifient (ce qui inclut quiconque utilisant MTA-STS ou DANE).
• Automatisez le renouvellement. L'expiration du certificat est l'échec TLS le plus courant. Utilisez ACME (Let's Encrypt) ou l'automatisation de votre CA pour garantir que les certificats sont renouvelés bien avant l'expiration.
• Incluez tous les noms d'hôte MX. Si vous avez plusieurs serveurs MX, chacun a besoin d'un certificat valide pour son nom d'hôte. Un certificat SAN (Subject Alternative Name) peut couvrir plusieurs noms d'hôte.

Erreurs de certificat et leur impact

Ce tableau révèle le problème fondamental du TLS opportuniste : sans MTA-STS ou DANE, la plupart des erreurs de certificat sont silencieusement ignorées. La connexion est chiffrée, mais non authentifiée — vous chiffrez peut-être votre message vers le serveur d'un attaquant.

L'état du chiffrement du courrier électronique

Le chiffrement du courrier électronique existe à deux niveaux, et ils sont souvent confondus :

Chiffrement du transport (TLS)

TLS chiffre la connexion entre les serveurs. Il protège contre l'écoute pendant que le message est en transit entre deux points. Une fois que le message arrive au serveur de destination, il est déchiffré et stocké en texte brut (généralement). TLS protège le transport, pas le message.

Le chiffrement du transport est saut par saut : le message est chiffré entre votre serveur et le serveur suivant, puis déchiffré, puis chiffré à nouveau pour le prochain saut. Chaque serveur intermédiaire a accès au message en texte brut.

Chiffrement de bout en bout (S/MIME, PGP)

Le chiffrement de bout en bout (S/MIME par RFC 8551, ou PGP/OpenPGP) chiffre le contenu du message lui-même, de sorte que seul le destinataire prévu avec la clé privée correcte peut le déchiffrer. Le message reste chiffré au repos sur le serveur et lors de chaque saut en transit.

L'adoption du chiffrement de bout en bout dans le courrier électronique reste extrêmement faible. Les raisons sont pratiques :

• La gestion des clés est difficile. L'expéditeur et le destinataire doivent tous deux gérer les clés cryptographiques. Il n'y a pas d'annuaire universel des clés.
• L'utilisabilité est mauvaise. La plupart des clients de courrier électronique rendent le chiffrement lourd. L'utilisateur moyen ne peut pas (et ne devrait pas avoir besoin de) gérer les clés PGP.
• Les fonctionnalités côté serveur se cassent. Si le serveur ne peut pas lire le message, il ne peut pas l'indexer, le rechercher, filtrer le spam ou appliquer des règles.
• L'interopérabilité est limitée. S/MIME et PGP ne sont pas compatibles l'un avec l'autre.

Pour la plupart des courriels, TLS au niveau du transport est la couche de chiffrement pratique. Le chiffrement de bout en bout reste de niche, utilisé dans les environnements hautement sécurisés où la charge opérationnelle est justifiée.

Exiger TLS (RFC 8689)

RFC 8689 définit un mécanisme par message pour exiger TLS. L'expéditeur ajoute une extension SMTP REQUIRETLS à des messages individuels :

Quand REQUIRETLS est défini :

• Le serveur récepteur doit utiliser TLS pour livrer ou relayer le message. Si TLS n'est pas disponible au prochain saut, le message est retourné plutôt que d'être envoyé en texte brut.
• La vérification du certificat TLS doit réussir.
• Tous les sauts en aval doivent également supporter et honorer REQUIRETLS.

REQUIRETLS est au niveau du message — vous pouvez l'utiliser pour les messages sensibles sans exiger TLS pour tout le courrier. Cependant, l'adoption est toujours limitée. La plupart des serveurs ne le supportent pas encore.

Guide de déploiement pratique

Voici une séquence recommandée pour déployer TLS pour le courrier électronique de votre domaine :

Étape 1 : assurer TLS sur vos serveurs MX

Obtenez des certificats valides d'une CA publique pour chaque nom d'hôte MX. Automatisez le renouvellement. Testez que STARTTLS fonctionne correctement à partir d'expéditeurs externes.

Étape 2 : déployer TLSRPT

Publiez un enregistrement TXT _smtp._tls pour recevoir les rapports d'échec TLS. Commencez à surveiller avant d'appliquer quoi que ce soit.

Étape 3 : déployer MTA-STS en mode test

Publiez l'enregistrement DNS TXT et le fichier de politique HTTPS avec mode: testing. Surveillez les rapports TLSRPT pour les échecs. Enquêtez et corrigez les problèmes.

Étape 4 : passer MTA-STS au mode enforce

Une fois que les rapports TLSRPT montrent des résultats clairs, changez le mode à enforce. Incrémentez l'id dans l'enregistrement DNS TXT pour signaler le changement de politique.

Étape 5 : envisager DANE (si vous utilisez DNSSEC)

Si votre domaine est signé DNSSEC, publiez des enregistrements TLSA pour vos serveurs MX. Cela fournit une couche supplémentaire d'épinglage de certificat indépendante du système d'autorité de certification.

Ce qui peut mal tourner

L'expiration du certificat provoque des échecs de livraison

Le certificat de votre serveur MX expire. Sans MTA-STS, la plupart des expéditeurs ignorent l'erreur et livrent quand même (non sécurisé mais fonctionnel). Avec MTA-STS en mode enforce, les expéditeurs qui valident les certificats vont différer la livraison. Les messages s'accumulent du côté de l'expéditeur. Si vous ne le corrigez pas dans la fenêtre de nouvelle tentative de l'expéditeur (généralement 4–5 jours), les messages rebondissent. La solution : automatisez le renouvellement des certificats avec Let's Encrypt / ACME.

Inadéquation de la politique MTA-STS après le changement MX

Vous ajoutez un nouveau serveur MX (mx3.example.com) mais oubliez de l'ajouter à votre fichier de politique MTA-STS. Les expéditeurs qui ont mis en cache l'ancienne politique rejettent les connexions au nouveau MX car il n'est pas dans la liste autorisée de la politique. La solution : mettez toujours à jour le fichier de politique MTA-STS avant d'ajouter de nouveaux enregistrements MX, et incrémentez l'id de la politique dans DNS.

Suppression STARTTLS non détectée

Sans MTA-STS ou DANE, un attaquant supprime STARTTLS de la réponse EHLO du serveur. Les messages sont livrés en texte brut. Ni l'expéditeur ni le destinataire n'en sont conscients. La solution : déployez MTA-STS pour rendre la suppression TLS détectable et évitable.

L'enregistrement TLSA DANE devient obsolète

Vous faites tourner votre certificat TLS mais oubliez de mettre à jour l'enregistrement TLSA dans DNS. Les expéditeurs qui valident DANE voient une inadéquation et refusent de livrer. La solution : mettez toujours à jour les enregistrements TLSA avant de déployer un nouveau certificat. Utilisez l'automatisation qui coordonne le déploiement des certificats avec les mises à jour DNS.

Points clés à retenir

• STARTTLS opportuniste est mieux que rien, mais ne protège pas contre les attaques actives. Un attaquant qui peut modifier le trafic réseau peut dépouiller TLS de la connexion.
• MTA-STS prévient la suppression de TLS en publiant une politique que les expéditeurs mettent en cache et appliquent. Il repose sur la PKI Web (autorités de certification).
• DANE prévient la suppression de TLS en publiant les données de certificat dans les enregistrements DNS signés par DNSSEC. Elle ne dépend pas des CAs mais requiert DNSSEC.
• Déployez les deux si possible. MTA-STS a un support d'expéditeur plus large ; DANE est plus fort mais requiert DNSSEC. Ensemble, ils couvrent le plus de terrain.
• TLSRPT est essentiel pour la visibilité. Sans cela, vous n'avez aucune idée de la fréquence des échecs de TLS pour le courrier entrant vers votre domaine.
• La gestion des certificats est une préoccupation opérationnelle. Automatisez le renouvellement. Faites correspondre les certificats aux noms d'hôte MX. Coordonnez la rotation des certificats avec les mises à jour TLSA DANE.
• TLS protège le transport, pas le contenu. Pour le chiffrement de message de bout en bout, vous avez besoin de S/MIME ou PGP — mais les obstacles d'utilisabilité et d'adoption restent élevés.
• TLS implicite (port 465) est l'avenir pour la soumission. Pour la livraison serveur à serveur, STARTTLS avec application MTA-STS/DANE est la meilleure pratique actuelle.

Lectures complémentaires

Related RFCs