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?
Client email (expéditeur) ↓ CLAIR (SMTP) ↓ Serveur SMTP ↓ CLAIR (IMAP) ↓ Client email (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.
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.
Client email (expéditeur) ↓ SECURE (SMTP) ↓ Serveur SMTP ↓ CLAIR (IMAP) ↓ Client email (destinataire)
IMAP en clair: nouvelle fuite!
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é
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
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)
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.
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
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.
Configuration Thunderbird
Si vous ne connaissez pas votre KEYID, utilisez gpg --list-keys
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.
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!
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).
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)
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.