Le protocole Web Key Service, qui doit permettre une meilleure distribution des clés pour un premier contact, est désormais actif par défaut dans GnuPG. Si des services comme Posteo commencent à l'implémenter, vous pouvez l'exploiter pour diffuser vous-même votre clé publique.
Comme nous avons pu le voir, l'équipe de GnuPG vient de publier une mise à jour importante estampillée 2.1.23. Préparant l'arrivée de la nouvelle branche stable 2.2.x, elle active par défaut le support d'un nouveau protocole de distribution : Web Key Service (WKS) et ses Web Key Directory (WKD).
WKS/WKD : la diffusion simplifiée de votre clé GPG publique
Pour faire simple, il s'agit de lier une adresse email à une clé publique GnuPG sans avoir à passer par le système des serveurs de clés. Ces derniers permettent en effet à n'importe qui de publier une clé pour n'importe quelle adresse, sans aucune vérification. Ils ne peuvent donc pas être considéré comme un moyen de trouver une clé de confiance du premier coup, sans vérification complémentaire.
L'idée derrière WKS/WKD est de stocker un fichier dans un dossier prédéfini du serveur hébergé par un domaine, afin d'y exposer les clés de ceux qui y disposent d'une adresse email. Si un utilisateur veut chiffrer un document pour cette adresse, et qu'il ne dispose pas déjà d'une clé associée dans son trousseau local, GPG ira la chercher sur le serveur.
Si un fichier contenant la clé publique est trouvé, il est importé et le message est chiffré automatiquement, une fois que l'utilisateur aura donné son accord. Ainsi, plus aucune étape n'est nécessaire entre la demande de chiffrement et son exécution en l'absence d'une clé publique associée. De quoi largement simplifier un premier contact.
L'objectif final est d'inciter les services de messagerie et autres hébergeurs à proposer une intégration native du protocole, tout comme les clients tels que Thunderbird/Enigmail. Ainsi, diffuser une nouvelle clé sera relativement simple tant pour l'expéditeur que pour le destinataire.
Posteo : un service d'email avec chiffrement plutôt intéressant
Mais voilà, pour le moment, seul Posteo propose un début d'intégration de WKS/WKD. Ce service de messagerie allemand est plutôt engagé dans le domaine du chiffrement et de la protection des données. Il permet notamment de chiffrer via un mot de passe votre carnet d'adresses, votre calendrier et le stockage de l'ensemble de vos données.
Vous pouvez aussi y refuser l'envoi d'un email si le chiffrement SSL/TLS de la connexion n'est pas assuré sur l'ensemble du parcours. Vous recevrez alors un message qui vous demandera si vous voulez tout de même envoyer le message ou non.
Vous pouvez simplement transmettre votre clé publique (GPG ou S/MIME) à travers un email, afin d'intégrer l'annuaire DNS du service. Mais pour le moment, WKD ne semble pas pleinement fonctionnel. La fourniture de cette clé vous permettra d'activer un chiffrement à l'entrée dont le principe est de l'utiliser pour chiffrer l'ensemble des messages reçus afin qu'ils ne soient pas accessibles en clair. Ainsi, seule une personne détenant votre clé privée pourra les lire.
Le service met aussi en avant son utilisation exclusive d'énergie « verte » (fournie par Greenpeace Energy) entre autres engagements sociaux et écologiques, l'absence de publicité et l'absence de divulgation de données à caractère personnel. Le tarif de base est de 1 euro par mois pour 2 Go de stockage, deux alias, la gestion du carnet d'adresse et du calendrier.
Si vous le souhaitez, vous pouvez payer plus, le service proposant un prix libre. Vous pouvez aussi ajouter du stockage (0,25 euro par Go), des alias (0,10 euro pour deux) ou des calendriers (0,10 euro pour trois). La note peut donc vite grimper, surtout si vous êtes gourmand du côté des pièces jointes.
Diffuser votre propre clé publique : les prérequis
En attendant que les hébergeurs et les fournisseurs d'email se bougent, vous avez néanmoins une possibilité qui s'offre à vous si vous voulez profiter de la généralisation de WKS/WKD : diffuser vous-même votre clé publique. Pour cela, il vous faudra disposer de quatre choses :
- Un serveur d'hébergement lié à un domaine
- Un certificat SSL/TLS lié à ce domaine
- Une adresse email liée à ce domaine
- Une paire de clés GPG liée à cette adresse
Dans notre cas nous avons opté pour une solution simple : un hébergement mutualisé OVH. Comme d'autres (Gandi ou Infomaniak par exemple), la société propose la mise en place automatisée et gratuite d'un certificat Let's Encrypt à activer dans son Manager, et des emails sur l'ensemble de son offre.
Notez d'ailleurs que même l'offre Start10M accessible gratuitement sur chaque domaine, permet d'obtenir un certificat Let's Encrypt. Pour rappel, elle se compose de 10 Mo de stockage web, 5 Go pour une adresse accessible via les protocoles POP/IMAP, une interface Roundcube (1.2.4), dix redirections et un répondeur.
Générer votre clé avec GPG
Une fois que vous avez tout ce qu'il vous faut, la première étape à suivre est de générer le fichier qui contiendra votre clé publique. Ici, une procédure d'export classique ne suffit pas.
Les équipes de GnuPG mettent à votre disposition une solution à base de script Python, plutôt pensée pour ceux qui disposent d'un serveur dédié. Mais il y a franchement plus simple. Tout commence par une simple ligne de commande :
C:\>gpg --with-wkd-hash -k me@jeandauh.fr
pub rsa4096 2015-04-12 [SC] [expire : 2017-12-31]
C508D8474655467F2E58D86A34354A80ABE928E6
uid [ inconnue] Jean Dauh <me@jeandauh.fr>
s8y7oh5xrdpu9psba3i5ntk64ohouhga@jeandauh.fr
sub rsa4096 2015-04-12 [E] [expire : 2017-12-31]
sub rsa4096 2015-04-12 [S] [expire : 2017-12-31]
Ici, le but est de récupérer un ID qui sera nécessaire dans la composition de l'URL où GPG ira chercher la clé. Celui-ci est constitué de 32 caractères issus d'une empreinte SHA-1 de la partie locale de l'email (ici, me) encodée via Z-Base32, qui est une version spécifique de Base32 se voulant plus simple à appréhender et à gérer pour un utilisateur, notamment en évitant les confusions possibles entre certains caractères.
Il se situe sous la ligne commençant par uid, dans notre cas il s'agit de s8y7oh5xrdpu9psba3i5ntk64ohouhga. Le fichier contenant la clé publique sera composé uniquement de cet ID. Ainsi la commande d'export devra être la suivante :
gpg --export me@jeandauh.fr > s8y7oh5xrdpu9psba3i5ntk64ohouhga
Mettre votre clé publique en ligne
Une fois ce fichier créé il faut le placer sur votre serveur. Dans notre cas nous utilisons le client FTP open source Filezilla. Il faudra commencer par créer une série de répertoires afin d'arriver à l'URL finale telle qu'elle doit être composée :
https://jeandauh.fr/.well-known/openpgpkey/hu/s8y7oh5xrdpu9psba3i5ntk64ohouhga
Une fois le dernier répertoire créé (hu, pour hashed user-id), il suffit d'y placer le fichier qui contient votre clé. Dans notre cas, nous avons rencontré deux problèmes à cette étape. La première concerne le mode de transfert opéré par défaut par Filezilla. En effet, le fichier était modifié et ne faisait plus la même taille à l'arrivée du fait de sa composition. Nous avons donc du opter pour un transfert binaire plutôt qu'ASCII ou le mode automatique (Transfert > Type de Transfert).
Ensuite, il faut savoir qu'OVH active par défaut un firewall sur ses offres mutualisées (mod_security). Celui-ci bloque certains types de requêtes, notamment celles opérées par GnuPG pour récupérer la clé lorsque celle-ci est détectée.
À défaut d'une solution plus fine permettant de faire passer ces requêtes, la seule chose à faire est de désactiver ce firewall. Pour cela vous pouvez passer par le Manager comme décrit ici, mais dans notre cas cela ne fonctionnait pas. Vous pourrez alors éditer le fichier .ovhconfig à la racine de votre serveur, et remplacer la ligne du firewall ainsi :
http.firewall=none
Espérons tout de même qu'une meilleure solution pourra être trouvée. Chez d'autres hébergeurs, des procédures similaires seront parfois nécessaires, tout dépendra de la composition et de la configuration de votre serveur. N'hésitez pas à vous rapprocher du service client en cas de problème ou à partager vos expériences dans les commentaires.
Enfin, n'hésitez pas à placer un fichier .htaccess à la racine du répertoire .well-known afin d'éviter qu'un tiers puisse lister les fichiers présents dans ses différents sous-répertoires, si une telle interdiction n'est pas déjà mise en place. Pour cela, il suffit de placer le contenu suivant dans le fichier :
Options -Indexes
Il n'y a plus qu'à tester
Une fois le fichier en ligne, vous n'avez plus qu'à vérifier que tout fonctionne. Pour cela, une simple ligne de commande de chiffrement d'un fichier suffit :
echo Coucou > test.txt
gpg -e -r me@jeandauh.fr test.txt
La clef devrait être récupérée automatiquement si elle n'est pas déjà présente dans votre trousseau local. L'avertissement classique pour une clé non certifiée vous sera ensuite affiché afin de vous demander de confirmer qu'il faut bien l'utiliser malgré tout. Cette demande peut être retirée avec l'utilisation de l'argument --always-trust.
gpg: clef 34354A80ABE928E6 : clef publique « Jean Dauh <me@jeandauh.fr> » importée
gpg: Quantité totale traitée : 1
gpg: importées : 1
gpg: aucune clef de confiance ultime n'a été trouvée
gpg: « me@jeandauh.fr » automatiquement récupéré par WKD
gpg: 49F683FB653B891F : aucune assurance que la clef appartienne vraiment à l'utilisateur.
sub rsa4096/49F683FB653B891F 2015-04-12 Jean Dauh <me@jeandauh.fr>
Empreinte clef princip. : C508 D847 4655 467F 2E58 D86A 3435 4A80 ABE9 28E6
Empreinte de sous-clef : 3416 D6D3 F710 A81D D899 E069 49F6 83FB 653B 891F
La clef n'appartient PAS forcément à la personne nommée
dans l'identité. Si vous savez *vraiment* ce que vous
faites, vous pouvez répondre oui à la prochaine question.
Faut-il quand même utiliser cette clef ? (o/N)
Si vous confirmez, le fichier sera chiffré. Dans tous les cas, la clé sera ajoutée à votre trousseau local. Et désormais, n'importe qui avec la dernière version de GnuPG pourra faire de même, et chiffrer un fichier vous étant destiné de manière automatique.
Un dispositif que l'on a hâte de voir intégré à des outils tels que GPA et Kleopatra ainsi que les différents clients mail qui gèrent GPG nativement ou via des extensions. L'arrivée de la version stable de GPG4Win 3.0 sous Windows, attendue normalement pour la fin du mois, devrait permettre d'en avoir un premier aperçu.
Notez enfin que cette URL peut aussi être utilisée dans les données d'une OpenPGP Card afin de permettre de récupérer votre clé publique au sein d'une nouvelle machine (voir notre analyse).
Commentaires (38)
Article d’utilité publique.
Diffuser votre propre clé publique.
Pour cela, il vous faudra disposer de quatre choses choses :
Depuis hier, c’est vraiment la fête du MAF (Michu Acceptance Factor).
Si c’était le cas, il ne serait pas réservé aux abonnés…
" />
C’est une bonne nouvelle :-)
Dans notre cas nous avons opté pour une solution simple : un hébergement mutualisé OVH. Comme d’autres (Gandi ou Infomaniak par exemple), la société propose la mise en place automatisée et gratuite d’un certificat Let’s Encrypt à activer dans son Manager, et des emails sur l’ensemble de son offre.
Notez d’ailleurs que même l’offre Start10M accessible gratuitement sur chaque domaine, permet d’obtenir un certificat Let’s Encrypt.
Ca, c’est très intéressant. ;-)
Pour rappel, elle se compose de 5 Go pour une adresse accessible via les protocoles POP/IMAP, une interface Roundcube (1.2.4), dix redirections et un répondeur.
?
Je suppose que le “?” faisait référence à une question sur le stockage proposé sur l’hébergement web de l’offre (je pensais que la capture était suffisante). J’ai rajouté une mention ;)
Question : Pourquoi le dernier répertoire s’appel «hu» ???
OK, je note dans ma liste des tâches de faire la manip ce soir :)
“hashed-userid”
" />
(Trouvé ici)
Je me posais la question aussi, c’est peut-être une allusion à la tête du mec qui voit le nom du fichier qui contient la clé ^^
Attention, je vais vérifier hein
" />
Ah bah pour l’instant, c’est mort.
" />
Il faut, pour une adresse mail de tutu.example, un serveur Web qui écoute pourhttps://tutu.example/
Or dans mon cas, je n’ai pas de service Web à l’apex de mon domaine (uniquement sur www). Ceci dit, l’opération (coller un Apache à la maison qui redirige tout vers www) est prévue de longue date, cela va juste précipiter les choses ;)
Ou alors, je colle un enregistrement SRV dans ma zone
Et ma ligne ADSL souffre déjà de la qualité toute relative de la boucle local, c’est pas pour y amener tous les bots des internets aussi
" />
Qu’elle idée d’y héberger des emails du coup !
La boite aux lettres, c’est à la maison. Dans le hall de l’immeuble éventuellement, mais il n’y a pas de prises RJ45 dans le mien
" />
" />
(C’est tout de même bien moins de connexions entrantes qu’un serveur Web, pour peu qu’on ne laisse pas traîner ces adresses n’importe où)
Je viens de regarder le brouillon de l’IETF, l’enregistrement SRV fera l’affaire et je vais encore pouvoir procrastiner pour la mise en place de ma petite redirection web
Happy User ?
Je n’utilise pas windows pour ces usages, exclusivement Debian. J’ai vu que c’était une ligne de commande sous windows. Je viens d’essayer pour “voir” sur une machine que j’ai sous la main, et j’ai eu ce retour : “gpg: option « –with-wkd-hash » incorrecte”
" />
Je constate donc que la version sur la machine est 2.0.30. Ok. Bon. Je veux mettre à jour pgp sous windows, et là, bah je ne comprends pas comment on fait, ou j’ai mal chercher, mais comment tu mets à jour gpg sous un windows ? j’ai essayé avec les outils depuis le site d’opengpg (ça a installé Kleopatra d’ailleurs) mais sans mettre à jour pgp sur windows.
J’ai loupé un truc, c’est sur mais quoi ? comment les gens sous windows peuvent ils mettre à jour pgp utiliser ce tuto ?
Désolé de mon ignorance windows
voir ici :
https://www.nextinpact.com/news/104950-gnupg-2-1-23-apporte-changements-majeurs-…
Sinon sur le site de GPG y’a une section Downloads pour récupérer la dernière version (tu as surement utilisé GPG4Win qui installe des outils complémentaires ;))
Je pense que tu voulais faire un lien vers l’autre article du jour et pas celui-ci. ….
sinon en mail chiffré il y protonmail.ch et ça marche très bien, il n’y a rien à configurer.
Nan, en fait je me posais la question de l’intérêt de cette mention
" />
Et ça ne chiffre tes emails en asymétrique que vers les autres contacts Proton Mail, qui détient ta clef privée ¯\_(ツ)_/¯, sans parler du fait que GPG, ça fait du chiffrement pour bien d’autres trucs que les emails ;)
PS : Je n’ai rien contre ProtonMail hein, l’outil a son intérêt pour ceux qui veulent du chiffrement en webmail (avec les limites que ça implique) avec quelques contacts et sans trop se prendre trop la tête. Ils évoluent pas mal, même si amha ils pourraient avancer un peu plus sur des promesses de départ comme le fait de proposer un support plus complet de GPG et de ses fonctionnalités.
D’ailleurs, ils sont un client idéal pour WKS/WKD puisqu’ils mettent à disposition des clés publiques et ne proposent pas de système d’annuaire, sur ce terrain, Posteo est bien plus avancé par exemple.
Bah je parle de l’offre et d’envoi d’emails, je précise ce que l’offre contient :)
Merci
" />
Le fichier est en binaire… tout comme la réaction des utilisateurs tombant dessus (ceux qui comprennent|ce qui ne comprennent pas)
" />
non je ne crois pas que protonmail ai accès à ta clef privé car c’est que si t’es loggué que l’interface peut déchiffrer tes emails et tu peux avoir 2 mdp pour te loggué puis pour déchiffrer. Donc quand tu envoies un mail à un autre contact proton cela chiffre avec sa clef publique :https://protonmail.com/security-details
Et tu peux recevoir des mails depuis d’autre client si chiffré en pgp avec ta clef publique.
Par contre effectivement un service d’annuaire serait le bienvenu pour ne pas avoir à envoyer ta clef publique avant.
Comme je le dis et redis souvent si on veut que le plus grand nombre adopte les outils libres de manière générale et une messagerie chiffrée en particulier il faut que ça soit simple et accessible en 2 clics.
Il faut que j’essaie posteo pour voir vu que je ne connais pas comment c’est.
Bah tu peux lire tes emails chiffrés en clair dans l’interface non ? Donc c’est bien que ta clef privée est utilisée quelque part ;) Et globalement, elle n’est ni générée par toi, ni stockée par toi.
Après comme dit, PM est intéressant, mais c’est pas du chiffrement E2E (puisque géré dans un webmail sans accès local à la clé privée), donc ça ne convient pas à tout le monde.
Ils utilisent OpenPGPjs une librairie en Javascript qui chiffre/déchiffre dans le browser. La clé privée n’est pas accessible par eux car protégée par mot de passe. Je n’ai pas trouvé où elle est stockée, mais je n’ai pas beaucoup cherché.
SI tu veux, leur code est maintenant open source, on doit pouvoir savoir où elle est stockée.
je comprends bien ce que tu dis et je conviens que cela ne puissent pas être adapté aux paranoïaques mais justement c’est très bien adapté à mr et mme tout le monde. Et pour moi c’est bien du e2e car l’interface ne peux déchiffrer tes mails qu’une fois authentifié (et j’imagine que c’est seulement là que l’appli récupère ta clef privé).
Encore une fois il faut voir dans son ensemble, et en faire de l’accessibilité aux plus grand nombre pour enlever l’étiquette de trucs de geek. Va faire comprendre une clef privée à tata janine alors qu’un webmail elle connait car l’utilise déjà sur sa messagerie orange par exemple.
De toute façon peut importe la solution il faut un moment une interface qui déchiffre tes mails alors probablement que c’est moins vulnérable si géré en local mais d’un autre coté si géré en global il n’y a pas dispersion de version et faille peuvent être bouchée très rapidement et accessible depuis partout sans rien a configurer ou presque.
après posteo a l’air très bien aussi et même plus poussé que protonmail. merci pour la découverte au passage mais pas de version d’essai.
merci pour l’info et +1
La clé privée chiffrée est stockée sur les serveurs de protonmail.
Elle est déchiffrée en local par le browser web avant d’être utilisée.
On peut la récupérer en mettant les mains dans le cambouis:
https://draft.li/blog/2017/05/18/retrieving-protonmail-private-key
C’est ce qui me semblait le plus logique pour que le service soit accessible de n’importe où. La protection de la clé privée est lié à la solidité de la passphrase, comme d’habitude, mais il faut en être conscient.
La simplicité est une chose et il faut aller vers ça pour que le chiffrement touche le plus grand nombre. Après il faut tout de même faire attention à ne pas tomber dans le simplisme au risque de passer outre tout ce qui est nécessaire à assurer la sécurité.
Ne pas avoir un accès direct à la clé privée, ne pas pouvoir l’importer et ne pas pouvoir envoyer des emails chiffrés via une clé publique hors de protonmail sont des problèmes que le service devra résoudre. Pour le moment il repousse pour des choses plus triviales ou relatives à leur modèle économique, mais ce sont des limites qui freinent pas mal de monde amha (hors de ceux qui ne veulent de toutes façons pas entendre parler d’un chiffrement dans le navigateur j’entend). Et pour le moment, on peut tout aussi bien utiliser un Roundcube avec une clef perso.
PS : Tata Janine n’utilise pas PM, clé privée ou pas ;)