Attaques de downgrade SMTP : comment elles fonctionnent et comment s'en protéger

⚡TL;DR

• SMTP transmet les emails en clair par défaut. STARTTLS ajoute le chiffrement, mais reste vulnérable aux attaques de downgrade (STARTTLS stripping)
• Un attaquant positionné sur le réseau peut supprimer l'option STARTTLS de la réponse du serveur, forçant l'envoi en texte clair sans que l'expéditeur le détecte
• MTA-STS (RFC 8461) et DANE/TLSA (RFC 7672) imposent le chiffrement TLS obligatoire et bloquent ces attaques
• Hébergez votre politique MTA-STS gratuitement avec CaptainDNS : deux enregistrements DNS suffisent pour protéger vos domaines en moins de 5 minutes

Chaque jour, des milliards d'emails circulent entre serveurs SMTP. La majorité utilisent STARTTLS pour chiffrer la connexion. Mais ce chiffrement est opportuniste : si le serveur distant ne répond pas au chiffrement, le message part en clair. Un attaquant positionné sur le réseau peut forcer ce comportement avec un simple paquet réseau.

Les attaques de downgrade SMTP, aussi appelées STARTTLS stripping, exploitent cette faiblesse. Elles permettent d'intercepter des emails en texte clair, même quand les deux serveurs supportent le chiffrement TLS. Le problème : ni l'expéditeur ni le destinataire ne sont informés de l'attaque.

Cet article détaille le mécanisme technique de ces attaques, leurs variantes, leur impact réel d'après les données de Google, et les solutions concrètes pour protéger vos domaines. Si vous gérez des serveurs email ou la sécurité d'un domaine, ce guide est pour vous.

Comment SMTP transmet vos emails

SMTP (Simple Mail Transfer Protocol, RFC 5321) est le protocole utilisé pour acheminer les emails entre serveurs. Conçu en 1982, il ne prévoit aucun chiffrement natif. Chaque message transite en texte clair entre le serveur émetteur et le serveur destinataire.

STARTTLS : un chiffrement opportuniste

En 2002, la RFC 3207 introduit STARTTLS. Ce mécanisme permet à deux serveurs SMTP de négocier une connexion TLS après l'établissement de la connexion initiale en clair.

Le processus se déroule ainsi :

1. Le serveur émetteur ouvre une connexion TCP sur le port 25
2. Le serveur destinataire répond avec ses capacités, dont 250 STARTTLS
3. Le serveur émetteur envoie la commande STARTTLS
4. Les deux serveurs négocient une connexion TLS
5. L'email est transmis de manière chiffrée

S: 220 mx.captaindns.com ESMTP
C: EHLO mail.captaindns.com
S: 250-mx.captaindns.com
S: 250-SIZE 52428800
S: 250-STARTTLS        ← le serveur annonce le support TLS
S: 250 OK
C: STARTTLS            ← le client demande le chiffrement
S: 220 Ready to start TLS
[Négociation TLS]
C: EHLO mail.captaindns.com
[Transmission chiffrée de l'email]

Pourquoi "opportuniste" pose problème

Le mot clé est opportuniste. Si la commande STARTTLS échoue ou n'est pas proposée, le serveur émetteur envoie l'email en clair sans avertir personne. C'est un choix de conception : la RFC 3207 privilégie la livraison du message sur sa confidentialité.

Cette décision crée la faille exploitée par les attaques de downgrade.

Anatomie d'une attaque de downgrade SMTP

Une attaque de downgrade SMTP, ou STARTTLS stripping, consiste à empêcher la négociation TLS entre deux serveurs email. L'attaquant force le retour à une connexion en clair.

Comment fonctionne le STARTTLS stripping ?

L'attaquant doit se positionner sur le chemin réseau entre les deux serveurs (man-in-the-middle). Il intercepte les paquets TCP et modifie la réponse du serveur destinataire :

1. Le serveur émetteur envoie EHLO au serveur destinataire
2. Le serveur destinataire répond avec 250 STARTTLS dans ses capacités
3. L'attaquant intercepte cette réponse et supprime la ligne 250 STARTTLS
4. Le serveur émetteur reçoit une réponse sans mention de STARTTLS
5. Le serveur émetteur conclut que le destinataire ne supporte pas le chiffrement
6. L'email est envoyé en texte clair
7. L'attaquant lit le contenu du message

[Réponse originale du serveur destinataire]
S: 250-mx.captaindns.com
S: 250-SIZE 52428800
S: 250-STARTTLS        ← présent
S: 250 OK

[Réponse modifiée par l'attaquant]
S: 250-mx.captaindns.com
S: 250-SIZE 52428800
S: 250 OK              ← STARTTLS supprimé

L'attaque est invisible pour les deux serveurs. Le serveur émetteur pense que le destinataire ne supporte pas TLS. Le serveur destinataire ne sait pas qu'un email lui a été envoyé en clair.

Qui peut lancer cette attaque ?

Toute entité positionnée sur le chemin réseau :

• Fournisseurs d'accès internet (FAI) : contrôlent le routage du trafic
• Opérateurs de réseaux intermédiaires : points d'échange internet (IXP)
• Attaquants sur le réseau local : Wi-Fi public, réseau d'entreprise compromis
• Acteurs étatiques : surveillance de masse documentée dans certains pays

Variantes d'attaques sur le transport email

Le STARTTLS stripping est la variante la plus connue, mais d'autres attaques ciblent le transport email.

Spoofing DNS des enregistrements MX

L'attaquant falsifie la réponse DNS pour les enregistrements MX du domaine destinataire. Le serveur émetteur envoie alors l'email vers un faux serveur contrôlé par l'attaquant.

; Réponse DNS légitime
captaindns.com. MX 10 mx.captaindns.com.

; Réponse DNS falsifiée par l'attaquant
captaindns.com. MX 10 mx.attaquant.com.

DNSSEC protège contre cette attaque en signant cryptographiquement les réponses DNS.

Attaque sur le certificat TLS

Même si STARTTLS est négocié, SMTP ne valide pas le certificat du serveur destinataire par défaut. Un attaquant peut présenter un certificat auto-signé ou invalide, et le serveur émetteur acceptera la connexion sans vérification.

MTA-STS et DANE imposent la validation du certificat, bloquant cette variante.

Détournement BGP

Un attaquant annonce de fausses routes BGP pour rediriger le trafic réseau vers ses propres équipements. Cette attaque cible l'infrastructure réseau et peut affecter tout le trafic, pas seulement les emails.

Impact réel : qui est concerné ?

Les chiffres de Google

Le Transparency Report de Google sur le chiffrement des emails en transit révèle des données concrètes :

• Plus de 90 % des emails entrants vers Gmail sont chiffrés avec TLS
• Plus de 90 % des emails sortants de Gmail utilisent TLS
• Certaines régions et certains fournisseurs restent en dessous de 70 %

Ces chiffres montrent que le chiffrement SMTP a progressé, mais que des lacunes persistent. Chaque email non chiffré représente une opportunité pour une attaque de downgrade.

Secteurs les plus exposés

Secteur	Risque	Raison
Santé	Élevé	Données patients, conformité HIPAA/RGPD
Finance	Élevé	Informations financières sensibles
Juridique	Élevé	Secret professionnel, confidentialité client
Administration	Moyen	Données citoyens, processus internes
PME	Moyen	Infrastructure email souvent sous-configurée

Attaques documentées

Des recherches publiées par l'EFF et l'APNIC ont documenté des cas de STARTTLS stripping à grande échelle par des opérateurs réseau dans plusieurs pays. Ces attaques ne ciblent pas un domaine spécifique : elles interceptent tout le trafic SMTP qui transite par l'infrastructure compromise.

Comment se protéger contre les attaques de downgrade

Quatre mécanismes complémentaires permettent de sécuriser le transport email.

MTA-STS (RFC 8461) : le chiffrement TLS obligatoire

MTA-STS permet à un domaine de publier une politique qui impose le chiffrement TLS aux serveurs émetteurs. La politique est hébergée sur un serveur HTTPS, un canal séparé et authentifié que l'attaquant ne peut pas compromettre avec du STARTTLS stripping.

Fonctionnement :

1. Le serveur émetteur découvre le record TXT _mta-sts.captaindns.com
2. Il télécharge la politique depuis https://mta-sts.captaindns.com/.well-known/mta-sts.txt
3. La politique indique les serveurs MX autorisés et le mode (testing/enforce)
4. En mode enforce, le serveur refuse d'envoyer en clair

Avantage : ne nécessite pas DNSSEC. Fonctionne avec n'importe quel registrar.

Limite : la première requête (avant mise en cache) reste vulnérable (TOFU, Trust On First Use).

DANE/TLSA (RFC 7672) : le certificat ancré dans le DNS

DANE publie l'empreinte du certificat TLS directement dans un record TLSA du DNS. Le serveur émetteur vérifie que le certificat présenté correspond à celui déclaré dans le DNS.

Avantage : pas de TOFU. La vérification est immédiate dès la première connexion.

Limite : exige DNSSEC sur toute la chaîne DNS, ce qui limite l'adoption.

TLS-RPT (RFC 8460) : la visibilité sur les échecs

TLS-RPT ne bloque pas les attaques, mais il les rend visibles. Les serveurs émetteurs qui supportent TLS-RPT envoient des rapports quotidiens sur les échecs de négociation TLS.

Ces rapports permettent de détecter :

• Des tentatives de downgrade
• Des certificats expirés ou invalides
• Des problèmes de configuration sur vos serveurs MX

Configurez TLS-RPT avec notre générateur TLS-RPT pour recevoir ces rapports.

DNSSEC : la protection du DNS

DNSSEC signe cryptographiquement les réponses DNS, empêchant le spoofing des enregistrements MX. C'est le socle de DANE, mais il renforce aussi la sécurité de MTA-STS en protégeant la résolution du record _mta-sts.

🎯 Plan d'action recommandé

1. Vérifiez votre configuration actuelle : utilisez le vérificateur MTA-STS pour analyser l'état de votre domaine
2. Activez MTA-STS en mode testing : hébergez votre politique gratuitement avec CaptainDNS et surveillez les rapports TLS-RPT pendant 1 à 2 semaines
3. Configurez TLS-RPT : recevez les rapports d'échec TLS pour détecter les problèmes avant qu'ils n'impactent vos emails
4. Passez en mode enforce : quand les rapports confirment que tout fonctionne, activez le mode enforce pour bloquer les connexions non chiffrées
5. Évaluez DANE : si votre registrar et votre hébergeur DNS supportent DNSSEC, ajoutez des records TLSA pour une protection sans TOFU

---

Protégez vos emails contre les attaques de downgrade maintenant : hébergez votre politique MTA-STS gratuitement avec CaptainDNS. Deux enregistrements DNS, zéro serveur web à gérer.

---

FAQ

Qu'est-ce qu'une attaque de downgrade SMTP ?

Une attaque de downgrade SMTP (ou STARTTLS stripping) consiste à empêcher la négociation du chiffrement TLS entre deux serveurs email. L'attaquant, positionné sur le réseau, supprime l'option STARTTLS de la réponse du serveur destinataire. Le serveur émetteur envoie alors l'email en texte clair, permettant à l'attaquant de lire le contenu du message.

Comment détecter une attaque de downgrade sur mes emails ?

Configurez TLS-RPT (RFC 8460) pour votre domaine. Les serveurs émetteurs compatibles enverront des rapports quotidiens listant les échecs de négociation TLS. Une augmentation soudaine des échecs peut indiquer une tentative de downgrade. Activez aussi MTA-STS en mode testing pour recevoir des rapports sans bloquer la livraison.

MTA-STS protège-t-il contre toutes les attaques de downgrade ?

MTA-STS protège contre le STARTTLS stripping et les attaques sur les certificats TLS. Il ne protège pas contre le spoofing DNS des enregistrements MX (utilisez DNSSEC pour cela) ni contre le détournement BGP. Pour une protection complète, combinez MTA-STS avec DNSSEC et, si possible, DANE/TLSA.

Quelle est la différence entre MTA-STS et DANE ?

MTA-STS publie une politique via HTTPS et fonctionne sans DNSSEC. DANE ancre le certificat TLS dans le DNS via des records TLSA et exige DNSSEC. MTA-STS souffre du problème TOFU (la première requête n'est pas protégée). DANE offre une vérification immédiate. Les deux sont complémentaires.

STARTTLS est-il suffisant pour sécuriser mes emails ?

Non. STARTTLS chiffre la connexion de manière opportuniste, mais ne protège pas contre les attaques de downgrade ni contre les certificats invalides. Un attaquant réseau peut supprimer l'option STARTTLS ou présenter un faux certificat. MTA-STS ou DANE sont nécessaires pour imposer le chiffrement TLS.

Les grands fournisseurs comme Gmail et Outlook sont-ils vulnérables ?

Gmail et Microsoft 365 supportent MTA-STS en tant que serveurs émetteurs : ils vérifient et respectent les politiques MTA-STS des domaines destinataires. Si votre domaine publie une politique MTA-STS en mode enforce, Gmail et Outlook refuseront d'envoyer en clair vers vos serveurs, même en cas de tentative de downgrade.

Faut-il activer MTA-STS et DANE en même temps ?

Ce n'est pas obligatoire, mais c'est recommandé si votre infrastructure le permet. MTA-STS est plus simple à déployer (pas besoin de DNSSEC) et couvre la majorité des serveurs émetteurs. DANE offre une sécurité supplémentaire (pas de TOFU) pour les serveurs qui le supportent. Les deux mécanismes coexistent sans conflit.

📖 Glossaire

• STARTTLS : extension SMTP (RFC 3207) qui permet de négocier une connexion TLS après l'établissement d'une connexion en clair sur le port 25.
• STARTTLS stripping : attaque consistant à supprimer l'annonce STARTTLS de la réponse du serveur pour empêcher le chiffrement.
• MTA-STS : Mail Transfer Agent Strict Transport Security (RFC 8461). Politique HTTPS qui impose le chiffrement TLS pour la réception d'emails.
• DANE : DNS-Based Authentication of Named Entities (RFC 7672). Mécanisme qui ancre le certificat TLS dans le DNS via des records TLSA.
• TLS-RPT : SMTP TLS Reporting (RFC 8460). Mécanisme de rapports sur les échecs de négociation TLS entre serveurs email.
• TOFU : Trust On First Use. Modèle de sécurité où la première connexion n'est pas vérifiée, mais les connexions suivantes sont validées par rapport à la première.
• DNSSEC : DNS Security Extensions. Système de signatures cryptographiques qui authentifie les réponses DNS et empêche leur falsification.

📚 Guides sécurité du transport email connexes

• MTA-STS vs DANE : quel protocole choisir pour sécuriser le transport email ? (à venir)
• De testing à enforce : stratégie de déploiement MTA-STS progressive (à venir)

Sources

• RFC 5321 - Simple Mail Transfer Protocol
• RFC 3207 - SMTP Service Extension for Secure SMTP over Transport Layer Security
• RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)
• RFC 7672 - SMTP Security via Opportunistic DNS-Based Authentication of Named Entities
• Google Transparency Report - Email encryption in transit