Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !

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

Il faut toujours anticiper
Logiciel 3 min
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.

8 commentaires
Avatar de DCmalcolm Abonné
Avatar de DCmalcolmDCmalcolm- 19/07/19 à 10:44:18

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

Avatar de David_L Équipe
Avatar de David_LDavid_L- 19/07/19 à 12:18:25

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)

Avatar de boogieplayer Abonné
Avatar de John Shaft Abonné
Avatar de John ShaftJohn Shaft- 20/07/19 à 01:47:00

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)

Édité par John Shaft le 20/07/2019 à 01:50
Avatar de David_L Équipe
Avatar de David_LDavid_L- 20/07/19 à 04:21:42

A chaque solution décentralisée sa réponse centralisée :D

Avatar de boogieplayer Abonné
Avatar de boogieplayerboogieplayer- 20/07/19 à 11:02:44

David_L a écrit :

A chaque solution décentralisée sa réponse centralisée :D

:transpi:

Avatar de KP2 Abonné
Avatar de KP2KP2- 21/07/19 à 17:21:20

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

Avatar de SebGF Abonné
Avatar de SebGFSebGF- 21/07/19 à 18:53:40

Ils ont DNSSEC.

Il n'est plus possible de commenter cette actualité.