gouttegd a écrit 1805 commentaires

Non merci. Cette « attaque » est un non-évènement, qui a déjà fait couler depuis ce matin beaucoup plus d’octets qu’elle ne le mérite.

Là seule attaque notable là-dedans, c’est une attaque directe contre la crédibilité d’OpenPGP, à gros coups de FUD, et le plus triste est que c’est l’EFF qui mène la charge (« arrêtez d’utiliser PGP, utilisez Signal plutôt » …).

/Mode paranoïaque ON

Qui a intérêt à ce que les gens utilisant PGP cessent subitement de l’utiliser ?

OK, l’attaque est désormais publique, et comme toutes les attaques désormais, elle a son propre nom (Efail), son site et son logo…

Je ne me prononce pas sur l’attaque ciblant le protocole S/MIME, qui semble réellement sérieuse. Mais sur l’attaque ciblant le protocole OpenPGP, je confirme ma première impression : meh.

Comme prévu, l’attaque ne fonctionne pas avec la majorité des clients mails, comme indiqué dans la table 4 du papier. Elle fonctionne avec Thunderbird/Enigmail, seulement si le message est chiffré avec un algorithme ancien comme 3DES ou CAST5 (parce que, avec ces algorithmes, GnuPG ne rejette pas immédiatement le message en absence de MDC — la raison en est que ces messages sont peut-être de vieux messages, générés à l’époque du RFC 2440, et que l’absence de MDC est peut-être légitime ; à l’inverse un message chiffré avec un algorithme moderne comme AES est forcément plus récent que le RFC 4880 qui a introduit le MDC, et l’absence de MDC est alors injustifiable).

Merci à l’EFF de répandre du FUD sur OpenPGP alors que :

• contrairement à ce que leur annonce alarmiste proclame, il n’y a rien dans le papier qui laisse entendre que l’attaque pourrait permettre de déchiffrer des messages transmis antérieurement à l’attaque ;
• le protocole S/MIME est semble-t-il beaucoup plus vulnérable à cette attaque (quasiment toutes les implémentations testées sont vulnérables d’après le papier), mais c’est PGP que l’EFF recommande explicitement de « désactiver ou désinstaller ».

Le papier final rapportant l’attaque doit sortir d’embargo demain, mais d’après la version préliminaire qui a été communiquée aux développeurs de GnuPG (que l’EFF n’a pas pris la peine de contacter avant de dire à tout le monde, en gros, « arrêter d’utiliser PGP »… meh), l’attaque n’est ni franchement nouvelle ni aussi catastrophique que proclamée.

L’attaque est complètement défaite par le mécanisme de vérification d’intégrité (MDC, Modification Detection Code) incorporé à OpenPGP depuis le RFC 4880 il y a… onze ans. Alors, certes, il est malheureusement possible de supprimer le MDC d’un message (c’est une véritable faille du protocole OpenPGP, qui n’a été découverte qu’après la publication du RFC 4880), et donc de se placer dans une situation où l’attaque est de nouveau possible, mais GnuPG renvoie un code d’erreur explicite dans ce cas, il appartient aux clients de messagerie se reposant sur GnuPG de ne pas l’ignorer.

Pour information, les messages de Werner Koch (principal développeur de GnuPG) et de Rob J. Hansen (mainteneur de la FAQ GnuPG) sur le sujet, notamment le passage suivant :

Werner saw a preprint of this paper some time ago. I saw it recently. Patrick Brunschwig of Enigmail saw it. None of us are worried.

Du coup, DMARC a-t-il une utilité si on ne souhaite pas un controle plus fin (pct) ni recevoir d'alertes ?

DMARC n’est pas redondant avec SPF/DKIM, mais il est conçu pour remplacer ADSP, et est donc effectivement partiellement redondant avec ce dernier.

DMARC is designed to replace ADSP by adding support for: wildcarding or subdomain policies, non-existent subdomains, slow rollout, SPF, quarantining mail.

(DMARC Overview)

Voir aussi l’annexe A.5 du RFC 7489 :

DMARC has been characterized as a "super-ADSP" of sorts.

Et concrètement, DMARC a une utilité en ce sens que les « gros » fournisseurs de messagerie commencent à l’exiger pour accepter des mails entrants en provenance des manants…

Il m’est arrivé un truc similaire une fois, même si je ne me souviens plus de la commande exacte (je crois que c’était quelque chose du genre rm -rf ../*, alors que j’étais dans un dossier juste sous mon home).

Je me souviens très bien de ce petit moment de flottement où je me dis « tiens c’est bizarre, pourquoi ça prend aussi long—OH PURÉE CTRL-C CTRL-C CTRL-C!!! »

Mais j’avais des sauvegardes, dont je n’ai quasiment rien perdu si ce n’est le temps de les restaurer. D’ailleurs en réalité ce n’était pas une mauvaise manip de ma part, en fait c’était délibéré, je voulais tester mes sauvegardes, si si.

(Bon j’ai quand même perdu quelques petits trucs, parce qu’à l’époque j’étais encore sélectif sur ce que je sauvegardais ou pas — vestige d’un temps où l’espace disque était compté… Depuis j’ai inversé la logique : par défaut tout mon home est sauvegardé, sauf ce que je décide explicitement d’exclure.)

(message supprimé par l'équipe de modération)

À moins que j’ai raté quelque chose il n’est nulle part dit qu’il est (ou se prétend) professeur d’université, il est clairement présenté comme doctorant (i.e. étudiant en thèse).

Et il n’y a rien de surprenant à ce qu’un doctorant soit aussi chargé d’enseigner, c’est une pratique très courante dans toutes les universités du monde — y compris en France, pas seulement dans les shithole countries™.

En tant que doctorant à l’Université Cheick Anta Diop (UCAD), Michel Seck a une adresse e-mail universitaire en @ucad.edu.sn, comme on peut le voir sur un de ses papiers.

Il est sur ResearchGate, aussi.

C’est malin de faire une dépêche aussi longue, le temps que je la lise GIMP 3.0 est déjà sorti…

Blague (pas drôle) à part, merci à Jehan et aux 41 contributeurs (!) pour la dépêche, à tous les développeurs de GIMP pour cette release, et encore à Jehan pour le flatpak.

Ah, et juste pour mettre en avant une nouveauté qui pour moi est cruciale mais qui est presque perdue dans toutes les infos de cette dépêche :

GIMP peut désormais travailler sur des images 8, 16 ou 32 bits

(Mais il y a tellement de nouveautés que j’imagine que chacun va avoir « sa » nouveauté préférée…)

pourquoi ne pas avoir retenu GCM ?

GCM ne fait pas l’unanimité chez les cryptographes. Ou alors, il fait l’unanimité contre lui.

D’après Jon Callas (un des membres du groupe de travail OpenPGP, et premier auteur du RFC 4880) :

I’ll request that another mode than GCM be used. In particular, I disagree with it being "uncontroversial." It's the most controversial mode you could pick.

GCM is very brittle. It breaks in very bad ways if you aren't careful with nonces/tags. There are many cases of people misusing it and getting worse than no security. I state that because if you think you're getting authenticated data, but it's actually been altered in transit, and that will likely cause issues in the receiving state machine.

Ou d’après Matthew Green :

Galois Counter Mode has quietly become the most popular AE(AD) mode in the field today, despite the fact that everyone hates it. The popularity is due in part to the fact that GCM is extremely fast, but mostly it’s because the mode is patent-free. […]

Une chose qui revient souvent dans la littérature sur GCM est sa fragilité (cf. le commentaire de Jon Callas, GCM is very brittle) dans le sens où il est très facile de l’utiliser de façon catastrophique. Voir par exemple Gueron and Krasnov (2013), Joux (2006), Ferguson (2005).

Au contraire, OCB est encensé par tout le monde, comme Brian Carlson (OCB is the mode everyone really wants to use), Jon Callas (We all really want to use OCB) ou Matthew Green (OCM blows the pants off of all the other modes I mention in this post)… la seule critique à son égard étant ce censuré de brevet. D’ailleurs comme le dit Werner Koch :

GCM has only be developed to avoid the OCB patent

Précision : la bibliothèque OpenPGP.js n’a rien à voir avec le fait que ProtonMail ne permet le chiffrement qu’entre ses utilisateurs. Que ProtonMail ne soit pas interopérable avec l’extérieur est purement un choix de ProtonMail, qui n’est pas lié à une hypothétique limitation d’OpenPGP.js.

OpenPGP.js est une implémentation complète et conforme du standard OpenPGP, parfaitement capable d’interopérer avec une autre implémentation conforme (sauf si l’option aead_protect est activée, comme expliqué dans la dépêche).

C'est à mon avis une très bonne nouvelle car c'est une preuve concrète de l'implication de ProtonMail dans du code libre

Oui, alors à choisir je préférerai qu’il fasse du code non libre et interopérable plutôt que du code libre intentionnellement conçu pour ne pas pas être interopérable.

ProtonMail prend bien soin de mettre en avant le fait qu’ils ont choisi d’utiliser un protocole standard (OpenPGP). Par exemple :

We believe in compatibility and interoperability. Thus, ProtonMail’s encryption complies fully with the OpenPGP standard. This brings a number of benefits. Because we are using an open standard, you as the user can know exactly how we are applying end-to-end encryption to secure your emails. In the future, we will be adding to ProtonMail the ability to import and export PGP keys. By complying with OpenPGP, it will be possible to do things like, download ProtonMail messages and decrypt them locally using your own PGP software.

Ou encore :

Why does ProtonMail use the OpenPGP standard? The reason is interoperability. By adhering to OpenPGP, we enable not just end-to-end encrypted messaging with other ProtonMail users, but compatibility with any PGP user worldwide. This means anybody, regardless of what email provider they use, can send end-to-end encrypted messages to ProtonMail users.

C’est beau comme de l’antique, pas vrai ?

Sauf que c’est du pipeau. Dans les faits, le chiffrement proposé par ProtonMail n’est utilisable qu’entre utilisateurs de ProtonMail.

Vous voulez envoyer un mail chiffré à un correspondant qui n’utilise pas ProtonMail ? Pas moyen. Les seules clefs publiques que vous pouvez utiliser depuis ProtonMail sont celles des autres utilisateurs de ProtonMail. Il est impossible d’importer une clef publique tierce pour l’utiliser depuis ProtonMail. Ça fait trois ans que la fonctionnalité est promise (notez par exemple la phrase commençant par In the future dans la citation ci-dessus), les utilisateurs l’attendent toujours.

La seule option pour envoyer un mail chiffré à un non-utilisateur de ProtonMail est d’utiliser leur méthode complètement non-standard qui consiste en gros à chiffrer le message symmétriquement avec un mot de passe et à envoyer votre correspondant sur une page web où il pourra entrer le mot de passe en question pour lire le message (et c’est à vous de vous débrouiller pour communiquer le mot de passe à votre correspondant).

Si vous voulez pouvoir recevoir sur ProtonMail des messages chiffrés provenant de correspondants non-ProtonMail, c’est théoriquement possible. Vous pouvez exporter votre clef publique, la diffuser comme bon vous semble, et donc la faire parvenir à vos correspondants qui peuvent dès lors l’utiliser pour chiffrer les messages qui vous sont destinés… Sauf que la possibilité d’exporter la clef publique semble avoir disparu des versions récentes de ProtonMail, et depuis ProtonMail ne cesse de promettre que ça va revenir « dans une version future ».

Concrètement, les seules personnes chez ProtonMail qui se soucient d’interopérabilité sont dans le département marketing, où « interopérabilité » est comme « open source » : c’est un mot qu’il est bon de caser partout où on peut sur le site web. Dans les faits, OpenPGP ou pas, ProtonMail ne propose de chiffrement de bout en bout qu’entre ses propres utilisateurs.

À part ça, oui, ProtonMail contribue à un projet open source. C’est bien mais ça n’en reste pas moins un service qui chercher à enfermer ses utilisateurs tout en se vantant d’être interopérable (non).

si la clé est perdue, […] les messages reçus précédemment ne sont plus lisibles

C’est vrai, mais c’est indépendant de Autocrypt. Le problème se pose dès lors que tes correspondants et toi chiffrez vos messages, quel que soit l’outil utilisé et qu’il soit compatible Autocrypt ou pas.

Là où il peut y avoir un soucis spécifique à Autocrypt, c’est que le protocole (et les outils qui l’implémentent) se veut transparent, il est envisageable que certains utilisateurs ne réalisent même pas que leurs messages sont chiffrés, et ne soient donc pas conscient qu’ils ont une clef qu’ils ne doivent pas perdre.

(Ça ne peut pas vraiment arriver avec Enigmail, pour la simple raison qu’Enigmail est un plug-in que l’utilisateur doit explicitement installer — et quelqu’un qui installe Enigmail est déjà un minimum averti. Mais on peut imaginer un client de messagerie prenant nativement en charge Autocrypt et générant la paire de clefs de sa propre initiative, sans aucune intervention de l’utilisateur. C’est certainement un objectif du projet, tel que je le comprends : arriver à une situation où les messages sont chiffrés par défaut sans que jamais l’utilisateur n’ait à s’en soucier.)

ça ne fonctionne que si on utilise un seul client de messagerie sur un seul terminal

Apparemment non, il est prévu de faciliter l’utilisation de plusieurs clients (potentiellement sur des appareils différents). Je n’ai pas étudié cette partie de la proposition en détail donc je n’ai pas d’opinion dessus (à part une : quelque soit la méthode mise en place, je rechigne à la seule idée d’avoir une clef privée stockée sur plusieurs appareils — mais encore une fois, c’est un problème inhérent au chiffrement de bout en bout, ce n’est pas propre à Autocrypt).

HPKP va être abandonné par Google pour Chrome

Oui, ça s’inscrit dans la stratégie de Google de contrecarrer toute initiative qui pourrait encourager à se passer du cartel des CA, et au contraire à renforcer le caractère incontournable des CA en poussant Certificate Transparency.

Rien de bien nouveau, c’est une stratégie en vigueur depuis déjà pas mal de temps.

Sauf que si j'en crois le journal, c'est pas seulement on first use

On dirait. Si je comprends bien la section Updating Autocrypt Peer State, l’apparition d’une nouvelle clef dans un entête Autocrypt (différente de celle déjà vue auparavant pour le même interlocuteur) est silencieuse : le client compatible Autocrypt met à jour sa base de données avec la nouvelle clef comme si de rien n’était.

Ce n’est pas du TOFU au sens où on l’entend habituellement, et tel qu’il est pratiqué avec SSH ou avec le modèle tofu de GnuPG — dans ces modèles, l’apparition subite d’une nouvelle clef produit un avertissement.

Je trouve ça personnellement regrettable mais c’est un choix cohérent avec les principes énoncés clairement dans le document :

• Autocrypt ne cherche explicitement pas à protéger contre les attaques actives (Autocrypt Level 1 only defends against passive data collection attacks) ;
• Autocrypt doit être le plus transparent possible vis-à-vis des utilisateurs (Ideally, Autocrypt users see very little UI).

Donc des headers de 300 à 1Mo pour ceux qui ont participé à une keysigning…

On peut aussi critiquer sans tomber dans la mauvaise foi. Deux paragraphes après la référence au RFC 4880 (qui explique ce qu’est une « Transferable Public Key »), la spec Autocrypt précise que la clef à inclure dans l’en-tête est une version minimale contenant uniquement :

• la clef publique proprement dite,
• l’User ID correspondant à l’adresse e-mail utilisé (si la clef est associée à d’autres User ID, elles ne sont pas incluses),
• l’auto-certification la plus récente,
• la sous-clef de chiffrement et sa signature associée.

Soit peu ou prou ce qu’on obtient avec l’option --export-options export-minimal de GnuPG, avec la suppression des User ID supplémentaires en plus.

Ça reste trop gros à mon goût pour être inclus dans un en-tête dans chaque e-mail, mais on est loin des 300 ko à 1 Mo, indépendamment du nombre de certifications sur ta clef.

il faut à la fois changer la signature SHA512 mais aussi modifier la clef PGP sur le serveur public, pas si facile que cela à faire si on n'est propriétaire de l'adresse de courriel

Euh, si, c’est très facile : n’importe qui peut charger une clef à n’importe quel nom sur un serveur de clefs.

Mettre la clef complète dans l’en-tête ou ne mettre que l’empreinte et une indirection vers la clef complète, en terme de protection contre une attaque MITM ça revient peu ou prou au même : dans le premier cas l’attaquant remplace la clef dans l’entête, dans le deuxième cas il remplace l’empreinte et publie la clef correspondante sur un serveur.

Sans oublier que l’attaquant peut dans tous les cas faire un truc encore plus simple, qui rend toute cette discussion complètement théorique : supprimer purement et simplement les en-têtes Autocrypt dans tous les messages. Les logiciels compatibles Autocrypt aux deux extrémités de la conversation en déduiront chacun que le logiciel d’en face ne connaît pas Autocrypt, et continueront à envoyer des messages en clair…

On ne peut pas envoyer sa signature SHA512 de sa clef et la personne la récupère de manière transparente sur un serveur PGP

Pourquoi une « signature » (qui n’en est pas une, c’est un condensat mais passons) SHA-512 ? Il y a l’empreinte SHA-1 de la clef pour ça.

Oui, je sais, SHA-1… mais SHA-1 n’est pas cassé pour ce cas d’usage et le calcul de l’empreinte SHA-1 d’une clef OpenPGP est clairement défini par le standard — il n’y a qu’une seule façon de calculer une telle empreinte. Si tu génères un condensat SHA-512 d’une certaine façon et que ton correspondant le calcule d’une autre façon, la comparaison est impossible.

Cela étant, on peut déjà faire ce que tu proposes (et il y a une option dans Enigmail pour le faire), c’est l’en-tête OpenPGP (non-standard — il y a eu un brouillon à une époque mais ce n’est pas allé plus loin) :

OpenPGP: id=<empreinte SHA1>; url=<url vers un serveur de clefs>

Quant à savoir pourquoi Autocrypt n’a pas ré-utilisé cet entête, aucune idée… NIH, peut-être ?

Eve intercepte ce message, édite l'en-tête à la volée et remplace la clé publique d'Alice par la sienne. Elle renvoie le message modifié à Bob ;

Respectons les usages : Eve ne peut pas faire ça, c’est un attaquant passif qui ne peut qu’écouter (Eavesdrop). L’attaquant actif, qui peut émettre et/ou modifier des messages, c’est Mallory.

Plaisanterie à part, je suis d’accord sur le fond, mais il faut quand même voir qu’on passe d’une situation où n’importe qui peut lire les messages de tout le monde sans que ça ne coûte grand’chose et sans quasiment aucun risque d’être découvert, à une situation (dans le cas hypothétique où tout le monde se met à chiffrer, que ce soit grâce à Autocrypt ou à n’importe quelle autre méthode similaire) où l’attaquant doit cibler les personnes dont il veut lire les communications et les attaquer activement, avec un risque non-négligeable de se faire griller.

Ce n’est certes pas parfait et les individus « à haut risque » (genre ancien contractant de la NSA avec des choses à révéler) seraient sans doute bien inspirés de ne pas se fier à ce genre de solutions, mais c’est tout de même un progrès.

je n'ai pas vu de moyen d'éviter que cet entête soit rajouté systématiquement, et du coup, j'ai désactivé Enigmail temporairement :(

Tu peux désactiver Autocrypt uniquement sans avoir à désactiver Enigmail dans son ensemble.

Menu Edit > Account Settings, rubrique OpenPGP Security, onglet Autocrypt, décocher Enable Autocrypt.

Que je leur fasse un minimum confiance pour ne pas intentionnellement cacher de code malicieux dans le script d’installation, sans doute (sinon ils pourraient tout aussi bien cacher le code malicieux dans le programme lui-même, indépendamment de la manière dont il est installé — sauf que le programme est typiquement exécuté avec les droits d’un utilisateur normal, alors que le script d’installation, tel qu’il est lancé dans la commande proposée au copier-coller, est exécuté avec les droits du super-utilisateur).

En revanche, que je leur fasse confiance pour écrire un script d’installation sans bug, qui fonctionnera exactement comme prévu… Non, juste non. Je ne fais confiance à aucun développeur pour écrire du code sans bug. Et un bug dans un script d’installation qui par nature touche aux fichiers du système, non merci, très peu pour moi.

Pourquoi se donner tant de mal à vouloir cacher des commandes derrière un copier-coller innocent alors qu’il est apparemment parfaitement acceptable de demander aux utilisateurs de faire ceci :

Please do not use your distribution provided calibre package. […] To install or upgrade, simply copy paste the following command into a terminal and press Enter:

sudo -v && wget -nv -O- https://download.calibre-ebook.com/linux-installer.py | sudo python -c "import sys; main=lambda:sys.stderr.write('Download failed\n'); exec(sys.stdin.read()); main()"

Sept contributeurs (dont moi) ont travaillé sur cette dépêche, un modérateur l’a validée, et on a quand même trouvé le moyen de ne pas voir que le titre de la première section (« OpenPGP ») était en doublon… Doh! :D

Sorry about that. Si un modérateur pouvait retirer le « OpenPGP » surnuméraire, merci.

Sans spécification correspondante et donc sans garantie que cela soit compris par d’autres implémentations qu’Enigmail, l’intérêt est réduit. La raison d’être d’OpenPGP est de garantir l’interopérabilité (sinon on aurait pu continuer à utiliser PGP pour n’échanger qu’avec des utilisateurs de PGP, sans se soucier de ceux qui utilisent autre chose).

L’auteur admet d’ailleurs que compléter ce brouillon n’est plus sa priorité

Pour ne pas être injuste : l’auteur en question, Daniel Kahn Gillmor (dkg), est un développeur Debian (en charge, entre autres, des paquets relatifs à GnuPG), contributeur à GnuPG, activiste de l’ACLU, et membre actif de l’IETF dans le domaine de la sécurité (notamment très impliqué dans le travail en cours sur le RFC 4880bis). Pour ne parler que des casquettes que je lui connais.

On peut comprendre qu’il ait d’autres priorités. :)

cela serait dû non à GnuPG, mais à un standard en cours de développement, le "Memory Hole Standard".

« En cours de développement » ? Avec un nom de domaine qui ne mène plus nulle part (pas d’enregistrements A ou AAAA), un dépôt sur GitHub plus mis à jour depuis trois ans, qui renvoie à un autre dépôt à peine plus actif dans lequel le brouillon de standard n’a plus été modifié depuis 2015 alors qu’il ne spécifie encore rien du tout ?

Jusqu’à preuve du contraire, ce n’est pas « en cours de développement », c’est « abandonné » pour ne pas dire « mort-né ».

L’auteur admet d’ailleurs que compléter ce brouillon n’est plus sa priorité, même s’il ne va pas jusqu’à dire qu’il est formellement abandonné.