gouttegd a écrit 1805 commentaires

Une autre alternative […] dont le code n'est pas Open Source est l'applet Javacard publié par l'ANSSI

Oui. Cette implémentation ne figure pas dans ma dépêche de 2014 tout simplement parce qu’elle n’existait pas encore à l’époque (ou alors elle n’était pas encore publique), mais je la mentionne dans une version de la dépêche que je maintiens à jour sur mon propre site.

Je maintiens aussi sous une forme plus compacte une liste des implémentations de la spécification.

/publicité

J'ai lu (il me semble) dans les publications de Gniibe qu'il préférait également l'utilisation d'un STM32 « standard » plutôt que d'un autre chip spécialement orienté crypto avec des fonctions « spécialisées » (et fermées), car il expliquait qu'on ne sait jamais ce que ça cache, et que ça finit toujours par être craqué un jour. Il est très orienté « liberté avant le reste »

Je confirme, c’est également ce qui ressort de ses interventions sur les listes de GnuPG et de Gnuk.

Pourquoi avoir pris la clé de la FSF plutôt que la Start ? Referais-tu ce choix aujourd'hui ?

À vrai dire je n’ai rien choisi du tout, mon FST-01 m’a été offert en personne par Werner Koch. :)

Si je devais choisir aujourd’hui, entre la Nitrokey Start et le FST-01 mon choix se porterait probablement toujours sur ce dernier, pour plusieurs raisons :

a) À titre personnel, j’apprécie que le FST-01 soit de conception libre.

b) Une des choses qui me dérangent avec la Nitrokey Start est que Nitrokey ne donne pas beaucoup d’informations sur la version de Gnuk utilisée et les options de compilation choisies.

Sur la version, la seule information que j’ai trouvée est cette annonce de l’année dernière qui mentionne Gnuk 1.2 datant de mai 2016. Les Nitrokey Start en production actuellement utilisent-elles toujours cette version, ou bien sont-elles passées à une version plus récente ? À ma connaissance cette information n’est disponible nulle part.

c) Je ne suis pas certain que la fonctionnalité de mise à jour « à chaud » (via reGNUal, comme expliqué dans la dépêche) soit utilisable sur la Nitrokey Start (et encore une fois, Nitrokey ne fournit aucune info).

(J’exclus le critère du prix, le FST-01 de la FSF et la Nitrokey Start n’étant pas vraiment comparable à mon sens : on a d’un côté un produit commercial fini vaisemblablement produit en relativement grande quantité, de l’autre un « goodie » dont le principal but est de supporter financièrement la FSF.)

À noter que si je devais me procurer un jeton Gnuk aujourd’hui, j’envisagerais sérieusement une troisième option : acheter un deuxième débogueur ST-Link/V2 et le convertir en jeton.

J'aimerai mettre ma clé primaire sur un token aussi pour que ma clé ne soit jamais accessible. Est-ce que ça vaut le coût de payer un deuxième token (surtout s'il coûte $50) ?

Pourquoi pas, mais si tu veux mettre ta clef primaire sur un jeton tu peux aussi te passer d’avoir une sous-clef de signature (la clef primaire est par défaut utilisable pour signer, sauf si tu as explicitement demandé à GnuPG de générer une clef primaire utilisable seulement pour certifier) et mettre ta clef primaire dans le slot de signature de la carte OpenPGP.

Je voudrai néanmoins savoir quel est l'avantage d'une telle clef sur une simple clef USB chiffrée avec luks et contenant les clefs GnuPG ?

Principalement deux :

D’abord et surtout, avec une carte OpenPGP les clefs privées sont et restent stockées sur la carte, l’ordinateur hôte ne les voit jamais, même temporairement.

Ensuite, GnuPG a un support explicite pour la carte OpenPGP (qu’elle soit implémentée sous la forme d’une « vraie » carte à puce ou sous la forme d’un jeton USB comme Gnuk), ce qui rend l’utilisation de ce type de carte très facile (en gros, dès lors que GnuPG a besoin d’une clef privée, il demande à l’utilisateur d’insérer sa carte et de saisir son PIN, et il se débrouille avec le reste ; on peut difficilement faire plus facile). Alors qu’avec un support de stockage chiffré par LUKS et contenant les clefs privées, c’est à toi qu’il revient de faire en sorte que GnuPG sache où trouver les clefs privées quand il en a besoin.

S'il est facile, avec GnuPG 2.2.x de choisir facilement la génération de clefs RSA ou EC sur les clefs Gnuk, ce n'est pas le cas avec GnuPG 2.1.x (nécessité de forcer au préalable la génération de clefs elliptiques comme expliqué ici https://www.nitrokey.com/news/2017/nitrokey-start-supports-elliptic-curves-ecc)

Ça ne concerne que la génération de clefs directement sur le jeton, une option dont j’ai décidé de ne pas parler puisque c’est une mauvaise idée selon moi en raison de l’impossibilité d’avoir une sauvegarde des clefs ailleurs que sur le jeton.

Mon observation portait sur le fait que la courbe Curve25519 fait l'objet de choix plutôt expliqués et documentés, ce qui n'est pas le cas des courbes du NIST comme des courbes ANSSI […]. Courbes dont le choix des paramètres est "obscure" et laisse à penser qu'il peut y avoir "manipulation

J’ai bien compris. Mon point est qu’il y a d’autres raisons de préférer la courbe 25519 aux courbes du NIST (ou de l’ANSSI), basées sur les seules propriétés de ces courbes, sans qu’il ne soit nécessaire de spéculer sur ce qu’a fait ou aurait pu faire le NIST.

On ne sait pas si les courbes du NIST ont été manipulées, mais on sait qu’elles sont par nature difficile à implémenter de façon sécurisée et potentiellement vulnérables à toutes sortes d’attaques par canaux cachés.

Excellent article qui m'a encore appris de nouvelles choses.

Merci.

Je vous propose quelques modestes ajouts et précisions :

Une fois la dépêche publiée il ne m’appartient plus de la modifier, mais c’est à ça que servent les commentaires. :)

plusieurs de options proposées comme les courbes Curve25519, l'option KDF-DO, l'option enable-factory-reset nécessitent une version très récente de GnuPG comme la 2.2.6.

Seule l’option KDF-DO nécessite GnuPG 2.2.6 (sortie en avril 2018). L’option factory-reset ou la prise en charge des courbes elliptiques (y compris la courbe 25519) font partie des fonctionnalités introduites dans la branche de développement GnuPG 2.1 (par exemple, version 2.1.1 en décembre 2014 pour factory-reset) et à ce titre sont présentes depuis le début de la branche 2.2 sortie en août dernier.

Or, plusieurs distributions Linux dont les plus célèbres (Debian stable, LinuxMint..) ne sont pas encore en version 2.2.x.

Hélas, et il est grand temps que ça change. J’ai pris le parti de ne plus jamais parler des branches obsolètes et plus maintenues de GnuPG. Aujourd’hui, GnuPG, c’est GnuPG 2.2.

Pour rappel ou information, les branches 2.0/2.1 ne reçoivent plus aucune mise à jour de la part des développeurs de GnuPG, y compris en cas de faille critique. Si une distribution continue à fournir une version 2.0/2.1, il appartiendra seulement aux mainteneurs de ladite distribution de rétroporter ce qui doit l’être.

précisez pour les nouveaux venus que la courbe Curve25519 bénéficie d'une "confiance" accrue sur P-256 dans la mesure ou elle n'a pas été conçu par le NIST américain et que c'est cet aspect qui la rend si populaire et demandée bien qu'elle soit de "même résistance"

Pas seulement. En fait, d’après Bernstein and Lange (2016) (full disclosure : Daniel J. Bernstein est l’un des principaux auteurs derrière la courbe 25519), les soupçons de manipulation de la part du NIST ne seraient même pas le véritable problème des courbes du NIST, qui de par leur conception sont intrinsèquement beaucoup plus susceptibles à toutes sortes d’attaques par canaux cachés (ce qui à mon humble avis reflète simplement le fait que ces courbes ont été conçues il y a une vingtaine d’années, au tout début de la cryptographie ECC — la courbe 25519 est « meilleure » non pas parce qu’elle n’a pas été manipulée, mais parce qu’elle bénéficie des progrès des quinze dernières années de recherche dans le domaine).

Je me demande si ce projet est vraiment vivant et, le cas échéant, s’il est bien sérieux…

• La dernière activité sur la liste starttls-everywhere@lists.eff.org remonte à octobre 2015.
• Depuis 2014 que le projet existe, leur STARTTLS Policy List (qui liste les domaines prenant en charge STARTTLS) est quasiment vide, la dernière version comptient une vingtaine de domaines à tout casser.
• Lorsqu’on tente d’ajouter son domaine à la liste, le mail de confirmation prétendant venir de no-reply@starttls-everywhere.org est envoyé à partir d’un hôte explicitement non autorisé par l’enregistrement SPF de starttls-everywhere.org, conduisant au rejet du mail par n’importe quel serveur implémentant une validation SPF — c’est peut-être en partie pour ça que leur liste est vide d’ailleurs, combien ont essayé d’ajouter leur domaine mais n’ont jamais reçu le mail de confirmation ?
• C’est un détail, mais rien que la page d’accueil du site s’affiche n’importe comment dans Firefox (je sais que c’est un navigateur pas très connu, mais quand même).

Si tu taxe l'importation d'acier, c'est que t'importes de l'acier parce que t'en as besoin pour ton industrie. Si l'industrie américaine paye plus cher son acier (parce qu'elle aura payé des taxes), forcément elle sera moins compétitive.

En gros, Trump est nostalgique de l’époque où la production d’acier était une grosse industrie, et il s’imagine pouvoir revenir à cette époque en taxant les importations d’acier étranger pour forcer les industriels américains à acheter de l’acier made in America. Je doute très fortement que Trump se soucie le moins du monde de ce que peuvent être les conséquences sur les industries downstream. (En même temps, faut le comprendre, c’est compliqué, l’économie ; personne ne se doutait que c’était si compliqué.)

C’est comme si en France quelqu’un proposait rien de moins que de sauver l’industrie minière du Nord de la France en taxant les importations de charbon. (Il y a certes une taxe sur le charbon, mais à ma connaissance personne ne prétend que ça va automatiquement nous ramener au temps de Germinal, ni ne prétend que c’est l’objectif souhaité.)

je pensais que pour le renouvellement des certificats Let's Encrypt, il était nécessaire de conserver le http (pour les challenges), apparemment ce n'est pas le cas. Est-ce moi qui me suis trompé ?

La dernière fois que j’ai vérifié le protocole ACME n’était pas très clair sur ce point. D’un côté il dit explicitement que le défi http-01 doit passer sur HTTP, pas sur HTTPS, mais de l’autre il dit aussi que les redirections HTTP doivent être suivies, sans exclure explicitement les redirections HTTP→HTTPS (qui ne sont que des redirections HTTP parmi d’autres). Du coup, ces redirections HTTP→HTTPS sont-elles admises ? D’après moi on peut conclure aussi bien « oui » que « non » …

Et dans le cas où la redirection HTTP→HTTPS est considérée comme admise, le reste du standard ne dit rien quand à la validation du certificat utilisé sur la redirection…

En pratique, du côté de chez Let’s Encrypt il me semble que leur implémentation a) accepte les redirections HTTP→HTTPS et b) ne vérifie pas dans ce cas le certificat du serveur. De sorte qu’on peut normalement se permettre de rediriger l’intégralité du trafic arrivant sur le port 80 vers le port 443 sans craindre, a priori, de problèmes avec le défi http-01.

(Cela dit, chez moi, pour être sûr de ne pas avoir de soucis y compris en cas de changement de comportement de l’implémentation de Let’s Encrypt je préfère continuer à tout rediriger sur le port 443 sauf les requêtes pour .well-known/acme-challenge/.)

Le truc fait grosso modo 1000 lignes de C++, mon projet sur Github est indiqué comme étant composé à 95.5% de shell…
On a 13 fichiers à la racine du projet dédié aux autotools, plus 2 fichiers pour chaque répertoire (Makefile.in et Makefile.am)

Rien ne t’oblige à committer les fichiers générés, il est d’ailleurs généralement recommandé de ne pas le faire…

Perso, pour tous mes projets j’ai juste un configure.ac et un Makefile.am à la racine, plus un Makefile.am dans chaque dossier source. Tout le reste est généré et n’a pas besoin d’être committé.

Le clou dans le cercueil à été 6 mois plus tard quand j'ai voulu ajouter un nouveau fichier C++ au build. Après plusieurs heures passées pour re-comprendre le bouzin

Des heures pour trouver qu’il faut ajouter le nom du fichier à la variable monprogramme_SOURCES dans le fichier Makefile.am ?

comment on met à jour un .am à partir d'un .in

On ne le fait pas, c’est le contraire : le Makefile.in est généré à partir du Makefile.am. C’est sûr que si tu as voulu ajouter ton nouveau fichier dans le Makefile.in, ça allait beaucoup moins bien marcher…

Sérieusement les éditeurs de jeux vidéos devraient mettre Autotools plutôt que SecuRom pour protéger leurs jeux des modifications des hackers.

Ça les protégera seulement des Kevin qui ne savent pas lire des docs, certainement pas des hackers…

Sérieusement, tu dis avoir eu à cœur d’apprendre les Autotools, mais ton expérience, soit est une caricature trollesque, soit est typique de celui qui veut utiliser les autotools sans rien comprendre de ce qu’il fait. (C’est très fréquent : beaucoup d’utilisateurs des Autotools se contentent de recopier ce qu’ils voient dans d’autres projets sans même jamais lire la moindre documentation ; ça ne peut que mal se terminer.)

Les Autotools ne sont pas les outils les plus faciles à utiliser, c’est un fait et c’est une critique tout-à-fait valable. Mais là, le problème est entre la chaise et le clavier.

Sauf que autotools est beaucoup trop Linux only.

Alors là c’est n’importe quoi. Les autotools fonctionnent sur n’importe quel système qui a un Bourne shell (même pas un shell POSIX, non, un Bourne shell des années 80 fait l’affaire) et un Make. Il n’y a aucune dépendance spécifique à Linux ni au système GNU de manière générale.

Merde, une des principales raisons d’être des autotools a toujours été de pouvoir compiler les programmes du projet GNU sur toutes les variantes d’UNIX. D’ailleurs c’est peut-être même un des principaux reproches qu’on pourrait leur faire aujourd’hui : ils ont dans une large mesure été conçus pour répondre à des problématiques du passé, datant de l’époque des « UNIX wars » et des compatibilités hasardeuses. Qui a besoin aujourd’hui de compiler des programmes pour Tektronix UTekV, Amdahl UTS ou Motorola System V/88 ?

Mais leur reprocher d’être Linux-centrique, même pour un vendredi c’est trop gros.

Oublie les projets autotools sur Windows.

C’est vrai, mais il est au moins possible de cross-compiler des programmes pour Windows depuis un système où les autotools sont disponibles. Pour un projet dont les développeurs sont sous GNU/Linux ou assimilés et qui veut fournir des exécutables Windows, c’est une option viable.

Je sais que beaucoup de gens aiment bien dire pis que pendre des autootools, mais j’aimerais quand même les défendre un peu, à la fois du point de vue de l’utilisateur (ie, celui qui veut compiler et installer un programme utilisant les autotools) et du point de vue du développeur (celui qui utilise les autotools pour gérer son projet).

Du point de vue de l’utilisateur, d’abord un peu de contexte. J’utilise Slackware, qui comme vous le savez peut-être est fournie avec assez peu de logiciels, de sorte qu’il m’arrive fréquemment de compiler moi-même les programmes que j’utilise (certainement plus souvent qu’un utilisateur de Debian ou Fedora par exemple). À titre indicatif, sur les 1534 paquets installés présentement sur mon système, 387 (25%) sont étrangers à la distribution et ont été compilés par mes soins. Une conséquence de ça, c’est que je suis pas mal confronté aux systèmes de build (non pas que ça me fasse grand plaisir, mais quand on choisit Slackware on sait à quoi s’attendre).

Encore un peu de contexte, avec quelques chiffres : sur les 387 paquets que j’ai construit moi-même et que j’utilise actuellement (je ne compte pas les paquets que j’ai construit par le passé mais que je n’utilise plus), j’enlève 149 paquets pour des modules Python qui ne sont pas vraiment pertinents ici (ils se construisent tous de la même manière, python setup.py build — et bon sang comme c’est agréable). Reste 238 paquets non-Python qui se répartissent ainsi :

• 173 utilisant les autotools (73%) ;
• 22 utilisant un « simple » (ou moins simple) Makefile (9%) ;
• 19 utilisant CMake (8%) ;
• 9 utilisant Waf (4%) ;
• 9 utilisant QMake (4%) ;
• 3 utilisant un système maison (1%) ;
• 2 utilisant Meson (1%) ;
• 1 utilisant Ant (< 1%).

Et bien, pour moi, le bilan est sans appel : je préfère largement construire un paquet pour un projet utilisant les autotools. Presque tous les autres systèmes m’ont posé des casses-têtes que je n’ai jamais eu avec les autotools qui sont pourtant beaucoup plus fréquents.

Pêle-mêle, quelques trucs qui m’irritent presque chaque fois que je dois compiler un projet sans les autotools :

• Pas toujours d’option standard pour indiquer où placer les bibliothèques. J’ai toujours besoin d’une option de ce genre, parce que Slackware a choisi, pour sa version 64 bits, d’installer les bibliothèques dans /usr/lib64 au lieu de /usr/lib. Oui, c’est un choix qui va à l’encontre de la plupart des autres distributions, mais il n’empêche : le système de build est supposé permettre de s’adapter au système cible. S’il ne le permet pas, c’est un système de build de merde, dont je maudis les auteurs sur cinq générations.

Mention très défavorable à CMake, qui est quand même là depuis suffisamment longtemps pour qu’on puisse se dire qu’une telle option devrait être disponible en standard, mais non : avec CMake, chaque projet fait sa propre sauce. Parfois il y a une option LIB_SUFFIX, parfois une option INSTALL_LIB_DIR, parfois une option WANT_LIB64, parfois une option MULTIARCH_SUFFIX — j’adore parcourir les CMakeLists.txt à la recherche de la bonne option, c’est ma joie —, et parfois… il n’y a pas d’option : le chemin d’installation des bibliothèques est codé en dur et il faut aller le modifier soi-même dans le CMakeLists.

• Pas toujours d’option standard pour indiquer où placer les pages de manuel ou d’info. Idem que ci-dessus. Avec les autools, c’est --mandir et --infodir. Avec CMake, parfois c’est MANDIR, le plus souvent c’est rien du tout, encore une fois il faut changer le chemin codé en dur dans le CMakeLists (ou aller déplacer les pages de manuel dans le bon dossier après installation).

• Plus généralement, le fait que tous ces projets ne sont pas fichus de s’arranger pour avoir une interface raisonnablement commune. Pensez ce que vous voulez des autotools, mais ils sont là depuis plus de vingt ans et les développeurs y sont habitués. Si vous voulez coder le nouveau build system du futur, au moins essayez de coller autant que possible à la syntaxe du classique configure (un bon point à Waf et Meson sur ce point — CMake, va te jeter dans les flammes de la Montagne du Destin où tu as été forgé, merci).

• Le simple fait de devoir installer yet-another-build-system juste pour pouvoir compiler un logiciel. Les autotools ont ceci de pratique qu’ils ne doivent être installés que sur la machine du développeur. Côté utilisateur, un shell (même pas besoin que ce soit GNU Bash) et un make (même pas besoin que ce soit GNU Make) suffisent. Mention spéciale aux projets qui ne se compilent qu’avec la dernière version de leur build-system, celle qui est sortie avant-hier.

Du point de vue du développeur maintenant : les autotools ne sont certes pas parfait (notamment, ils sont lents, c’est indéniable), mais il y a quand même quelques petites (ou pas si petites) choses que j’apprécie, comme :

• le support de la compilation croisée, y compris vers Windows (--build=x86_64-slackware-linux --host=i686-mingw32) ;
• make distcheck, pour non seulement générer une tarball mais vérifier automatiquement qu’elle est complète et autosuffisante ;
• le support automatique de toutes les options qu’on attend d’un système de build conforme aux GNU Coding Standards (--prefix, --libdir, --mandir, plus généralement tous les --machinsdir, --disable-static, --program-prefix, etc.) ;
• la prise en charge de gettext (alors là, je suis d’accord, c’est géré de façon très moche — mais au moins c’est géré, ce qui n’est pas le cas avec tous les autres systèmes…).

Les autotools ont leur défaut, certes. Mais demandez-vous aussi pourquoi ils sont encore massivement utilisés.

Pour ma part, franchement, je n’ai vu passer aucun système de build que je puisse considérer comme un successeur crédible aux autotools (non, CMake n’est pas un successeur crédible, voir ci-dessus), à part Meson récemment qui semble prometteur.

Ça me fait penser à ce billet de « Jean-Pierre Troll » (aussi paru dans GNU/Linux Magazine France) : Comment être indispensable à un projet

Du côté de chez Google ? De mémoire les deux principales raisons officiellement avancées sont :

• DNSSEC (dont DANE dépend) se repose trop sur RSA 1024, alors que tout le monde veut se débarasser de RSA 1024 ;
• DANE augmente les risques de fishing, puisque n’importe qui peut obtenir un nom de domaine pour, par exemple, paypa1.com, et publier dans cette zone un certificat qui serait accepté par le navigateur (si les navigateurs supportaient DANE).

Le premier argument était déjà de mauvaise foi à l’époque : les clefs DNSSEC de 1024 étaient déjà en train d’être progressivement remplacées par des clefs de 2048 bits, et DNSSEC permet aussi l’utilisation de clefs ECDSA pour ceux qui trouvent que des clefs RSA de 2048 bits sont trop volumineuses pour le DNS.

Pour ce qui est du deuxième… mort de rire, comme si les autorités de certification faisaient quoi que ce soit contre le phishing… (Il est vrai que certaines prennent le temps de vérifier, avant de délivrer un certificat, que le nom demandé n’est pas « trop proche » d’un nom bien connu comme paypal et assimilés. Mais : ① toutes ne le font pas — elles n’ont aucune obligation de le faire — et la magie du système des CA est que la fiabilité du système est celle de la moins fiable des CA ; ② cette protection anti-fishing, quand elle est mise en œuvre que pour protéger les « gros » sites bien connus, les autres peuvent aller se faire voir.)

La véritable raison est que pour Google, toute technique qui permettrait de se passer des CA (comme DANE ou HPKP quand on les utilise pour épingler un certificat auto-signé ou signé par une autorité « non-reconnue ») est à banir. Pour des raisons qui m’échappent, Google considère que les CA sont une pierre angulaire d’Internet et il est hors de question de s’en passer. Certificate Transparency sert précisément à rendre les CA encore plus indispensables qu’elles ne le sont déjà. À cela s’ajoute une certaine défiance envers tout ce qui passe par le DNS.

Pour ceux qui trouveraient que j’exagère sur les intentions de Google : regardez par exemple ce qu’ils ont fait avec leur proposition SMTP-STS (SMTP Strict Transport Security, en gros la transposition de HTTP STS pour les serveurs mails). La première version du brouillon était prévue pour interagir sans heurts avec DANE : il y était dit que SMTP-STS pouvait être utilisé aussi bien seul que conjointement avec DANE, et qu’il y avait des avantages spécifiques à utiliser les deux ; l’utilisation d’un certification auto-signé (ou signé par une CA « non-reconnue ») était aussi explicitement autorisée si ledit certificat était publié dans le DNS. Un mois plus tard, le brouillon suivant fait machine arrière toute : la cohabitation entre DANE et SMTP-STS (renommé MTA-STS) n’est plus envisagée, DANE est désormais décrit comme un mécanisme concurrent ; la politique STS, qui pouvait auparavant être publié dans le DNS, doit désormais être récupéré via HTTPS ; et la possibilité d’utiliser un certificat auto-signé a complètement disparu, désormais le certificat doit être signé par une CA « reconnue ». Voyez-y ce que ce vous voulez, mais pour moi entre le premier et le deuxième brouillon quelqu’un chez Google (la plupart des auteurs des deux brouillons sont chez Google) s’est rappelé que tout ce qui pouvait permettre de réduire l’emprise des CA était à proscrire.

Au-delà de chez Google, pourquoi DANE n’est pas davantage répandu de manière générale ? Probablement un problème d’œuf et de poule, je suppose : les navigateurs ne l’implémentent pas (en tout cas pas nativement), donc côté serveur on ne le déploie pas (note : côté serveur, il n’y a plus rien à implémenter, tout ce dont on a besoin est d’un serveur DNS supportant DNSSEC, ce qui est le cas de n’importe quel serveur DNS digne de ce nom), donc on ne l’implémente pas côté client, donc on ne le déploie pas côté serveur, et ainsi de suite… Sans un « gros » pour pousser les choses (comme Google qui pousse Certificate Transparency), ça ne va pas bien loin…

(Je pense personnellement qu’on franchirait déjà un grand pas si les systèmes d’exploitation pouvait être fourni avec un résolveur DNS validant par défaut, ce qui à ma connaissance n’est aujourd’hui le cas d’aucun OS. Ce n’est pas normal qu’il faille être un « geek » pour pouvoir bénéficier d’une résolution DNSSEC sur sa machine…)

Pour ceux qui me moinssent, franchement je ne comprends pas pourquoi.

De manière générale, sur LinuxFR il est vain de chercher à comprendre :

• les raisons derrières les moinssages et les pertinentages ;
• les réactions des gens dès qu’il est question de systemd.

Alors chercher à comprendre la raison d’un moinssage sur un sujet où on parle de systemd…

Regarde plus bas les réponses au message qui demande la source de l’affirmation « Devuan représente plus de 1% des utilisateurs de Debian » : la réponse de maclag, qui est certes drôle mais évidemment pas sérieuse (ni ne se prétend telle) est à 10 (à l’heure où je poste), tandis que la réponse de BohwaZ, qui n’est certes pas drôle mais est probablement correcte (en tout cas crédible) est à -2.

Rien ne m'interdit de diffuser du logiciel sous licence libre qui ne serait pas compilable.

Ce n’est sans doute pas le cas de toutes les licences libres, mais la GPL au moins est claire sur ce point. Extrait de la GPL 2 :

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.

Extrait de la GPL 3 :

The "Corresponding Source" for a work in object cide means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control these activities.

la présence de Expect-CT demande au navigateur d'aller faire une requête à des journaux publics de Certificate Transparency.

C’est un peu (beaucoup, en fait, parce que quand Google décide de monter une usine à gaz pour donner l’impression qu’ils solutionnent un problème, ils ne font pas les choses à moitié) plus compliqué que ça.

Le navigateur n’a pas à aller chercher lui-même les jetons SCT. C’est au serveur de les lui fournir, par trois moyens possibles :

• embarquer les jetons directement dans le certificat, sous la forme d’une extension X.509 (c’est à la CA émettrice du certificat de le faire, évidemment, le serveur ne peut pas faire ça de lui-même) ;
• servir les jetons SCT « à côté » du certificat lors de la poignée de main TLS, via une extension du protocole TLS ;
• servir les jetons SCT dans une réponse OCSP « épinglée », via une extension du protocole OCSP.

(Oui, le bon fonctionnement de Certificate Transparence nécessite de modifier toute la chaine HTTPS, depuis les CA jusqu’au navigateur final. À côté de ça DANE et HPKP ne nécessitent qu’une prise en charge par le navigateur indépendamment de tous les autres acteurs, mais ça n’a pas empêché Google de faire preuve d’une phénoménale mauvaise foi en promouvant CT comme « plus simple ».)

Après, une fois que le navigateur a en mains les jetons SCT, il doit aller vérifier auprès d’un « auditeur CT » que les jetons sont valides, c’est-à-dire que les certificats correspondants ont bel et bien été publiés dans des journaux CT. Cette vérification doit normalement être faite par lots et « de temps en temps » (et non pas à chaque connexion), de sorte que l’auditeur n’a pas une vision en temps réel de toutes les connexions HTTPS d’un client. Mais oui, l’auditeur CT pourra quand même connaître tous les jetons dont le client demande la validation, et donc tous les serveurs visités.

Je pense que « cette version d’Emacs » fait référence non pas à cette release 26.1 (par opposition aux versions précédentes), mais au fait qu’il s’agit spécifiquement de GNU Emacs, par opposition à tous les autres Emacs (comme Gosling Emacs, XEmacs… cf la timeline Emacs de Jamie Zawinski).

Alors, d’un côté : bravo à l’administrateur qui se lève le dimanche matin, constate le problème, et fait immédiatement le nécessaire.

D’un autre côté : pas bravo pour avoir laissé le certificat expirer en premier lieu. C’est pas sérieux, si ça se reproduit je donnerai mes 0 € d’abonnement à un autre site.

Bon, et du coup, le passage d’un certificat Gandi à un certificat Let’s Encrypt, c’était ce qui était prévu ou c’est juste que c’était plus facile d’obtenir un certificat en urgence auprès de Let’s Encrypt ? :D

Il faudrait au moins permettre la suppression de la clé (ou au moins de la partie UID nom/prénom/courriel/photo) par le propriétaire de la clé.

RGPD ou pas, c’est une demande qui revient souvent. Le fait que les serveurs de clefs sont en écriture seule est sans doute un des aspects les plus mal connus de ces serveurs, et il n’est pas rare en découvrant cet aspect que la première réaction d’un utilisateur soit quelque chose du genre « mais pourquoi vous n’autorisez pas au moins le propriétaire de la clef à la supprimer, il suffirait de… »

Pour ceux qui seraient intéressés, cette question a fait l’objet d’une longue discussion sur gnupg-users en janvier dernier. Le point de départ de la discussion. Et une conclusion à méditer de Robert J. Hansen : But please, understand why SKS works the way it does before telling people to change it.

Ce qui contredit ton affirmation que

Ah, et en aucun cas la « faille » ne permet « d’accéder aux anciens e-mails chiffrés ».

Je maintiens : l’attaque ne permet pas d’accéder aux anciens e-mails chiffrés. Elle permet à un attaquant, ayant déjà mis la main sur des anciens messages (par enregistrement du traffic à l’époque, ou par pénétration du serveur IMAP où ces messages sont stockés par exemple), de réaliser une attaque active en fabriquant un nouveau message contenant l’ancien message dont il souhaite obtenir le texte clair.

Autrement dit, c’est une attaque active qui permet (ou permettrait en l’absence des contre-mesures propres à OpenPGP) à chaque coup le texte clair d’un message. Le fait que le message en question soit un nouveau message intercepté extemporanément ou un ancien message capturé et rejoué par l’attaquant ne change concrètement pas grand’chose.

Dire que la faille « permet d’accéder aux anciens e-mails » est une exagération très imprudente, et lourde de conséquences. Dans l’esprit de quiconque connaît un peu de crypto, c’est compris comme « la faille permet de déchiffrer a posteriori du traffic passé », ce qui ne serait possible que si la clef privée était d’une manière ou d’une autre divulguée. Cette formulation conduit ainsi les utilisateurs a craindre pour leur clef privée, de manière complètement non-justifiée.

Après, ils disent, si tu lis bien le warning, plutôt qu'ils ne connaissent pas les détails de l'attaque et qu'en attendant ils conseillent de désactiver les plugins GPG des clients mails en attendant que l'attaque soit révélée (c.a.d le lendemain).

On est le lendemain, tous les détails sont connus (au moins depuis hier puisque l’embargo n’a pas été respecté), et ils conseillent toujours d’arrêter d’utiliser PGP. Et pas « temporairement » :

PGP in its current form has served us well, but “pretty good privacy” is no longer enough. We all need to work on really good privacy, right now.

EFF’s recommendations: Disable or uninstall PGP email plugins for now. Do not decrypt encrypted PGP messages that you receive. Instead, use non-email based messaging platforms, like Signal, for your encrypted messaging needs.

 

Bref, à mon avis, toi aussi tu FUD un peu

J’aimerais bien. Mais je maintiens que de mon point de vue, la seule attaque notable est une attaque de plein fouet contre la crédibilité d’OpenPGP, visant entre autres à jeter les utilisateurs dans les bras des messageries centralisées e non-interopérables à-la-Signal. Et c’est une attaque qui fonctionne impeccablement.

Pourquoi, une protection qui est là depuis 2001 ne laisse qu’un warning et donne le message en cleartext sans option particulière.

Lorsqu’un message n’est pas protégé par un MDC, GnuPG renvoie déjà une erreur (et non un warning), lorsqu’il peut être sûr que l’absence de MDC n’est pas normale. Concrètement, si le message est chiffré avec un algorithme moderne (introduit avec le RFC4880, qui a également normalisé le MDC), alors il devrait être protégé par un MDC et on peut le rejeter s’il ne l’est pas.

Mais si le message est chiffré avec un algorithme plus ancien (typiquement 3DES), il a probablement été générée par une ancienne implémentation. Comment GnuPG pourrait-il alors savoir si l’absence de MDC est légitime (parce que l’implémentation émettrice ne connaît pas le système MDC) ou si c’est parce qu’un attaquant a fait sauter le MDC en cours de route ? Dans ce cas, GnuPG émet un warning, à charge au client mail ou à l’utilisateur d’agir.

Alors certes, quand on est un yakafocon comme Matthew Green, on peut gueuler en all caps que la solution est évidente, IL FAUT CONSIDÉRER LE MDC OBLIGATOIRE EPICÉTOU.

Mais quand on est développeur de GnuPG, on est un peu plus circonspect. Pour info, traiter l’absence de MDC comme erreur fatale dans tous les cas (pas seulement lorsqu’un algorithme moderne est utilisé) avait été considéré il y a bien longtemps par les développeurs, qui avaient finalement décidé de n’en rien faire suite aux plaintes des utilisateurs (il semblerait qu’il y ait beaucoup de monde qui déchiffrent régulièrement des vieux messages, et qui seraient incommodés par une telle mesure).

Pour ce que ça vaut, la discussion en cours actuellement chez les développeurs est de finalement mettre en œuvre cette mesure, en utilisant précisément le papier Efail pour convaincre les utilisateurs récalcitrants que c’est justifié.

Un autre point, c’est Werner Koch qui dit qu’il n’a pas été prévenu mais a eu les infos par les dev de Kmail. Alors que les chercheurs annoncent avoir contacté les développeurs de GPG en novembre.

D’après Werner (qui a posté un historique sur gnupg-users), il y a eu des échanges en novembre effectivement, qui se sont interrompus abruptement.

d’ailleurs, sympa de foutre les dev de kmail dans la merde, qui ne seront sans doute plus prévenus la prochaine fois.

Je ne vois pas ce que tu veux dire. Ce n’est pas Werner qui a mis fin à l’embargo. Le site Efail (avec le papier) était en ligne hier matin, 24h avant la fin de l’embargo annoncé par l’EFF. Ni Werner ni les autres développeurs de GnuPG nBont divulgué quoi que ce soit.

ça fait des années qu’on entend régulièrement des grands noms de la cryptographie critiquer vertement PGP sur des bases particulièrement fragiles, à grand coup de mauvaise foi

Et hop, dernier exemple, Bruce Schneier en remet une couche sur l’attaque d’aujourd’hui. Notez comme il parle d’emblée d’une « vulnérabilité PGP » et ne dit pas un mot sur S/MIME, alors qu’il est très clair à la lecture du papier que S/MIME est beaucoup plus vulnérable qu’OpenPGP.

Et on n’oublie pas de terminer par le classique « laissez tomber PGP, utilisez Signal » :

Why is anyone using encrypted e-mail anymore, anyway? […] If you need to communicate securely, use Signal.

je suis preneur d'explications qui pourraient expliquer une telle recommandation.

Moi aussi. Cette recommandation est totalement injustifiée par l’attaque rapportée.

D’où mon hypothèse personnelle, qui est que OpenPGP fonctionne trop bien aux goûts de certains et qu’il faut dissuader les gens de l’utiliser. Ce n’est pas nouveau : ça fait des années qu’on entend régulièrement des grands noms de la cryptographie critiquer vertement PGP sur des bases particulièrement fragiles, à grand coup de mauvaise foi (Matthew Green, cryptographe à l’université John Hopkins, en avait fourni un bel exemple il y a deux ou trois ans ; de même que Moxie Marlinspike, ce qui n’a sûrement rien à voir avec le fait qu’il promeut son propre système — complètement centralisé — qu’il érige en grand remplaçant de OpenPGP…). « Il est temps d’abandonner PGP » est devenu une rengaine. Qui a un intérêt à ça ?

je pense à un cas où un attaquant pourrait empêcher le propriétaire d'accéder à ses propres e-mails mais à part ça

Il n’y a rien dans le papier publié qui suggère une telle attaque.

L’attaque rapportée permet uniquement à un attaquant qui intercepte un mail en transit de modifier le mail de telle sorte que, une fois le message (modifié) reçu par son destinaire, déchiffré par son implémentation d’OpenPGP ou S/MIME (en supposant l’absence totale de contre-mesure permettant de détecter la modification, ce qui n’est pas le cas pour OpenPGP — mais apparemment c’est hélas le cas pour S/MIME), et son contenu analysé par son client de messagerie, ledit client de messagerie fasse fuiter le contenu du message à une adresse contrôlée par l’attaquant.

L’attaque est sérieuse dans le cas de S/MIME, oui, mais dans le cas d’OpenPGP ne justifie absolument pas la réaction démesurée et alarmiste de l’EFF (« désactivez OpenPGP ou vous allez tous mourir »).

Arrêtez de relayer ce FUD, bon sang…

on ne connait ni la faille, ni ses effets, pas grand-chose en fait

Si. On connaît tout, le papier est publié. Et il n’y a rien. Si la vulnérabilité de S/MIME semble avérée, celle d’OpenPGP est du pur FUD.

Plus précisément, l’attaque est réelle, mais elle est déjà complètement mitigée par le système MDC et par le fait que GnuPG renvoie délibérément une erreur lorsqu’on lui demande de déchiffrer un message non-protégé par un MDC.

Donc, si vous n’utilisez pas des versions complètement obsolètes et plus supportées des plugins OpenPGP (genre la version 2007 de GpgOL, le plugin pour Outlook), et si dans le cas spécifique de Thunderbird/Enigmail vos correspondants n’utilisent pas d’algorithmes de chiffrement pré-RFC 4880, vous êtes tranquilles. (Et si vous voulez être encore plus rassurés, désactivez simplement l’affichage automatiquement des mails au format HTML, nul besoin de désactivez complètement OpenPGP comme l’EFF le recommande complètement stupidement…)

Ah, et en aucun cas la « faille » ne permet « d’accéder aux anciens e-mails chiffrés ».

la EFF et le chercheur à l'origine du tweet conseillent de déactiver les modules d'encodage/décodage dans les clients e-mails.

Ils recommandent spécifiquement de « désactiver ou désinstaller » PGP, alors même que c’est S/MIME et non OpenPGP qui est réellement affecté par cette attaque. Tirez-en les conclusions que vous voulez. Moi je commence sérieusement à penser que quelqu’un a un agenda caché derrière cette annonce sensationnaliste.