gouttegd a écrit 1805 commentaires

C'est ensuite en lisant les commentaires que j'ai eu le plus cette impression.

Euh, il n’y a que deux fils de commentaires « polémiques ». L’un traite d’emblée les slackers de « puristes complètement déconnectés de la réalité », l’autre commence par quelqu’un qui nous explique qu’il jette Slackware à la poubelle à la vue du premier écran de l’installeur.

Respect pour les autres distributions/logiciels, tu dis ?

Tu peux pas signer un traité qui dicte qu'un état peut se barrer de l'UE et tout d'un coup quand l'un d'entre eux décide de le faire vouloir le freiner des 4 sabots pour l'en empêcher.

Ouais enfin depuis vendredi, ceux qui « freinent des 4 sabots » c’est plutôt les chefs de file du Leave, comme Boris Johnson: « In voting to leave the EU it’s vital to stress that there’s no need for haste. […] There is no need to invoke article 50. »

Je commence à voir venir le coup où aucun politicien britannique n’osera déclencher concrètement la procédure de sortie, et où ils trouveront un moyen de justifier le fait d’ignorer le résultat du référendum en mettant ça sur le dos de Bruxelles. Perfide Albion.

Comme l'a dit Zenitram, leur retour au marché unique serait incompatible avec les promesses de campagne du Brexit.

Et tu crois sérieusement que revenir sur des promesses de campagne poserait un problème aux politiciens anglais ?

Ils ont déjà commencé à le faire même pas 24 heures après l’annonce des résultats.

Je ne comprends par pourquoi ceux qui étaient en faveur du 'stay' refond une campagne pour refaire…

Sauf qu’en fait cette pétition a été lancée par un partisan du Brexit, il y a un mois, quand certains sondages donnaient plutôt le Remain vainqueur.

Et bizarrement, maintenant que le Leave l’a emporté, le créateur de la pétition semble s’en satisfaire, bien que les seuils qu’il a lui-même fixé n’ont pas été atteints (moins de 75% des électeurs ont voté et aucun camp n’a remporté 60% des suffrages)…

Bah ils l’utilisent peut-être (c’est ce que je ferais à leur place, à mon avis c’est la meilleure réaction que pourrait avoir une CA traditionnelle qui se sentirait menacée par Let’s Encrypt), mais au vu de ce qu’ils disent on n’en sait rien du tout.

Et je n’ai pas l’intention, ni de m’amuser à analyser le binaire, ni de regarder ce qu’il envoie sur le réseau (de toute façon je n’ai aucune intention d’exécuter ce binaire où que ce soit, même pas dans une VM) juste pour le savoir…

Des nouveaux venus dans le TLS ou des nouveaux venus dans le monde du TLS avec CA ? C'est une vraie question, je ne sais pas comment sont fait les métriques.

Les données viennent d’une part des logs CT (donc uniquement des certificats émis par des CA reconnues) et d’autre part de Censys qui recense tous les certificats indépendamment de l’émetteur (donc y compris les certificats auto-signés ou signés par une CA maison) — toutefois l’auteur de l’étude a choisi (pour je ne sais quelle raison) de ne garder que les certificats émis par des CA reconnues par Firefox (« When importing the Censys.io dataset, I only imported certificates which Censys had flagged with nss_valid=true »).

Donc en effet, dans les 95% de « nouveaux venus » qui n’étaient pas déjà clients d’une CA, il y a sans doute des précédents utilisateurs de certificats auto-signés (ou signés par CAcert ou une CA maison).

Mais je ne pense pas que ça change mon point, qui était que Let’s Encrypt ne cible pas forcément (en tout cas pas pour l’instant) la clientèle des CA traditionnelles.

Sans Let’s Encrypt, les utilisateurs de certificats auto-signés auraient probablement continué à utiliser des certificats auto-signés — ils s’étaient déjà détournés des CA traditionnelles, ce n’est pas Let’s Encrypt qui les en a détournés.

Ce n'est pas pour des raisons de sécurité qu'ils ont limité à 3 mois ? Juste éviter d'avoir un certificat compromis qui se trimbale trop longtemps ?

Pas seulement. C’est aussi pour réduire la charge de travail de leurs serveurs OCSP. Un certificat valable 90 jours, c’est un certificat pour lequel on n’a plus à répondre aux requêtes OCSP le concernant après 90 jours.

StartCom de son côté semble avoir fait, il y a déjà longtemps, le choix de se moquer éperdument de la qualité de leur service OCSP, donc ça ne leur pose pas de souci de proposer des certificats valides pour plusieurs années.

ça montre vraiment que let's encrypt a mis un coup de pied dans la fourmillière.

Encore trop tôt pour le dire à mon avis. StartEncrypt est une réaction épidermique de la part d’une CA, mais pour l’instant je ne vois pas trop les autres bouger.

Et elles n’auront peut-être pas besoin de bouger d’ailleurs, parce qu’il n’est pas certain que Let’s Encrypt constitue une menace pour leur marché. Les statistiques issues des premiers mois d’activité de Let’s Encrypt montrent que la grande majorité des certificats émis (près de 95%) concerne des domaines qui auparavant n’avaient aucun certificat. Donc, les « clients » de Let’s Encrypt sont majoritairement des nouveaux venus dans le monde HTTPS, et non pas des « transfuges » des autres CA.

Si Let’s Encrypt a mis un coup de pied quelque part, ce n’est pas tant dans la fourmilière des CA traditionnelles que dans le cul des administrateurs de serveurs web qui jusqu’à présent ne s’étaient pas donné la peine de mettre en place HTTPS.

On notera tout de même que là où l’automatisation permise par Let’s Encrypt repose sur un protocole complètement décrit et en cours de standardisation, et sur des clients (implémentant ce protocole) qui sont tous libres… l’automatisation promise par StartEncrypt repose sur un programme :

• disponible uniquement pour Windows et Linux 32/64-bits ;
• fourni uniquement sous la forme d’un binaire ;
• à exécuter sous l’identité du superutilisateur ;
• dont le code source ne semble disponible nulle part ;
• dont rien que le script d’installation me donne des sueurs froides, quand je vois que la première chose qu’il fait est un rm -rf $QUELQUECHOSE (à exécuter sous root, rappelez-vous).

Je ne sais pas qui ils espèrent convaincre avec ça, mais de mon point de vue ça ressemble plus à un truc goupillé à l’arrache dans une réaction désespérée face à Let’s Encrypt qu’à un projet mûrement réfléchi…

Mais là ou ça me pose question c'est par rapport à l'accessibilité du web : les sites de e-commerces prennent-ils la peine de tester leurs sites pour des utilisateurs ayant des problèmes impondérables, genre de la cécité ?

Évidemment. Tu imagines l’énorme perte généralisée sur leur chiffre d’affaires, si les 2-3 clampins aveugles ne pouvaient pas acheter ⸮

Cela n'a pas de gravité tant que la BDD ne sort pas du serveur.

C’est ce devaient se dire les admins de tous les sites listés ici…

Effectivement, tant qu’on n’est pas attaqué, peu importe la façon de stocker les mots de passe, on pourrait même les stocker en clair que ça ne poserait aucun souci… tant que la BDD ne sort pas du serveur.

qui est la garante de la fiabilité, donc la faute retombe sur eux

Sûrement pas. Les autorités de certification prennent grand soin de se dégager de toute responsabilité.

Elles fournissent le certificat, point. Elles ne sont responsables de rien de ce qui peut se passer ensuite, et aucune faute légale ne retombera sur elles.

Tiens, ça faisait longtemps que je n’avais pas chipoté.

Notez que de la même façon, la signature ne pourra être vérifiée que si la clé est encore valable. Si elle est révoquée, on peut encore vérifier la signature mais rien nous dit si le message a été modifié depuis.

Ça dépend de ce que dit le certificat de révocation.

S’il comprend une « raison de révocation » (RFC 4880, §5.2.3.23) et que celle-ci indique que la clef a simplement été remplacée ou retirée du service, les signatures antérieures à la date de révocation sont toujours valables.

Si la clef a été révoquée parce qu’elle a été compromise, ou si le certificat de révocation ne fournit pas de raison (et donc qu’on ne peut exclure que la raison soit par crainte que la clef ait été compromise), alors en effet toutes les signatures émises par cette clef sont suspectes (même celles antérieures à la date de révocation).

Cela m'étonne même de ne pas encore avoir vu GPG dans les commentaires.

On m’a appelé ?

Si le but est que la signature ait une valeur légale, je ne suis pas certain que GnuPG soit une bonne réponse malheureusement.

La dernière fois que j’ai vérifié, en France (et probablement dans le reste de l’Union Européenne, parce que la loi française en la matière est une transposition d’une directive de l’UE), une signature électronique a un « haut niveau de reconnaissance juridique » (signifiant qu’elle a la même valeur qu’une signature manuscrite) si, entre autres :

• elle est émise par un dispositif certifié conforme (comme ceux-ci) ;

• le certificat du signataire est fourni par un prestataire lui-même certifié (comme ceux-ci).

À ma connaissance, seule une version spécifique de GnuPG a jamais été formellement certifiée.

A priori, une signature générée par toute autre version, et/ou avec une clef générée par soi-même indépendamment de toute autorité de certification (comme c’est généralement le cas des certificats OpenPGP, l’un des principes d’OpenPGP étant de ne pas avoir besoin absolument d’autorités de certification), ne saurait répondre à ces critères, et serait donc regardée comme une signature à « bas niveau de reconnaissance juridique », c’est-à-dire « ne pouvant prétendre à un niveau de reconnaissance équivalent à celui de la signature manuscrite ».

(Tant il est vrai qu’une signature manuscrite est beaucoup plus sûre et difficile à forger qu’une signature RSA, c’est bien connu ⸮)

Et je dis ça pour OpenPGP, mais une signature S/MIME émise par un produit non-certifié et/ou avec un certificat délivré par un prestataire non-certifié ne vaudra pas mieux.

On dirait. La plupart des IP néerlandaises sont attribuées (d’après WHOIS) à « Quasi Networks LTD », qui serait le nouveau petit nom de Ecatel.

Par curiosité, je viens de regarder dans mes logs fail2ban d’où viennent les IP bannies. Si les IP chinoises représentent un bon 15%, les plus gros contingents et de loin sont fournis en réalité par le Sri Lanka et les Pays-Bas :

LK 33.45 %
NL 31.36 %
CN 14.63 %
TH 8.36 %
US 5.23 %
GB 2.79 %
IL 0.70 %
DE 0.70 %
CA 0.70 %
SG 0.35 %
SE 0.35 %
RU 0.35 %
MY 0.35 %
KH 0.35 %
IN 0.35 %

Ce n’est un problème que si :

• le serveur autorise l’authentification par mot de passe ;
• un des comptes est protégé par un mot de passe faible ;
• rien n’est fait pour limiter le nombre de tentatives de connexion.

Faire écouter sshd sur un autre port que le port 22 permet d’éviter de polluer les logs, mais ça n’apporte pas grand’chose en terme de sécurité.

J’ai pour ma part cessé d’utiliser un port non-standard lorsque je suis arrivé sur mon lieu de travail actuel, où le pare-feu ne laisse passer qu’une petite poignée de ports — dont le port 22, mais pas le port arbitraire que j’utilisais auparavant.

Tu dis "une pièce de théâtre, un tableau, ont à priori vocation à passer en 1.05b" mais tu ne dis pas pourquoi.

Parce que j’aime beaucoup ce morceau que tu as écrit, sauf le passage entre le 37ème et la 39ème mesure, et que j’aimerais bien voir (ou plutôt entendre) ce que donnerait ma propre idée de ce passage ?

On parle de besoin, là, non ?

J’ai autant besoin de modifier ce morceau que tu avais besoin de l’écrire en premier lieu. Mon besoin est-il moins important que le tien ?

Après, si tu ne veux pas que je touche à ton œuvre, je l’accepte, mais dans ce cas ne viens pas dire qu’elle est libre. Librement diffusable, d’accord, mais pas libre.

Parce que tu veux ré-écrire "Animal Farm" en changeant la fin

Pourquoi pas ?

et en continuant à le signer G. Orwell ?

En continuant à créditer l’auteur original et en indiquant qu’il s’agit d’une version modifiée, oui (comme l’impose, par exemple, la licence CC-BYSA). Où est le problème ?

Est-ce qu’il faut que le guitariste rende public son montage de pédales d’effet avec l’intégralité des positions des potentiomètres à chaque moment du morceau pour que ce soit libre ?

Si, dans le cadre de son « workflow » habituel, il a enregistré ces paramètres dans une piste d’automation, pourquoi ne pas la rendre disponible avec le reste ?

Et dans le cas contraire, pourquoi ne pas au moins diffuser l’enregistrement « brut », avant l’application des effets ? Encore une fois, si sa méthode habituelle de composition implique qu’il dispose de cette piste (s’il enregistre directement avec les effets au lieu de les appliquer a posteriori, je ne vais évidemment pas lui demander de refaire un enregistrement « nu » juste pour me faire plaisir).

Donc si je te suis bien, les sources d’une œuvre musicale devraient être diffusées si elles existent pour que l’œuvre soit libre, c’est bien ça ?

Ben, euh… oui ?

S’il existe des fichiers sources à partir desquels tu as obtenu ton œuvre finale, et si tu souhaites que tout le monde puisse modifier ton œuvre à sa guise (parce que tu es libriste), je ne vois pas ce qui justifierait de ne pas publier les sources…

La correction nécessite peut-être une correction (et/ou une clarification) :

Le chiffrement des mots de passe se base sur un standard reconnu : OpenPGP (en utilisant GnuPG).

La partie en italique est trompeuse. On apprend en effet plus loin dans la dépêche que les implémentations de OpenPGP utilisées sont « OpenPGP.js, ainsi que le module GPG de PHP ».

Le module PHP fait bien appel à GnuPG en arrière-plan, mais OpenPGP.js est une implémentation indépendante, aucunement basée sur GnuPG.

Sous Linux, c'est la longueur de chaque composant qui est limitée à 255, mais un chemin peut faire jusqu'à 4096 octets (d'après les quelques sources que je trouve sur le Web).

En fait c’est un peu plus compliqué que ça. POSIX définit la « valeur minimale acceptable » à 256 (_POSIX_PATH_MAX), mais explique que la limite réelle peut être supérieure et surtout qu’elle n’est pas nécessairement constante (par exemple, elle peut varier selon le système de fichiers utilisé).

Du coup, la limite réelle n’est pas à chercher dans un fichier d’en-tête, mais doit être obtenue à l’exécution avec pathconf(3).

Quel est le résultat ?

Concrètement ? Après chaque retour d’une session de microscopie, je trouvais à la racine de ma clef au moins trois ou quatre fichiers cachés exécutables (au nom généralement aléatoire), qui ne s’y trouvaient pas auparavant.

Moi je m’en fichais vu que mon propre poste était sous GNU/Linux (j’effaçais quand même les fichiers pour ne pas les propager à mon tour la prochaine fois que je branchais ma clef sur une autre machine), mais pour les autres utilisateurs (la plupart sous Windows), c’est pas terrible.

j'ai du mal à voir comment des clefs USB peuvent être un vecteur de contamination.

Je crois que c’est un vecteur beaucoup plus efficace et réaliste que le réseau.

Je veux bien reconnaître à Microsoft que l’époque où on pouvait dire « tu branches un Windows sur le réseau, 10 secondes plus tard paf t’es infecté » est probablement révolue. Mais les infections par média amovible restent bien une réalité.

Dans le même genre de Fausses Bonnes Idées™, dans mon ancien labo il avait été décidé que les ordinateurs pilotant les microscopes ne seraient pas du tout connectés au réseau (ni au réseau local de l’institut, ni — encore moins — à l’Internet). Raison invoquée : éviter les virus.

« Et donc quand je veux transférer les images que je viens de prendre depuis l’ordinateur du microscope vers mon propre poste de travail, je fais comment sans réseau ?
— Bah vous passez par une clef USB. »

Résultat des courses, des ordinateurs avec un antivirus dont la base de signatures n’est jamais mise à jour (puisque pas d’accès Internet), et des dizaines d’utilisateurs qui vont et viennent avec des clefs USB. Je vous laisse imaginer le résultat…

PS : mais le pire est sans doute que des gens pensent que c'est comme ça qu'on devrait faire…

Donald Trump a déjà proposé de s’en prendre aux familles des terroristes… avant de rétropédaler un peu sur l’air de « mais non je n’ai jamais dit explicitement qu’il fallait les tuer »…