Vidéo d'introduction


Table de matières

  1. Le problème (insécurité des emails)
  2. La solution (signatures GPG)
    1. Key pairs (privée et publique)
    2. Identités
    3. Key Servers
    4. Signature de emails
    5. Encryption de emails

Le problème

Imagine une seconde que quelqu'un veut se faire passer pour ton boss (ou autre autorité), afin de te faire faire quelque chose qui compromet la sécurité de l'organisation. Par exemple:

  1. Il va sur https://lachapelle.me/contact/
  2. Il trouve le email de David Pothier (le pasteur en chef pour qui tu fais du bénévolat): dpothier@lachapelle.me
  3. Il code un script PHP ou autre, afin d'envoyer un email à un des programmeurs (toi) pour avoir des infos cruciales ("social engineering", baby).
  4. Il a préalablement enregistré un domaine similaire à lachapelle.me, où il a créé une adresse email similaire à celle de David, où il recevra ta réponse.
  5. Il exécute le script, et attend patiemment que ta psychologie faillible fasse son oeuvre.

Voici le script en question :

<?php
$to      = 'hello@juliendesrosiers.com';
$subject = "Besoin urgent";
$headers = 'From: dpothier@lachapelle.me' . "\r\n" .
'Reply-To: dpothier@lachapele.me' . "\r\n" .
'X-Mailer: PHP/' . phpversion();

$message = "J'ai une modification urgente à faire par un nouveau développeur
bénévole, donc si tu peux me donner le user et mot de passe pour l'admin du
WordPress de la Chapelle.

Merci d'avance de ta rapidité !

David";

mail($to, $subject, $message, $headers);

On exécute ce script, et voici ce qui apparaît dans notre boîte de réception :

Fake email

Pourquoi c'est possible ? Parce que le protocole des emails n'est pas sécurisé à la base.

Reponse

Avez-vous spotté l'erreur ?

Oui, le domaine (qui est fournis par le Reply-To) lachapele.me (un seul l) est disponible au moment d'écrire ces lignes, donc le hacker aura préalablement enregistré ce domaine, et ajouté un email dpothier@ à celle-ci. Donc si le destinataire répond, ça va envoyer à cette adresse-là, qui est assez similaire, qui est un hacker. Et ça risque de passer complètement inapperçu.

Parce que même David ne recevra pas ta réponse, parce que le Reply-To est différente, quoi que semblable.

Et pendant que tu es stressé à répondre promptement à un email urgent d'une autorité, la dernière chose que tu va checker c'est si le email de réponse est bien valide.

La solution

PGP : Pretty Good Privacy. À ne pas confondre avec GPG (GNU Privacy Guard), qui fait à peu près la même chose, mais est open source.

Key pairs

Des clés RSA, DSA, et autres algorithmes de ce genre.

Dans tous les cas, cette paire de clés est formée d'une clé privée et d'une clé publique qui y est associée.

La clé privée, biensûr, doit rester secrète, comme un mot de passe. Et la clé publique peut être partagée autant que nécessaire.

Identités

Une clé (constituée d'une version privée et d'une contrepartie publique) peut être associée à plusieurs emails (et facultativement, couplé du nom de son propriétaire), qui sont associées à une même personne.

Voici un exemple:

Cles

On peut voir par exemple que Francis a plusieurs clés qui sont assignées à plusieurs adresses emails.

Et Julien, pour sa part, a lié plusieurs adresses email à la même clé, parce qu'il considèrent qu'elles représentent la même identité/personne.

Identites

Key Servers

Pourquoi on a besoin des Key Servers ?

De la même manière qu'un ROOT Certificate Authority est nécessaire pour l'infrastructure de certificats TLS pour les sites Web, il est nécessaire d'avoir des serveurs qui servent à stocker des clés publiques, et à permettre à des gens de :

  1. trouver la clé publique de quelqu'un afin de décrypter un email qu'il nous a envoyé, ou de valider que la signature est bien la sienne.
  2. certifier qu'une clé est bien valide.

Pourquoi les Key Servers ne sont pas suffisants ?

Par exemple, si on regarde la clé PGP de Richard Stallman, on peut voir qu'il en a plusieurs, parce que des trolls ont trouvé drôle de créer des fakes.

C'est pourquoi il dit sur son site:

If you want to send me GPG-encrypted mail, do not trust key servers! Some of them have phony keys under my name and email address, made by someone else as a trick. See gpg.html for my real key.

C'est pas fou. Parce qu'en effet, n'importe qui peut créer des fausses clés et les uploader sur des key servers:

Richard Stallman's fake PGP keys

Et si ces personnes utilisent cette fausse identité (enregistrée et soumise au keyserver par quelqu'un qui n'est PAS Richard Stallman), elle va avoir son email apparaître comme étant signé par Richard Stallman. Seulement, ce n'est pas la bonne clé qui a été utilisée.

Exemple d'un email qui est valide, selon l'extension Enigmail dans Thunderbird:

Signed Email

C'est un peu comme si quelqu'un créait un site de fishing avec le vrai nom de domaine de ta banque, et bypassait ton routeur pour rediriger les requêtes de desjardins.com vers l'IP de son serveur de fishing, mais qu'EN PLUS DE ÇA, il avait un certificat SSL que ton browser voit comme étant légitime (petit cadenas vert dans la barre d'adresse).

Ça c'est la petite faiblesse de PGP. C'est pourquoi on a besoin non seulement des key servers, mais aussi d'une manière d'être sûr qu'un clé publique est bien celle de la personne qui nous contacte, et pas de quelqu'un d'autre.

C'est entre autre pour ça que Keybase.io (tsé, la compagnie que Zoom a acheté ?) a été créé; ça permet de partager sa clé publique, tout en prouvant, au même endroit, que c'est la bonne, via des preuves vérifiées par keybase, tel qu'un fichier que tu héberges sur github, un tweet qu'il a publié à partir de ton compte twitter, etc.

Keybase de Pascal

Ici on peut vérifier chacune de ses preuves, pour valider soi-même que la key fingerprint (9521 927B 5582 0DA2) -- qui est un hash de la clé publique -- appartient bien à LUI. Donc on peut lui faire confiance, et même télécharger sa clé publique pour l'ajouter à notre keychain (logiciel qui gère les clés de nos contacts de confiance).

Encryption des emails

TODO

Conclusion

J'espère qu'avec ces infos, vous aurez une meilleure idée de pourquoi PGP est encore pertinent aujourd'hui.

Et encore, je n'ai pas effleuré le sujet de l'encryption des messages, car c'est une autre des fonctionalités de PGP.

Remerciements

Merci à Pascal Meunier de HiveTek pour sa relecture et son feedback.