STARTTLS, SSL/TLS et SMTP : quel chiffrement pour vos emails ?
Par CaptainDNS
Publié le 17 février 2026
- SSL est obsolète depuis 2015 (RFC 7568) : le terme correct est TLS. STARTTLS n'est pas un protocole de chiffrement, c'est une commande qui active TLS sur une connexion existante
- STARTTLS est vulnérable aux attaques downgrade : un attaquant réseau peut supprimer l'annonce STARTTLS et forcer la communication en clair. MTA-STS et DANE corrigent cette faille
- TLS 1.3 est le standard recommandé pour SMTP en 2026 : handshake plus rapide (1-RTT), cipher suites plus sûres, forward secrecy obligatoire
- Configurez votre MTA avec TLS obligatoire en sortie (
smtp_tls_security_level = encryptsur Postfix) et déployez MTA-STS pour protéger les emails entrants
Vos emails transitent-ils vraiment chiffrés ? En 2024, Google rapporte que plus de 95 % des emails reçus par Gmail utilisent TLS (Transparency Report). Ce chiffre est rassurant, mais trompeur. STARTTLS est opportuniste par défaut. Les attaques downgrade sont documentées. Et beaucoup de serveurs acceptent encore TLS 1.0 ou des cipher suites faibles.
Ce guide va au-delà de la simple comparaison STARTTLS vs Implicit TLS. Il couvre quatre axes : le fonctionnement du handshake TLS, les apports de TLS 1.3 pour SMTP, les failles exploitées par les attaquants, et la configuration concrète sur Postfix, Exim et Exchange. Que vous administriez un serveur MX ou auditiez une infrastructure email, vous repartirez avec des actions concrètes.
SSL, TLS, STARTTLS : clarifier la terminologie
Les termes SSL, TLS et STARTTLS sont utilisés de manière interchangeable dans l'industrie email. C'est une source de confusion majeure, car ils désignent des choses fondamentalement différentes.
SSL est mort, TLS l'a remplacé
SSL (Secure Sockets Layer) est le prédécesseur de TLS. La dernière version, SSL 3.0, a été publiée en 1996 et officiellement abandonnée par la RFC 7568 en 2015 à cause de vulnérabilités critiques (POODLE, BEAST). Quand un fournisseur email mentionne "SSL" en 2026, il parle en réalité de TLS.
| Protocole | Année | Statut en 2026 |
|---|---|---|
| SSL 2.0 | 1995 | Interdit (RFC 6176) |
| SSL 3.0 | 1996 | Interdit (RFC 7568) |
| TLS 1.0 | 1999 | Obsolète (RFC 8996) |
| TLS 1.1 | 2006 | Obsolète (RFC 8996) |
| TLS 1.2 | 2008 | Acceptable |
| TLS 1.3 | 2018 | Recommandé |
En pratique : si votre serveur SMTP accepte encore SSL 3.0 ou TLS 1.0, il est vulnérable à des attaques connues. Désactivez ces protocoles.
STARTTLS n'est pas un protocole de chiffrement
STARTTLS est une commande SMTP (définie dans la RFC 3207) qui demande au serveur de basculer une connexion en clair vers une connexion chiffrée TLS. Ce n'est ni SSL, ni TLS, ni un protocole autonome : c'est un mécanisme de mise à niveau (upgrade) d'une connexion existante.
La confusion vient du nom : "STARTTLS" contient "TLS", mais il ne spécifie pas quelle version de TLS sera utilisée. La version négociée dépend de la configuration du client et du serveur.
Implicit TLS vs Explicit TLS (STARTTLS)
Il existe deux manières d'établir TLS sur une connexion SMTP :
| Méthode | Port typique | Fonctionnement | Analogie web |
|---|---|---|---|
| Explicit TLS (STARTTLS) | 25, 587 | Connexion en clair, puis upgrade via commande STARTTLS | HTTP puis redirection vers HTTPS |
| Implicit TLS | 465 | Connexion TLS dès le premier octet | HTTPS natif sur le port 443 |
Avec Explicit TLS, il y a toujours un moment où la communication est en clair (la phase EHLO avant STARTTLS). Avec Implicit TLS, il n'y a jamais de communication en clair. C'est cette différence qui a des conséquences majeures en termes de sécurité.
Comment fonctionne le chiffrement SMTP en pratique ?
Que vous utilisiez STARTTLS ou Implicit TLS, le chiffrement repose sur un handshake TLS. Ce processus de négociation détermine la version du protocole, le cipher suite utilisé, et l'échange de clés.
Le handshake TLS étape par étape
Voici ce qui se passe quand un serveur SMTP négocie TLS (après la commande STARTTLS ou dès la connexion sur le port 465) :
Avec TLS 1.2 (4 échanges, 2-RTT) :
- ClientHello : le client envoie les versions TLS et cipher suites qu'il supporte
- ServerHello : le serveur choisit la version TLS et le cipher suite, envoie son certificat
- Échange de clés : le client génère un secret pré-maître, le chiffre avec la clé publique du serveur
- Finished : les deux parties confirment que le canal est chiffré
Avec TLS 1.3 (2 échanges, 1-RTT) :
- ClientHello : le client envoie les versions TLS, cipher suites et ses clés Diffie-Hellman
- ServerHello + Finished : le serveur choisit les paramètres, envoie son certificat et confirme le chiffrement
TLS 1.3 fusionne des étapes : le handshake passe de 2-RTT à 1-RTT, ce qui réduit la latence d'établissement de connexion. Pour un serveur MX qui traite des milliers de connexions par heure, cette optimisation est significative.
TLS 1.2 vs TLS 1.3 : quelles différences pour SMTP ?
| Critère | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Handshake | 2-RTT | 1-RTT |
| Forward secrecy | Optionnel (dépend du cipher) | Obligatoire |
| Cipher suites | 37 suites (dont des faibles) | 5 suites (toutes robustes) |
| Compression | Supportée (vulnérable CRIME) | Supprimée |
| Renegotiation | Supportée (vecteur d'attaque) | Supprimée |
| 0-RTT resumption | Non | Oui (avec précautions) |
| RFC | RFC 5246 | RFC 8446 |
Le point clé pour SMTP : TLS 1.3 élimine les cipher suites faibles et rend la forward secrecy obligatoire. Avec TLS 1.2, un serveur peut négocier RSA sans échange Diffie-Hellman. Un attaquant qui obtient la clé privée peut alors déchiffrer toutes les communications passées. TLS 1.3 corrige ce risque : chaque session utilise des clés éphémères. Même si la clé privée fuit, les sessions passées restent protégées.
Cipher suites recommandées en 2026
Pour SMTP, configurez votre serveur avec ces cipher suites, dans cet ordre de préférence :
TLS 1.3 (pas de configuration nécessaire, les 5 suites sont toutes sûres) :
TLS_AES_256_GCM_SHA384TLS_CHACHA20_POLY1305_SHA256TLS_AES_128_GCM_SHA256
TLS 1.2 (restreindre aux suites avec forward secrecy) :
ECDHE-ECDSA-AES256-GCM-SHA384ECDHE-RSA-AES256-GCM-SHA384ECDHE-ECDSA-CHACHA20-POLY1305ECDHE-RSA-CHACHA20-POLY1305ECDHE-ECDSA-AES128-GCM-SHA256ECDHE-RSA-AES128-GCM-SHA256
Cipher suites à bannir : tout ce qui contient RC4, DES, 3DES, MD5, NULL, EXPORT, ou RSA sans ECDHE/DHE (pas de forward secrecy).
Les failles de STARTTLS et comment s'en protéger
STARTTLS est le mécanisme de chiffrement le plus répandu pour les connexions SMTP entre serveurs (port 25). Mais que se passe-t-il si un attaquant s'interpose avant l'activation du chiffrement ? La conception opportuniste de STARTTLS introduit des failles exploitables.
L'attaque downgrade STARTTLS
Quand un client SMTP se connecte à un serveur sur le port 25, il envoie EHLO et attend la liste des extensions. Si le serveur annonce 250-STARTTLS, le client sait qu'il peut basculer en TLS. Le problème : cet échange se fait en clair.
Un attaquant positionné entre le client et le serveur (man-in-the-middle) peut modifier la réponse EHLO pour supprimer la ligne 250-STARTTLS. Le client ne voit plus l'extension et continue en clair. Résultat : l'attaquant peut lire et modifier tous les emails en transit.
# Réponse légitime du serveur
250-mx1.captaindns.com
250-STARTTLS <-- l'attaquant supprime cette ligne
250 OK
# Ce que voit le client après l'attaque
250-mx1.captaindns.com
250 OK <-- pas de STARTTLS, connexion en clair
L'attaque STRIPTLS
STRIPTLS est une variante plus sophistiquée. L'attaquant ne modifie pas la réponse du serveur : il intercepte la commande STARTTLS envoyée par le client et retourne une fausse erreur (454 TLS not available). Le client abandonne TLS et continue en clair, croyant à un problème temporaire.
Ces deux attaques sont documentées et ont été observées à l'échelle nationale. En 2014, des chercheurs ont montré que plusieurs pays pratiquaient le STRIPTLS sur les connexions SMTP internationales.
MTA-STS : forcer TLS sur les emails entrants
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) est la réponse de l'IETF aux attaques downgrade sur SMTP. Le principe est simple : le domaine destinataire publie une politique exigeant TLS avec un certificat valide pour toute livraison d'email.
Comment ça fonctionne :
- Le domaine
captaindns.compublie un enregistrement DNS TXT_mta-sts.captaindns.comavec un identifiant de politique - Le domaine héberge un fichier
https://mta-sts.captaindns.com/.well-known/mta-sts.txtcontenant la politique - Le serveur expéditeur consulte cette politique avant de se connecter au MX
- Si la politique est en mode
enforce, le serveur expéditeur refuse de livrer en clair
# Enregistrement DNS
_mta-sts.captaindns.com. TXT "v=STSv1; id=20260217"
# Fichier de politique (HTTPS obligatoire)
version: STSv1
mode: enforce
mx: mx1.captaindns.com
mx: mx2.captaindns.com
max_age: 604800
Limite : MTA-STS dépend de HTTPS pour distribuer la politique. Si l'attaquant bloque l'accès au fichier, le serveur expéditeur ne peut pas récupérer la politique et peut revenir en clair. C'est le problème du TOFU (Trust On First Use) : la protection n'est effective qu'après la première récupération réussie.
DANE (TLSA) : authentifier le certificat via DNS
DANE (DNS-based Authentication of Named Entities, RFC 7672 pour SMTP) adopte une approche différente. Le domaine publie un enregistrement TLSA dans le DNS contenant l'empreinte du certificat TLS attendu. Pas de dépendance à HTTPS.
# Enregistrement TLSA pour le MX (port 25)
_25._tcp.mx1.captaindns.com. TLSA 3 1 1 a0b1c2d3e4f5...
Avantages de DANE :
- Pas de dépendance à HTTPS (contrairement à MTA-STS)
- Authentifie le certificat du serveur via DNSSEC (pas seulement "TLS obligatoire", mais "TLS avec ce certificat")
- Protège contre les attaques downgrade et les faux certificats
Prérequis : DANE nécessite DNSSEC sur le domaine. Sans DNSSEC, les enregistrements TLSA ne sont pas authentifiés et DANE est inefficace. C'est le principal frein à l'adoption : seulement environ 5 % des domaines utilisent DNSSEC en 2026.
| Mécanisme | Protège contre le downgrade | Authentifie le certificat | Prérequis |
|---|---|---|---|
| STARTTLS seul | Non | Non | Aucun |
| MTA-STS | Oui (après premier fetch) | Oui (CA publique) | HTTPS + DNS TXT |
| DANE | Oui | Oui (empreinte exacte) | DNSSEC + DNS TLSA |
| MTA-STS + DANE | Oui (double protection) | Oui (CA + empreinte) | DNSSEC + HTTPS |
Configurer le chiffrement TLS sur votre serveur SMTP
La théorie est claire. Comment appliquer ces principes sur votre serveur ? Voici la configuration concrète sur les trois MTA les plus utilisés.
Postfix : activer et durcir TLS
Postfix est le MTA le plus déployé sur les serveurs Linux. La configuration TLS se fait dans main.cf.
TLS entrant (serveur, réception d'emails) :
# Activer TLS pour les connexions entrantes
smtpd_tls_cert_file = /etc/letsencrypt/live/mx1.captaindns.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mx1.captaindns.com/privkey.pem
smtpd_tls_security_level = may
# Forcer TLS 1.2 minimum
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_protocols = >=TLSv1.2
# Cipher suites (TLS 1.2)
smtpd_tls_mandatory_ciphers = high
smtpd_tls_exclude_ciphers = aNULL, MD5, DES, 3DES, RC4
TLS sortant (client, envoi d'emails) :
# Activer TLS pour les connexions sortantes
smtp_tls_security_level = may
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
# Forcer TLS 1.2 minimum en sortie
smtp_tls_mandatory_protocols = >=TLSv1.2
smtp_tls_protocols = >=TLSv1.2
# Journaliser les connexions TLS (utile pour l'audit)
smtp_tls_loglevel = 1
Durcir davantage : remplacez smtp_tls_security_level = may par encrypt pour refuser toute connexion en clair en sortie. Attention : certains petits serveurs n'ont pas TLS, vos emails vers ces serveurs seront bloqués. Utilisez dane si DNSSEC est disponible.
Valeur security_level | Comportement |
|---|---|
none | Pas de TLS (déconseillé) |
may | TLS opportuniste (défaut, accepte le clair) |
encrypt | TLS obligatoire (refuse le clair) |
dane | TLS + vérification DANE via DNSSEC |
verify | TLS + vérification du hostname du certificat |
Exim : configuration TLS
Exim utilise une configuration modulaire. Les directives TLS se trouvent dans le bloc principal.
# Certificat et clé
tls_certificate = /etc/letsencrypt/live/mx1.captaindns.com/fullchain.pem
tls_privatekey = /etc/letsencrypt/live/mx1.captaindns.com/privkey.pem
# Annoncer STARTTLS
tls_advertise_hosts = *
# Forcer TLS 1.2 minimum
openssl_options = +no_sslv2 +no_sslv3 +no_tlsv1 +no_tlsv1_1
# Exiger TLS pour les connexions sortantes (optionnel)
tls_require_ciphers = ECDHE-ECDSA-AES256-GCM-SHA384:\
ECDHE-RSA-AES256-GCM-SHA384:\
ECDHE-ECDSA-AES128-GCM-SHA256:\
ECDHE-RSA-AES128-GCM-SHA256
Pour vérifier la configuration : exim -bV affiche les capacités TLS compilées.
Microsoft Exchange : imposer TLS
Sur Exchange (2019+), la configuration TLS se fait via les connecteurs de réception et d'envoi.
Connecteur de réception (emails entrants) :
# Forcer TLS sur le connecteur de réception
Set-ReceiveConnector "Default Frontend" -RequireTLS $true
# Désactiver les protocoles obsolètes (via registre Windows)
# HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
# Désactiver SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1
Connecteur d'envoi (emails sortants vers un partenaire spécifique) :
# Créer un connecteur d'envoi avec TLS obligatoire
New-SendConnector -Name "Vers captaindns.com (TLS)" `
-AddressSpaces "captaindns.com" `
-RequireTLS $true `
-TlsAuthLevel DomainValidation
Note : RequireTLS $true sur un connecteur d'envoi signifie qu'Exchange refuse d'envoyer en clair vers cette destination. Utilisez-le pour les domaines partenaires qui supportent TLS, pas pour un connecteur catch-all (des messages seraient bloqués).
Vérifier le chiffrement de vos emails
Configurer TLS ne suffit pas. Comment savoir si le chiffrement fonctionne réellement en production ? Voici trois méthodes de vérification.
Depuis Gmail : indicateur de chiffrement
Gmail affiche un cadenas dans l'en-tête des emails. Un cadenas gris signifie que l'email a transité en TLS (standard). Un cadenas rouge avec un point d'exclamation signifie que l'email n'a pas été chiffré en transit.
Pour les détails techniques, cliquez sur "Afficher l'original" dans Gmail : le header Received contient la version TLS et le cipher suite utilisés.
Received: from mx1.captaindns.com (mx1.captaindns.com [203.0.113.10])
by mx.google.com with ESMTPS id abc123
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384)
En ligne de commande : openssl s_client
Pour tester le chiffrement d'un serveur MX depuis un terminal :
# Test STARTTLS sur le port 25
openssl s_client -connect mx1.captaindns.com:25 -starttls smtp \
-servername mx1.captaindns.com 2>/dev/null | \
grep -E "Protocol|Cipher|Verify"
# Résultat attendu
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Verify return code: 0 (ok)
Si Protocol affiche TLSv1 ou TLSv1.1, votre serveur utilise un protocole obsolète. Si Verify return code est différent de 0, le certificat a un problème.
Avec l'outil CaptainDNS
Le SMTP/MX Connectivity Tester de CaptainDNS teste automatiquement tous les MX d'un domaine et vérifie pour chacun : la version TLS négociée, le cipher suite, la validité du certificat (expiration, SAN, chaîne de confiance) et le support STARTTLS. Le résultat inclut un scoring par serveur MX avec des codes de diagnostic explicites.
Plan d'action recommandé
- Auditez votre configuration actuelle : vérifiez la version TLS et les cipher suites de chaque MX avec
openssl s_clientou le SMTP/MX Connectivity Tester - Désactivez SSL 3.0, TLS 1.0 et TLS 1.1 : ces protocoles sont obsolètes (RFC 8996) et vulnérables. TLS 1.2 est le minimum, TLS 1.3 est recommandé
- Restreignez les cipher suites : supprimez RC4, DES, 3DES, MD5 et les suites sans forward secrecy (ECDHE/DHE obligatoire)
- Déployez MTA-STS : publiez une politique
enforcepour protéger vos emails entrants contre les attaques downgrade - Activez DANE si DNSSEC est disponible : publiez des enregistrements TLSA pour authentifier les certificats de vos MX via DNS
FAQ
Quelle est la différence entre STARTTLS et SSL/TLS ?
SSL et TLS sont des protocoles de chiffrement (SSL étant l'ancêtre obsolète de TLS). STARTTLS n'est ni SSL ni TLS : c'est une commande SMTP qui active le chiffrement TLS sur une connexion initialement en clair. Après STARTTLS, la connexion utilise TLS (1.2 ou 1.3), mais la phase initiale avant la commande reste vulnérable aux attaques downgrade.
Faut-il encore utiliser SSL pour SMTP ?
Non. SSL 2.0 et 3.0 sont interdits par les RFC 6176 et 7568. TLS 1.0 et 1.1 sont obsolètes depuis la RFC 8996. Tout serveur SMTP doit utiliser TLS 1.2 au minimum, et TLS 1.3 de préférence. Si un fournisseur mentionne "SSL", il désigne en réalité TLS.
Comment forcer le chiffrement TLS sur les emails sortants ?
Sur Postfix, configurez smtp_tls_security_level = encrypt dans main.cf pour refuser toute connexion en clair en sortie. Sur Exchange, activez RequireTLS sur le connecteur d'envoi. Attention : les emails vers des serveurs sans TLS seront bloqués. Utilisez le mode dane ou may si vous devez livrer à tous les destinataires.
Qu'est-ce que DANE et comment ça sécurise SMTP ?
DANE (DNS-based Authentication of Named Entities) permet de publier l'empreinte du certificat TLS d'un serveur MX dans un enregistrement DNS TLSA. Le serveur expéditeur vérifie que le certificat présenté correspond à l'empreinte publiée, ce qui empêche les attaques par faux certificat et les downgrades. DANE nécessite DNSSEC pour garantir l'authenticité des enregistrements DNS.
Comment vérifier si mes emails transitent en TLS ?
Trois méthodes : (1) dans Gmail, cliquez sur "Afficher l'original" et cherchez les headers Received avec la version TLS, (2) en ligne de commande, utilisez openssl s_client -connect mx:25 -starttls smtp pour tester la négociation, (3) utilisez le SMTP/MX Connectivity Tester de CaptainDNS pour un diagnostic automatisé de tous vos MX.
Quels cipher suites utiliser pour SMTP en 2026 ?
Pour TLS 1.3 : toutes les suites sont sûres (AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305). Pour TLS 1.2 : utilisez uniquement les suites ECDHE avec AES-GCM (forward secrecy obligatoire). Bannissez RC4, DES, 3DES, MD5, les suites NULL, EXPORT, et les échanges RSA sans ECDHE/DHE.
Quelle est la différence entre MTA-STS et DANE ?
MTA-STS publie une politique TLS via HTTPS (fichier .well-known/mta-sts.txt) qui indique que le domaine exige TLS. DANE publie l'empreinte du certificat via un enregistrement DNS TLSA sécurisé par DNSSEC. MTA-STS est plus facile à déployer (pas besoin de DNSSEC) mais souffre du problème TOFU (Trust On First Use). DANE offre une authentification plus forte mais nécessite DNSSEC. Les deux peuvent être déployés simultanément.
Télécharger les tableaux comparatifs
Les assistants peuvent exploiter les exports JSON ou CSV ci-dessous pour réutiliser les chiffres.
Glossaire
- TLS (Transport Layer Security) : Protocole de chiffrement des communications réseau. Successeur de SSL, versions actuelles : TLS 1.2 et TLS 1.3 (RFC 8446).
- STARTTLS : Commande SMTP (RFC 3207) qui demande la mise à niveau d'une connexion en clair vers TLS. Ce n'est pas un protocole de chiffrement en soi.
- Implicit TLS : Mode de connexion où TLS est établi dès le premier octet, sans phase en clair. Utilisé sur le port 465 (SMTP) et le port 443 (HTTPS).
- Forward secrecy : Propriété cryptographique garantissant que la compromission d'une clé privée ne permet pas de déchiffrer les sessions passées. Assurée par les échanges de clés ECDHE/DHE.
- Cipher suite : Combinaison d'algorithmes utilisés pour une session TLS : échange de clés (ECDHE), authentification (RSA/ECDSA), chiffrement (AES-GCM) et hachage (SHA384).
- DANE : DNS-based Authentication of Named Entities (RFC 7672 pour SMTP). Permet d'authentifier le certificat TLS d'un serveur via un enregistrement DNS TLSA sécurisé par DNSSEC.
- MTA-STS : Mail Transfer Agent Strict Transport Security (RFC 8461). Politique publiée via HTTPS qui force les serveurs expéditeurs à utiliser TLS avec un certificat valide.
- Attaque downgrade : Attaque réseau qui force une connexion à utiliser un protocole moins sécurisé, typiquement en supprimant l'annonce STARTTLS ou en modifiant la négociation TLS.
- TOFU : Trust On First Use. Modèle de sécurité où la confiance est établie lors de la première interaction. MTA-STS souffre de ce problème : la première récupération de la politique est vulnérable.
Vérifiez le chiffrement TLS de vos serveurs MX : Utilisez notre SMTP/MX Connectivity Tester pour tester la version TLS, les cipher suites et la validité du certificat de chaque MX, en quelques secondes.
📚 Guides SMTP et connectivité email connexes
- Les ports SMTP expliqués : 25, 465, 587, 2525 : rôle, chiffrement et cas d'usage de chaque port SMTP
- Comment tester la connectivité SMTP de vos serveurs MX : guide pas-à-pas avec telnet et openssl
- Port 25 bloqué : diagnostic et solutions par hébergeur (à venir)
