GnuPG se détourne des serveurs de clés SKS et favorise WKD

GnuPG se détourne des serveurs de clés SKS et favorise WKD

Il faut toujours anticiper

Avatar de l'auteur
David Legrand

Publié dans

Logiciel

19/07/2019 3 minutes
8

GnuPG se détourne des serveurs de clés SKS et favorise WKD

Après la découverte d'un problème important dans la mécanique de distribution des clés par les serveurs SKS, l'écosystème autour de GPG s'active. Outre les mises à jour, tout le monde se tourne désormais vers l'initiative Web Key Directory (WKD), en développement depuis plusieurs années. 

Début juillet, un défaut du protocole OpenPGP était découvert, suite à l'empoisonnement de certificats. « Quiconque tente d'importer un certificat "empoisonné" dans une installation OpenPGP vulnérable la bloquera très probablement d'une manière difficile à déboguer » prévenait alors Robert J. Hansen (rjh).

Première étape : se débarrasser du bug

Seule solution, ne plus importer de clés depuis des serveurs SKS, en attendant qu'une solution de fond soit trouvée. Pour rappel, ils servent principalement à trouver la clé attachée à une identité : nom, adresse e-mail, pseudo, etc. Dès lors, comment faire pour les échanger ? 

Revenir aux basiques, mais également miser sur l'une des solutions actuellement en cours de développement, à en croire les premiers échanges sur le sujet et la réaction de GnuPG.

L'équipe de développement a en effet publié une nouvelle version 2.2.17, GPG4Win a suivi peu de temps après avec sa version 3.1.10. Quelques bugs sont corrigés en complément d'une coupure avec les serveurs de clés. Toutes les signatures importées par ce biais sont désormais ignorées.

Une option à ajouter au fichier gpg.conf permet de revenir en arrière pour ceux qui acceptent de prendre le risque :

keyserver-options no-self-sigs-only,no-import-clean

Le bug en cas d'import de blocs trop importants pour pubring.kdbx ne devrait plus être rencontré.

Seconde étape : passer à l'ère WKD

Comment faut-il donc s'échanger les clés ? On peut bien entendu passer par un téléchargement direct depuis le serveur d'un utilisateur, mais il faut connaître l'adresse du fichier, en vérifier la provenance et la conformité. 

C'est là que Web Key Directory (WKD) entre en scène. Consciente depuis un moment que les serveurs de clé constituent un problème qu'il faudra résoudre, l'équipe de développement de GnuPG travaille sur cette alternative introduite publiquement avec la mouture 2.2 en août 2017. Protonmail l'utilise depuis fin 2018.

Pour faire simple, il s'agit de permettre à chacun de stocker des clés liées à son domaine dans un emplacement dit « well known » (« bien connu »), puis leur vérification de manière automatisée. Il faut bien entendu passer par un serveur profitant du chiffrement des échanges via TLS (ce qui est assez simple avec Let's encrypt). 

D'autres méthodes sont explorées, comme l'enregistrement DNS, qui semble être la solution utilisée par Posteo. Car l'objectif est que chacun puisse s'en servir à son échelle : les particuliers, les entreprises pour leurs employés ou un fournisseur de webmail qui peut ainsi proposer la clé publique de tous ceux à qui il fournit un compte. 

Dans tous les cas, nous ne pouvons que vous inciter à diffuser votre clé publique par ce biais via votre serveur.

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Première étape : se débarrasser du bug

Seconde étape : passer à l'ère WKD

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Fermer

Commentaires (8)


une simple url en https via dns srv, ça serait tellement simple.


L’intérêt du well known c’est justement de ne pas avoir besoin d’un enregistrement DNS particulier. Par contre tu peux utiliser DNS SRV pour indiquer pour renvoyer vers un domaine/port différent de mémoire (on en avait parlé dans le papier de 2017 sur WKD/WKS)


La possibilité d’utiliser un enregistrement SRV a dégagée du brouillon IETF depuis pas mal de temps :(









draft-koch-openpgp-webkey-service a écrit :



The use of DNS SRV records as specified in former revisions of this document reduces the certainty that a mail address belongs to a domain. For example an attacker may change the target to a host in a sub-domain under their control and thus gain full control over all keys.







Z’auraient pu contraindre à utiliser DNSSEC pour éviter ce problème et ne pas totalement abandonner l’option, m’enfin bon.



C’est dommage, c’était la solution que j’avais choisi (pas trop le choix, c’était ça où coller un serveur HTTP à l’apex de mon domaine, et c’est niet ça)



Sinon, il reste possible d’utiliser les enregistrement OPENPGPKEY (coller sa clé publique dans un - gros - enregistrement), mais ça nécessite que le domaine soit signé avec DNSSEC et à moins d’héberger soit même ses serveurs faisant autorités, pas sûr que les vendeurs de noms de domaine le propose quand on leur délègue la gestion (en tout cas, y a pas chez OVH et Gandi)



A chaque solution décentralisée sa réponse centralisée <img data-src=" />








David_L a écrit :



A chaque solution décentralisée sa réponse centralisée <img data-src=" />





<img data-src=" />



OVH propose DNSSEC depuis qq années et je doute que gandi ne fasse pas de même…


Ils ont DNSSEC.