Emails sécurisés

L'exemple d'un SMTP en clair

Supposons que vous vouliez envoyer un email à quelqu'un. Supposons aussi que vous n'ayez pas prêté attention à la configuration de votre client email: celui-ci va utiliser un serveur SMTP en clair. Que se passe-t-il alors quand vous envoyez un mail?

Dans cet article, je prendrai test-smtp@reinom.com en guise d'exemple non sécurisé.
Le client mail (Thunderbird) est configuré pour utiliser un serveur SMTP en clair ("Connection security: None")
Si vous souhaitez refaire ce setup, n'oubliez pas de sélectionner le bon "Outgoing Server" pour votre compte de test
				Client email (expéditeur)
				↓ CLAIR (SMTP) ↓
				Serveur SMTP
				↓ CLAIR (IMAP) ↓
				Client email (destinataire)
			
On a, sommairement, ce setup avec un expéditeur, un serveur SMTP et un destinataire

Je vais donc lancer Wireshark, pour simuler un espionnage sur le réseau (un sniffer), et je vais envoyer un email depuis mon compte de test (test-smtp@reinom.com) vers mon email habituel.

Wireshark voit tout

Une fois l'email envoyé (ce que je ne vais pas montrer tiens, pour prouver que je retrouverai le contenu de l'email très facilement!), je filtre sur le protocole SMTP dans Wireshark.

En filtrant sur "SMTP", les paquets apparaissent immédiatement
Clic droit, suivre, flux TCP et on a la reconstitution de l'email envoyé!

Il n'est donc pas du tout recommandé d'utiliser une connexion SMTP non chiffrée. Mais allons plus loin…

Connexion SMTP chiffrée

On peut se dire qu'un moyen de corriger le problème est d'utiliser une connexion chiffrée au SMTP.

On change la "Connexion security" pour "SSL/TLS" et on réessaie
Wirteshark ne voit en effet plus rien! Est-on sauvé? Pas du tout…!
				Client email (expéditeur)
				↓ SECURE (SMTP) ↓
				Serveur SMTP
				↓ CLAIR (IMAP) ↓
				Client email (destinataire)
			
On a donc sécurisé l'échange client ↔ SMTP mais qu'en est-il de l'IMAP?

IMAP en clair: nouvelle fuite!

On reprend notre compte email de test et on le configure pour que l'IMAP soit en clair
Dès que notre client email (destinataire) va demander au serveur s'il y a des messages, Wireshark le voit.
Et s'il y a de nouveaux messages, Wireshark en voit le contenu aussi!

Comme pour un SMTP en clair, un IMAP en clair = confidentialité zéro.

IMAP SSL/TLS

On va donc appliquer la même protection côté IMAP: au lieu d'ouvrir une connexion directe, en clair, on va d'abord ouvrir une connexion SSL/TLS et on l'utilisera pour discuter avec le serveur en IMAP. Notez que le client et le serveur négocieront le meilleur chiffrement (TLS v1.3 typiquement) et que vous ne semblez pas avoir la main là-dessus depuis les paramètres de thunderbird

En pratique, je ne serai pas étonné qu'on puisse paramétrer plus finement cette connexion et la forcer en TLS1.3, depuis "about:config" mais je n'ai pas essayé

On configure donc la "Connexion Security" pour être "SSL/TLS"

Notez que "Normal Password" est la seule option offerte par OVH: il se peut qu'elle permette une "replay attack" mais la connexion SSL/TLS devrait suffire à empêcher les replay attacks

Et voilà! Quand on reçoit un message, Wireshark ne voit plus rien!
En pratique, bien sûr, Wireshark voit tous les paquets, mais comme ceux-ci sont des paquets SSL/TLS (port 993), Wireshark n'est pas en mesure d'en déchiffrer le contenu

Are we safe now?

Spoiler: non. Car rien ne dit qu'un seul serveur SMTP existe sur la chaine de transmission! Jusqu'ici, nous avons sécurisé les communications avec les "endpoints", mais la chaine intermédiaire reste non-sécurisée.

				Client email (expéditeur)
				↓ SECURE (SMTP) ↓
				Serveur SMTP
				↓ SECURE? CLEAR? ↓
				Serveur SMTP (rogue?)
				↓ SECURE? CLEAR? ↓
				Serveur SMTP (hacké?)
				↓ SECURE? CLEAR? ↓
				Serveur SMTP (digne de confiance?)
				↓ SECURE (IMAP) ↓
				Client email (destinataire)
			
On a sécurisé le début et la fin de la chaine, mais pas le milieu!

Mais, osef, les serveurs sont de confiance non?

Eh bien, pas toujours… Imaginez que vous ayez envoyé des données confidentielles, que vous discutiez des manières de contourner une loi, de favoriser l'implantation d'une multi-nationale dans un pays, ou que vous divulguiez à une entreprise une faille sur ses produits. Dans tous ces cas, l'assurance que les emails ne seront pas consultés par une tierce personne est capitale.

On observe que certains serveurs SMTP semblent chiffrer l'email quand ils le transmettent, mais pas tous

Si vous n'avez que des serveurs de confiance, alors oui, vous pourriez vous contenter de chiffrer la connexion SMTP/IMAP entre les clients et les serveurs, ainsi qu'entre les serveurs. C'est le cas pour les emails internes d'une organisation par exemple. Mais si vous communiquez avec d'autres entreprises, avec l'extérieur, la donne change: cette solution n'est plus possible.

OpenPGP

La solution recommandée pour le chiffrement dit "de bout en bout", c'est à dire depuis le client email expéditeur jusqu'au client email destinataire, est OpenPGP. Elle va nous permettre d'échanger les email de manière sécurisée, même si le canal SMTP ou IMAP n'utilisait pas SSL/TLS

En pratique, il est fortement recommandé de garder SMTP/IMAP sur SSL/TLS même avec un chiffrement OpenPGP. En effet, si vous ne chiffrez pas via SSL/TLS votre communication SMTP et IMAP, alors il sera possible à un attaquant d'espionner le réseau pour récupérer le mot de passe de votre boite mail.

Notez que même en ayant le mot de passe de votre boite mail, un attaquant ne pourra pas en lire le contenu s'il a été chiffré via OpenPGP. Il ne pourra pas non plus envoyer des emails signés depuis votre compte. Mais il pourra lire les emails non chiffrés, envoyer des emails non signés, et peut-etre se connecter à d'autres comptes qui utiliseraient le même mot de passe.
Donc, dans tous les cas, IMAP et SMTP doivent être en SSL/TLS.

Création des clefs

Pour utiliser OpenPGP, vous pouvez créer une paire de clef depuis Thunderbird. Mais nous allons la créer depuis GPG parce que… pourquoi pas!
De nombreux guides en ligne existent déjà, donc je ne vais pas les paraphraser. Il suffit d'un gpg --full-generate-key et de se laisser guider

Durant la création de la paire de clef, GPG vous demandera un mot de passe. Il sert à protéger votre clef privée. Choisissez-en un complexe.

Sur Outlook, il semble que ce mot de passe ne s'enregistre pas correctement. En tous cas, il m'est demandé bien une fois par jour, alors, choisissez un mot de passe que vous saurez retenir et rentrer facilement si vous êtes dans ce cas.

En quelques commandes, on crée sa clef (utilisez pgp4win, qui contient Kleopatra, si vous êtes sous windows)

Configuration Thunderbird

On importe alors la clef secrete (exportée via gpg --output xx.gpg --armor --export-secret-keys KEYID)

Si vous ne connaissez pas votre KEYID, utilisez gpg --list-keys

Thunderbird doit trouver une clef dans le fichier
Et l'import devrait réussir

S'il rate, assurez-vous de ne pas avoir importé la clef publique! Vous avez besoin de votre clef privée pour signer vos mails sortants, et pour déchiffrer vos mails entrants. La clef publique sera envoyée par un autre canal (serveur de clef, site web, etc) au monde entier pour lui permettre de valider la signature des emails que vous enverrez, et pour chiffrer les emails à vous envoyer.

N'oubliez pas de sélectionner la clef importée pour terminer la configuration

Je n'ai pas mis d'expiration à ma clef, puisqu'il s'agit d'un test. Libre à vous d'en mettre une, mais personnellement, je n'y vois pas grand intérêt

Email chiffré de bout en bout!

Maintenant envoyons un email, avec un SMTP en clair mais en le chiffrant (avec la clef publique du destinataire) et en le signant (avec notre clef privée)
Wireshark voit toujours la communication SMTP, puisqu'elle est en clair
Mais le contenu ayant été chiffré, il n'est plus compréhensible par Wireshark, ni par aucun serveur SMTP de la chaine

En pratique, Thunderbird a simplement créé automatiquement un fichier contenant l'email entier, qu'il a chiffré avec la clef publique de chaque destinataire et signé avec votre clef privée, puis il a envoyé ce fichier en pièce jointe d'un email classique.
Le client email du destinataire faire alors l'inverse de manière tout aussi transparente: voyant que l'email contient en fait une pièce jointe chiffrée, il la déchiffre avec sa clef privée, vérifie la signature avec votre clef publique, et il "retransforme" le fichier déchiffré en un email classique (à l'affichage).

Enfin, côté destinataire, Thunderbird montrera à droite un marqueurs "OpenPGP: chiffré, signé"

Bilan

				Client email (expéditeur)
				↓ Chiffrement OpenPGP ↓
				Email chiffré + signé
				↓ SMTP over SSL/TLS ↓
				Serveur SMTP (fiable ou pas)
				↓ SMTP over whatever ↓
				Serveur SMTP (fiable ou pas)
				↓ SMTP over whatever ↓
				Serveur SMTP (fiable ou pas)
				↓ SMTP over whatever ↓
				Serveur SMTP (fiable ou pas)
				↓ IMAP over SSL/TLS ↓
				Email chiffré + signé
				↓ Déchiffrement OpenPGP ↓
				Client email (destinataire)
			
La chaîne est sécurisée de bout en bout, quelque soit la fiabilité des serveurs intermédiaires

Plus tard, on parlera de comment chiffrer les emails envoyés par un script PHP et comment implémenter DMARC/DKIM pour certifier que le serveur SMTP envoyant les emails d'un domaine donné est bien autorisé à le faire.