Chiffrement email : ce qui est protégé, et ce qui ne l’est pas

Sommaire

Deux mécanismes différents derrière le même mot

Quand un fournisseur annonce que vos emails sont chiffrés, il parle presque toujours de TLS entre serveurs. Le message est protégé pendant le trajet, puis déchiffré et stocké en clair par chaque serveur qui le relaie. Votre hébergeur mail peut le lire, l'indexer, le sauvegarder, le remettre sur réquisition.

Le chiffrement de bout en bout fonctionne autrement : le corps du message est chiffré sur le poste de l'expéditeur avec la clé publique du destinataire, et personne d'autre ne peut le déchiffrer. Ni le serveur d'envoi, ni celui de réception, ni un opérateur au milieu. En contrepartie, il faut avoir récupéré la clé du correspondant avant d'écrire, et la recherche plein texte côté serveur ne fonctionne plus.

Les deux ne s'excluent pas. Un message S/MIME transite lui aussi sur une session TLS, ce qui masque au passage le sujet et les adresses d'enveloppe aux yeux d'un observateur réseau.

Critère	TLS / STARTTLS	S/MIME ou OpenPGP
Ce qui est protégé	Le trajet entre deux serveurs	Le corps et les pièces jointes
Qui peut lire le contenu	Chaque serveur du trajet	Le seul destinataire
Action de l'utilisateur	Aucune	Échange de clés ou de certificat
Sujet du message	Masqué pendant le transit	En clair dans les en-têtes stockés
Recherche côté serveur	Fonctionne	Impossible sur le corps
Références	RFC 3207, RFC 8314	RFC 8551, RFC 9580

STARTTLS, ports et vérification réelle du transit

Le port 25 sert au relais entre serveurs de messagerie. Le TLS y est opportuniste : le serveur annonce la capacité STARTTLS dans sa réponse EHLO, l'expéditeur bascule en chiffré s'il la voit, sinon il envoie en clair. Pour la soumission depuis un client, la RFC 6409 décrit le port 587 avec STARTTLS, et la RFC 8314 a rétabli en 2018 le port 465 en TLS implicite, chiffré dès la première octet de la connexion.

Pour tester un serveur, la commande de référence reste openssl. Un `openssl s_client -starttls smtp -crlf -connect smtp.exemple.fr:587` affiche la chaîne de certificats, la version TLS négociée et une ligne `Verify return code: 0 (ok)` si la validation passe. Sur le port 465, retirez l'option `-starttls smtp`.

Côté message reçu, la preuve se lit dans les en-têtes Received. Gmail écrit `with ESMTPS id ... (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256)`, Postfix écrit plutôt `(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))`. Un simple `with ESMTP`, sans le S final, signifie que ce saut s'est fait en clair.

Le cas de panne classique vient d'un équipement réseau. Une inspection SMTP applicative, typiquement `inspect esmtp` sur un pare-feu Cisco ASA, remplace l'annonce `250-STARTTLS` par `250-XXXXXXXX` pour pouvoir analyser le flux. Les deux serveurs concluent qu'aucun chiffrement n'est disponible et basculent en clair, sans la moindre erreur dans les journaux. Si vos messages sortent en clair alors que les deux extrémités supportent TLS, cherchez l'inspection SMTP avant de toucher à la configuration mail.

Port	Usage	Mode de chiffrement
25	Relais entre serveurs (MTA)	STARTTLS opportuniste (RFC 3207)
465	Soumission client	TLS implicite (RFC 8314)
587	Soumission client (RFC 6409)	STARTTLS
143	IMAP	STARTTLS (RFC 2595)
993	IMAP	TLS implicite
110	POP3	STARTTLS
995	POP3	TLS implicite

Rendre le TLS obligatoire : MTA-STS, DANE et TLS-RPT

STARTTLS seul ne résiste pas à un attaquant actif, puisqu'il suffit de retirer l'annonce pour faire retomber la session en clair. Trois mécanismes corrigent ce défaut, tous publiés dans le DNS du domaine destinataire.

MTA-STS (RFC 8461) repose sur un enregistrement TXT `_mta-sts.exemple.fr` contenant `v=STSv1; id=20260816120000`, et sur un fichier servi en HTTPS à l'adresse `https://mta-sts.exemple.fr/.well-known/mta-sts.txt`. Ce fichier liste les MX autorisés, un `mode` (`none`, `testing` ou `enforce`) et un `max_age` en secondes, plafonné à 31557600. En mode enforce, un serveur d'envoi conforme refuse de livrer si le certificat du MX ne valide pas ou si le nom ne correspond pas.

DANE pour SMTP (RFC 7672) atteint le même objectif via un enregistrement TLSA sur `_25._tcp.mx1.exemple.fr`, mais impose une zone signée DNSSEC de bout en bout. TLS-RPT (RFC 8460) complète l'ensemble : un TXT sur `_smtp._tls.exemple.fr` avec `v=TLSRPTv1; rua=mailto:tlsrpt@exemple.fr` déclenche l'envoi de rapports JSON quotidiens listant les sessions échouées.

Le scénario qui fait mal : votre certificat MX expire un vendredi soir alors que vos correspondants appliquent MTA-STS en enforce. Leurs serveurs ne rejettent pas immédiatement, ils diffèrent. Sur Postfix, `maximal_queue_lifetime` vaut 5 jours par défaut, donc les messages restent en file puis repartent en bounce le mercredi suivant. Les rapports TLS-RPT arrivent avec un jour de décalage, ce qui laisse la supervision de la date d'expiration du certificat comme seule alerte utile.

Vérifier la politique publiée : `dig +short TXT _mta-sts.exemple.fr`
Lire le fichier de politique : `curl https://mta-sts.exemple.fr/.well-known/mta-sts.txt`
Vérifier un enregistrement TLSA : `dig +short TLSA _25._tcp.mx1.exemple.fr`
Commencer en `mode: testing` pendant plusieurs semaines avant de passer en `enforce`

S/MIME et OpenPGP : le chiffrement de bout en bout en pratique

S/MIME s'appuie sur un certificat X.509 délivré par une autorité de certification, exactement comme un certificat de site web mais lié à une adresse email. Outlook, Apple Mail et Thunderbird le gèrent nativement, ce qui en fait le choix par défaut en entreprise quand une PKI existe déjà. Depuis le 1er septembre 2023, ces certificats sont encadrés par les Baseline Requirements S/MIME du CA/Browser Forum, ce qui a raréfié les offres gratuites.

OpenPGP ne dépend d'aucune autorité : chacun génère sa paire de clés et publie la partie publique. Thunderbird intègre OpenPGP directement depuis la version 78, sans extension. La génération se fait avec `gpg --full-generate-key`, l'export avec `gpg --armor --export alice@exemple.fr > cle.asc`, l'envoi avec `gpg --encrypt --sign --armor --recipient bob@exemple.fr message.txt`. Le Web Key Directory évite l'échange manuel : la clé est servie sous `/.well-known/openpgpkey/` du domaine, et `gpg --locate-keys bob@exemple.fr` la récupère toute seule.

Deux limites à connaître avant de déployer. D'abord, le sujet, les adresses From et To et les lignes Received ne sont pas chiffrés : S/MIME et OpenPGP protègent le corps MIME, pas l'enveloppe. Certains clients réencapsulent le message pour masquer le sujet, mais le support reste inégal et le destinataire doit implémenter la même chose. Ensuite, l'attaque EFAIL publiée en 2018 a montré qu'un client affichant du HTML distant pouvait exfiltrer le texte déchiffré vers un serveur tiers. Les clients ont été corrigés, mais couper le chargement automatique des images externes reste la précaution la plus efficace.

Critère	S/MIME	OpenPGP
Modèle de confiance	Autorité de certification X.509	Toile de confiance ou WKD
Spécification	RFC 8551	RFC 9580 (ex-RFC 4880), RFC 3156 pour MIME
Support natif	Outlook, Apple Mail, Thunderbird	Thunderbird 78 et suivants, GnuPG
Coût	Certificat souvent payant	Gratuit
Révocation	CRL et OCSP	Certificat de révocation à publier soi-même
Terrain de prédilection	Entreprise avec annuaire et PKI	Correspondants techniques dispersés

Ce que le chiffrement email ne protège pas

Les métadonnées restent lisibles dans tous les cas. Qui écrit à qui, à quelle heure, depuis quelle IP, avec quelle taille de pièce jointe : un observateur reconstitue un organigramme sans jamais déchiffrer une ligne. C'est la raison pour laquelle le chiffrement de contenu ne remplace pas une politique de rétention.

Confusion fréquente : SPF, DKIM et DMARC ne chiffrent rien. DKIM appose une signature cryptographique sur certains en-têtes et sur le corps pour prouver l'origine et détecter une altération, mais le message reste parfaitement lisible. Authentifier et chiffrer sont deux objectifs séparés, avec des enregistrements DNS séparés.

Le poste client reste le maillon faible. Une clé privée protégée par une passphrase faible, ou un poste compromis, annulent tout le dispositif : le message déchiffré s'affiche à l'écran, l'attaquant aussi le voit. L'authentification à deux facteurs sur le compte mail et une passphrase sérieuse sur la clé privée font partie du même chantier.

Dernier point sur les messageries dites chiffrées. Entre deux comptes de la même plateforme, le bout en bout s'applique automatiquement. Vers un destinataire Gmail ou Outlook, la plateforme retombe soit sur du TLS ordinaire, soit sur un lien protégé par un mot de passe qu'il faut transmettre par un autre canal. Rien de magique se produit à la frontière entre deux fournisseurs.

Chiffrer un email recouvre deux mécanismes distincts : TLS, qui protège le message pendant son trajet entre serveurs, et le chiffrement de bout en bout (S/MIME ou OpenPGP), qui le rend illisible pour tout le monde sauf le destinataire. Le premier est automatique mais laisse votre fournisseur lire le contenu, le second demande un échange de clés et laisse malgré tout le sujet et les adresses en clair.

Questions fréquentes

Gmail chiffre-t-il vraiment mes emails ?

Gmail chiffre en TLS le trajet vers le serveur d'en face quand celui-ci l'accepte, et chiffre les données au repos sur ses disques. Google conserve en revanche la capacité de lire le contenu, ce qui exclut le bout en bout. L'interface affiche un indicateur de cadenas rouge quand le serveur destinataire ne supporte pas TLS.

STARTTLS suffit-il à sécuriser un serveur de messagerie ?

Non face à un attaquant actif. Comme le passage en TLS est négocié en clair, un intermédiaire qui supprime l'annonce STARTTLS fait retomber toute la session en clair sans alerte. Publier une politique MTA-STS ou des enregistrements TLSA avec DANE ferme cette porte.

Le sujet d’un message chiffré est-il protégé ?

Pas avec S/MIME ni OpenPGP dans leur usage courant : ils chiffrent le corps MIME, pas les en-têtes. Le sujet, l'expéditeur et le destinataire restent lisibles sur les serveurs. Certains clients encapsulent le message d'origine pour masquer le sujet, mais cela suppose un support des deux côtés.

S/MIME ou OpenPGP, lequel choisir ?

S/MIME si vous avez déjà un annuaire et une autorité de certification interne : le déploiement se pilote de façon centralisée et Outlook le gère sans extension. OpenPGP si vos correspondants sont dispersés et techniques, puisque personne n'a besoin d'acheter un certificat. Les deux formats ne sont pas interopérables entre eux.

Comment vérifier qu’un message est arrivé chiffré ?

Affichez la source du message et lisez les lignes Received de bas en haut. Chaque saut ayant utilisé TLS porte la mention ESMTPS avec la version et la suite négociées, par exemple version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384. Un saut affichant ESMTP sans S s'est fait en clair, même si les autres étaient chiffrés.

Testez vos connaissances

Quiz rapide Question 1 sur 3

Quel port correspond à la soumission de messages en TLS implicite ?