En 2013, des documents divulgués par Edward Snowden ont révélé que des agences de renseignement interceptaient le trafic email entre les centres de données des principaux fournisseurs. Les connexions n'étaient pas chiffrées — l'email circulait en clair sur des câbles en fibre optique, facilement lisible par quiconque pouvait les mettre sur écoute.
La réponse a été rapide. Google, Microsoft, Yahoo et d'autres ont rapidement déployé du chiffrement entre leurs serveurs. La technologie utilisée était STARTTLS, un mécanisme qui existait depuis des années mais n'était pas universellement implémenté. En quelques mois, la majorité du trafic email entre les grands fournisseurs était chifrée.
STARTTLS n'est pas parfait, mais c'est le socle du chiffrement des emails en transit. Comprendre son fonctionnement permet de saisir à la fois ce qu'il protège et ses limites.
Comment fonctionne STARTTLS
STARTTLS est une extension SMTP qui met à niveau une connexion en clair vers une connexion chiffrée. Son nom décrit littéralement ce qui se passe : vous démarrez TLS.
Voici la séquence. Un client se connecte à un serveur sur un port SMTP standard. La connexion débute non chiffrée — les deux côtés voient tout en clair. Le client envoie une commande EHLO, et le serveur répond avec ses capacités, incluant "250-STARTTLS" s'il prend en charge le chiffrement.
Si le client veut du chiffrement (et il devrait), il envoie la commande STARTTLS. Le serveur répond avec "220 Ready to start TLS." À ce stade, les deux parties effectuent un handshake TLS — le même processus qui sécurise les connexions HTTPS. Une fois le handshake terminé, tout ce qui suit est chifré.
Le client recommence ensuite la conversation SMTP, mais cette fois chiffrée. Il envoie un autre EHLO, s'authentifie si nécessaire, et procède à l'envoi d'email. Quiconque observe le réseau ne voit que des données chiffrées illisibles.
Cette approche "upgrade" s'appelle le chiffrement opportuniste. La connexion commence non chiffrée, et le chiffrement est ajouté si les deux côtés le supportent. Cela diffère de TLS implicite (utilisé sur le port 465), où la connexion est chifrée dès le tout premier octet.
Pourquoi l'approche de mise à niveau
Vous pouvez vous demander pourquoi l'email ne commence pas simplement chifré, comme HTTPS. La réponse tient à la compatibilité historique.
SMTP a été conçu en 1982, bien avant que le chiffrement ne soit une préoccupation. Des millions de serveurs de messagerie ont été déployés parlant SMTP non chiffré. Quand le chiffrement est devenu important, le protocole devait évoluer sans casser l'infrastructure existante.
STARTTLS a résolu cela en rendant le chiffrement optionnel et négocié. Les vieux serveurs qui ne le supportent pas n'annoncent simplement pas la capacité, et les connexions se poursuivent en clair. Les nouveaux serveurs peuvent passer au chiffrement lorsqu'ils parlent à d'autres nouveaux serveurs. L'écosystème a pu migrer progressivement.
Cette compatibilité rétroactive s'accompagne de compromis. Le mécanisme d'upgrade crée une fenêtre de vulnérabilité, et le caractère optionnel signifie que le chiffrement n'est pas garanti. Mais il a permis au chiffrement de se répandre dans l'écosystème email sans exiger un flag day où tout aurait changé d'un coup.
Les limites de sécurité
STARTTLS apporte une protection réelle, mais il présente des faiblesses connues.
Le problème principal est l'attaque de rétrogradation. Comme la négociation STARTTLS se fait en clair, un attaquant capable d'intercepter le trafic peut retirer l'annonce de la capacité STARTTLS. Le client pense que le serveur ne supporte pas le chiffrement et continue en clair. Aucun des deux côtés ne sait que l'attaque a eu lieu.
Ce n'est pas théorique. Des chercheurs ont documenté des FAI et des États-nations réalisant des attaques de STARTTLS stripping. Votre email peut être chifré quand il quitte votre serveur et chifré quand il arrive à destination, mais, quelque part au milieu, quelqu'un a retiré le chiffrement et a tout lu.
La validation des certificats est une autre faiblesse. Beaucoup de serveurs de messagerie ne valident pas strictement les certificats pendant STARTTLS. Ils acceptent des certificats auto-signés, expirés, ou pour le mauvais nom d'hôte. Cela facilite le déploiement mais signifie qu'un attaquant de type man-in-the-middle pourrait présenter un faux certificat et intercepter le trafic.
Ces limites expliquent pourquoi MTA-STS et DANE existent — ils fournissent des mécanismes pour exiger le chiffrement et valider les certificats, comblant les lacunes que STARTTLS laisse ouvertes.
STARTTLS vs TLS implicite
L'email prend en charge deux approches de chiffrement : STARTTLS (TLS explicite) et TLS implicite.
Avec STARTTLS, la connexion commence en clair et est mise à niveau. C'est utilisé sur le port 587 pour la soumission et peut être utilisé sur le port 25 pour le transfert serveur à serveur.
Avec TLS implicite, la connexion est chifrée dès le premier octet. Il n'y a pas de phase en clair, pas de négociation d'upgrade. C'est utilisé sur le port 465 pour la soumission.
TLS implicite est sans doute plus sécurisé car il n'y a aucune opportunité d'attaques de rétrogradation lors de l'établissement de la connexion. Le handshake TLS se produit immédiatement ; s'il échoue, la connexion échoue. Il n'y a pas de repli en clair.
Cependant, STARTTLS est plus largement déployé, surtout pour la communication serveur à serveur. Le port 25 avec STARTTLS est la manière dont la plupart des emails circulent entre serveurs. Le TLS implicite sur le port 465 est principalement utilisé pour la soumission côté client.
Pour votre propre soumission d'email, les deux approches conviennent si elles sont correctement implémentées. Pour l'email serveur à serveur, STARTTLS sur le port 25 est la norme, complété par MTA-STS ou DANE pour des garanties plus fortes.
Vérifier la prise en charge de STARTTLS
Vous pouvez vérifier si un serveur prend en charge STARTTLS avec des outils en ligne de commande.
Connectez-vous avec telnet ou netcat au port SMTP et envoyez une commande EHLO. La réponse du serveur liste ses capacités. Si "250-STARTTLS" apparaît dans la liste, le serveur supporte l'upgrade vers le chiffrement.
Pour tester la connexion TLS réelle, utilisez OpenSSL : "openssl s_client -starttls smtp -connect mail.example.com:25". Cela se connecte, émet STARTTLS, effectue le handshake TLS, et vous affiche le certificat et les détails de la connexion.
Des outils en ligne comme CheckTLS et MXToolbox peuvent tester la prise en charge de STARTTLS pour les serveurs de messagerie de n'importe quel domaine. Ils indiquent si le chiffrement est disponible et donnent des détails sur les certificats utilisés.
Surveiller STARTTLS sur l'ensemble de votre trafic email aide à identifier les serveurs qui ne supportent pas le chiffrement. Si vous envoyez un email sensible vers un domaine qui ne supporte pas STARTTLS, cet email circule en clair.
STARTTLS en pratique
La plupart des infrastructures email modernes supportent STARTTLS, mais la qualité de l'implémentation varie.
Les principaux fournisseurs d'email (Gmail, Microsoft, Yahoo) supportent STARTTLS et l'utilisent pour la grande majorité de leur trafic email. Google publie des rapports de transparence montrant quel pourcentage des emails vers et depuis Gmail utilisent le chiffrement — c'est au-dessus de 90% pour la plupart du trafic.
Les serveurs de messagerie d'entreprise varient beaucoup. Des déploiements Exchange et Google Workspace bien entretenus supportent STARTTLS. Des serveurs plus anciens ou mal entretenus peuvent ne pas le faire. Lors de l'envoi vers des domaines d'entreprise, le chiffrement n'est pas garanti.
Les serveurs de messagerie auto-hébergés devraient toujours activer STARTTLS. La configuration est simple dans les logiciels MTA modernes. Il n'y a aucune bonne raison d'exploiter un serveur de messagerie non chiffré en 2024.
Les services email (SendGrid, Mailgun, etc.) supportent STARTTLS pour les connexions entrantes et sortantes. Quand vous envoyez via ces services, ils utiliseront le chiffrement lorsque la destination le supporte.
Au-delà de STARTTLS
STARTTLS fournit un chiffrement en transit, mais ce n'est pas du chiffrement de bout en bout. L'email est déchiffré à chaque serveur le long du chemin. Si vous avez besoin d'un vrai chiffrement de bout en bout — où seuls l'expéditeur et le destinataire peuvent lire le message — il faut S/MIME ou PGP.
Pour une sécurité de transport plus forte, MTA-STS et DANE traitent les faiblesses de STARTTLS. MTA-STS publie une politique exigeant le chiffrement et spécifiant les certificats valides. DANE utilise DNSSEC pour authentifier les certificats. Les deux empêchent les attaques de rétrogradation que STARTTLS seul ne peut pas stopper.
L'écosystème email évolue progressivement vers un chiffrement obligatoire. Google et Microsoft pénalisent de plus en plus les connexions non chiffrées dans leur scoring de spam. De futures normes pourraient exiger le chiffrement plutôt que de le rendre optionnel.
Frequently asked questions
STARTTLS chiffre-t-il mon email de bout en bout?
Non. STARTTLS chiffre les emails en transit entre les serveurs, mais l'email est déchiffré à chaque serveur. Les administrateurs de serveur et toute personne ayant accès au serveur peuvent lire le contenu. Pour un chiffrement de bout en bout, utilisez S/MIME ou PGP.
STARTTLS est-il la même chose que TLS?
STARTTLS est une commande qui initie le chiffrement TLS sur une connexion existante. TLS est le protocole de chiffrement lui-même. STARTTLS est le mécanisme; TLS est ce qu'il active.
Pourquoi certains emails restent-ils non chiffrés?
STARTTLS est optionnel. Si le serveur destinataire ne le supporte pas, ou si un man-in-the-middle supprime la capacité, l'email retombe en clair. MTA-STS et DANE aident à prévenir cela, mais l'adoption n'est pas universelle.
Dois-je exiger STARTTLS pour tous les emails?
Pour l'envoi, vous pouvez privilégier le chiffrement mais devrez peut-être permettre un repli pour les serveurs qui ne le supportent pas. Pour la réception, exiger STARTTLS peut amener à rejeter des emails légitimes de la part d'expéditeurs mal configurés. MTA-STS vous permet d'exiger le chiffrement avec plus de nuances.