Let's Encrypt est-il en train de passer de sauveur à single point of failure (SPOF) ?

Let’s Encrypt est-il en train de passer de sauveur à single point of failure (SPOF) ?

Vers un FramaTLS ?

Avatar de l'auteur
David Legrand

Publié dans

Internet

23/04/2018 5 minutes
56

Let's Encrypt est-il en train de passer de sauveur à single point of failure (SPOF) ?

Let's Encrypt continue de gagner en puissance et serait à l'origine de la moitié des certificats gérant les connexions chiffrées des sites que nous visitons chaque jour. Une évolution bienvenue et fulgurante, qui soulève néanmoins la question de la dépendance du web à cette autorité.

Ces dernières années, l'un des combats des acteurs du Net a été la généralisation de l'accès sécurisé aux sites (HTTPS). De quoi fiabiliser les échanges en ligne, mais aussi limiter la surveillance et l'interception des requêtes. Des éléments importants, notamment pour des pratiques comme la connexion à un site, l'échange de messages, etc.

Deux des principaux points de blocage étaient le coût et la difficulté de mise en place des certificats SSL/TLS, surtout pour les petits sites, associations ou particuliers. Les navigateurs pouvaient donc difficilement prendre des sanctions contre ceux n'ayant pas encore sauté le pas.

Ces dernières années, plusieurs initiatives sont nées pour tenter de réduire cette problématique, sans trop de succès. Jusqu'à Let's Encrypt qui a rapidement changé la donne.

HTTPS pour tous... 

Fin 2014, l'Internet Security Research Group (ISRG) a été créé afin d'apporter une solution pérenne, connue sous le petit nom de Let's Encrypt. Regroupant l'EFF, Mozilla, Akamai, Cisco et bien d'autres acteurs, cette alliance voulait proposer des certificats gratuits, pour tous, simples à générer et à installer.

L'opération a demandé un peu plus d'un an avant que les premiers effets se ressentent et que les grands hébergeurs proposent une telle solution, notamment en France. Mais depuis, l'initiative est bien lancée. Gandi a proposé Let's Encrypt en janvier 2016, peu après Infomaniak. Des acteurs comme SynologyFree ou Wordpress ont suivi.

Courant 2016, le projet a gagné en maturité avec un changement de nom du client de l'EFF, le support de l'IPv6, la mise en place d'un certificat racine reconnu par Firefox, etc. Au début de l'année 2018, le protocole ACMEv2 a été publié, et les certificats wildcard (*.exemple.com) rendus disponibles, de quoi étendre encore un peu plus la portée de Let's Encrypt.

... mais de manière plus centralisée

Et au final, le but du projet a été atteint. Selon Google, la part du traffic HTTPS traité par Chrome est passé de 30/40% selon les plateformes à 70/80%. Tout ça en seulement deux ans.

Le géant du Net et les navigateurs n'y sont pas pour rien puisqu'ils n'ont pas hésité à mettre la pression aux éditeurs de sites : meilleure place dans les résultats pour ceux jouant le jeu et disposant d'un accès sécurisé, cadenas rouge et message d'alerte pour les autres.

Aujourd'hui, pas moins de 53,4 millions de certificats sont actifs, sur 25 millions de domaines. Chaque jour, environ 600 000 certificats sont créés ou renouvelés.

Selon des chiffres diffusés par NetTrack, Let's Encrypt a passé en avril la barre des 50 % des domaines gérés, parmi les presque 8 millions surveillés par le service. Comodo et Geotrust affichent un lourd recul de leur position depuis le début de l'année. C'est d'ailleurs GoDaddy qui occupe désormais la troisième place du classement.

Let's Encrypt SPOF Statistiques

Ainsi, commence à se poser la question de la dépendance de l'infrastructure du web à Let's Encrypt. Gérant une majorité des certificats utilisés, souvent de manière spécifique et automatisée, il devient un élément central d'une taille critique. Que se passera-t-il en cas de problème avec les services de Let's Encrypt ou d'attaque coordonnée ? 

Ceux qui en dépendent ne pourront pas facilement trouver une solution de remplacement, même chez les concurrents. La bonne santé de l'autorité est donc devenue vitale.

« Avant, on avait un problème avec les autorités de certification (CA). Maintenant, on a toujours le problème des CA, et en plus un problème avec un SPOF énorme... », commentait non sans ironie Aeris il y a quelques jours. Le spécialiste de tout ce qui touche aux certificats, travaillant chez Cozy Cloud et proposant le service CryptCheck, frappe ici assez juste.

Des alternatives pour limiter le SPOF

Il serait ainsi temps de se demander comment s'assurer collectivement qu'Internet ne dépende pas tant du bon fonctionnement d'un seul acteur, et quelles peuvent être les alternatives possibles ou solutions de repli en cas de problème. Une réflexion qui devrait être menée en premier lieu par l'EFF et l'ISRG.

Travail avec les autres CA pour l'adoption du protocole ACMEv2 ou émergence d'un « concurrent » à Let's Encrypt peuvent être des solutions à envisager. Il faut en tout cas commencer à étudier sérieusement ces pistes. Car si rien n'est fait, on pourrait un jour s'apercevoir un peu trop tard que l'analyse était juste, à l'occasion d'une panne majeure qui laissera des millions de sites et d'internautes dans la panade. 

Il faudra alors rendre des comptes, quand chacun s'étonnera de la situation, en premier lieu les États. La belle histoire de Let's Encrypt pourrait alors virer au cauchemar.

56

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

HTTPS pour tous... 

... mais de manière plus centralisée

Des alternatives pour limiter le SPOF

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (56)


J’utilise très peu LE pour cette raison. Car je n’ai pas trouvé, ou pas su trouvé, la taille de l’infra sa sécurité, sa redondance, sa résilience… L’analyse est très juste et ça va poser un problème lors d’une attaque coordonnées, comme contre DYN.com. Mais DYN c’est gros et il y’a de l’argent pour agir et mettre en place des contres-mesures.



Pour LE, quels sont les moyens financiers pour s’organiser ?


Je sais pas trop comment ça marche mais une fois le certificat généré il est valide pendant 3 mois et pendant ces 3 mois que let’s encrypt soit vivant ou mort ça ne change rien non ?

Ça laisse quand même 1moi et demi en moyenne pour se retourner en cas de problème à long terme avec LE non ?




Il serait ainsi temps de se demander comment s’assurer collectivement qu’Internet ne dépende pas tant du bon fonctionnement d’un seul acteur





Facile: il suffit d’avoir des alternatives gratuites financées par la collecte de données personnelles.



<img data-src=" />


Hmm.



En soit, Let’s Encrypt n’est utile qu’au moment de la création ou du renouvellement d’un certificat. Entre les deux, il n’a aucune utilité, le certificat est installé localement bien au chaud. Du coup, un down du serveur let’s encrypt serait génant mais pas critique.



&nbsp;Le protocole ACME sur lequel est basé Let’s Encrypt est public.

Le serveur Let’s Encrypt peut être réimplémenté par qui-veux-bien, tout comme le client certbot qui est open source (il y a d’ailleurs un client alternatif, Boulder).



Je pense que c’est un faux problème, en cas de soucis on verrait apparaitre très vite des alternatives. Pour l’instant, il n’y a pas vraiment ce besoin étant donné que Let’s encrypt fonctionne très bien.








Nutato a écrit :



Je sais pas trop comment ça marche mais une fois le certificat généré il est valide pendant 3 mois et pendant ces 3 mois que let’s encrypt soit vivant ou mort ça ne change rien non ?

Ça laisse quand même 1moi et demi en moyenne pour se retourner en cas de problème à long terme avec LE non ?





C’est bien ça. Et rien n’empêche de renouveler avant. Style tout les 30j



Un&nbsp; « rêve » serait DANE avec DNSSEC, mébon…



En attendant, c’est vrai que c’est un problème…


Entre le moment où l’alternative apparait et le moment où les navigateurs reconnaissent l’authenticité du certificat de ton site, tu as le temps de bouffer les pissenlits par la racine…


Ca aurait été bien que l’article nous explique plus clairement les risques si LE devient indisponible, et ce, pendant 5 minutes, 1 heures, définitivement…



Parce que oui, si LE disparait, les sites et services l’exploitant seront dans la merde… je crois qu’on avait compris ça merci.


Malgré le problème intéressant soulevé par cet article, je pense que lorsqu’on a besoin d’un certificat pour un petit site, même professionnel, LE est largement suffisant.



Quand on commence à gérer des données sensibles (identité des utilisateurs par exemple), cela commence à devenir tendancieux de se fier à un système (pour le moment) centralisé, cependant la solution reste libre, ce qu’il manque en réalité… Ce sont des alternatives amis de LE !



Sinon, en sachant le faire, à partir du moment où tu achète ton certificat (chez Gandi par exemple), il faudra quelques heures à peines pour pouvoir le mettre en place (et encore, c’est parce qu’il faut attendre Gandi). Quand vous avez accès au .crt et au .pem, c’est une question de minutes. Et ça coûtera autour de 20€.



Enfin, LE reste largement plus abordable financièrement que les solutions classiques, car si vous avez un site avec des sous domaines et que vous voulez un wildcard… Comptez autour de 100€, pour un étudiant (par exemple) ça pique. Et les certificats auto-signés, c’est moche en dehors d’un projet interne/privé.



Je continue à faire confiance à LE (que ce soit pour la pérennité ou la sécurité) mais il serait temps qu’un fork ou une solution concurrente apparaisse et gratte quelques parts de marchés.


5 minutes:le site dont le certificat expire dans cette heure ne peuvent pas le renouveler leur site est en rade.

1h : le gens dont le certificat expire dans cette heure ne peuvent pas le renouveler leur site est en rade.





en general on renouvelle le certificat un peu avant la date butoir…


Le SPOF résiderait dans la révocation du certificat racine de Let’s Encrypt dans les navigateurs, je pense (déjà arrivé à des grosses CA). Et le temps que le nouveau se propage via les mises à jour des bases de certifs, l’impact ne serait pas neutre.



A part ça, la livraison du certif est une opération que le site recommande une fois par mois, donc peu de risques de se retrouver avec un certificat expiré.



C’est le revers de la médaille d’avoir poussé le tout Saint Cadenas sans comprendre la totalité de l’enjeu. Il suffira de révoquer le certificat d’un site pour le faire disparaître, l’utilisateur ayant peu de chances de passer outre le message anxiogène des navigateurs dans ce cas.


Je vais sans doute faire faire la moue au lectorat, mais vous avez aussi des “solutions” de type cloudflare, où ils fournissent eux-mêmes et gratuitement le SSL aux sites web.

Juste puisqu’on parle de mentionner les alternatives.


On appelle ça le courtermisme, et en terme d’infrastructure, ça finit toujours par te péter à la gueule <img data-src=" />

&nbsp;







CryoGen a écrit :



Ca aurait été bien que l’article nous explique plus clairement les risques si LE devient indisponible, et ce, pendant 5 minutes, 1 heures, définitivement…



Parce que oui, si LE disparait, les sites et services l’exploitant seront dans la merde… je crois qu’on avait compris ça merci.





Bah le souci c’est que plus de 50% des sites avec un accès sécurisés se reposent là dessus. Donc effectivement, si ça pète, ça posera des soucis. Je ne vois pas ce que tu veux expliquer de plus dans le détail. Après, une indispo d’une heure, ce n’est pas vraiment le cas typique contre lequel il faut se protéger.



Bon après il n’y a pas que les questions d’indispo parce que pas de chance, hein. Mais un SPOF c’est aussi un élément à attaquer, dans lequel chercher des failles, etc. Actuellement, on a pas d’alternative apte à remplacer LE en cas de souci, sauf à repasser tous vers des CA payantes avec une installation “classique”.&nbsp;



Cloudflare, niveau SPOF, ça se pose là aussi <img data-src=" />


Malheureusement non: pour gérer la révocation ils doivent signer toutes les 23 semaines une preuve de validité du certificat (OCSP), et si le serveur n’utilise pas OCSP stapling, LE doit pouvoir fournir cette preuve sur demande pour tous les visiteurs.



(l’OCSP stapling permet donc d’être en sécurité 12 semaines en cas de coupure de Let’s Encrypt)








David_L a écrit :



Cloudflare, niveau SPOF, ça se pose là aussi <img data-src=" />







Et vous savez de quoi vous parlez <img data-src=" />



Plus sérieusement, Cloudflare ou LE ou d’autres services “haut niveau” de ce genre ne sont pas tellement des SPOF. Enfin, si ça tombe, ça crée une indisponibilité d’une partie du net mais cette “partie” ne disparait pas pour autant. Elle est juste inaccessible. Et même si ça réclame un peu de boulot manuel pour les shunter, c’est possible et même pas excessivement difficile ni long de le faire. Et il n’y aurait même pas de perte de données…



A ma connaissance, y’a pas de centrale nucléaire qui dépend de ces services donc on devrait survivre…



Rendre une partie du web indisponible, c’est chiant, c’est pas marrant, c’est même humiliant parfois mais y’a pas mort d’homme… Et quand bien même des boites/startups aux pieds d’argiles couleraient à cause de ça, c’est pas une catastrophe ni nationale ni internationale.



Et ce sont pas les alternatives à CF ou LE qui manquent si ils devaient disparaitre du jour au lendemain. Il faudrait pas longtemps pour remettre les choses en route.

Le net n’est peut-être pas aussi décentralisé qu’on pourrait rêver qu’il le soit mais il reste solide. Et si le web (qui n’est qu’un sous-ensemble du net) se rend un peu trop dépendant de grosses boites pour des raisons pratiques et économiques, ça ne remet pas en cause les bases fondamentales de l’ensemble…



+1 je ne comprends pas vraiment en quoi ça constitue un SPOF…

Par contre une position dominante oui ça va pas tarder <img data-src=" />


Pour CF on étudie des alternatives justement, après c’est la même chose que pour LE : trouver des solutions tierces et raisonnables ce n’est pas simple…&nbsp;








David_L a écrit :



Pour CF on étudie des alternatives justement, après c’est la même chose que pour LE : trouver des solutions tierces et raisonnables ce n’est pas simple…







Ben moi, je pense que ça vaut pas le coup de se casser le cul.

Ces trucs marchent bien globalement et ne coutent pas excessivement cher. Faut réfléchir à ce que vous pourriez faire en cas de panne qui dépasserait les 4h-8h mais, franchement, je pense pas que ça vaille le coup d’aller au delà…



Si j’ai bien compris, Let’s encrypt compte sur IdenTrust comme autorité de certification en fallback dans un avenir plus ou moins proche.








Obidoub a écrit :



+1 je ne comprends pas vraiment en quoi ça constitue un SPOF…

Par contre une position dominante oui ça va pas tarder <img data-src=" />







Le prob c’est que le certif n’est valable que 3 mois et c’est -par exemple- cerbot qui le renouvelle automatiquement. Des milliers de demande de renouvellement se font toutes les heures en automatique, si le service est down bah les sites vont tomber petit à petit au fur et à mesure du temps. Si tu es en HSTS tu ne pourras même pas passer en HTTP en attendant.



Ensuite en cas de problème sur le certif racine, il faudra attendre la mise à jour des navigateurs.



C’est déjà pas mal.









David_L a écrit :



Pour CF on étudie des alternatives justement, après c’est la même chose que pour LE : trouver des solutions tierces et raisonnables ce n’est pas simple…







Yep. Je ne suis même pas sûr qu’une alternative à CF dans les même prix avec les même services existe tout simplement. Après ça dépend de ce que tu veux faire, mais CF est devenu hégémonique parce qu’il propose des services gratuits très utiles et très fiables, trouver l’équivalent est aujourd’hui une gageure.



Autant sur des sujets de sécurité qui touchent directement le grand public, je suis d’accord, le courtermisme n’a pas sa place. Mais là on parle d’une solution utilisée par des gens avertis, normalement prompts à réagir en cas de soucis.



Y a qu’à voir la faille Heartbleed: la majorité des serveurs ont été patchés en quelques jours.

Je n’ai aucun doute que si problème il y a avec Let’s encrypt un jour (que ce soit sur le serveur ou le client), la solution sera en place dans les jours qui suivent, et que tout continuera à tourner sans problème entretemps (sauf si un mec a attendu le dernier jour pour faire son renouvellement, mais bon ça c’est juste de la bêtise).



Sinon on peut considérer que l’hégémonie d’OpenSSL ou de NPM sont problématiques également (le hors-sujet est volontaire ;)


50 % ?Oo&nbsp;

Je ne m’y attendais vraiment pas…


Tout à fait d’accord. Je n’arrive pas à comprendre que cette techno soit inexistante aujourd’hui. Aucun navigateur ne la gère et il n’est pas question que cela soit le cas dans un avenir proche (on aura peut être même IPv6 avant, qui sait ?).


En fait il n’y a pas que les problèmes d’end of validity. Si les CRL sont inaccessibles, certificats toujours valides ou non, tu l’as dans le baba.


Effectivement, je n’ai pas pensé à la révocation, bien vu. Mais pour le coup, toutes les autorités de certification ont ce soucis.


Euh, scusez, mais, on est d’accord que si LE tombe (de manière totale et définitive, car une pannes de quelques heures/jours ça n’aura aucun impact), au pire les sites qui ont besoin d’un certificat reconnu ils en achètent un, et les autres ils font de l’auto-signé non ?




Oui les navigateurs vont raler pour les auto-signé, mais bon, je vois pas bien le problème... Dans les cas où l'identité du serveur en face est important ils auront acheté du DigiCert, et dans le cas où le certif sert juste à faire fonctionner le SSL, bah on s'en fout de l'identité.      






Si quelqu'un voit le moindre problème là dedans je suis preneur, car je vois pas vraiment le soucis si LE disparait. C'est chiant pur ceux qui l'utilise mais bon, de là à faire un article pour ça ?!      

&nbsp;









aldwyr a écrit :



50 % ?Oo&nbsp;



 Je ne m'y attendais vraiment pas...








 Google a imposé le SSL par son inclusion dans ses paramètres de ranking. LE est le seul gratos. Combo gagnant !








Vinayancho a écrit :



vous pouvez trouver des vraies filles cornées de différents pays.







Ça s’appelle des chèvres, ma chère…









Vinayancho a écrit :



….http://ma.pub ….





&nbsp;Et même pas capable de mettre un lien https avec un certificat LE pour essayer d’être dans le thème <img data-src=" />



S’il y a un problème, et que les sponsors https://letsencrypt.org/sponsors/&nbsp;) ne suffisent pas, Google viendra certainement aider à faire repartir la machine en devenant sponsor. Pas d’inquiétude donc, mais ça serait plus rassurant que ce service dépende de Google pour assurer une fiabilité parfaite vu leurs moyens.








Bejarid a écrit :



Euh, scusez, mais, on est d’accord que si LE tombe (de manière totale et définitive, car une pannes de quelques heures/jours ça n’aura aucun impact), au pire les sites qui ont besoin d’un certificat reconnu ils en achètent un, et les autres ils font de l’auto-signé non ?




Oui les navigateurs vont raler pour les auto-signé, mais bon, je vois pas bien le problème... Dans les cas où l'identité du serveur en face est important ils auront acheté du DigiCert, et dans le cas où le certif sert juste à faire fonctionner le SSL, bah on s'en fout de l'identité.      






Si quelqu'un voit le moindre problème là dedans je suis preneur, car je vois pas vraiment le soucis si LE disparait. C'est chiant pur ceux qui l'utilise mais bon, de là à faire un article pour ça ?!      

&nbsp;






 Google a imposé le SSL par son inclusion dans ses paramètres de ranking. LE est le seul gratos. Combo gagnant !







Passer en https avec un certif auto-signé ne corrige rien, il suffit à un attaquant de générer le même de son côté pour se faire passer pour la cible (pas d’AC racine =&gt; pas de preuve que le certif est légitime) donc, usurpation (phishing) et MItM possible









versgui a écrit :



Effectivement, je n’ai pas pensé à la révocation, bien vu. Mais pour le coup, toutes les autorités de certification ont ce soucis.







Comme dit plus haut, revoque le certificat racine et tu revoques TOUS les certificats en dessous. Et générer une racine est loin d’être trivial.

Sinon, même sans qu’un attaquant révoque lui-même le certificat, s’il arrive à se générer des certifs arbitraires, ça peut mener à un changement de clé racine, suivant la procédure en place ( en plus des gros risques de phishing, entre autres)



Le certificats servent aussi pour faire du machine to machine. SI par exemple tu as une appli embarquée sur un appareil que tu ne peux pas mettre à jour à distance pour X raisons, et que cet appareil vérifie explicitement ton certificat (par exemple en comparant la racine avec ce qu’il connaît), tu risques d’avoir d’un coup tout ton parc de machines qui ne fonctionne plus.








Zrechim a écrit :



Passer en https avec un certif auto-signé ne corrige rien, il suffit à un attaquant de générer le même de son côté pour se faire passer pour la cible (pas d’AC racine =&gt; pas de preuve que le certif est légitime) donc, usurpation (phishing) et MItM possible




Comme dit plus haut, revoque le certificat racine et tu revoques TOUS les certificats en dessous. Et générer une racine est loin d'être trivial.      

Sinon, même sans qu'un attaquant révoque lui-même le certificat, s'il arrive à se générer des certifs arbitraires, ça peut mener à un changement de clé racine, suivant la procédure en place ( en plus des gros risques de phishing, entre autres)








Hmmm ... non, créer son propre Root CA n'a rien de très compliqué, c'est même relativement facile (par exemple : https://www.semurity.com/blog-post/setup-certificate-authority-ca-using-openssl/...  





Ce qui est compliqué c’est de créer son propre Root CA de manière sécurisée et auditable (cf&nbsp; http://cubicspot.blogspot.fr/2016/12/setting-up-your-own-root-certificate.html par exemple), de l’automatiser (encore que, maintenant il “suffit” d’implémenter le protocole ACMEv2, ou on peut aussi regarder du côté du secret engine PKI de Vault https://www.vaultproject.io/docs/secrets/pki/index.html ), et surtout d’arriver à obtenir sa diffusion dans les bases de données publiques.



C’est sur ce dernier point qu’avoir des sponsors au bras long, comme Google (via Chrome), Cisco ou Facebook, ça aide énormément.









boogieplayer a écrit :



Le prob c’est que le certif n’est valable que 3 mois et c’est -par exemple- cerbot qui le renouvelle automatiquement. Des milliers de demande de renouvellement se font toutes les heures en automatique, si le service est down bah les sites vont tomber petit à petit au fur et à mesure du temps. Si tu es en HSTS tu ne pourras même pas passer en HTTP en attendant.



Ensuite en cas de problème sur le certif racine, il faudra attendre la mise à jour des navigateurs.



C’est déjà pas mal.





certbot essaie de renouveler le certificat bien avant son expiration, ce qui laisse de la marge pour remonter le service ou a pire changer d’autorité de certification.



J’ai du mal à voir le soucis en vrai. SI LE tombe, il te reste 1 mois pour générer un nouveau certificat d’une manière ou d’une autre (un certificat LE est renouvelé un mois avant son expiration, donc à tout moment il reste au moins un mois de validité, justement pour se protégér en cas de problème avec LE), ce qui au pire te coutera quelques euros et voila.



Ce n’est pas un SPOF, ou en tous cas pas plus que n’importe quel fournisseur de certificats. Le fait que LE tombe en panne n’empêchera aucun site de fonctionner (juste les nouveaux d’être déployés mais c’est une autre histoire).



Si on veut vraiment parler de SPOF parlons de Cloudflare ou des services DNS, ou même de AWS/GCP/Azure.



Et de toutes facons si tu es un gros site très précieux qui doit s’inquiéter de ce genre de chose tu devrais avoir un certificat étendu bien cher pas du tout par LE donc bon …








dineptus a écrit :



J’ai du mal à voir le soucis en vrai. SI LE tombe, il te reste 1 mois pour générer un nouveau certificat d’une manière ou d’une autre (un certificat LE est renouvelé un mois avant son expiration, donc à tout moment il reste au moins un mois de validité, justement pour se protégér en cas de problème avec LE), ce qui au pire te coutera quelques euros et voila.



Ce n’est pas un SPOF, ou en tous cas pas plus que n’importe quel fournisseur de certificats. Le fait que LE tombe en panne n’empêchera aucun site de fonctionner (juste les nouveaux d’être déployés mais c’est une autre histoire).



Si on veut vraiment parler de SPOF parlons de Cloudflare ou des services DNS, ou même de AWS/GCP/Azure.



Et de toutes facons si tu es un gros site très précieux qui doit s’inquiéter de ce genre de chose tu devrais avoir un certificat étendu bien cher pas du tout par LE donc bon …





La failure c’est pas juste que le service tombe ou disparaisse.

&nbsp;Il peut être piraté, une entité malintentionnée peut découvrir une faille et détourner, espionner, vendre les données circulant. Sans que ça se sache, pendant des années…

&nbsp;Et comme Let’sEncrypt est gros, ça affecterait une grande partie d’internet.

&nbsp;

Moralité : { plusieurs acteurs &gt; un gros acteur } car risque réparti.

&nbsp;



Il faut une blockchain&nbsp; pour les certificats !&nbsp;<img data-src=" />








Ptitl0u a écrit :



Il faut une blockchain&nbsp; pour les certificats !&nbsp;<img data-src=" />





Il existe déjà le Certificate Transparency, qui est un grand log public automatisé des pratiques des CA.

&nbsp;Mis en place par Google.









ErGo_404 a écrit :



Le certificats servent aussi pour faire du machine to machine. SI par exemple tu as une appli embarquée sur un appareil que tu ne peux pas mettre à jour à distance pour X raisons, et que cet appareil vérifie explicitement ton certificat (par exemple en comparant la racine avec ce qu’il connaît), tu risques d’avoir d’un coup tout ton parc de machines qui ne fonctionne plus.






Oui, tout à fait, on est bien dans le cas où l'identité est primordiale. Dans ce cas faut payer son certificat. Et ne pas utiliser LE, car cette autorité de certification est plus que limite niveau validation de l'identité. Perdre LE dans ce cas n'est en rien gênant, car ce n'est de toute façon pas la solution.     



&nbsp;





Zrechim a écrit :



Passer en https avec un certif auto-signé ne corrige rien, il suffit à un attaquant de générer le même de son côté pour se faire passer pour la cible (pas d’AC racine =&gt; pas de preuve que le certif est légitime) donc, usurpation (phishing) et MItM possible






Hein ? Tant que ta clé privée ne fuite pas, personne ne peut régénérer un certificat identique au tiens. Le certificat auto-signé n'est pas un nom, c'est juste une paire de clé de chiffrement. Et c'est tout ce que SSL demande.    





Même avec une nuit qui porte conseil, je vois toujours pas le soucis de sécurité avec une disparition de LE. D’usage, oui, de sécurité, non. Du coup, y a pas de failure, donc pas de SPOF. Du coup pas d’article.









dineptus a écrit :



Si on veut vraiment parler de SPOF parlons de Cloudflare ou des services DNS, ou même de AWS/GCP/Azure.



&nbsp;



Pour les services DNS, t'es sensé en avoir 1 primaire et 1 secondaire. Si les deux viennent du même fournisseur, c'est ta faute, y a suffisamment de concurrence dans le domaine pour en trouver deux à ton gout. Et donc faudrait que les deux tombent pour que tu ne puisses plus faire de résolution.      






Pour les fournisseurs de cloud (AWS...), c'est pareil, le fonctionnement même du cloud est basé sur le multi-instance et la répartition de charge. Si t'es assez idiot pour avoir héberger toutes tes instances chez un seul fournisseur, c'est ta faute. Il en faut au moins deux (je crois pas avoir entendu parler de perturbation simultané sur deux cloud différents, déjà qu'ils en ont rarement).    






Pour CloudFlare, c'est un peu plus chiant à cause de la propagation DNS. C'est à ses utilisateurs (donc les admins sys) de prévoir un plan de secours, afin de sortir de CloudFlare si nécessaire, mais ça veut dire changer l'IP du nom de domaine pour qu'il pointe en direct vers le serveur (ou un autre fournisseur d'anti-ddos), et ça malheureusement ça prend plusieurs heures. Donc ça se fait, mais pas automatiquement, et pas sans casse :(




Même avec une nuit qui porte conseil, je vois toujours pas le soucis de sécurité avec une disparition de LE. D’usage, oui, de sécurité, non. Du coup, y a pas de failure, donc pas de SPOF. Du coup pas d’article.



Réduire la failure à une disparition est réducteur. Que penses-tu du piratage ?

As-tu lu ce commentaire ?








dineptus a écrit :



J’ai du mal à voir le soucis en vrai. SI LE tombe, il te reste 1 mois pour générer un nouveau certificat d’une manière ou d’une autre





Pas un mois: si LE tombe, les conséquences seront au pire immédiate à cause d’OCSP (qui permets de vérifier la révocation des certificats), au mieux, reportés de 1 ou&nbsp; 2 semaines (si OCSP stapling).



Le fait que LE tombe n’entraine en rien la révocation des certificats.



Si on parle de révocation, la danger n’est pas LE mais Symantec/Identrust.



D’ailleurs Let’s Encrypt est déjà tombé plusieurs fois et les dégats ont été virtuellement invisibles.



La raison principale est que OCSP est fail-open donc si LE tombe, par défaut le certificat ne sera pas considéré révoqué.


je ne parle pas du DNS côté client mais côté serveur (voir Dyn par exemple:https://news.ycombinator.com/item?id=12759697) qui est bien plus compliqué à résoudre.



Et pour les fournisseurs cloud c’est bien joli la théorie mais va donc installer une base de donnée SQL partagée entre plusieurs fournisseurs et on en reparle. Ou le cache, ou n’importe quel système qui a besoin d’una ccès immmédiat à des données communes en temps réel. C’est déjà super compliqué d’avoir une BDD multi-régions en temps réel, mais alors entre fournisseurs différents ca relève de l’utopie.



Les instances évidemment que c’est facile de les repartir, mais si tu as une seule base de donnée ca ne sert á rien du tout, au final ta BDD tombe et ton site ne marche plus du tout.



Et encore je ne parle pas de tous les services qui sont exclusifs à chaque fournisseurs et qui sont donc par définission impossibles à répliquer dans un autre (genre Elasticbean, tous les trucs “serverless” etc.)








dineptus a écrit :



je ne parle pas du DNS côté client mais côté serveur (voir Dyn par exemple:https://news.ycombinator.com/item?id=12759697) qui est bien plus compliqué à résoudre.






    Bah c'est plus du SPOF dans ce cas là. C'est pas transversale, ça touche que ce qui est sous sa responsabilité. A toi de pas être dépendant d'un seul lien.        

&nbsp;







dineptus a écrit :



Les instances évidemment que c’est facile de les repartir, mais si tu as une seule base de donnée ca ne sert á rien du tout, au final ta BDD tombe et ton site ne marche plus du tout.






   Il est tout à fait possible de faire une BDD résiliente multi-machine (chaque logiciel de BDD a son nom pour ça mais ça revient au même, répartition des lectures et réplication des écritures). Et ces machines peuvent être réparti comme tu le veux. Si un hébergeur tombe, bah ses front et back/BDD tombent, les autres continuent leur vie.        

&nbsp;







dineptus a écrit :



Et encore je ne parle pas de tous les services qui sont exclusifs à chaque fournisseurs et qui sont donc par définission impossibles à répliquer dans un autre (genre Elasticbean, tous les trucs “serverless” etc.)






   Oui, AWS joue très bien là-dessus pour enfermer ses utilisateurs. Ils proposent beaucoup de choses très intéressantes, sauf que ça implique de les utiliser que eux, et de jamais les quitter. Sauf c'est ton choix de les utiliser.         






   Mais ElasticSearch ce n'est en aucun cas limité à un fournisseur (tu peux le répartir), et le principe du serverless est facilement adaptable partout (la plomberie est dépendante du fournisseur, mais le code métier est sensé être portable si tu sais coder...). Ce n'est qu'une question de volonté. Bien sur c'est plus facile de faire un truc mono-fournisseur, en informatique comme dans tous les domaines (aéronautique, etc.), mais c'est aussi plus dangereux pour ton activité, comme dans tous les domaines (demande donc à Airbus).         






   A toi de faire ton choix, mais tous les SPOF que tu vois c'est du à ta méconnaissance des alternatives ou des principes sous-jacents à mon avis. Un peu comme l'auteur de cet article en somme.


Elastic Beanhttps://aws.amazon.com/elasticbeanstalk/ n’a rien á voir avec Elastic Search https://www.elastic.co/)



Elastic Bean est un concurrent de GAE flexible https://cloud.google.com/appengine/docs/flexible/)



Et bien sur il est possible de faire une BDD multi machine mais dans ce cas tu dois la gérer toi même, ce qui est hyper lourd et ingérable pour une startup, sauf si c’est une startup de sysadmin bien sur. C’est bien pour ca que les BDD gérer par AWS/Google/Microsoft ou tu n’as pas d’accès à la machine sont si populaires.



Et Dyn était bien un SPOF pour beaucoup de sites, y compris des très gros. En étant honnête, combien d’entre nous ont plusieurs fournisseurs différent pour les DNS racine ? Même Github, Netflix et AirBNB étaient tombés à cause de ca, alors dire “A toi de pas être dépendant d’un seul lien” c’est cool mais à quel moment on se rend compte que c’est exagéré de demander ce genre de chose pour un site moyen ?


Pas tout à fait : tu ne peux pas renouveler un certificat Let’s Encrypt tant qu’il lui reste plus de 30 jours de validité. Tu ne peux le renouveler que pendant les 30 derniers jours. Autrement, certbot (le programme qui permet de récupérer un certificat) s’arrête avec un message “no certificate due for renewal”.








dineptus a écrit :



Même Github, Netflix et AirBNB étaient tombés à cause de ca, alors dire “A toi de pas être dépendant d’un seul lien” c’est cool mais à quel moment on se rend compte que c’est exagéré de demander ce genre de chose pour un site moyen ?






   Je connais pas les moyens financiers de Github, mais pour les deux autres, on peut pas dire qu'ils soient dans la catégorie des "moyens". Par contre, pour les petits sites, oui, avoir des SPOF est monnaie courante et normal, car tu cherches pas l'uptime de 99,99%. Mais quand tu veux t'en débarrasser tu peux, contraire à ce que tu disais. Ça a un cout, mais les moyens pour se protéger sont connus, et crois-moi que Netflix a appris de ses erreurs et qu'ils ont maintenant plusieurs gestionnaires DNS. Car oui, c'était une grossière erreur, pas un SPOF inévitable, ce qui est ton discours et qui est complètement faux.        

&nbsp;







dineptus a écrit :



C’est bien pour ca que les BDD gérer par AWS/Google/Microsoft ou tu n’as pas d’accès à la machine sont si populaires.






  Ces services sont surtout populaire car ça prend des minutes et non des semaines pour obtenir des nouvelles machines. Je ne connais pas le taux d'utilisation des BDD maison, mais c'est surtout les VM (PAAS/IAAS) qui fonctionnent. Après ceux qui les utilisent pour se passer de sysadmin, ben ils méritent toutes les pannes qui peuvent leur arriver. Il n'est même pas question de SPOF mais bien d'inconscience. Si tu n'as pas de sysadmin en interne, tu externalise, mais tu les fais pas disparaitre en laissant un unique fournisseur faire ce qu'il veut. C'est vrai pour toutes les industries ça.        






  Et comme dans toutes industries, t'as des entreprises qui essayent de faire des économies au mauvais endroit... Et des gens qui préfèrent annoncer que c'est pas possible plutot que de chercher :)


Bizarrement ça me rappelle quelque chose (de loin mais quand même) ah oui symantec…



Il y a deux problèmes dans LE actuellement :



&nbsp;- La sécurité des clés privés et du seul et unique certificat racine (parce que si le certificat racine de let’s encrypt saute ou comme pour symantec est hacké ben… ca va faire mal au net <img data-src=" />)

&nbsp;




  • Il n’a pas de concurrence au même prix








dineptus a écrit :



Le fait que LE tombe n’entraine en rien la révocation des certificats.



Si on parle de révocation, la danger n’est pas LE mais Symantec/Identrust.



D’ailleurs Let’s Encrypt est déjà tombé plusieurs fois et les dégats ont été virtuellement invisibles.



La raison principale est que OCSP est fail-open donc si LE tombe, par défaut le certificat ne sera pas considéré révoqué.





Sauf erreur, OCSP est hard-fail sur Firefox (possiblement derrière une option):https://support.mozilla.org/en-US/questions/1161980