gouttegd a écrit 1805 commentaires

Je ne parlais pas de ceux qui critiquent le format PGP inline sur des bases techniques, mais de ceux que le simple fait de voir une série de caractères inintelligibles dans un mail à leur intention insupporte (« mais bon dieu, il fait chier avec ses mails avec du chinois avant et après le contenu en français, il pourrai pas virer sa merde? » — et je n’invente rien, quelqu’un a réellement écrit ça en parlant d’une signature PGP)…

Euh, le but c’est de pourrir encore un peu plus l’image du chiffrement, que ce soit le plus rebutant possible pour les utilisateurs, c’est ça ?

Non parce que là, pour moi la seule réaction que je peux imaginer venant d’un utilisateur moyen (« utilisateur moyen » dans ce contexte = toute personne qui n’utilise pas déjà OpenPGP ou une autre technologie de chiffrement), c’est « purée qu’il me saoûle l’autre, à m’envoyer ce genre de messages ! ».

Certains se plaignent déjà juste quand on leur envoie des messages clear-signed — ceux commençant par -----BEGIN PGP SIGNED MESSAGE----- —, alors même que le message reste directement lisible. Alors les obliger à passer par un lien à usage unique et à validité limité juste pour lire un message… on voudrait braquer encore un peu plus les réfractaires au chiffrement qu’on ne s’y prendrait pas autrement.

s'il suffit d'une seule personne dans la chaine pour tout peter

C’est le cas seulement si tu le décides. C’est toi et toi seul qui décide d’accorder une confiance complète à une personne. Et c’est aussi toi qui décides du nombre de signatures nécessaires pour valider une clef.

je vois pas la difference avec un systeme de CA

Rapidement :

• Système de CA à la PKIX :

  • Chaque certificat est signé par une autorité et une seule.
  • Si Alice ne fait pas confiance à la (seule) autorité qui a signé le certificat de Bob, elle n’a aucun autre moyen de s’assurer de la validité du certificat de Bob (sauf échange direct entre elle et Bob, mais dans ce cas ils n’ont besoin ni d’un système de CA ni d’une toile de confiance — c’est justement pour s’affranchir du besoin d’un échange direct que les CA ou la toile de confiance existent).
  • La confiance est uniquement absolue (ou bien Alice fait une confiance totale à la CA, ou bien pas du tout).

• Toile de confiance à la OpenPGP :

  • Chaque certificat peut porter autant de signatures que l’on veut.
  • Chacun décide de la confiance qu’il souhaite accorder aux signatures émises par une clef donnée.
  • On peut ne faire que partiellement confiance aux signatures émises par une clef donnée.
  • Chacun peut décider de ses propres critères pour valider une clef.

Que tu ne sois pas convaincu par le modèle de la toile de confiance, soit, mais prétendre que ce n’est pas différent d’un système de CA, c’est de la mauvaise foi.

Le modèle de confiance des CA (« tout le monde fait une confiance absolue à une poignée de clefs ») n’est qu’un sous-ensemble de ce qu’il est possible de faire avec le modèle de confiance d’OpenPGP.

Découverte de GNU/Linux en 2001, à l’époque via les CD de distribution fournis dans les divers magazines spécialisés.

J’ai « testé » successivement plusieurs distributions (Debian, Red Hat, Corel, …) sans succès, leur programme d’installation se plantait lamentablement à une étape ou à une autre de l’installation. À l’époque je n’avais pas la moindre idée de ce que je pouvais faire pour passer outre, donc à chaque fois l’expérience s’arrêtait là (« tant pis, on verra avec le CD du mois suivant »).

(Rétrospectivement je suis sûr qu’une simple recherche sur Internet m’aurait permis de trouver l’astuce pour surmonter le problème — genre passer une option au noyau lors du démarrage pour désactiver tel ou tel composant qui pose problème — mais je n’avais pas de connexion Internet à l’époque.)

Finalement, Mandrake (7.1 je crois) est la première distribution qui a daigné s’installer (et fonctionner) correctement. Du coup, quelques mois plus tard j’ai acheté à la FNAC la version « boîte » de la Mandrake 8.1 (7 CD) que j’ai utilisé pendant deux ans.

Puis en 2003/2004 je suis passé sous Slackware (version 9 ou 9.1, je crois), que j’utilise encore aujourd’hui.

Mon passage définitif à GNU/Linux s’est fait à l’été 2006, lorsque j’ai supprimé la partition Windows XP que j’avais gardé jusqu’alors.

Où ai-je dis ça ? Je répondais juste à la revendication du droit à l’ignorance, qui d’après toi va jusqu’au droit de ne rien connaître de son appartement, parce qu’il y a des plombiers/électriciens/whatever dont c’est le boulot et à qui on peut se contenter de faire appel sans lever le petit doigt.

"je comprends pas qu'on puisse vivre dans une maison dont on ne sait rien sur la plomberie!!"

Je ne suis pas passionné de plomberie, mais non, en effet, je ne comprends pas. Surtout quand en cas de fuite, on attend bêtement que le plombier arrive sans rien faire, sans même couper l’arrivée d’eau principale parce qu’on ne sait même pas où elle se trouve !

Revendiquer un droit à l’ignorance, OK. Mais quand ça affecte le voisin du dessous dont le compteur électrique se retrouve inondé et mis hors d’usage, ce n’est plus de droit à l’ignorance mais de comportement irresponsable dont il est question.

(Oui, c’est du vécu.)

Désolé, mais seuls les ermites vivant loin de toute civilisation ont droit à l’ignorance totale. Vivre en société nécessite de savoir un minimum de choses, dès l’instant où tes actions (ou inactions) ont des conséquences sur tes congénères.

Bref à ces gens là je demande : montrez nous ces fameux utilisateurs dont vous parlez tant

Attention à ne pas tomber dans la généralisation inverse : l’utilisateur dépeint par Zenitram et Maclag existe aussi.

Personnellement, parmi mes collègues, j’ai aussi bien des utilisateurs « qui veulent juste cliquer et que ça marche »¹ que des utilisateurs « curieux, blâmant leur incompétence lorsqu’ils ne parviennent pas à faire quelque chose ».

---

¹ Au passage, pour ces utilisateurs-là, même les Mac et leur légendaire simplicité d’utilisation dont on nous rabat les oreilles sont des « putains de bécane de merde qui ne marchent jamais comme il le faudrait ».

Je pense que la protection de la clé privée pose plus de problèmes que la clé publique

Pas vraiment d’accord. Les implémentations actuelles d’OpenPGP se chargent déjà de ça (ce n’est fiable que si la machine terminale est sûre mais c’est de toute façon à peu près ce qu’on peut espérer de mieux — aucune solution n’est fiable sur une machine compromise).

La généralisation du chiffrement est à mon avis beaucoup plus freinée par le problème d’utilisabilité que représente la distribution et l’authentification des clefs publiques que par la nécessité de protéger ses clefs privées.

Une extension Firefox pré-installée qui permet de se connecter à son compte mail, génère un couple de clé, publie la clé publique sur un serveur de clé et peut chiffrer la clé privée avec un mot de passe.

Si tu considères la protection de la clef privée comme un problème important, en quoi ta solution fait-elle mieux que ce qui existe déjà ? Si protéger la clef privée, c’est juste la chiffrer avec un mot de passe, ça tombe bien c’est déjà ce que font toutes les implémentationsd’OpenPGP.

N'ayant pas vraiment utilisé S/MIME dans un contexte perso je me trompe peut-être ?

Non, mais ça ne résoud pas le problème. Tu as un certificat signé par StartSSL. OK, et si je veux l’utiliser pour t’envoyer un mail chiffré je le récupère comment ?

Les autorités de certification répondent au besoin d’authentification (enfin… oh et puis non, je ne vais pas redire tout le bien que je pense des CA, j’ai du boulot ce matin), mais pas à celui de la distribution.

Ce qui se fait typiquement en entreprise, à ma connaissance, est de distribuer les clefs dans un annuaire LDAP en même temps que les autres coordonnées des employés. Mais c’est indépendant de S/MIME (on pourrait très bien faire la même chose avec des clefs OpenPGP, si les entreprises utilisaient OpenPGP plutôt que S/MIME), et c’est justement parce que S/MIME ne résoud pas, en lui-même, la question de la distribution qu’il faut mettre en place ce genre d’annuaire.

les gens n'ont pas besoin d'échanger leurs clés

Si, justement.

Tu oublies d’aborder le problème de la distribution des clefs publiques. C’est pourtant une question centrale dans tous les cryptosystèmes asymétriques : comment Alice récupère-t-elle la clef de Bob et comment sait-elle que c’est la bonne ?

Pour celui qui se plaint que S/MIME est « bannis par les geeks » : S/MIME n’est pas une réponse à cette question, le problème de la distribution s’y pose de la même manière que pour OpenPGP — si le problème est moins souvent mentionné pour S/MIME, c’est juste que ce dernier est généralement utilisé en milieu plus « contrôlé » qu’OpenPGP, typiquement dans une grande entreprise où les sysadmins peuvent gérer un serveur de clefs central et configurer les postes utilisateurs pour aller chercher les clefs dessus. C’est inapplicable dans le cas général d’utilisateurs non-liés entre eux par l’appartenance à une même organisation.

(Et S/MIME a ses propres problèmes, comme par exemple le fait qu’un certificat n’est lié qu’à une clef et une seule, ce qui implique notamment qu’on ne peut utiliser que RSA si on veut un certificat avec lequel on peut signer et chiffrer — sinon il faut un certificat pour la signature et un autre, complètement indépendant, pour le chiffrement…)

Le chiffrement du canal (SMTP sur TLS sur tous les segments du trajet, y compris de serveur à serveur) n’empêche pas pour autant le chiffrement de bout en bout du message.

La combinaison des deux technos est même souhaitable : SMTP sur TLS pour protéger l’intégralité du message (y compris les en-têtes) contre tout le monde sauf les intermédiaires techniques (fournisseurs de messagerie de l’expéditeur et du destinataire), et OpenPGP ou S/MIME pour protéger le corps du message contre tout le monde, y compris les intermédiaires.

Une (très hypothétique) recrudescence de l’utilisation du chiffrement de bout en bout ne doit pas servir d’excuse aux administrateurs de serveurs mails pour ne pas déployer le chiffrement opportuniste des liaisons SMTP. Inversement, l’augmentation (bien réelle) du chiffrement des liaisons SMTP ne doit pas dissuader le chiffrement de bout en bout.

Je souhaite acquérir *.mondomaine.tld, mais au vu de ce thread, cela ne signifiera pas forcément que tous mes sous-domaines soient valides (toto.mondomaine.tld, toto2.mondomaine.tld ne pourront pas utiliser la wildcard) ??

Si.

Ce que voulait faire NicolasK, et qui n’est presque certainement pas possible (sauf si son autorité de certification lui a donné un certificat avec une extension X509v3 Basic Constraints CA:TRUE — ce qui arrive parfois involontairement), c’est pouvoir signer à volonté des certificats pour chacun de ses sous-domaines.

Mais utiliser le même certificat wildcard pour tous les domaines reste bien sûr possible.

que Gandi n'est pas une authorité de certification assez reconnue ?

Gandi, pas forcément, mais Gandi est signée par Comodo, qui l’est généralement.

que je me suis planté lors de la configuration ?

Possible. Gandi n’est apparemment pas dans la liste des CA reconnues par Thunderbird (en tout cas pas chez moi). Tu dois donc faire en sorte que ton serveur envoie le certificat de Gandi (qui techniquement est un certficat intermédiaire et non un certificat racine) en plus de ton propre certificat, afin que Thunderbird puisse remonter la chaîne de certification jusqu’à une racine qu’il connaît.

Comment faire ça dépend de ton logiciel serveur, mais souvent, il suffit de concaténer, dans un seul fichier PEM, ton propre certificat puis le (ou les) certificat(s) intermédiaire(s).

En fait, la solution idéale à ton besoin serait un certificat te permettant d’être une sous-CA techniquement contrainte : un certificat autorisé à signer (et révoquer bien sûr) d’autres certificats, mais uniquement sur ton domaine (tu pourrais signer un certificat pour sous.domaine.tld, mais pas pour www.rienàvoir.tld — ou plus exactement, tu pourrais toujours, mais le certificat résultant ne serait pas considéré valide).

Malheureusement, même si la possibilité existe (extension X509v3 Name Constraint) et est d’ailleurs mentionné dans les documents du CA/Browser Forum, je me souviens n’avoir pas réussi à trouver d’autorité de certification proposant ce genre de certificat (en même temps, ce n’est pas vraiment leur intérêt…).

J'ai un certificat wildcard pour *.domaine.tld, et j'aimerais savoir si avec la clé de celui-ci il serait possible de signer des CSR pour pour les sous-domaine de domaine.tld et d'inclure le certificat du wildcard dans la chaîne de certificats.

Examine ton certificat (openssl x509 -in ton_certificat.pem -noout -text) et regarde s’il contient une extension X509v3 Basic Constraints : si elle contient la valeur CA:FALSE (c’est quasi-certainement le cas), ce certificat ne peut pas servir à en signer d’autres.

Non, seulement arrêter de les lire avec des logiciels qui ne prennent pas en charge OpenPGP.

Le problème n’est pas l’existence ou l’absence de logiciels prenant en charge OpenPGP sur ordiphone — il y en a, au moins sur Android.

Mais pour qu’un tel logiciel soit utilisable pour lire des emails chiffrés, encore faut-il lui fournir la clef privée, ce qui personnellement me poserait deux problèmes :

• si je veux pouvoir lire mes emails tantôt sur mon PC, tantôt sur mon ordiphone, je dois avoir la clef sur les deux machines — une clef privée stockée sur deux ordinateurs connectés différents, je tique à cette idée ;
• même sans ça, je tique déjà à la seule idée de stocker ma clef privée sur un ordiphone sur lequel j’ai un contrôle bien moindre que sur mon PC.

Ce à quoi tu penses, c'est une date d'expiration impérative et non éditable : je ne crois pas que ça existe dans le format de clef publique OpenPGP.

Ça existait avec les clefs au format V3 (générées/utilisées par PGP 2.6). Le format V4, introduit avec PGP 5, a supprimé ça au profit des dates d’expiration dans les auto-signatures (donc modifiables simplement en resignant la clef).

Le groupe de travail OpenPGP à l’IETF discute actuellement (entre autres) de la possibilité de rétablir des dates d’expiration non-modifiables dans un éventuel format V5.

C'est de convaincre d'utiliser un client lourd.

J’ai une expérience différente. Après avoir montré à certains de mes collègues, soit Apple Mail, soit Thunderbird (en fonction des systèmes), aucun n’a plus jamais accepté de retourner sur un webmail…

En fait ils utilisaient un webmail non parce qu’ils préféraient ça, mais parce qu’ils ne savaient même pas qu’ils pouvaient faire autrement…

et par transitivité du "je ne signe pas une clé comme un idiot"

Non, la confiance n’est pas transitive (hors le cas des trust signature, mais elles sont très peu utilisées en pratique).

Si Alice a confiance en Bob qui a confiance en Charlie, ça n’implique pas du tout que Alice fasse confiance à Charlie.

La confiance accordée par Alice à la clef de Charlie restera indéfinie jusqu’à ce que Alice lui attribue un niveau de confiance explicite. En attendant, si Charlie signe la clef de David, cette signature n’aura aucune valeur pour Alice.

Personne ne s'accorde sur ce que signifie en pratique la "confiance" dans une clef

Ah non non non, pas du tout.

La confiance a au contraire un sens très précis, c’est juste que ce n’est que très rarement expliqué¹ et, de plus, très souvent confondu avec la validité d’une clef.

Cette confusion vient notamment du fait qu’à une époque, GnuPG parlait de trust pour désigner la validité et d’ownertrust pour désigner la confiance proprement dite, ce qui n’aidait pas vraiment.

---

¹ C’est d’ailleurs le sujet que je compte aborder dans mon prochain journal sur OpenPGP.

Aucun rapport : ici, je ne demande pas à ce qu'on m'aide

Bah quand tu dis « j'aimerai bien utiliser GPG pour signer mes mails par exemple », ça y ressemble, quand même.

Mais voila, plutôt que d'accepter les faits (la difficulté) on tape HS ("tu donnes pas envie d'aider").

Il ne t’est pas venu à l’esprit que si j’ai envie d’aider les gens, c’est précisément parce que j’ai conscience que ce n’est pas aussi facile qu’ils le voudraient ?

Là, j’ai quelqu’un qui me dit « j’aimerais bien faire ça, mais c’est trop compliqué ».

Moi : « C’est vrai que c’est pas facile, attends je t’explique… »

Lui : « Ah non mais je ne veux pas qu’on m’explique quoi que ce soit, s’il faut qu’on m’explique c’est que c’est pourri, moi je veux que ça marche épicétou ! »

J’ai déjà expliqué que c’était typiquement la situation où je refuse d’aider :

En attendant, je suis complètement disposé à aider quiconque veut se mettre à protéger ses communications. Mais ① il faut le vouloir (je ne vais pas aller chercher ceux qui disent « m’en fous, j’ai rien à cacher ») et ② il faut y mettre du sien (je ne vais pas tenir la main à ceux qui disent « ouh là, c’est trop compliqué ton truc » au bout de trois secondes d’explication).

Tutoriel

fail.

Putain tu donnes vraiment envie d’aider les gens, toi.

Installer Enigmail (installation identique à une extension Firefox)
Commencer à écrire un mail
Dans la barre de menu, cliquer sur l'onglet Enigmail > Gestion de clés.
Dans la barre de menu de la fenêtre qui vient de s'ouvrir, cliquer sur Générer > Nouvelle paire de clé

Je viens de faire un test sur un compte vierge : l’assistant de création de clefs se lance automatiquement sitôt l’extension installée :

It looks like you started Enigmail for the first time on this computer. In order to use Enigmail, you need to first set it up properly. This assistant can guide you through the setup process.

Do you want to set up Enigmail now, or do you wish to do this later?

☑ Start setup now
☐ Configure Enigmail later

Oui, c’est ça. En fait la NSA cherchait un moyen de collecter les clefs publiques en circulation, et comme ils n’ont jamais découvert l’existence des serveurs de clefs, ils ont demandé à Facebook de procéder à la collecte pour eux.

Non mais sérieusement…

CAcert ne fonctionne pas comme les autres,

Ça n’a strictement aucune importance. Le problème ne vient pas de CAcert ni d’aucune autre CA prise individuellement. CAcert pourrait bien être absolument parfait, ça ne changerait toujours rien.

Le problème, c’est le principe même de faire une confiance absolue à des CA qui peuvent signer des certificats pour n’importe qui (et encore, je ne parle pas de la possibilité de signer des sous-CA).

c'est surtout favoriser le communautaire et avoir un système plus sécurisé.

Favoriser le communautaire, OK.

Mais en quoi est-ce plus sécurisé ? Même si CAcert a procédé a une vérification rigoureuse avec multiples rencontres physiques avant de signer ton certificat, ça n’empêche pas le premier pékin venu d’obtenir un certificat frauduleux pour ton site auprès de n’importe quelle CA.

En tant qu’hôte, tu n’as pas plus de garantie avec CAcert qu’avec n’importe quelle autre CA que personne ne va jouer à l’homme du milieu entre ton site et tes visiteurs. En tant que visiteur, pareil : Mallory peut me présenter un certificat bidon que mon navigateur acceptera sans broncher.

Ce n’est que si je sais, via un autre canal, que ton certificat est supposé être signé par CAcert et personne d’autre, que je pourrais détecter un homme du milieu avec un certificat frauduleux. Et il n’y a là rien de spécifique à CAcert : par exemple, je sais maintenant que le certificat de DLFP est supposé être signé par Gandi, Mallory ne peut pas me présenter un certificat frauduleux obtenu auprès de insérez ici une CA aux pratiques douteuses sans me mettre la puce à l’oreille.

En fait, les « alternatives aux CA » dont je parle ne font justement rien d’autre que de fournir cet « autre canal » par lequel un site peut annoncer à ses visiteurs « voici mon certificat (ou le certificat de la CA qui a signé le mien) ».

Je suis désolé, mais la valeur ajoutée par CAcert et sa communauté est nulle, et ce indépendamment de tous leurs efforts. CAcert n’apporte aucune sécurité parce que le système PKIX dans son ensemble n’apporte aucune sécurité (sauf contre un attaquant passif, mais pour ça même un certificat autosigné est suffisant).

cette façon de tourner la phrase du genre on fait juste un truc à l'arrache pour se donner bonne conscience est légèrement vexante.

Tu peux le prendre comme ça. Tu peux aussi voir que je constate que tes choix ne correspondent pas à certaines de tes convictions — celle de vouloir « un système plus sécurisé » (en revanche, je n’ai rien à redire sur la conviction « je préfère un système communautaire ») — et que je ne me contente pas de te le faire remarquer mais je te propose aussi des alternatives pour corriger ça.

Je ne prétends pas que les alternatives que j’évoque se mettent en place facilement et sans efforts (j’ai mis en œuvre DNSSEC et DANE sur mon serveur, je sais que je n’ai pas fait ça en cinq minutes), mais quelqu’un qui veut un système plus sécurisé que PKIX devrait au moins les considérer.

En attendant, choisir CAcert, au moins pour le motif « parce que c’est plus sécurisé » (encore une fois, je ne critique pas le choix motivé par l’aspect communautaire), c’est à la fois une solution de facilité et une fausse solution par-dessus le marché.

Bref, on se pose sérieusement la question de garder CAcert ou pas, j'ai l'impression de trahir un (petit) peu nos convictions si on le fait

Je ne sais pas quelles sont tes convictions, mais si tu n’apprécies pas le système actuel des CA, la solution n’est pas, à mon sens, de soutenir une CA alternative mais de soutenir une alternative aux CA.

Par exemple, prendre un certificat quelconque (venant de CAcert ou de n’importe quelle autre CA, ou même autosigné) et :

• l’épingler dans les en-têtes HTTP (ça ne protège pas la première connexion, mais ça protège les suivantes : rien que ça, c’est déjà mieux que ce que le système PKIX a à offrir) ;
• le publier dans le DNS et expliquer aux utilisateurs comment utiliser DANE (ce n’est pas plus idiot que de leur expliquer qu’ils doivent ajouter le certificat racine de CAcert dans le magasin de leur navigateur) ;
• le publier dans la toile de confiance OpenPGP et expliquer aux utilisateurs comment utiliser Monkeysphere ;
• expliquer aux utilisateurs comment utiliser Convergence.

Alors, oui, ça demande un peu plus de boulot que simplement se tourner vers une CA qui a l’air un peu plus cool que les autres (mais qui malheureusement, en tant que CA, fait partie du problème, quand bien même elle serait mille fois plus digne de confiance que les autres). À voir maintenant ce que valent les « convictions »…