Chiffrement : l’EFF publie la version 1.0 finale de son Certbot

Chiffrement : l’EFF publie la version 1.0 finale de son Certbot

Chiffrement : l’EFF publie la version 1.0 finale de son Certbot

En 2015, l’Electronic Frontier Foundation lançait son projet Certbot, destiné à automatiser et donc faciliter le chiffrement sur les sites web.

La version 1.0 finale est disponible depuis peu et témoigne de l’évolution du projet en quelques années. Certbot était initialement destiné à récupérer et déployer des certificats Let’s Encrypt.

Il a depuis gagné une compatibilité (en bêta) avec Windows, la prise en charge de plus d’une douzaine de fournisseurs DNS pour la validation des domaines ou encore la configuration Nginx automatique.

L’EFF rappelle que le projet s’inscrit dans le cadre plus global de sa poussée pour un chiffrement généralisé, puisqu’il « protège les gens contre l’espionnage, l’injection de contenus et le vol de cookies, qui peut être utilisé pour prendre le contrôle de votre compte ».

La fondation rappelle que depuis l’arrivée de Let’s Encrypt et de Certbot, le trafic HTTPS est passé de 40 à 80 % en quelques années seulement. Elle se félicite du chemin parcouru, mais nous rappellerons de notre côté que ces derniers 20 % sont justement les plus difficiles à conquérir.

Elle remercie les plus de 30 000 personnes ayant participé d’une manière ou d’une autre à l’amélioration de Certbot. Durant la phase bêta, l’outil aurait « aidé plus de deux millions d’utilisateurs à maintenir un accès à HTTPS sur plus de 20 millions de sites ».

Commentaires (23)


C’est clair que l’outil Certbot est super pour automatiser l’obtention et le renouvèlement de certificats, mais je pense très franchement que son succès est plutôt dû au simple fait que c’est le seul moyen d’obtenir un certificat Let’s Encrypt, qui a permis à beaucoup d’entre-nous de se passer de certificats auto-signés pour des petits projets à la limite du perso.








Plastivore a écrit :



C’est clair que l’outil Certbot est super pour automatiser l’obtention et le renouvèlement de certificats, mais je pense très franchement que son succès est plutôt dû au simple fait que c’est le seul moyen d’obtenir un certificat Let’s Encrypt, qui a permis à beaucoup d’entre-nous de se passer de certificats auto-signés pour des petits projets à la limite du perso.







 Seul moyen? Il y a plein de client qui implémentent le protocole ACME de Let’s Encrypt ( https://github.com/search?q=ACME ) ainsi que pas mal de soft qui l’implémentent en interne (traefik, Nginx, …)



Par contre certbot est probablement le client le mieux maintenu. 









Plastivore a écrit :



C’est clair que l’outil Certbot est super pour automatiser l’obtention et le renouvèlement de certificats, mais je pense très franchement que son succès est plutôt dû au simple fait que c’est le seul moyen d’obtenir un certificat Let’s Encrypt, qui a permis à beaucoup d’entre-nous de se passer de certificats auto-signés pour des petits projets à la limite du perso.







Ce n’est plus le cas… Il y a beaucoup de clients différents (de tous styles et toutes technos) aujourd’hui et y’a même un autre fournisseur de certifs gratuits ACME (Buypass.com)



Donc l’écosystème commence à se développer, c’est pas mal.



Mais je reste quand même dubitatif car l’abaissement du cout des certifs a tout de même aussi pas mal aidé le phishing car on ne peut même plus conseiller de vérifier que le “cadenas vert” est là pour être en sécurité.

C’est très ennuyeux.

Et Let’s Encrypt reste encore en heavy dev et n’est toujours pas prêt pour de la prod. Au niveau Pro, j’évite autant que possible pour l’instant…









KP2 a écrit :



Mais je reste quand même dubitatif car l’abaissement du cout des certifs a tout de même aussi pas mal aidé le phishing car on ne peut même plus conseiller de vérifier que le “cadenas vert” est là pour être en sécurité.

C’est très ennuyeux.







entièrement d’accord. Les gens pensent que le HTTPS est un site “sûr et sécurisé” ce qui est faux on peut créer un site malveillant avec un HTTPS. Le “S” c’est juste le tunnel chiffré entre le navigateur et le site, certifié par une autorité tiers.



Du coup bon… pas simple en formation/cours sur le sujet.



Top, merci!


Je l’utilise en prod depuis 3 ans sur un petit nombre de serveurs. Pas de problème à déplorer, ça simplifie la vie !


“mais nous rappellerons de notre côté que ces derniers 20 % sont justement les plus difficiles à conquérir”

En même temps, si seulement tous les hebergeurs proposaient Lets Enscrypt, ça serait plus simple. Quand on voit que 1and1/Ionos par exemple ne propose que des certificats payants, on se doute que ça ne va pas être simple de passer à 100%.








KP2 a écrit :



Ce n’est plus le cas… Il y a beaucoup de clients différents (de tous styles et toutes technos) aujourd’hui et y’a même un autre fournisseur de certifs gratuits ACME (Buypass.com)





Bonjour à tous, tu est sur pour buypass je vois que des certificats payants ?









boogieplayer a écrit :



entièrement d’accord. Les gens pensent que le HTTPS est un site “sûr et sécurisé” ce qui est faux on peut créer un site malveillant avec un HTTPS. Le “S” c’est juste le tunnel chiffré entre le navigateur et le site, certifié par une autorité tiers.



Du coup bon… pas simple en formation/cours sur le sujet.





Je suis d’accord.



L’un des problèmes est que le SSL mélange le chiffrement et l’authentification (mais comment faire autrement ?) Pour moi ça reste un problème d’UI.



Ne pas oublier aussi que si le HTTPS s’est démocratisé, c’est aussi parce que les états et les FAI s’en donnaient à cœur joie en terme de censure, espionnage, détournements, … Il fallait trouver un moyen de se prémunir contre le MiM, et le SSL restait la norme existante et implémentée.



Donc oui, d’un coté Let’sEncrypt a dévoyé le SSL . Après, avant LetsEncrypt le problème du magasin certificat des OS ou des navigateur complètement hors de contrôle et les autorité de certif voyou existaient aussi (Hong Kong Post Officehttps://www.ogcio.gov.hk/en/our_work/regulation/eto/ordinance/ca_in_hk/ en tant que CA ? Sérieux ?)

 









djegus a écrit :



Bonjour à tous, tu est sur pour buypass je vois que des certificats payants ?







Je l’ai fait pas plus tard qu’il y a 2 semaines.



Avec le client certbot, tu utilises exactement la même procédure et les mêmes commandes, il suffit juste d’ajouter : “ –server &#39https://api.buypass.com/acme/directory’ ” et ça passe.












OB a écrit :



Donc oui, d’un coté Let’sEncrypt a dévoyé le SSL . Après, avant LetsEncrypt le problème du magasin certificat des OS ou des navigateur complètement hors de contrôle et les autorité de certif voyou existaient aussi







Franchement, je pense que plus de chiffrement est toujours une bonne chose… Néanmoins, c’est la gratuité du chiffrement qui pose problème.

Et aujourd’hui, avec Let’s Encrypt, on se protège de la surveillance étatique (type NSA - et encore, ça reste à prouver) mais pas du tout du phishing… voire, on l’a facilité. Or, pour moi, d’un point de vue utilisateur lambda, on a beaucoup plus à craindre du phishing que de la surveillance étatique.









KP2 a écrit :



Or, pour moi, d’un point de vue utilisateur lambda, on a beaucoup plus à craindre du phishing que de la surveillance étatique.







Ben quand tu vois le nombre de psychopathes qui sont à la tête d’un certain nombre de pays maintenant (Trump, Erdogan, Poutine, Macron, Kim Jong-un, Bongo, Loukachenko sans parler de l’autre débile profond de Kadyrov etc….), ben je me dit que le phishing, c’est un moindre mal tout compte fait. De plus, les banques, sites marchands, messageries devraient toutes avoir des certifs TLS à validation étendue, or c’est pas le cas.









KP2 a écrit :



Franchement, je pense que plus de chiffrement est toujours une bonne chose… Néanmoins, c’est la gratuité du chiffrement qui pose problème.









A partir du moment où il y a un écosystème d’autorité de certifications, même si on “oblige” à ce que ce soit payant, rien empêche une autorité de certif en ukraine de se faire payer en BTC pour délivrer des certifs valides.



Donc on décale le problème dans les magasins de certificat des OS & navigateurs.

Il y a eu des CA qui se sont fait éjecter parce qu’elles ont vraiment abusé : startssl, symantec, …

 

A moins de vraiment bien contrôler cette liste de CAs, comment veux tu faire pour accorder ou pas ta confiance sur une CA dont t’a jamais entendu parler ?





 





KP2 a écrit :



Et aujourd’hui, avec Let’s Encrypt, on se protège de la surveillance étatique (type NSA - et encore, ça reste à prouver)



 

100% d’accord , malheureusement



 





KP2 a écrit :



mais pas du tout du phishing… voire, on l’a facilité. Or, pour moi, d’un point de vue utilisateur lambda, on a beaucoup plus à craindre du phishing que de la surveillance étatique.





Ca dépends complètement du modèle de menace que chacun considère et des sites sur lesquels tu vas , et avec quel mot de passe.



J’ai un password manager donc j’ai pas UN mot de passe identique sur le net (et même pas UNE adresse mail car j’ai des alias). Oui, je reçois, comme tout le monde je pense, des mails de rançon parceque le service Discord s’est fait piquer sa base de donnée, et je ne doute pas qu’il peux y avoir des actions de détournement plus importantes (D’où, aussi, le certificate pinning, le fait que chrome a une liste de certif en dur, etc…)



A coté de ça , on a des FAI et des états qui essaient par tous les moyens d’éviter que tu ailles sur certains site que EUX , unilatéralement, considère comme “mauvais pour toi” (enfin, surtout pour leurs potes).

C’est pas tellement la surveillance, et encore en cette période troublée où le gouvernement serait vraiment très très content de savoir que toi & quelques potes prévoient une action à la rafinerie du coin) mais plutôt la censure  voir la modification de contenu (là je pense plus aux actions de Comcast).



 

 





Ricard a écrit :



Ben quand tu vois le nombre de psychopathes qui sont à la tête d’un certain nombre de pays maintenant (Trump, Erdogan, Poutine, Macron, Kim Jong-un, Bongo, Loukachenko sans parler de l’autre débile profond de Kadyrov etc….), ben je me dit que le phishing, c’est un moindre mal tout compte fait.



 

Oh tu sais, nul besoin de psychopathes . Tout gouvernement serait ravi de “maintenir l’ordre social” à tous prix, même celui de la censure et de l’espionnage. C’est juste qu’ils ont pas tous les memes moyens… :-)



 





Ricard a écrit :





Je suis d’accord, après niveau UI des navigateurs c’est pas flagrant la différence.

Et il n’y a pas que les navigateurs : Les clients mails n’attachent souvent pas d’importance au chiffrement et aux signatures DKIM (par exemple)









OB a écrit :



Je suis d’accord, après niveau UI des navigateurs c’est pas flagrant la différence.

Et il n’y a pas que les navigateurs : Les clients mails n’attachent souvent pas d’importance au chiffrement et aux signatures DKIM (par exemple)







Malheureusement, plus personne n’utilise de clients mail… A part quelques geeks (et le monde pro, Outlook), tout le monde utilise GMail. <img data-src=" />









Ricard a écrit :



Malheureusement, plus personne n’utilise de clients mail… A part quelques geeks (et le monde pro, Outlook), tout le monde utilise GMail. <img data-src=" />





Mouais…. c’est pas faux, gmail ou webmail en général.

Du coup on en reviens à l’intérêt du système de chiffrement + CA des navigateurs.



(Ceci étant dit , plein de gens gardent leurs habitudes, et utilisent ce qu’on leur a mis à l’instant T . Les PME dont je m’occupe continuent à utiliser firefox & thunderbird & lightning :-) Après, ok, c’est pas représentatif)



&nbsp;









Ricard a écrit :



Malheureusement, plus personne n’utilise de clients mail… A part quelques geeks (et le monde pro, Outlook), tout le monde utilise GMail. <img data-src=" />









OB a écrit :



Mouais…. c’est pas faux, gmail ou webmail en général.

Du coup on en reviens à l’intérêt du système de chiffrement + CA des navigateurs.



(Ceci étant dit , plein de gens gardent leurs habitudes, et utilisent ce qu’on leur a mis à l’instant T . Les PME dont je m’occupe continuent à utiliser firefox & thunderbird & lightning :-) Après, ok, c’est pas représentatif)







DKIM est implémenté sur les MTA (serveurs SMTP), pas coté MUA (web, client lourd). Qu’on utilise le web ou le client lourd ne change rien.









ForceRouge a écrit :



DKIM est implémenté sur les MTA (serveurs SMTP), pas coté MUA (web, client lourd). Qu’on utilise le web ou le client lourd ne change rien.







La discution ne portait pas sur DKIM.<img data-src=" />









Ricard a écrit :



La discution ne portait pas sur DKIM.<img data-src=" />







Toutes mes plates excuses <img data-src=" />









ForceRouge a écrit :



DKIM est implémenté sur les MTA (serveurs SMTP), pas coté MUA (web, client lourd). Qu’on utilise le web ou le client lourd ne change rien.





Ce que je voulais dire c’est que coté MUA ya pas d’élément UI (cadenat, …) qui montre si la signature DKIM est valide et a été validée ou pas. Le MUA pourrait très bien faire cette vérif lui même, ça coûte 1 requête DNS.









OB a écrit :



Ce que je voulais dire c’est que coté MUA ya pas d’élément UI (cadenat, …) qui montre si la signature DKIM est valide et a été validée ou pas. Le MUA pourrait très bien faire cette vérif lui même, ça coûte 1 requête DNS.







Bah normalement, si un serveur reçoit un e-mail et que le DKIM ne passe pas, il est sensé rejeter l’e-mail au lieu de l’accepter (gmail style), ou l’accepter et le supprimer silencieusement. Donc finalement, aucun e-mail non conforme ne doit être vu par l’utilisateur.



Aujourd’hui, l’idéal coté e-mail, c’est:



Minimum syndical:




  • Certificats valide (type Let’s encrypt) coté serveur qui accepte une connexion (le serveur-serveur)

  • SPF pour valider qu’un serveur SMTP est bien autorisé à envoyer des e-mails pour un domaine donné

  • DKIM pour valider que le serveur SMTP est bien un serveur géré (directement ou indirectement) par le mainteneur du domaine

  • DMARC pour propager la politique SPF+DKIM et recevoir les rapports de spoof

  • DNSSEC pour certifier que les requêtes DNS qui fait marcher tout ce bordel n’est pas en train d’être spoofé



    Bonus:

  • Certificat valide (type Let’s encrypt) coté serveur qui ouvre une connexion (le serveur-client)

  • GPG pour authentifier que l’auteur n’est pas usurpé

  • GPG pour chiffré et faire en sorte que seul le destinataire peut lire l’e-mail

  • Un serveur web WKD avec certificat valide et entrée DNS signé DNSSEC pour partager sa clé GPG









ForceRouge a écrit :



Bah normalement, si un serveur reçoit un e-mail et que le DKIM ne passe pas, il est sensé rejeter l’e-mail au lieu de l’accepter (gmail style), ou l’accepter et le supprimer silencieusement. Donc finalement, aucun e-mail non conforme ne doit être vu par l’utilisateur.



&nbsp;

Alors, le rejet pourquoi pas, mais l’acceptation + jetage c’est quand même très limite, ça viole la convention du mail qui implique qu’un serveur de mail qui prends en charge un message doit soit l’acheminer, soit renvoyer une erreur à l’envoyeur.

Ya microsoft qui fait ce que tu dis depuis un certain temps maintenant.



Ya quand même énormément de mails qui soit arrivent sans en-tête dkim, soit avec une en-tête fausse&nbsp; , notamment via les maling list.

&nbsp;

Perso un mail qui ne passe pas DKIM est “simplement” marqué en spam, mais il est quand même déposé dans la boite mail du client.



Pour la partie GPG…. bof, ya trop de monde qui s’en sert pas - ça n’est pas assez bien intégré dans les MUA, encore moins dans les webmail. Dans ce cas autant passer sur un autre outil de messagerie, selon moi.









OB a écrit :



Alors, le rejet pourquoi pas, mais l’acceptation + jetage c’est quand même très limite, ça viole la convention du mail qui implique qu’un serveur de mail qui prends en charge un message doit soit l’acheminer, soit renvoyer une erreur à l’envoyeur.

Ya microsoft qui fait ce que tu dis depuis un certain temps maintenant.



Ya quand même énormément de mails qui soit arrivent sans en-tête dkim, soit avec une en-tête fausse  , notamment via les maling list.

 

Perso un mail qui ne passe pas DKIM est “simplement” marqué en spam, mais il est quand même déposé dans la boite mail du client.



Pour la partie GPG…. bof, ya trop de monde qui s’en sert pas - ça n’est pas assez bien intégré dans les MUA, encore moins dans les webmail. Dans ce cas autant passer sur un autre outil de messagerie, selon moi.







Tout à fait, un email douteux, qui est très court, est accepté, puis supprimé par outlook (hotmail) sans que l’utilisateur ne le voit.



“Donc l’écosystème commence à se développer, c’est pas mal.”



Avec un avatar de pinguin, pense à l’INpact de la chaleur du chiffrement sur les écosystèmes. <img data-src=" />


Fermer