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 2.2 est disponible : des changements majeurs, notamment pour la distribution des clés

\o/
GnuPG 2.2 est disponible : des changements majeurs, notamment pour la distribution des clés
Mise à jour :

La version 2.1.23-1 de GnuPG vient de devenir la version 2.2.0, considérée comme la nouvelle branche « stable », en remplacement de la 2.0.x. Elle est disponible par ici. La sortie de GPG4Win 3.0 est donc imminente. L'équipe de GPGTools, qui produit un pack destiné aux utilisateurs de macOS, n'a pas encore donné de détails sur l'arrivée de sa prochaine version.

Pendant l'été, GnuPG a subi plusieurs mises à jour. La dernière en date ne paie pas de mine, mais elle augure de la prochaine branche stable 2.2.0 de l'outil de chiffrement. Elle active ainsi par défaut des fonctionnalités simplifiant l'échange de clés lors d'un premier contact.

Dans la série « on vous annonce des trucs énormes, mais on le fait l'air de rien », notre gagnant du moment est l'équipe de GnuPG. Il faut dire qu'elle est une habituée du genre.

Après une version 2.1.21 qui corrigeait principalement des bugs et autres failles de sécurité, nous avons a eu droit fin juillet à la 2.1.22 qui apportait quelques nouveautés, surtout une reconnaissance automatique de la présence de Tor sur le système. S'il est détecté, il est désormais automatiquement utilisé, excepté si l'utilisateur utilise l'argument --no-use-tor.

Début août, c'est la version 2.1.23 qui a été mise en ligne, une mouture qui va changer la donne. Et pour cause, il s'agit en réalité d'une release candidate pour la version 2.2.0 qui doit devenir à terme la nouvelle branche stable.

gpg2, c'est fini

Pour rappel, trois branches de GnuPG coexistent. Chacune propose un niveau de fonctionnalités différent et permet d'assurer un support à plus ou moins long terme selon les besoins : Classique (1.4.x), Stable (2.0.x) et Moderne (2.1.x).

La branche stable actuelle sera considérée comme en fin de vie le 31 décembre 2017. D'ici là, elle devra donc être remplacée par la 2.2.x qui commence à se dévoiler. Et le premier changement majeur qu'elle apporte est la fin de gpg2.

En effet, selon les cas, il existait jusqu'à maintenant deux exécutables installables sur le système. Le second était gpg qui sera désormais utilisé par défaut. Les adeptes de l'ancienne méthode ou ceux disposant d'applications qui nécessitent une continuité peuvent utiliser le paramètre --enable-gpg-is-gpg2 s'ils le souhaitent.

On compte aussi d'autres petites nouveautés :

  • --no-grab est activé par défaut pour éviter les attaques de type X-Sniffing
  • --disable-dirmngr permet de désactiver complètement les accès réseau de GnuPG
  • show-only peut être utilisé lors d'un import pour montrer le résultat, sans action

Dans ce dernier cas, la commande exacte à utiliser est la suivante : 

gpg --import --import-options "show-only" clef.gpg

La révolution est dans la distribution

Mais le plus grand changement vient de la méthode de distribution des clés, qui se prépare à évoluer de manière importante. En effet, GnuPG est critiqué de longue date pour sa complexité, notamment dans la gestion et le partage des clés publiques avec des tiers (voir notre analyse).

Le système actuel repose sur deux grands principes : les serveurs de clés publiques et la toile de confiance (Web Of Trust, ou WOT) qui permet à chacun d'indiquer le niveau de confiance qu'il accorde à telle ou telle clé. Mais il permet à n'importe qui de publier une clé pour n'importe quelle identité/adresse email. De plus, il rencontre de nombreuses limites pratiques, notamment lors d'un premier contact. De quoi réduire sa capacité à être utilisé par le plus grand nombre.

Au fil du temps, différentes méthodes ont été tentées. Une clé publique étant un simple fichier texte, il peut être transmis de bien des manières. Récemment, ce sont les enregistrements DNS qui ont été exploités, notamment via DANE (DNS - based Authentication of Named Entities). Mais la faible évolution des pratiques en la matière, notamment chez les hébergeurs, a presque tué dans l'œuf une telle solution.

Il a donc été mis de côté pour le moment, même si l'utilisation de DANE reste une solution évoquée par l'équipe sur le long terme, notamment dans le cadre de la mise en place de son nouveau protocole de distribution.

TOFU et Web Key Service, c'est le turfu !

Car lorsqu'elle a reçu de nouveaux financements, l'équipe de GnuPG a décidé de travailler sur la refonte de ces deux grands principes en priorité. Ainsi, plusieurs éléments sont mis en place progressivement.

Pour le modèle de confiance, c'est TOFU (Trust On First Use) qui devra prendre place dans les mois à venir. Il est possible de le tester depuis la version 2.1.10. Pour la distribution des clés, c'est le protocole Web Key Service (WKS) et ses Web Key Directory (WKD) dont il est question.

Dans les deux cas, le but recherché est le même : faciliter l'échange de clés entre deux personnes qui se contactent pour la première fois, et qui n'ont donc pas à disposition dans leur trousseau local leurs clés publiques respectives. C'est cet ensemble qui se met en place petit à petit auquel nous commençons à avoir droit à travers cette version 2.1.23, qui active par défaut deux arguments qui étaient jusqu'à maintenant optionnels.

  • GPG Web Key Service
  • GPG Web Key Service
  • GPG Web Key Service
  • GPG Web Key Service

La récupération automatique pour vérifier une signature

Le premier est --auto-key-retrieve. Comme son nom l'indique, il permet de récupérer automatiquement la clé d'un tiers à travers les serveurs de clés publics, afin de permettre de vérifier simplement une signature.

Imaginons que vous téléchargiez la dernière version de votre distribution Linux préférée ou une application. Avec le fichier principal, les développeurs publient en général une signature permettant à un tiers de s'assurer qu'ils sont bien à l'origine du fichier téléchargé et que celui-ci n'a pas été altéré (voir notre analyse).

Ainsi, vous pouvez vérifier simplement la validité de l'ISO d'Ubuntu 17.04 via la commande suivante : 

gpg --verify SHA256SUMS.gpg ubuntu-17.04-desktop-amd64.iso

Problème : vous ne disposez pas de la clé publique des développeurs d'Ubuntu. Jusqu'à maintenant, la procédure à suivre était de la télécharger pour l'importer dans votre trousseau local (via la commande gpg --fetch). Désormais, tout est automatique, tant que cette clé est présente au sein d'un serveur public. 

GnuPG va automatiquement récupérer l'ID de celle qui a servi à générer la signature, et la télécharger. Le résultat vous sera alors affiché et la clé sera importée dans votre trousseau. Vous aurez alors la possibilité de la supprimer, ou de modifier votre niveau de confiance si vous avez pu vérifier sa véracité :

GnuPG Import Auto RetrieveGnuPG Import Auto Retrieve
Avant / Après GnuPG 2.1.23

L'équipe a néamoins décidé de revenir en arrière pour éviter certains problèmes évoqués dans cet email, et de désactiver ce paramètre par défaut dans la prochaine version de GnuPG. Une version 2.1.23-1 a aussi été poussé dans la branche Unstable de Debian. Il restera tout de même possible de l'activer à la demande.

La récupération automatique pour chiffrer un message

L'autre argument mis en place par défaut est --auto-key-locate "local,wkd". Celui-ci implique que lorsque vous chiffrerez un message pour une adresse email précise, la clé publique sera cherchée dans votre trousseau local, et à défaut dans une Web Key Directory définie dans le protocole Web Key Service.

Derrière ce nom se cache un nouveau concept proposé comme standard à l'IETF par le développeur principal de GnuPG, Werner Koch. L'idée est de proposer de retrouver les clés liées à un domaine directement via des fichiers présents dans un répertoire à l'emplacement prédéfini (well-know URI).

Ainsi, lorsque vous décidez de chiffrer un message pour me@davlgd.fr, sans disposer de la clé publique associée, GnuPG va aller interroger le fichier suivant afin d'y trouver la clé publique, et l'importer si elle correspond : 

https://davlgd.fr/.well-known/openpgpkey/hu/s8y7oh5xrdpu9psba3i5ntk64ohouhga

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 guide).

L'ID de fin est constituée 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. 

Notez qu'un enregistrement DNS SRV peut être utilisé afin d'indiquer un domaine ou un port différent. On regrettera par contre qu'une telle fonctionnalité ne soit pas proposée de manière plus générale, notamment à travers la commande --fetch qui pourrait aller chercher la clé liée à un email précis dans la Web Key Directory afin de simplement l'ajouter au trousseau local sans autre action complémentaire.

La simplicité n'est pas la sécurité

Le chiffrement de la connexion via HTTPS doit être supporté par le serveur. À l'heure de Let's Encrypt, il est souvent proposé par défaut par les hébergeurs qui permettent de le mettre en place assez simplement.

Ainsi, on est assuré que le fichier transmis est bien celui présent sur le serveur, et qu'il n'a pas pu être altéré par un tiers pendant son téléchargement. Attention néanmoins, si une personne mal intentionnée venait à avoir accès à votre serveur, elle pourrait aisément modifier ce fichier, et donc se faire passer pour vous.

C'est notamment pour cela que WKS/WKD est présenté comme une manière de simplifier la distribution lors d'un premier échange, mais pas de revoir le modèle de confiance sur le fond. Ainsi, la toile de confiance permet toujours de s'assurer de la véracité d'une clef sur le long terme, avec le témoignage d'une multitude de tiers.

Il est donc toujours important de certifier des clés dont vous avez pu assurer la validité, afin de faire vivre ce modèle de confiance décentralisée. Bien entendu, vous pouvez aussi vous baser sur différentes déclarations effectuées par un utilisateur à travers des services comme Keybase.io (voir notre analyse).

L'objectif final : motiver les hébergeurs et les services de messagerie

La méthode des Well-kown URI n'a rien de bien nouveau. Elle est notamment utilisée par Keybase pour valider la propriété d'un domaine ou encore par Do Not Track. Chacun peut bien entendu publier sa clé sur son propre serveur (voir notre guide ci-dessous), mais le but de l'équipe de GnuPG est d'inciter les hébergeurs et autres fournisseurs de services d'email à proposer directement ce service.

Le protocole WKS intègre ainsi tout un dispositif permettant à un utilisateur de transmettre sa clé publique à son gestionnaire d'email pour que celui-ci la publie directement via WKD ou DANE. Là aussi, cela passe par une adresse prédéfinie, qui peut être reconnue et utilisée par des outils tiers. Un début d'intégration, détaillé par l'équipe de GnuPG, est d'ailleurs présent dans les nightly builds d'Enigmail.

Malheureusement, pour le moment seul le service Posteo propose l'embryon d'une telle fonctionnalité. Espérons qu'avec l'arrivée de cette version 2.1.23, puis de la future branche 2.20, les différents services commenceront enfin à jouer le jeu comme ils ont pu le faire avec la mise en place progressive de Let's Encrypt.

Ces derniers cherchant à inciter leurs utilisateurs à moins dépendre des GAFAM et à reprendre en main leurs données, nul doute que cela ne saurait tarder. Surtout que l'implémentation du protocole WKS proposé par GnuPG est relativement triviale pour leurs équipes. C'est en tous cas un point que nous suivrons avec attention dans les mois à venir.

40 commentaires
Avatar de 127.0.0.1 INpactien
Avatar de 127.0.0.1127.0.0.1- 17/08/17 à 08:06:40
  • récupérer automatiquement la clé d'un tiers à travers les serveurs de clés publics
  • retrouver les clés liées à un domaine directement via des fichiers présents dans un répertoire à l'emplacement prédéfini (well-know URI).

Bref, ils ont automatisé ce qu'on fait tous quand on veux chercher une clé (ou un md5, ou une adresse email...): on va chercher l'information sur le web à un endroit qu'on considère arbitrairement "de confiance".

Bref, c'est la mort du "Web Of Trust" et le retour du "I Know What I'm Doing".

Avatar de David_L Équipe
Avatar de David_LDavid_L- 17/08/17 à 08:15:20

Bravo, tu viens de découvrir la différence entre un standard et la bidouille :D Pour le reste, tu as du mal lire, puisque ce n'est en rien la mort du WOT, mais plutôt un complément pour la phase de découverte qui reste un des points de friction essentiel (sans pouvoir remplacer le modèle de confiance sur le fond)

Avatar de 127.0.0.1 INpactien
Avatar de 127.0.0.1127.0.0.1- 17/08/17 à 08:45:11

Hmm.... Pas d'accord.

"WoT = establish the authenticity of the binding between a public key and its owner."

Laisser le logiciel télécharger une clé depuis une URL quelconque (qui n'est même pas une Autorité de Certification ou un site ayant pignon sur rue) n'apporte aucun niveau de confiance

https://davlgd.fr/.well-known/openpgpkey/hu/s8y7oh5xrdpu9psba3i5ntk64ohouhga

WHOIS davlgd.fr

nic-hdl: ANO00-FRNIC
type: PERSON
contact: Ano Nymous
remarks: -------------- WARNING --------------
remarks: While the registrar knows him/her, this person chose to restrict access to his/her personal data.
remarks: So PLEASE, don't send emails to Ano Nymous.
remarks: This address is bogus and there is no hope of a reply.
remarks: -------------- WARNING --------------
registrar: OVH
changed: 04/01/2011 anonymous@anonymous
anonymous: YES

La seule chose qui me donne confiance dans le lien que tu as donné, c'est qu'il est posté dans une news rédigée par ton compte sur le site nextinpact.com. :chinois:

Édité par 127.0.0.1 le 17/08/2017 à 08:48
Avatar de David_L Équipe
Avatar de David_LDavid_L- 17/08/17 à 08:56:34

Tu confonds deux éléments : le modèle de distribution et le modèle de confiance.

 WOT est là pour établir une confiance sur le fond pour, parce qu'une clef (et ses identités) sont reconnues par des tiers qui l'ont vérifié de différentes manières. TOFU, est là pour permettre de faciliter les choses lors d'un premier contact, en complément du modèle classique (via le paramètre tofu+pgp qui reste celui recommandé).

WKD est là pour assurer une distribution simple, automatisée et sécurisée de la clé, pour un email donné. Quand tu inities du WKD, tu sais quel email tu vises (du coup OSEF du Whois). Parce que si tu essaies d'écrire à me@davlgd.fr, c'est qu'il y a une raison et que tu as déjà confiance dans cette adresse.

Avatar de 127.0.0.1 INpactien
Avatar de 127.0.0.1127.0.0.1- 17/08/17 à 09:20:44

Le pire c'est qu'on est d'accord. Je reprend tes terme entre guillemets:

  1. WKD n'établit aucune "confiance sur le fond " mais néanmoins permet techniquement d'utiliser GPG pour écrire à une adresse email quelconque.

  2. "tu as déjà confiance dans cette adresse" email quelconque à laquelle tu vas écrire.

    Moralité, tu as confiance dans l'adresse email et tu peux techniquement utiliser GPG pour écrire a cette adresse email => pourquoi se faire chier avec le WoT dans ce cas ?

Édité par 127.0.0.1 le 17/08/2017 à 09:22
Avatar de Ricard INpactien
Avatar de RicardRicard- 17/08/17 à 09:27:51

Moi je balance ma clé GnuPG dans l'enregistrement TXT de mon DNS. :8

Avatar de David_L Équipe
Avatar de David_LDavid_L- 17/08/17 à 09:30:21

WKD n'est pas une question de confiance, mais de distribution. Cela permet d'automatiser le processus de premier contact à travers un canal sécurisé et simple à mettre en place.

Le WOT permet de vérifier qu'une clé (et non un email) et certifiée par d'autres ou non, et éventuellement de la certifier soi-même si on a pu la vérifier d'une manière ou d'une autre avec la personne concernée. Tu peux récupérer une fausse clé via WKD si le serveur est compromis.

Le WOT est là pour te permettre de t'en apercevoir simplement ou au moins de douter de la véracité de la clé si aucune certification tierce ne vient la confirmer, et donc de procéder à des vérifications complémentaires. 

Pour rappel, l'email est une partie d'une identité d'une clé, pas son élément principal. Tu peux avoir 50 clés avec différentes identités et parfois une même adresse email.

Avatar de David_L Équipe
Avatar de David_LDavid_L- 17/08/17 à 09:31:08

Et personne n'a de moyen simple de la récupérer (de mémoire GPG proposait une méthode de récupération du genre via PKA mais elle a été dépréciée il y a un moment)

Avatar de Ricard INpactien
Avatar de RicardRicard- 17/08/17 à 09:37:37

David_L a écrit :

Et personne n'a de moyen simple de la récupérer (de mémoire GPG proposait une méthode de récupération du genre via PKA mais elle a été dépréciée il y a un moment)

Un script avec dig en bash.:transpi:
Bon, j'avoue que ça n'a pas d'intérêt à part pour 2 geeks. Mais l'idée aurait du être creusée selon moi, surtout avec DNSsec (et DANE), pas mal niveau sécu et intégrité.
Juste l'enregistrement TXT doit faire 1024 signes, pas plus et découpé par tranche de 255.

Avatar de David_L Équipe
Avatar de David_LDavid_L- 17/08/17 à 09:43:37

Tu peux diffuser déjà ta clef via un enregistrement DNS / DANE (avec les paramètres cert, pka ou dane de l'argument --auto-key-locate). Après il faut juste disposer d'un serveur DNS qui le propose (pas franchement pratique à gérer soi-même) ou d'un hébergeur qui le permet (rarement le cas). C'est notamment pour ça que d'autres pistes ont été creusées comme je l'explique dans le papier, même si DANE reste un élément qui est dans le scope de ce que prévoit l'équipe de GPG via le protocole WKS (voir les slides)

Il n'est plus possible de commenter cette actualité.
Page 1 / 4
  • Introduction
  • gpg2, c'est fini
  • La révolution est dans la distribution
  • TOFU et Web Key Service, c'est le turfu !
  • La récupération automatique pour vérifier une signature
  • La récupération automatique pour chiffrer un message
  • La simplicité n'est pas la sécurité
  • L'objectif final : motiver les hébergeurs et les services de messagerie
S'abonner à partir de 3,75 €