Quand je parlais des certificats payants en terme de sécurité, je voulais surtout le dire sur la validation/certification de la personne ou entreprise cliente.
Tu prends les infos venant de letsencrypt, tu ne sais rien, il n'y a rien du tout. Tu prends un DV ou mieux un OV et on voit la différence. Se rappeler du "warranty" quand on prend un certificat payant, cela n'existe pas dans letsencrypt. Je n'ai pas encore compris pourquoi le hash n'était pas encore en argon2 sur les tous derniers mais bon, c'est perso. Quand le nist aura terminé sa partie post quantum, on aura peut-être finalement dans 15 ans, le premier certificat post quantum cryptography de déployable. En client acme, j'ai utilisé dehydrated, ça fonctionne bien surtout pour les hooks. Ensuite, au niveau DNS, on a TLSA (RFC 6698) qui permet de se passer d'une CA mais bon, pas déployé sur tous les browsers. La solution serait qu'un nixos mobile (https://mobile.nixos.org/index.html) arrive par exemple sur plus de modèles compatibles ( https://mobile.nixos.org/devices/index.html). Pour l'IOT, je sais que c'est la chose qui va faire le plus de mal mais ils ont une parade: lancer un container et l'actualiser de temps en temps voir jamais vu comment sont les constructeurs: https://youtu.be/w_6qsYWyDg0 ou mieux lors d'une question que j'avais eu dernièrement et qui commençait par "you have an IOT machine that is running a container…" On Sat, Nov 7, 2020, 03:44 Stéphane Rivière <s...@genesix.org> wrote: > > Il faut arrêter d'abuser de letsencrypt, si le site pro rapporte x > > centaines de milliers de dollars, il faut vraiment passer sur un > certificat > > avec une vraie assurance, c'est un investissement largement gagnant en > cas > > de besoin. > > Peut-être pour un gros site ecommerce. Surtout vrai si, comme là, LE a > un problème sur une plateforme et que ça va faire perdre de l'argent. De > toute façon, un cert, ça se change facilement. > > Pour le reste, le biz des certificats est un truc parfaitement malsain > et carrément moisi. Comment croire que la plupart de ces marchands de > petits fichiers ne sont pas maqués avec telle ou telle agence de sécu ? > > Comment croire que le niveau de chiffrement requis n'est pas explosé > depuis qu'il a été autorisé (i.e. on n'autorise pas le chiffrement à 128 > bits si on n'est pas capable de déchiffrer ce niveau de chiffre). > > Bref, c'est de la touille qui a encore compliqué la glute. À la toute > fin, ça ne change rien, hormis protéger les transacs face à des hackers > michus. > > > PS: look CAcert (http://www.cacert.org/) que seulement certains > > connaissent, on avait nos certificats gratuits bien avant l'existence de > > letsencrypt et en même temps, bien plus sécurisé que letsencrypt car la > > validation de la personne est obligatoire. > > CAcert, on a donné en son temps, c'était probablement le moins pire mais > incomparablement plus lourdeau que l'excellent Let's Encrypt. > > Ici on a dev un script (acmemgr.sh, on le trouve sur github) qui vient > au dessus de l'excellentissime acme.sh et c'est le bonheur tellement que > ça se fait oublier. Ca vaut le coup de regarder le readme pour voir si > ça peut aider. Pas mal de sysadmins l'utilisent. > > Il y a plein d'autres soluces tout aussi valables et velues, selon son > infra et ses goûts : l'écosystèmes LE est pléthorique. > > Mais dire que LE n'est pas sécurisé, etc, c'est du FUD. Il n'est pas > moins sécurisé que les autres. Il est probablement plus sécurisé que > certains et, en fin de compte, ça n'a pas d'importance :) > > -- > Be Seeing You > Number Six > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
