Benoît Sibaud a écrit 8838 commentaires

Pour Debian par exemple :

• http://www.debian.org/doc/manuals/securing-debian-howto/ch7.fr.html#s-deb-pack-sign
• http://ftp-master.debian.org/keys.html
• http://www.cryptnet.net/fdp/crypto/strong_distro.html

Actuellement, si tu te logues en HTTPS, tu restes en HTTPS. Par contre si tu te logues en HTTP, ça dépend des URL que tu tapes ou sur lesquelles tu cliques.

Les distributions utilisent des sommes de contrôle et des signatures GPG (au passage CaCert et sûrement d'autres autorités signent les clés GPG aussi), notamment parce qu'ils gèrent la diffusion via HTTP/FTP/CD/divers moyens pour lesquels les certificats x509 ne sont pas forcément la solution ou parce qu'ils gèrent des miroirs HTTP sur divers domaines hors de leur contrôle.

Corrigé, merci.

La dernière fois que j'ai essayé il n'avait pas linuxfr (mais je ne l'utilise plus depuis très longtemps).

Il y a LinuxFr.org dedans depuis octobre 2010

Sinon oui on croise peu de sites avec CaCert oui.

Une liste non exhaustive a priori de sites ayant recours à CaCert http://wiki.cacert.org/CacertSites (donc quelques sites majeurs tout de même).

Sinon quelques liens intéressants trouvés au passage :

• analyse de l'Observatoire SSL de l'EFF concernant CaCert en 2011 : annonce du blogueur, entrée de blog et prise en compte et résolution par CaCert
• tout frais côté EFF, le statut de chiffrement des gros du web : Encrypt the Web Report: Who's Doing What

Bref, comme cette position est la position officielle de linuxfr, je n'ai plus rien à faire sur ce site.

J'ai bien séparé la partie qui relève de LinuxFr.org de celle qui est mon avis personnel dans le cadre de mon activité de libriste bénévole dans le commentaire concerné.

Corrigé, merci.

Ton propos sur l'éducation est à côté de la plaque. On ne dit pas « ne tenez pas compte des avertissements », on dit « comprenez ce que ça veut dire ». Les navigateurs ont des avertissements que je trouve plutôt abusifs car ils mettent dans le même sac certificat obsolète, algorithme obsolète, autorité non reconnue et certificat auto-signé. La sécurité ce n'est pas « faites aveuglément confiance à votre navigateur il sait ce qui est le mieux pour vous ». Sinon mon processeur pourrait décider à ma place quel binaire mérite l'exécution, mon disque dur quels sont les meilleurs octets, etc. Si je veux accéder à https://le_meilleur_des_lolcats.example.com avec son certificat auto-signé donc je me contrefiche vu que je veux juste mater des photos de chatons, c'est mon choix.

Pour des gens parlant de sécurité dans une dépèche, ça fait un peu le cordonnier qui est le plus mal chaussé et faites ce que je dis, pas ce que je fais.

Et pour quelqu'un qui comme toi parle de sécurité, opter pour des clés de chiffrement générées par un tiers et transmises à tu ne sais pas qui ? Combien de gens sont capables de produire des certificats linuxfr.org "valides pour les navigateurs" grâce à des autorités n'ayant pas fait leur boulot ?

On pourrait fournir sur le site la signature GPG de nos empreintes de certificats x509 par contre. Mais faudra toujours accepter de lire et de comprendre l'avertissement du navigateur.

Et dire que tout ça serait déjà plus simple si CACert faisait l'audit… Ca montrerait que la sécurité est sérieusement prise en compte par CACert et que la barrière est financière (IE et S

Ça je suis bien d'accord.

Depuis toutes ces années, dlfp est toujours le seul site que je connais à utiliser CACert. Ne faudrait-il pas choisir ses combats ?

D'abord LinuxFr.org est géré par l'asso LinuxFr, dont le but est tout de même de parler de logiciels libres. Du coup on préfère les solutions à base de logiciels libres.

Parmi les assos du libre, d'autres ont fait le choix de ne pas se préoccuper de qui fournit leur certificat ou d'opter pour un certificat qui leur donnera la meilleure efficacité possible, notamment pour collecter des dons. Pour LinuxFr.org on a l'avantage de ne pas avoir besoin de se dire que l'on doit gagner 3 points de marché sur les CSP+ sur iMachins afin d'optimiser nos revenus publicitaires et que pour ça il faudrait opter pour une solution propriétaire ou une solution centralisée. C'est-à-dire que si on venait me donner gratuitement la solution ultime qui marche partout mais qui est propriétaire et centralisée, elle ne vaudrait pas à mes yeux une solution libre et décentralisée qui marche suffisamment bien.

Sinon oui on croise peu de sites avec CaCert oui.

Au final, les gens ont le choix entre :

• une chaîne de confiance douteuse via une autorité reconnue qui fonctionne en boite noire mais qui sera bien acceptée partout
• un certificat auto-signé douteux qui fera hurler les navigateurs
• une chaîne de confiance communautaire et à base de logiciels libres, parfois non reconnue ou reconnue douteuse suivant les navigateurs
• attendre DANE et devoir batailler avec DNSSEC …

Pour LinuxFr, je n'ai pas encore trouvé de moyen d'avoir une chaine de sécurité correcte.

Pourtant tu en as déjà eu une au moins. Cf https://linuxfr.org/users/necua6nahs/journaux/que-r%C3%A9pondre-%C3%A0-%C3%A7a#comment-1242690

LinuxFr.org n'a pas de serveur DNS en propre. On utilise ceux de TuxFamily.org (merci à eux).

Qui connaît une autre « autorité de certification basée sur une communauté (community driven non-Profit Certificate Authority), qui propose à la fois du centralisé et du décentralisé (réseau de confiance), qui publie son code sous licence libre » ?

Désolé, mais si : pas d'activité --> dégage, c'est une punition pour cause d'inactivité.

Note qu'il y a aussi le cas des décès à prendre en compte (ça arrive (trop) vite dès que tu gères un minimum d'utilisateurs…). Dans la plupart des cas, personne ne viendra jamais demander la fermeture du compte ni un changement de mot de passe ni rien sur le compte d'un(e) décédé(e). Du coup il pourrait être utilisé par quelqu'un pour usurper une identité ou juste pour récupérer un mot de passe utilisable ailleurs car le/la décédé(e) aurait comme beaucoup de monde le même mot de passe partout.

Côté usurpation, on peut aussi envisager de récupérer les vieux domaines d'adresses de courriel et de demander des renvois de mot de passe sur les vieux comptes.

Bref l'inactivité peut être utile comme indicateur de fermeture de compte (je dis bien fermeture de compte, pas purge de compte, il peut aussi être utile de les rouvrir si l'utilisateur le demandait).

Le mot de passe pourrait être écrasé lors de la fermeture, mais il ne reste que l'adresse de courriel comme élément d'identification ensuite. D'où l'entrée de suivi sur la clé GPG dans le profil qui pourrait être utile (pour ceux qui l'utilisent…).

Pour LinuxFr.org, voir Fermer son compte dans l'aide.

Je dirais qu'ici on a plus de demandes pour récupérer des comptes inactifs depuis longtemps dont les gens ont perdu mot de passe et/ou adresse de courriel que de demandes de fermeture/purge de compte. À voir si on peut améliorer les choses avec l'empreinte GPG dans le profil pour faciliter la récupération d'un compte.

Mais bref on permet la fermeture du compte par l'utilisateur, mais pas la purge de compte directement par l'utilisateur.

Est-ce qu'OVH fournit son outil de gestion sous licence libre ? De façon déployable par tout un chacun ? Sinon tant mieux pour leurs clients, mais ce n'est pas ce qui est évoqué dans la dépêche.

Justement c'est un peu le questionnement final : comment rendre cela plus facile et plus accessible pour les futurs geeks, libristes et hackers encore glabres ou qui débutent en pilosité ? Comment les libristes peuvent se faciliter la vie les uns les autres et la rendre plus facile aux utilisateurs en général ? Comment seront les « systèmes d'information » des prochaines FSF/LQDN/April/LinuxFr.org/Framasoft/EFF/LeaLinux/FDN/etc. ? Comment éviter que ça ne devienne qu'un truc de professionnels et d'experts hors de portée de bénévoles et d'amateurs motivés ?

Exemple : comment avoir des paquets nginx/apache2/postifx/etc. qui gèrent mieux cette complexité et qui proposent des configurations plus « avancées » ? Qui vérifient ou aident à configurer les entrées DNS DKIM/SPF/DNSSEC ?

Sur la page, on peut lire qu'il faut accepter les certificats.

Sinon y a https://www.eff.org/https-everywhere qui est utilisé par certains ici.

Et sinon y a juste à se loguer en HTTPS en fait. Cf http://linuxfr.org/aide#aide-cookies

Sachant que tu pêches 1000 kg de poissons, que tu en jetterais 200 kg, qu'il faut enlever arêtes et autres (*) et que 25% des aliments achetés sont jetés, combien faut-il à apprendre à pêcher à un homme pour qu'il se nourrisse toute sa vie ? Vous avez 4 heures.

(*) qui doivent pouvoir servir de farines animales pour nourrir des vaches ou des ornithorynques

ça tombe bien c'est l'entrée suivante dans l'aide. Cf http://linuxfr.org/aide#aide-autrecertificatssl

TU veux dire que si je parle ici du « inadpatés » il sera corrigé ?

Bonne nouvelle, le paragraphe PDLSA « La création d'un lien hypertexte vers le site www.wizishop.com ne peut se faire qu’avec l’autorisation de Wizishop, et sous réserve qu'aucune confusion ne puisse exister dans l'esprit des internautes sur l'identité du site ou la provenance des informations. » a disparu, même si l'info « Mentions légales créées le 6 Septembre 2010. » est toujours là (cache Google, page actuelle)

À cause de ça :

host smtp-in.orange.fr(...) refused to talk to me: 421 (...) Trop de connexions, veuillez verifier votre configuration. Too many connections, slow down. OFR004_104 [104]
host mx1.free.fr(...) refused to talk to me: 421 Server busy, too many connections from your IP

Pour Free cf http://search1-2.free.fr/index_en.html

C'est quand même moche une liste d'exclusion à maintenir à jour à chaque nouvelle version du noyau pouvant ajouter de nouvelles capabilities.

C'est un débat commencé à divers endroits. Dans le suivi par exemple. J'ai un doute sur le « plus simple » entre « ne rien faire par choix ou fainéantise/procrastination » et « anonymiser des données de manière fiable et durable malgré les évolutions à venir » par contre. Il faut aussi tenir compte des licences sur les contenus (en particulier ceux qui ne sont pas souss CC By-Sa), bien filtrer les contenus/commentaires non publics, du fait qu'il n'a pas été signalé à nos utilisateurs que les données seraient fournies à n'importe qui pour n'importe quel usage, etc. Ça mérite d'être bien réfléchi si on le fait en tout cas ; surtout qu'on a toujours plus de demandes que d'aide fournie.

Il existe une API Oauth2 pour les développeurs.