À ma connaissance également il a explicitement indiqué qu'il n'intègrerait pas systemd tant qu'il n'aura pas été prouvé que c'est un système plus fiable que l'existant ou quand il n'aura pas le choix compte tenu de l'évolution globale (lu je ne sais plus où, probablement sur LQ).
Je demandais un lien. Parce que la seule intervention de Pat que je connaisse où il mentionne systemd, c’est celle à laquelle tu fais référence, et que je me permets de citer plus largement :
Yeah, I see a few things coming down the line that may cause a shakeup to our usual way of doing things, and could force Slackware to become, well, perhaps less UNIX-like. I guess the two big ones that are on the horizon are Wayland and systemd. Whether we end up using them or not remains to be seen. It's quite possible that we won't end up having a choice in the matter depending on how development that's out of our hands goes. It's hard to say whether moving to these technologies would be a good thing for Slackware overall. Concerning systemd, I do like the idea of a faster boot time (obviously), but I also like controlling the startup of the system with shell scripts that are readable, and I'm guessing that's what most Slackware users prefer too. I don't spend all day rebooting my machine, and having looked at systemd config files it seems to me a very foreign way of controlling a system to me, and attempting to control services, sockets, devices, mounts, etc., all within one daemon flies in the face of the UNIX concept of doing one thing and doing it well. To the typical end user, if this results in a faster boot then mission accomplished. With udev being phased out in favor of systemd performing those tasks we'll have to make the decision at some point between whether we want to try to maintain udev ourselves, have systemd replace just udev's functions, or if we want the whole kit and caboodle.
Ça ne traduit certainement pas un enthousiasme débordant pour systemd comme on peut le voir par ici (où certains semblent croire que systemd va résoudre tous leurs problèmes), mais ça ne ressemble pas non plus à un refus catégorique. M’est avis qu’il attend de voir, tout simplement.
Et j’ai déjà eu l’occasion de le dire, mais ceux qui comptent sur Slackware pour les « sauver » de systemd se mettent le doigt dans l’œil à mon avis s’ils s’imaginent que Pat va se coltiner à lui tout seul la maintenance d’une alternative à systemd.
Pour Chrome je ne sais pas, mais pour Firefox, Thunderbird et les autres programmes utilisant les bibliothèques NSS, il y a p11-kit pour faire en sorte que tous ces programmes utilisent les certificats racines du système au lieu d’avoir leur propre magasin.
Le « mode dégradé » existe, c’est précisément ce qui permet d’afficher la page blanche avec le message « To view the full contents of this document, you need a later version of the PDF viewer » à la place du formulaire…
En théorie, le programme générant le fichier PDF avec un formulaire XFA pourrait utiliser ce mode dégradé pour afficher quelque chose d’utile — comme un formulaire non-interactif — au lieu d’un message publicitaire pour Adobe. Mais bizarrement, ça n’est jamais fait. Je me demande si c’est parce que Adobe Live Cycle ne le permet pas, ou si c’est parce que les administrations générant ces PDF ne prennent pas la peine de changer le comportement par défaut de Live Cycle…
A moins que j'ai loupé un épisode ou que les specs ne sont pas aussi belles qu'elles en ont l'air ?
C’est surtout qu’elles sont tellement complexes que même Adobe a renoncé à les implémenter ailleurs que sur la version « Desktop » de Acrobat Reader.
Spécifications disponibles ou pas, s’il n’y a qu’une seule implémentation disponible, sur seulement deux plateformes (ne comprenant aucune des plateformes mobiles en pleine expansion actuellement), on ne peut guère prétendre que c’est interopérable.
Les PDF interopérables, c’est le profil PDF/A, dont les formulaires XFA sont explicitement exclus.
Pour ma part, j’ai construit ma phrase de passe en essayant de faire en sorte qu’elle ait « presque du sens » pour moi, alors qu’elle en est dépourvue.
Pour illustrer, elle pourrait ressembler à quelque chose comme ça (en réalité, elle n’y ressemble pas du tout, mais j’ai essayé d’appliquer peu ou prou le même principe pour construire cet exemple) :
<?#import [gpg];open("fei+th7Xah5e") end
Je dis que ça a « presque du sens » parce que ça pourrait se comprendre, dans un pseudo-langage qui aurait l’air d’un mix entre PHP et je ne sais quel autre, comme l’inclusion d’un hypothétique module dédié à l’utilisation de GnuPG et l’ouverture d’un trousseau de clef. Ce qui tient lieu de « paramètre » à la « fonction » open est choisi aléatoirement, c’est la seule partie de la phrase de passe que je dois réellement mémoriser — j’arrive à retrouver le reste en me souvenant de l’idée initiale qui a conduit à cette phrase de passe.
aux final la phrase de passe peut se trouver plus facilement à partir de dictionnaires (au final est-ce si grave que ça, je ne sais pas trop)
La phrase de passe est ce qui protège les clefs privées au cas où le fichier qui les contient ($GNUPGHOME/secring.gpg) ne serait plus aussi privé qu’il doit l’être. Un attaquant doit d’abord se procurer ce fichier avant de pouvoir se livrer à une attaque par dictionnaire.
Sachant cela, il serait tentant de se dire qu’une phrase de passe faible n’est pas grave, « de toute façon le trousseau privé est à l’abri sur ma machine, personne ne peut venir le chercher ».
Toutefois, pénétrer ta machine,¹ exfiltrer le trousseau privé et bruteforcer la phrase de passe est presque certainement plus facile et moins coûteux que de cryptanalyser la clef proprement dite (retrouver la clef privée à partir de la clef publique).
Au final, normalement, je n'ai pas besoin de taper la phrase de passe maitresse souvent
Attention à ne pas confondre « clef maîtresse » et « phrase de passe protégeant le trousseau privé ». À ma connaissance, il n’y a qu’une seule phrase de passe pour tout le trousseau privé, je ne crois pas que GnuPG permette de choisir des phrases de passe différente pour la clef maîtresse et pour chacune des sous-clefs.
Donc, même si tu n’utilises la clef maîtresse qu’occasionnellement (en principe, seulement pour modifier ton trousseau et certifier d’autres clefs), tu auras besoin de saisir ta phrase de passe pour chaque utilisation de routine de tes sous-clefs.
Et ça tombe bien, parce que c’est justement ce qui va te permettre de mémoriser la phrase de passe rapidement et sans efforts. À l’inverse, il n’y a rien de tel pour oublier une phrase de passe que de s’en servir une fois tous les trois mois…
¹ À ce sujet, Bruce Schneier, après avoir vu une partie des documents de Snowden, a résumé les capacités de pénétration de la NSA par ces mots : « If the NSA wants in your computer, it’s in. Period. »
Ici, le « code malfaisant » est systématiquement exécuté à la définition de la fonction, même si ladite fonction n’est jamais appelée par la suite. Alors qu’avec
le code malfaisant ne sera exécuté que si le shell appelle la fonction mafonction à un moment.
J'ai aussi du mal à concevoir en quoi cette… "faille" serait plus conséquente que HeartBleed…
Je ne me prononcerai pas sur « quelle faille est la plus conséquente » ; entre une fuite d’information (dont potentiellement les clefs privées du serveur TLS) et une exécution de code arbitraire, je ne suis pas sûr qu’une comparaison soit pertinente.
… étant donné que tout code arbitraire ne peut que se dérouler avec les privilèges du compte sous lequel le processus appelant s'exécute, exact?
Exact, mais selon le compte en question, ça peut déjà permettre de faire des dégâts (par exemple, tu n’as pas forcément besoin des privilèges administrateurs pour envoyer du spam). Et ça peut toujours servir de « tête de pont » pour ensuite exploiter une éventuelle faille locale.
Ça ne choque personne qu'ils utilisent encore le Latin 1 (ISO-8859-1) qui entre autre ne contient pas le symbole €
Ils n’utilisent déjà pas le symbole È (<ville>SAINT-DENIS-LèS-BOURG</ville>) qui est pourtant encodable en Latin-1, alors pas sûr qu’ils auraient utilisé le symbole € s’ils avaient choisi un encodage qui le contient…
Ce n'est plutôt le problème d'un nom de domaine signé par deux CA, comment tu départage ?
C’est un problème, oui, mais je ne vois pas ce que ça a à voir avec l’enregistrement de certificats auto-signés et/ou publiés dans le DNS…
Et dans le cas que tu cites, Certificate Transparency ne départage pas : si deux CA reconnues soumettent un certificat pour un même nom de domaine, les deux certificats seront enregistrés et auront leur SCT. C’est au propriétaire du nom de domaine qu’il appartient de surveiller les logs publics : s’il voit passer un certificat pour son domaine, autre que celui qu’il a lui-même demandé auprès de son AC, c’est que quelqu’un joue au con.
En pratique, je suppose que la surveillance des logs sera proposée directement par les AC en tant que service supplémentaire (« on vous fournit un certificat qui sera accepté automatiquement par les navigateurs — ça c’est ce qu’on faisait déjà —, et en plus maintenant on surveillera que personne n’obtient un certificat pour votre domaine, et on vous préviendra si ça arrive »).
Certificate Transparency ne change rien au fait qu’une AC indélicate peut émettre un certificat valide et accepté pour un domaine déjà certifié par une autre AC, mais cela permet à tout le monde (et notamment le propriétaire légitime du domaine) de s’en apercevoir.
Ce qu’il advient une fois que tout le monde s’en est aperçu, en revanche, n’est plus de ressort de Certificate Transparency et est complètement non spécifié. En théorie, l’AC indélicate devrait immédiatement perdre son statut d’AC « de confiance » et être donc retirée du magasin des navigateurs, mais c’est une décision qui est à la discrétion des éditeurs de navigateurs (je soupçonne pour ma part qu’il faudra fournir aux éditeurs beaucoup d’exemples de certificats illégitimes — avec à l’appui les preuves fournies par les logs CT — avant qu’ils ne considèrent le retrait d’une AC).
Il y a une comparaison proposée par les auteurs de Certificate Transparency eux-mêmes. À prendre pour ce que ça vaut.
Personnellement, je note que contrairement à ce qu’ils prétendent, la cohabitation de DANE et de Certificate Transparency n’est pas sans problème.
Some consider DANE to be an alternative to CT, which we disagree with and document here. But DANE could also be used with CT, which seems much more reasonable.
Seuls les profils PKIX-TA et PKIX-EE de DANE (où le certificat validé par DANE doit en plus être validé par le système PKIX) sont utilisables conjointement avec Certificate Transparency. Les profils DANE-TA et DANE-EE (où DANE remplace complètement le système PKIX, et permet notamment l’utilisation de certificats auto-signés ou signés par une AC inconnue des navigateurs) ne sont pas admis.
En effet, avec CT un certificat DOIT avoir un « SCT » (sorte de jeton, émis par un « log » CT, qui prouve que le certificat a bien été ajouté au log) pour que le client l’accepte. Or un log ne doit accepter un nouveau certificat (et donc lui donner le SCT qui lui permettra de montrer patte blanche) que si celui-ci est émis par une AC de confiance. La recommandation ne dit pas comment chaque log choisit les « AC de confiance », mais en pratique (les auteurs du RFC le suggèrent), ce seraient les mêmes que celles reconnues par les navigateurs.
Exit donc les CA peu connues et les certificats auto-signés, même s’ils sont publiés dans le DNS, et un des principaux intérêts de DANE vole en éclat…
Les auteurs justifient ça par le besoin de limiter le risque de spam : « This effectively excludes self-signed and DANE-based certificates until some mechanism to control spam for those certificates is found. » Je ne suis de comprendre de quoi ils parlent (je suppose qu’ils craignent que les logs ne soient surchargés de requêtes si tous ceux qui ont un certificat auto-signé et/ou publié dans le DNS veulent l’ajouter aux logs), mais ça me paraît fallacieux.
Une façon de résoudre ça serait de considérer que Certificate Transparency fait en réalité partie du système PKIX (ce qui est à mon sens complètement vrai si les logs n’acceptent rien d’autres que des certificats venant des AC de confiance publiquement reconnues). Dans ce cas, en présence d’un enregistrement TLSA avec un profil d’utilisation réglé sur DANE-TA ou DANE-EE, le navigateur devrait être autorisé à accepter le certificat même en absence de jeton SCT (puisque ces profils servent précisément à bypasser le système PKIX).
Je note par ailleurs un tout petit peu de mauvaise foi dans l’élément « Unmodified Servers » de leur comparaison. D’après eux, un avantage de Certificate Transparency sur DANE est que le premier ne nécessite pas de modifications côté serveur. Sauf que :
– CT peut s’utiliser sans modification côté serveur, seulement dans un mode d’opération, celui où le SCT est directement intégré au certificat ; s’il ne l’est pas, le serveur doit être capable de transmettre lui-même le SCT au client. Le premier mode semble être le favori des auteurs, mais il requière la coopération des CA (qui doivent envoyer le certificat au log avant de le signer).
– Dire que DANE requière des modifications côté serveur parce qu’il faut « servir des enregistrements DNS », c’est du foutage de gueule. N’importe quel site a déjà besoin pour être joignable qu’un serveur DNS serve des enregistrements pour lui…
– Les serveurs DNS doivent supporter DNSSEC. Oui, et ça tombe bien la plupart des serveurs DNS le supportent.
– Les enregistrements TLSA doivent être modifiés chaque fois qu’un certificat est changé. Oui, et chaque nouveau certificat doit être ajouté à un log Certificate Transparency.
surtout quand on parle de CACert qui ne peut même pas faire ça, et qui ne parle pas non plus de changer le système, juste y participer.
Je croyais avoir été clair sur le fait que je ne considérais aucunement CAcert comme une solution.
Allez, je tente une dernière fois : ce ne sont pas les CA le problème, c’est le fait de faire une confiance absolue à une poignée de CA et de regarder tout le reste comme forcément suspicieux.
Oui. D'où l'intérêt d'auditer sur un point de vue opérationnel et techniques les CA pour s'assurer qu'elles ne font pas n'importe quoi
Toutes les CA qui ont fait parler d’elles ces dernières années avaient été auditées, ça ne les a pas empêché de se révéler non-fiable.
« Comment je sais si je peux avoir confiance en ce site ?
– On a des Autorités de Certification pour ça.
– Comment je sais si je peux avoir confiance en (toutes) les Autorités de Certification ?
– On a des Auditeurs pour ça.
– Comment… »
J’arrête avant d’entrer dans une boucle infinie.
Quand bien même les CA et leurs auditeurs seraient fiable (ce n’est pas le cas), ça n’apporte aucune sécurité face au risque d’une CA bidon introduite dans le magasin par un tiers tel que l’employeur. Et avant qu’on me dise que les CA ne sont pas responsables de ce genre de choses, mon point est que c’est le principe même d’avoir un magasin de CA auxquelles il est fait une confiance absolue qui rend ça possible.
Non, la démarche est globalement cohérente
Pour fournir une illusion de sécurité, peut-être, mais pas plus.
le fond du problème demeure au niveau matériel et les lois de la physique n'ont pas évoluées dans ce domaine.
Les lois de la physique n’ont peut-être pas évolué, mais le matériel et les OS, si.
Ce n’est peut-être pas généralisable à toutes les machines et tous les systèmes, mais sur tous les PC que j’ai utilisé depuis au moins les 7 ou 8 dernières années il faut un appui prolongé (environ 4 secondes) sur le bouton Power Off pour provoquer un arrêt « physique » de la machine. Une pression unique non-prolongée ne fait qu’envoyer un signal au système d’exploitation, qui déclenche alors (s’il est configuré pour ça, ce qui est le cas du mien) une procédure d’extinction logicielle « propre ».
Entre ca et "nan mais, j'te jure, c'est moi tartempion.com, bon j'ai pas mes papiers, juste ma carte de bibliotheque, mais croit moi, c'est bien moi
Alors qu’en face, on a « c’est moi tartempion.com, regarde mes papiers, bon ils sont signés par quelqu’un dont tu n’as jamais entendu parler, mais crois-moi — crois-les — c’est bien moi. »
Comme il suffit qu’une seule AC du magasin (quelle qu’elle soit) reconnaisse un certificat pour qu’il soit jugé trusted, il suffit d’une seule AC non digne de confiance pour faire s’écrouler toute la confiance qu’on peut avoir en un certificat « reconnu ».
Il faut un bel optimisme béat pour faire encore confiance à un système pareil. (Et au passage, un optimisme tout aussi béat pour croire que CAcert change quoi que ce soit au jeu.)
Attention, ton certificat il est chelou, on pourrait t'écouter. Normalement, ça ne devrait pas se produire et les sites devraient être reconnus correctement(*). Si d'habitude c'est pas comme ça, *y a probablement un truc pas net.
Non. Un truc « chelou » ou « pas net », c’est un certificat invalide — expiré, révoqué, dont le sujet ne correspond pas au nom du serveur, ou dont la signature est incorrecte. C’est un certificat au sujet duquel on peut dire « je sais qu’il n’est pas correct.¹ »
Un certificat autosigné, c’est un certificat dont on ne peut que dire « je ne sais pas », ce qui est très différent. Et mettre un tel certificat « untrusted » au même niveau qu’un certificat invalide n’est pas justifié (dans un cas on a la certitude qu’il y a un problème, dans l’autre on n’en a aucune).
Non, sérieusement, je ne vois pas ce qu'un éditeur de brouteur pourrait dire d'autre
La vérité. « Je ne peux pas confirmer que ce site est bien ce qu’il prétend. » La dernière fois que j’ai vérifié, c’était peu ou prou ce que disait Firefox. Sans chercher à faire peur à l’utilisateur avec un gros message d’erreur sur fond rouge comme le font ou l’ont fait certains navigateurs, et sans sous-entendre qu’il y a forcément quelque chose de « chelou ».
Et pour être encore plus honnête, le navigateur devrait aussi prévenir, en allant sur un site dont le certificat est signé par une autorité reconnue, que cela n’apporte pas pour autant la garantie qu’il est bien sur le bon site ou qu’il n’y a pas un homme du milieu sur le chemin…
¹ Ce qui ne veut pas forcément dire qu’il y a un acte malicieux derrière. Il peut aussi s’agir d’une erreur ou de laxisme de part de l’administrateur légitime du serveur (qui laisse passer la date d’expiration du certificat par exemple).
Après personnellement, j'ai deux certificats que je n'utilise plus (mais qui n'ont pas fuités). La logique voudrait que je les révoque, mais comme ils n'ont pas pu fuiter, je ne le fais pas.
Laisser les certificats expirer tranquillement sans rien faire ne me parait pas illogique. Je dirais même que c’est raisonnable, dès l’instant où ① tu es confiant que les clefs privées n’ont pas fuité jusqu’à présent et ② tu continues à t’assurer qu’elles ne fuitent pas jusqu’à la date d’expiration (la meilleure solution étant carrément de supprimer ces clefs que tu n’utilises plus de toute façon).
Et puis, clef privée compromise ou pas, de toute façon personne ne vérifie si un certificat est révoqué… et ceux qui tentent de le faire considèrent le certificat valide si la vérification ne peut aboutir, ce qui rend le principe même de vérification des révocations complètement inutile.
Pour moi le concept de WoT pour le SSL n'est pas très applicable.
Je dirais pour ma part qu’il n’est pas applicable à tous les cas de figure, mais qu’il l’est très bien pour certain.
Plus généralement d’ailleurs, je conteste l’idée qu’il devrait y avoir un seul mécanisme d’authentification des serveurs, que ce soit le système PKIX actuel ou une des alternatives en gestation comme DANE, Monkeysphere, Convergence… Plusieurs mécanismes, répondant éventuellement à des situations différentes, doivent pouvoir co-exister.
En gros, le principe est de faire valider les certificats par la toile de confiance OpenPGP.
Côté serveur :
L’administrateur du serveur utilise Monkeysphere pour générer, à partir de la clef privée du serveur, un certificat OpenPGP.
Il signe ce certificat avec sa propre clef, et le publie d’une façon ou d’une autre (typiquement dans les serveurs de clefs).
Côté client, lorsqu’un visiteur qui utilise aussi Monkeysphere se connecte au serveur :
Le serveur présente son certificat X.509 habituel.
Le client cherche sur les serveurs de clef un certificat OpenPGP correspondant à ce serveur, et vérifie que les clefs des deux certificats sont identiques.
Le certificat X.509 est considéré valide (et donc, le serveur est authentifié) si le certificat OpenPGP est signé par une personne en qui l’utilisateur a confiance.
Ou alors, il parle du RFC 6091, qui vise au même but mais remplace carrément les certificats X.509 par des certificats OpenPGP, éliminant ainsi la gymnastique de Monkeysphere — mais que seul GnuTLS prend en charge, à ma connaissance.
Être reconnue par défaut par les navigateurs est un plus, mais si on se limite à ce critère, on encourage un oligopole d'autorités de confiance
Mouais. Le simple fait de choisir une « autorité de confiance » (que ce soit CAcert ou une autre) revient déjà à encourager le système PKIX et le principe même des autorités de confiance, alors que c’est précisément ce principe qui est foireux.
Je trouverais plus cohérent que vous encouragiez les alternatives à PKIX. DANE par exemple, pourquoi ne pas publier d’enregistrements TLSA dans la zone linuxfr.org ? Et expliquer dans la FAQ comment configurer un navigateur pour valider un certificat contre ces enregistrements ?
J’utilise tout bêtement le bouton « Power ON/OFF » de la machine (le même qui me sert à l’allumer), avec un gestionnaire ACPI qui réagit à l‘évènement button/power et appelle init 0 en réponse.
D'ailleurs, c'est pas ce que Friendica voulait faire?
Oui, et il le fait. Un plugin (pas forcément installé ou activé sur tous les nœuds du réseau) permet l’intégration avec Facebook — ce qui est posté sur Friendica apparaît sur le « mur » Facebook, ce qui est posté par tes amis sur Facebook apparaît sur ton fil Friendica.
Deux problèmes néanmoins :
l’intégration avec Facebook est très consommatrice de ressources, surtout si tu as beaucoup de contacts sur Facebook — en fait de nombreux nœuds Friendica choisissent de ne pas activer cette intégration à cause de ça ;
le plugin est cassé tous les trois mois par les changements de l’API de Facebook, et les développeurs semblent avoir du mal à suivre. C’est à cause de ça que j’ai pour ma part renoncé à l’intégration Facebook sur mon instance.
Bonne question, mais c’est à Theodore Ts’o qu’il faudrait la poser.
De ce que je comprends du patch qui a introduit ce changement, le seuil random_write_wakeup_thres (ancien nom de random_write_wakeup_bits, la variable a été renommée peu de temps après ce patch) a en fait deux rôles distincts :
si l’entropie est inférieure à ce seuil, on réveille les processus en attente d’écriture dans /dev/random (c’est la raison d’être initiale de cette variable) ;
si l’entropie est supérieure à ce seuil, ça indique que le pool d’entrée commence à être raisonnablement rempli, suffisamment en tout cas pour qu’on puisse commencer à taper dedans pour approvisionner les pools de sortie.
Cette seconde signification, introduite par ce patch, est probablement la raison pour laquelle le seuil a été relevé de 128 à 896 bits.
[P.S. : Quelle est la logique qui fait apparaître ce strip lors de la prévisualisation ? Une discussion qui dure est forcément présumée être un débat enflammé ?]
Personne à part toi n’a dit qu’il était « à la cheville de » Microsoft (expression que je ne connais pas, mais que tu emploies avec une connotation négative assez évidente).
Il était en question d’être « en cheville avec » Microsoft, expression certes familières mais qui veut simplement dire être associé, être de connivence.
[^] # Re: un message de lennart
Posté par gouttegd . En réponse à la dépêche systemd versions 212 à 215. Évalué à 4.
Je demandais un lien. Parce que la seule intervention de Pat que je connaisse où il mentionne systemd, c’est celle à laquelle tu fais référence, et que je me permets de citer plus largement :
Ça ne traduit certainement pas un enthousiasme débordant pour systemd comme on peut le voir par ici (où certains semblent croire que systemd va résoudre tous leurs problèmes), mais ça ne ressemble pas non plus à un refus catégorique. M’est avis qu’il attend de voir, tout simplement.
Et j’ai déjà eu l’occasion de le dire, mais ceux qui comptent sur Slackware pour les « sauver » de systemd se mettent le doigt dans l’œil à mon avis s’ils s’imaginent que Pat va se coltiner à lui tout seul la maintenance d’une alternative à systemd.
[^] # Re: un message de lennart
Posté par gouttegd . En réponse à la dépêche systemd versions 212 à 215. Évalué à 4. Dernière modification le 07 octobre 2014 à 22:15.
Tu as un lien rapportant une prise de position des contributeurs de Slackware à propos de systemd ?
Aux dernières nouvelles et à ma connaissance, Patrick Volkerding n’a simplement pris encore aucune décision.
[^] # Re: CA reconnue, mais pas partout
Posté par gouttegd . En réponse au journal Scripter la génération de certificat. Évalué à 3.
Pour Chrome je ne sais pas, mais pour Firefox, Thunderbird et les autres programmes utilisant les bibliothèques NSS, il y a p11-kit pour faire en sorte que tous ces programmes utilisent les certificats racines du système au lieu d’avoir leur propre magasin.
# “I am not the one to fix any of this”
Posté par gouttegd . En réponse au journal Lennart Poettering trouve la communauté Linux désagréable. Évalué à 10.
Je suis déçu, je pensais qu’il allait nous annoncer la création de
communitydou d’un truc de ce genre.[^] # Re: Adobe Reader pour GNU/Linux
Posté par gouttegd . En réponse au journal PDF d'un site de l'administration illisible. Évalué à 10.
Le « mode dégradé » existe, c’est précisément ce qui permet d’afficher la page blanche avec le message « To view the full contents of this document, you need a later version of the PDF viewer » à la place du formulaire…
En théorie, le programme générant le fichier PDF avec un formulaire XFA pourrait utiliser ce mode dégradé pour afficher quelque chose d’utile — comme un formulaire non-interactif — au lieu d’un message publicitaire pour Adobe. Mais bizarrement, ça n’est jamais fait. Je me demande si c’est parce que Adobe Live Cycle ne le permet pas, ou si c’est parce que les administrations générant ces PDF ne prennent pas la peine de changer le comportement par défaut de Live Cycle…
[^] # Re: Adobe Reader pour GNU/Linux
Posté par gouttegd . En réponse au journal PDF d'un site de l'administration illisible. Évalué à 7.
C’est surtout qu’elles sont tellement complexes que même Adobe a renoncé à les implémenter ailleurs que sur la version « Desktop » de Acrobat Reader.
Spécifications disponibles ou pas, s’il n’y a qu’une seule implémentation disponible, sur seulement deux plateformes (ne comprenant aucune des plateformes mobiles en pleine expansion actuellement), on ne peut guère prétendre que c’est interopérable.
Les PDF interopérables, c’est le profil PDF/A, dont les formulaires XFA sont explicitement exclus.
# Une possibilité
Posté par gouttegd . En réponse au message Bien garder secret sa phrase de passe pour GnuPG. Évalué à 4.
Pour ma part, j’ai construit ma phrase de passe en essayant de faire en sorte qu’elle ait « presque du sens » pour moi, alors qu’elle en est dépourvue.
Pour illustrer, elle pourrait ressembler à quelque chose comme ça (en réalité, elle n’y ressemble pas du tout, mais j’ai essayé d’appliquer peu ou prou le même principe pour construire cet exemple) :
Je dis que ça a « presque du sens » parce que ça pourrait se comprendre, dans un pseudo-langage qui aurait l’air d’un mix entre PHP et je ne sais quel autre, comme l’inclusion d’un hypothétique module dédié à l’utilisation de GnuPG et l’ouverture d’un trousseau de clef. Ce qui tient lieu de « paramètre » à la « fonction » open est choisi aléatoirement, c’est la seule partie de la phrase de passe que je dois réellement mémoriser — j’arrive à retrouver le reste en me souvenant de l’idée initiale qui a conduit à cette phrase de passe.
La phrase de passe est ce qui protège les clefs privées au cas où le fichier qui les contient (
$GNUPGHOME/secring.gpg) ne serait plus aussi privé qu’il doit l’être. Un attaquant doit d’abord se procurer ce fichier avant de pouvoir se livrer à une attaque par dictionnaire.Sachant cela, il serait tentant de se dire qu’une phrase de passe faible n’est pas grave, « de toute façon le trousseau privé est à l’abri sur ma machine, personne ne peut venir le chercher ».
Toutefois, pénétrer ta machine,¹ exfiltrer le trousseau privé et bruteforcer la phrase de passe est presque certainement plus facile et moins coûteux que de cryptanalyser la clef proprement dite (retrouver la clef privée à partir de la clef publique).
Attention à ne pas confondre « clef maîtresse » et « phrase de passe protégeant le trousseau privé ». À ma connaissance, il n’y a qu’une seule phrase de passe pour tout le trousseau privé, je ne crois pas que GnuPG permette de choisir des phrases de passe différente pour la clef maîtresse et pour chacune des sous-clefs.
Donc, même si tu n’utilises la clef maîtresse qu’occasionnellement (en principe, seulement pour modifier ton trousseau et certifier d’autres clefs), tu auras besoin de saisir ta phrase de passe pour chaque utilisation de routine de tes sous-clefs.
Et ça tombe bien, parce que c’est justement ce qui va te permettre de mémoriser la phrase de passe rapidement et sans efforts. À l’inverse, il n’y a rien de tel pour oublier une phrase de passe que de s’en servir une fois tous les trois mois…
¹ À ce sujet, Bruce Schneier, après avoir vu une partie des documents de Snowden, a résumé les capacités de pénétration de la NSA par ces mots : « If the NSA wants in your computer, it’s in. Period. »
[^] # Re: Je pense avoir bien lu la dépèche mais...
Posté par gouttegd . En réponse à la dépêche Une faille nommée « shellshock ». Évalué à 7.
Ici, le « code malfaisant » est systématiquement exécuté à la définition de la fonction, même si ladite fonction n’est jamais appelée par la suite. Alors qu’avec
le code malfaisant ne sera exécuté que si le shell appelle la fonction
mafonctionà un moment.Je ne me prononcerai pas sur « quelle faille est la plus conséquente » ; entre une fuite d’information (dont potentiellement les clefs privées du serveur TLS) et une exécution de code arbitraire, je ne suis pas sûr qu’une comparaison soit pertinente.
Exact, mais selon le compte en question, ça peut déjà permettre de faire des dégâts (par exemple, tu n’as pas forcément besoin des privilèges administrateurs pour envoyer du spam). Et ça peut toujours servir de « tête de pont » pour ensuite exploiter une éventuelle faille locale.
[^] # Re: ISO-8859-1 ???
Posté par gouttegd . En réponse au journal Le prix des carburants enfin en OpenData. Évalué à 6.
Ils n’utilisent déjà pas le symbole È (
<ville>SAINT-DENIS-LèS-BOURG</ville>) qui est pourtant encodable en Latin-1, alors pas sûr qu’ils auraient utilisé le symbole € s’ils avaient choisi un encodage qui le contient…[^] # Re: Pourquoi je vois les captures, sous Firefox, justement ?
Posté par gouttegd . En réponse à la dépêche Firefox 32. Évalué à 2.
C’est un problème, oui, mais je ne vois pas ce que ça a à voir avec l’enregistrement de certificats auto-signés et/ou publiés dans le DNS…
Et dans le cas que tu cites, Certificate Transparency ne départage pas : si deux CA reconnues soumettent un certificat pour un même nom de domaine, les deux certificats seront enregistrés et auront leur SCT. C’est au propriétaire du nom de domaine qu’il appartient de surveiller les logs publics : s’il voit passer un certificat pour son domaine, autre que celui qu’il a lui-même demandé auprès de son AC, c’est que quelqu’un joue au con.
En pratique, je suppose que la surveillance des logs sera proposée directement par les AC en tant que service supplémentaire (« on vous fournit un certificat qui sera accepté automatiquement par les navigateurs — ça c’est ce qu’on faisait déjà —, et en plus maintenant on surveillera que personne n’obtient un certificat pour votre domaine, et on vous préviendra si ça arrive »).
Certificate Transparency ne change rien au fait qu’une AC indélicate peut émettre un certificat valide et accepté pour un domaine déjà certifié par une autre AC, mais cela permet à tout le monde (et notamment le propriétaire légitime du domaine) de s’en apercevoir.
Ce qu’il advient une fois que tout le monde s’en est aperçu, en revanche, n’est plus de ressort de Certificate Transparency et est complètement non spécifié. En théorie, l’AC indélicate devrait immédiatement perdre son statut d’AC « de confiance » et être donc retirée du magasin des navigateurs, mais c’est une décision qui est à la discrétion des éditeurs de navigateurs (je soupçonne pour ma part qu’il faudra fournir aux éditeurs beaucoup d’exemples de certificats illégitimes — avec à l’appui les preuves fournies par les logs CT — avant qu’ils ne considèrent le retrait d’une AC).
[^] # Re: Pourquoi je vois les captures, sous Firefox, justement ?
Posté par gouttegd . En réponse à la dépêche Firefox 32. Évalué à 4.
Il y a une comparaison proposée par les auteurs de Certificate Transparency eux-mêmes. À prendre pour ce que ça vaut.
Personnellement, je note que contrairement à ce qu’ils prétendent, la cohabitation de DANE et de Certificate Transparency n’est pas sans problème.
Seuls les profils PKIX-TA et PKIX-EE de DANE (où le certificat validé par DANE doit en plus être validé par le système PKIX) sont utilisables conjointement avec Certificate Transparency. Les profils DANE-TA et DANE-EE (où DANE remplace complètement le système PKIX, et permet notamment l’utilisation de certificats auto-signés ou signés par une AC inconnue des navigateurs) ne sont pas admis.
En effet, avec CT un certificat DOIT avoir un « SCT » (sorte de jeton, émis par un « log » CT, qui prouve que le certificat a bien été ajouté au log) pour que le client l’accepte. Or un log ne doit accepter un nouveau certificat (et donc lui donner le SCT qui lui permettra de montrer patte blanche) que si celui-ci est émis par une AC de confiance. La recommandation ne dit pas comment chaque log choisit les « AC de confiance », mais en pratique (les auteurs du RFC le suggèrent), ce seraient les mêmes que celles reconnues par les navigateurs.
Exit donc les CA peu connues et les certificats auto-signés, même s’ils sont publiés dans le DNS, et un des principaux intérêts de DANE vole en éclat…
Les auteurs justifient ça par le besoin de limiter le risque de spam : « This effectively excludes self-signed and DANE-based certificates until some mechanism to control spam for those certificates is found. » Je ne suis de comprendre de quoi ils parlent (je suppose qu’ils craignent que les logs ne soient surchargés de requêtes si tous ceux qui ont un certificat auto-signé et/ou publié dans le DNS veulent l’ajouter aux logs), mais ça me paraît fallacieux.
Une façon de résoudre ça serait de considérer que Certificate Transparency fait en réalité partie du système PKIX (ce qui est à mon sens complètement vrai si les logs n’acceptent rien d’autres que des certificats venant des AC de confiance publiquement reconnues). Dans ce cas, en présence d’un enregistrement TLSA avec un profil d’utilisation réglé sur DANE-TA ou DANE-EE, le navigateur devrait être autorisé à accepter le certificat même en absence de jeton SCT (puisque ces profils servent précisément à bypasser le système PKIX).
Je note par ailleurs un tout petit peu de mauvaise foi dans l’élément « Unmodified Servers » de leur comparaison. D’après eux, un avantage de Certificate Transparency sur DANE est que le premier ne nécessite pas de modifications côté serveur. Sauf que :
– CT peut s’utiliser sans modification côté serveur, seulement dans un mode d’opération, celui où le SCT est directement intégré au certificat ; s’il ne l’est pas, le serveur doit être capable de transmettre lui-même le SCT au client. Le premier mode semble être le favori des auteurs, mais il requière la coopération des CA (qui doivent envoyer le certificat au log avant de le signer).
– Dire que DANE requière des modifications côté serveur parce qu’il faut « servir des enregistrements DNS », c’est du foutage de gueule. N’importe quel site a déjà besoin pour être joignable qu’un serveur DNS serve des enregistrements pour lui…
– Les serveurs DNS doivent supporter DNSSEC. Oui, et ça tombe bien la plupart des serveurs DNS le supportent.
– Les enregistrements TLSA doivent être modifiés chaque fois qu’un certificat est changé. Oui, et chaque nouveau certificat doit être ajouté à un log Certificate Transparency.
[^] # Re: Pourquoi je vois les captures, sous Firefox, justement ?
Posté par gouttegd . En réponse à la dépêche Firefox 32. Évalué à 0.
Je croyais avoir été clair sur le fait que je ne considérais aucunement CAcert comme une solution.
Allez, je tente une dernière fois : ce ne sont pas les CA le problème, c’est le fait de faire une confiance absolue à une poignée de CA et de regarder tout le reste comme forcément suspicieux.
C’est ce que j’ai fait dès le début de mon intervention… j’ai proposé que linuxfr.org promeuve des alternatives aux CA (notamment DANE) au lieu de promouvoir une CA alternative.
Sans aucun espoir que cela fasse décoller DANE du jour au lendemain bien sûr, mais pour moi c’est un pas dans une meilleure direction que CAcert.
[^] # Re: Pourquoi je vois les captures, sous Firefox, justement ?
Posté par gouttegd . En réponse à la dépêche Firefox 32. Évalué à 0.
Toutes les CA qui ont fait parler d’elles ces dernières années avaient été auditées, ça ne les a pas empêché de se révéler non-fiable.
« Comment je sais si je peux avoir confiance en ce site ?
– On a des Autorités de Certification pour ça.
– Comment je sais si je peux avoir confiance en (toutes) les Autorités de Certification ?
– On a des Auditeurs pour ça.
– Comment… »
J’arrête avant d’entrer dans une boucle infinie.
Quand bien même les CA et leurs auditeurs seraient fiable (ce n’est pas le cas), ça n’apporte aucune sécurité face au risque d’une CA bidon introduite dans le magasin par un tiers tel que l’employeur. Et avant qu’on me dise que les CA ne sont pas responsables de ce genre de choses, mon point est que c’est le principe même d’avoir un magasin de CA auxquelles il est fait une confiance absolue qui rend ça possible.
Pour fournir une illusion de sécurité, peut-être, mais pas plus.
[^] # Re: Le bouton Power ON/OFF
Posté par gouttegd . En réponse au sondage Pour éteindre/redémarrer mon ordinateur, j'utilise.... Évalué à 6.
Les lois de la physique n’ont peut-être pas évolué, mais le matériel et les OS, si.
Ce n’est peut-être pas généralisable à toutes les machines et tous les systèmes, mais sur tous les PC que j’ai utilisé depuis au moins les 7 ou 8 dernières années il faut un appui prolongé (environ 4 secondes) sur le bouton Power Off pour provoquer un arrêt « physique » de la machine. Une pression unique non-prolongée ne fait qu’envoyer un signal au système d’exploitation, qui déclenche alors (s’il est configuré pour ça, ce qui est le cas du mien) une procédure d’extinction logicielle « propre ».
[^] # Re: Pourquoi je vois les captures, sous Firefox, justement ?
Posté par gouttegd . En réponse à la dépêche Firefox 32. Évalué à 0.
Alors qu’en face, on a « c’est moi tartempion.com, regarde mes papiers, bon ils sont signés par quelqu’un dont tu n’as jamais entendu parler, mais crois-moi — crois-les — c’est bien moi. »
Comme il suffit qu’une seule AC du magasin (quelle qu’elle soit) reconnaisse un certificat pour qu’il soit jugé trusted, il suffit d’une seule AC non digne de confiance pour faire s’écrouler toute la confiance qu’on peut avoir en un certificat « reconnu ».
Il faut un bel optimisme béat pour faire encore confiance à un système pareil. (Et au passage, un optimisme tout aussi béat pour croire que CAcert change quoi que ce soit au jeu.)
[^] # Re: Pourquoi je vois les captures, sous Firefox, justement ?
Posté par gouttegd . En réponse à la dépêche Firefox 32. Évalué à 2.
Non. Un truc « chelou » ou « pas net », c’est un certificat invalide — expiré, révoqué, dont le sujet ne correspond pas au nom du serveur, ou dont la signature est incorrecte. C’est un certificat au sujet duquel on peut dire « je sais qu’il n’est pas correct.¹ »
Un certificat autosigné, c’est un certificat dont on ne peut que dire « je ne sais pas », ce qui est très différent. Et mettre un tel certificat « untrusted » au même niveau qu’un certificat invalide n’est pas justifié (dans un cas on a la certitude qu’il y a un problème, dans l’autre on n’en a aucune).
La vérité. « Je ne peux pas confirmer que ce site est bien ce qu’il prétend. » La dernière fois que j’ai vérifié, c’était peu ou prou ce que disait Firefox. Sans chercher à faire peur à l’utilisateur avec un gros message d’erreur sur fond rouge comme le font ou l’ont fait certains navigateurs, et sans sous-entendre qu’il y a forcément quelque chose de « chelou ».
Et pour être encore plus honnête, le navigateur devrait aussi prévenir, en allant sur un site dont le certificat est signé par une autorité reconnue, que cela n’apporte pas pour autant la garantie qu’il est bien sur le bon site ou qu’il n’y a pas un homme du milieu sur le chemin…
¹ Ce qui ne veut pas forcément dire qu’il y a un acte malicieux derrière. Il peut aussi s’agir d’une erreur ou de laxisme de part de l’administrateur légitime du serveur (qui laisse passer la date d’expiration du certificat par exemple).
[^] # Re: Le bouton power de mon ordi ?
Posté par gouttegd . En réponse au sondage Pour éteindre/redémarrer mon ordinateur, j'utilise.... Évalué à 2.
Non.
[^] # Re: Pourquoi je vois les captures, sous Firefox, justement ?
Posté par gouttegd . En réponse à la dépêche Firefox 32. Évalué à 2.
Laisser les certificats expirer tranquillement sans rien faire ne me parait pas illogique. Je dirais même que c’est raisonnable, dès l’instant où ① tu es confiant que les clefs privées n’ont pas fuité jusqu’à présent et ② tu continues à t’assurer qu’elles ne fuitent pas jusqu’à la date d’expiration (la meilleure solution étant carrément de supprimer ces clefs que tu n’utilises plus de toute façon).
Et puis, clef privée compromise ou pas, de toute façon personne ne vérifie si un certificat est révoqué… et ceux qui tentent de le faire considèrent le certificat valide si la vérification ne peut aboutir, ce qui rend le principe même de vérification des révocations complètement inutile.
[^] # Re: Pourquoi je vois les captures, sous Firefox, justement ?
Posté par gouttegd . En réponse à la dépêche Firefox 32. Évalué à 3.
Je dirais pour ma part qu’il n’est pas applicable à tous les cas de figure, mais qu’il l’est très bien pour certain.
Plus généralement d’ailleurs, je conteste l’idée qu’il devrait y avoir un seul mécanisme d’authentification des serveurs, que ce soit le système PKIX actuel ou une des alternatives en gestation comme DANE, Monkeysphere, Convergence… Plusieurs mécanismes, répondant éventuellement à des situations différentes, doivent pouvoir co-exister.
[^] # Re: Pourquoi je vois les captures, sous Firefox, justement ?
Posté par gouttegd . En réponse à la dépêche Firefox 32. Évalué à 4.
Probablement Monkeysphere.
En gros, le principe est de faire valider les certificats par la toile de confiance OpenPGP.
Côté serveur :
Côté client, lorsqu’un visiteur qui utilise aussi Monkeysphere se connecte au serveur :
Ou alors, il parle du RFC 6091, qui vise au même but mais remplace carrément les certificats X.509 par des certificats OpenPGP, éliminant ainsi la gymnastique de Monkeysphere — mais que seul GnuTLS prend en charge, à ma connaissance.
[^] # Re: Pourquoi je vois les captures, sous Firefox, justement ?
Posté par gouttegd . En réponse à la dépêche Firefox 32. Évalué à 10.
Mouais. Le simple fait de choisir une « autorité de confiance » (que ce soit CAcert ou une autre) revient déjà à encourager le système PKIX et le principe même des autorités de confiance, alors que c’est précisément ce principe qui est foireux.
Je trouverais plus cohérent que vous encouragiez les alternatives à PKIX. DANE par exemple, pourquoi ne pas publier d’enregistrements TLSA dans la zone linuxfr.org ? Et expliquer dans la FAQ comment configurer un navigateur pour valider un certificat contre ces enregistrements ?
# Le bouton Power ON/OFF
Posté par gouttegd . En réponse au sondage Pour éteindre/redémarrer mon ordinateur, j'utilise.... Évalué à 10.
J’utilise tout bêtement le bouton « Power ON/OFF » de la machine (le même qui me sert à l’allumer), avec un gestionnaire ACPI qui réagit à l‘évènement
button/poweret appelleinit 0en réponse.[^] # Re: un réseau social pirate qui soit interopérable avec Facebook
Posté par gouttegd . En réponse au sondage Pour moi l'avenir des communications à distance c'est.... Évalué à 4.
Oui, et il le fait. Un plugin (pas forcément installé ou activé sur tous les nœuds du réseau) permet l’intégration avec Facebook — ce qui est posté sur Friendica apparaît sur le « mur » Facebook, ce qui est posté par tes amis sur Facebook apparaît sur ton fil Friendica.
Deux problèmes néanmoins :
l’intégration avec Facebook est très consommatrice de ressources, surtout si tu as beaucoup de contacts sur Facebook — en fait de nombreux nœuds Friendica choisissent de ne pas activer cette intégration à cause de ça ;
le plugin est cassé tous les trois mois par les changements de l’API de Facebook, et les développeurs semblent avoir du mal à suivre. C’est à cause de ça que j’ai pour ma part renoncé à l’intégration Facebook sur mon instance.
[^] # Re: pilote noyau
Posté par gouttegd . En réponse à la dépêche scdrand: alimenter le pool d’entropie du noyau à partir d’une carte à puce. Évalué à 3.
Bonne question, mais c’est à Theodore Ts’o qu’il faudrait la poser.
De ce que je comprends du patch qui a introduit ce changement, le seuil
random_write_wakeup_thres(ancien nom derandom_write_wakeup_bits, la variable a été renommée peu de temps après ce patch) a en fait deux rôles distincts :si l’entropie est inférieure à ce seuil, on réveille les processus en attente d’écriture dans
/dev/random(c’est la raison d’être initiale de cette variable) ;si l’entropie est supérieure à ce seuil, ça indique que le pool d’entrée commence à être raisonnablement rempli, suffisamment en tout cas pour qu’on puisse commencer à taper dedans pour approvisionner les pools de sortie.
Cette seconde signification, introduite par ce patch, est probablement la raison pour laquelle le seuil a été relevé de 128 à 896 bits.
[P.S. : Quelle est la logique qui fait apparaître ce strip lors de la prévisualisation ? Une discussion qui dure est forcément présumée être un débat enflammé ?]
[^] # Re: Interopérabilité
Posté par gouttegd . En réponse au journal Munich ferait marche arrière. Évalué à 10.
Personne à part toi n’a dit qu’il était « à la cheville de » Microsoft (expression que je ne connais pas, mais que tu emploies avec une connotation négative assez évidente).
Il était en question d’être « en cheville avec » Microsoft, expression certes familières mais qui veut simplement dire être associé, être de connivence.