Let’s Encrypt raccourcit sa chaîne de confiance

 (letsencrypt.org)
2 points par GN⁺ 2023-07-11 | 1 commentaires | Partager sur WhatsApp
  • Let’s Encrypt passe à une chaîne de certificats plus courte se terminant par ISRG Root X1, sans prolonger la signature croisée (cross-sign) qui expire le 30 septembre 2024
  • À ses débuts, sa propre racine n’étant pas encore suffisamment reconnue, le service dépendait de la DST Root CA X3 d’IdenTrust ; aujourd’hui, la couverture de confiance d’ISRG Root X1 s’est fortement élargie
  • La signature croisée de la racine ajoutée en 2021 pour la compatibilité avec les anciens Android était une mesure temporaire, qui a permis aux appareils Android anciens de faire confiance aux certificats Let’s Encrypt pendant 3 années supplémentaires
  • Au cours des 3 dernières années, la part des appareils Android faisant confiance à ISRG Root X1 est passée de 66 % à 93,9 %, et la suppression de la signature croisée réduit aussi de plus de 40 % le volume d’octets de certificats dans le handshake TLS
  • Il est recommandé aux utilisateurs d’Android 7.0 ou inférieur d’utiliser Firefox Mobile ; les administrateurs de sites et les auteurs de clients ACME doivent vérifier leur traitement des chaînes en vue du calendrier de transition 2024

Contexte de la fin de la signature croisée

  • À ses débuts, pour que ses certificats soient largement reconnus, Let’s Encrypt a fait signer de façon croisée son certificat intermédiaire par la DST Root CA X3 d’IdenTrust
    • Le principe était de faire reconnaître les certificats émis par cet intermédiaire, même si sa propre racine, ISRG Root X1, n’était pas encore largement approuvée
  • Avec le temps, ISRG Root X1 est devenue largement reconnue par elle-même
  • Fin 2021, le certificat intermédiaire signé de façon croisée et la DST Root CA X3 elle-même devaient expirer
    • À l’époque, les navigateurs récents faisaient confiance à la racine de Let’s Encrypt, mais plus d’un tiers des appareils Android utilisaient encore d’anciennes versions de l’OS
    • Ces appareils risquaient de ne plus faire soudainement confiance aux sites web utilisant des certificats Let’s Encrypt
  • En 2021, Let’s Encrypt a mis en place une mesure temporaire durant plus longtemps que la DST Root CA X3, en appliquant une signature croisée directement à la racine plutôt qu’au certificat intermédiaire
    • Cette mesure a permis aux anciens appareils Android de faire confiance aux certificats Let’s Encrypt pendant 3 années supplémentaires
  • Cette signature croisée expire le 30 septembre 2024

Pourquoi passer à une chaîne plus courte

  • Let’s Encrypt ne demandera plus de nouvelle signature croisée pour prolonger la compatibilité
    • Au cours des 3 dernières années, la part des appareils Android faisant confiance à ISRG Root X1 est passée de 66 % à 93,9 %
    • Android 14 peut mettre à jour le magasin de confiance sans mise à jour complète de l’OS, ce qui pourrait encore augmenter cette proportion
    • La suppression de la signature croisée réduit de plus de 40 % le nombre d’octets de certificats transmis lors du handshake TLS
    • Elle réduit aussi fortement les coûts d’exploitation, permettant à Let’s Encrypt de concentrer ses financements sur l’amélioration de la confidentialité et de la sécurité

Calendrier de transition 2024

  • Jeudi 8 février 2024 : arrêt de la fourniture par défaut de la signature croisée pour les requêtes vers l’endpoint API /acme/certificate
    • Pour la plupart des abonnés, le client ACME configure une chaîne se terminant par ISRG Root X1, et le serveur web fournit la chaîne plus courte lors du handshake TLS
    • La chaîne plus longue se terminant par la signature croisée bientôt expirée pouvait encore être demandée comme chaîne alternative
  • Jeudi 6 juin 2024 : arrêt complet de la fourniture de la chaîne plus longue avec signature croisée
    • Cette date précède d’un peu plus de 90 jours l’expiration de la signature croisée, soit la durée de vie d’un certificat
    • Ce calendrier vise à garantir aux abonnés au moins un cycle complet d’émission pour quitter la chaîne avec signature croisée
  • Lundi 30 septembre 2024 : expiration du certificat signé de façon croisée
    • Pour la plupart des utilisateurs, cela ne devrait pas constituer un événement particulier, et les défaillances côté clients devraient déjà être apparues au cours des 6 mois précédents

Points à vérifier pour les utilisateurs et les opérateurs

  • Les utilisateurs d’Android 7.0 ou inférieur pourraient devoir agir pour continuer à accéder aux sites web protégés par des certificats Let’s Encrypt
    • Let’s Encrypt recommande d’installer et d’utiliser Firefox Mobile, qui utilise son propre magasin de confiance plutôt que celui de l’OS Android
  • Les administrateurs de sites doivent vérifier les statistiques d’utilisation de leurs sites web et les chaînes user-agent actives aux 2e et 3e trimestres 2024
    • Une chute soudaine des visites depuis Android peut indiquer la présence d’un nombre important d’utilisateurs sous Android 7.0 ou inférieur
    • Il est recommandé de leur fournir des consignes pour utiliser Firefox Mobile
  • Les auteurs de clients ACME doivent télécharger et installer correctement la chaîne de certificats fournie par l’API à chaque émission et renouvellement de certificat
    • Parmi les types d’incidents observés par le passé, certains clients ne téléchargeaient pas du tout la chaîne et ne fournissaient que le certificat end-entity
    • D’autres fournissaient une chaîne codée en dur sans télécharger la chaîne
    • D’autres encore téléchargeaient la chaîne uniquement lors de la première émission, sans la télécharger à nouveau lors des renouvellements
  • Les questions relatives à la transition peuvent être posées sur le forum communautaire de Let’s Encrypt

À lire aussi

1 commentaires

 
GN⁺ 2023-07-11
Avis Hacker News

  • Je me souviens que Let's Encrypt avait annoncé qu'il ferait cette transition à l'été 2019, puis l'avait reportée après avoir écouté les retours de la communauté
    J'étais l'une des personnes qui demandaient fortement de reconsidérer la décision à l'époque, mais je ne pensais pas qu'ils repousseraient cela de quatre ans et demi, bien au-delà de toutes les attentes. Merci d'avoir traité l'écosystème TLS avec autant de prudence

    • Tu peux expliquer ? Je l'utilise, mais j'oublie souvent à quel point Let's Encrypt est important pour mon site web

  • Pour couvrir 95 % des appareils Android, il faut prendre en charge Android 7.0 Nougat d'août 2016
    https://en.wikipedia.org/wiki/Android_Nougat
    Pour couvrir 95 % des appareils iOS, iOS 14 de septembre 2020 suffit, et même en regardant seulement 90 %, Android en est à 8.1 (2017) contre iOS 15 (2021)
    https://iosref.com/ios-usage
    https://en.wikipedia.org/wiki/IOS_14
    Apple semble mieux réussir à convaincre ou à permettre aux gens de passer à des systèmes d'exploitation plus récents

    • Apple ne vend pas de téléphones à 10 dollars dans les pays en développement. Si on compare des appareils de la même gamme de prix chez les grands fabricants ou opérateurs, l'écart n'est probablement pas aussi extrême
    • C'est plus simple. Apple empêche les tiers de fabriquer des iPhone, tandis que Google permet aux tiers de fabriquer des téléphones Android
      Si les appareils ne sont pas mis à jour, c'est parce que les fabricants cessent de fournir des mises à jour
    • Les mises à niveau du système d'exploitation sont mal gérées à la fois par Google et par les fabricants d'appareils, mais il n'y a aucune raison pour que le bundle de CA soit lié à la version de l'OS
      D'après la page du bundle de CA de curl, le bundle Mozilla fait environ 200 Ko une fois décompressé, et l'application Chrome sur mon Android fait 25 Mo, donc rester à jour pour une augmentation de 1 % de la taille de l'appli semble raisonnable
      Bien sûr, d'autres applis pourraient aussi vouloir des CA à jour, mais on peut aussi se demander s'il faut vraiment toutes les CA ou seulement celles qui ont une chance réelle d'être utilisées
    • Quand on contrôle toute la pile matérielle et logicielle, il est beaucoup plus facile de garder à jour les anciens appareils des clients
      Google ne peut pas faire grand-chose si un fabricant low cost décide de ne pas fournir de mises à jour à ses clients. Il peut exiger une certaine durée de support pour obtenir ou conserver la certification Android, mais à un moment donné ce fabricant peut aussi abandonner Android lui-même
      En plus, Qualcomm cesse lui aussi de fournir des noyaux et blobs mis à jour pour les anciens chipsets avec le temps. Google a négocié une durée plus longue que les pitoyables 18 mois d'autrefois, mais Qualcomm n'a aucune obligation d'aller plus loin. Depuis que Google a commencé à fabriquer ses propres chipsets, son intérêt pour ce problème a aussi un peu diminué
      Ce n'est pas pour dire que c'est bien, mais avec le modèle d'Android, cela tend globalement à se passer ainsi, alors que le modèle d'Apple permet de mieux contrôler cet aspect
    • Dans mon cas, c'est à cause de l'amélioration de la caméra

  • La manière dont ils ont réussi à faire fonctionner durablement l'ancienne cross-signature était assez intéressante
    La nouvelle cross-signature était quelque peu inhabituelle, en ce qu'elle allait au-delà de l'expiration de DST Root CA X3. Cette solution était possible parce qu'Android n'applique pas délibérément la date d'expiration des certificats utilisés comme ancres de confiance
    En pratique, une ancre de confiance se comporte de façon assez différente des autres certificats, ce qui peut surprendre
    [1] https://letsencrypt.org/2020/12/21/extending-android-compati...
    [2] https://alexsci.com/blog/name-non-constraint/

    • Cette solution n'était pas parfaite. La plupart des problèmes ont été réglés assez vite, mais cela a quand même donné lieu à l'un des plus longs fils que j'aie vus sur le forum LE : https://community.letsencrypt.org/t/help-thread-for-dst-root...
      Si je me souviens bien, l'un des gros problèmes était que les anciennes versions de OpenSSL vérifiaient l'expiration de l'ancre racine. Et ce n'était pas tout : à l'époque, dans mon entreprise, Ubuntu a dû patcher quelque chose pour gérer la situation, et le correctif n'est sorti que quelques jours avant l'expiration, ce qui a causé une brève panne sur certains systèmes. Il a fallu reconstruire en masse des images Docker pour corriger le problème
      Ce contournement était tellement radical et sans précédent que j'imagine qu'ils n'y ont eu recours que parce que l'écart de coût avec une cross-signature depuis une racine non expirée et largement compatible était énorme. Cela a aussi dû demander énormément de tests. Ce n'était pas parfait, mais le fait que cela se soit globalement déroulé sans trop d'accroc reste impressionnant
    • J'ai été un peu surpris qu'ailleurs, la méthode d'Android ne soit pas la façon habituelle de faire. Je pensais que la validation temporelle d'une chaîne de certificats TLS C0 -> C1 -> C2 ... -> Cn fonctionnait grosso modo comme ce pseudocode
      1 time_check = now()
      2 for cert in Cn to C0
      3 if time_check < cert.valid_from || time_check > cert.valid_to
      4 return EXPIRED
      5 time_check = cert.issue_time
      6 return NOT_EXPIRED
      Mais en cherchant, j'ai vu qu'en pratique cela fonctionne sans la ligne 5, donc toutes les vérifications temporelles se font par rapport à l'instant présent. Tous les certificats de la chaîne doivent être valides maintenant
      Les certificats de signature de code fonctionnent, eux, comme j'imaginais que TLS fonctionnait aussi. Un code horodaté reste valide même si le certificat racine a expiré, tant que la racine était valide au moment de l'horodatage

  • Espérons que l’expiration du certificat à signature croisée ne soit sans effet pour la plupart des gens, mais la précédente expiration de la signature croisée DST ne s’était pas passée ainsi
    Si je me souviens bien, GnuTLS n’arrivait pas à construire correctement le chemin après l’expiration. Il semblait ne construire qu’un chemin vers le certificat expiré, constater qu’il était expiré, puis s’arrêter en ignorant les autres chemins possibles
    Pire encore, GnuTLS était la bibliothèque TLS utilisée par apt lorsqu’il utilisait HTTPS. HTTPS n’est pas la valeur par défaut, mais notre équipe sécurité voulait distribuer tous les paquets de façon sûre en les vendorisant, ce qui était raisonnable en soi, mais le coût a pris la forme d’une panne. Il me semble que cela a été corrigé dans Bullseye, et pure coïncidence, à peine une semaine avant l’expiration. Azure a aussi subi plusieurs incidents liés à cette expiration

    • Est-ce que tous les opérateurs de miroirs apt ne renouvellent pas leurs certificats LE avec certbot environ une fois par mois ? Dans ce cas, après le 6 juin 2024, ils devraient recevoir des certificats signés par la nouvelle racine LE, sans expiration ni signature croisée, non ? Est-ce que quelque chose m’échappe ?

  • En dehors de l’utilisation de HTTP non chiffré, existe-t-il une solution proposée pour faire en sorte que TLS ne soit plus l’élément le plus fragile du Web ?
    Les changements incessants comme l’abandon de protocoles, l’expiration des certificats et leur remplacement donnent l’impression d’amplifier excessivement l’obsolescence programmée

    • Je ne dirais pas que TLS est l’élément le plus fragile du Web. Ce titre reviendrait probablement à DNS, à BGP, ou selon les critères, à us-east-1
    • Le problème n’est pas que TLS évolue en permanence. Il doit évoluer pour des raisons de sécurité
      Le vrai problème qui mène à l’obsolescence programmée, c’est que les appareils cessent trop vite de recevoir des mises à jour du fabricant, et qu’aucun tiers ne peut les mettre à jour non plus
      La solution que je préférerais serait une loi imposant aux fabricants, avant de cesser de produire des mises à jour de sécurité moins de 10 ans après la fin de commercialisation, soit de tout publier en open source, soit de rembourser intégralement tous les acheteurs
    • Une grande partie de ce qui est pénible avec TLS semble venir du fait qu’il faut suivre en permanence la réémission des certificats
      La raison, c’est que la révocation distribuée à l’échelle mondiale est un problème absurdement difficile. Pour atténuer le fait qu’une partie de l’association entre l’utilisateur et le certificat est pratiquement impossible à révoquer, on réduit la durée de vie des certificats afin de limiter l’ampleur des dégâts
      Ce n’est évidemment pas très consolant, mais l’univers des certificats à courte durée de vie après ACME offre quand même une meilleure expérience développeur que le cauchemar des certificats Verisign longue durée. Il faut aussi garder à l’esprit que les alternatives à TLS seraient confrontées à des problèmes similaires
    • Fondamentalement, je pense qu’aucune entité ne peut être digne de confiance pour toujours. La meilleure solution consiste à fournir des mises à jour de certificats séparées du canal de mise à jour habituel
      Le format de certificat x509, en pratique, n’a presque pas changé depuis très longtemps
      Les changements de protocole semblent maintenant se stabiliser. TLS 1.2 a été introduit en 2008 et est toujours considéré comme acceptable, donc on ne peut plus vraiment parler de nouveauté. Beaucoup de gens l’ont examiné de près, on peut donc espérer que la plupart des problèmes ont été mis au jour
    • DANE : https://wikipedia.org/wiki/DNS-based_Authentication_of_Named...
      À mon avis, ce que fait Let's Encrypt revient fondamentalement à faire du DANE, donc j’ai envie de dire : pourquoi ne pas simplement le prendre en charge ? Bien sûr, il peut exister des cas d’usage où DANE n’est pas adapté
      Il n’y a pas de raison que le parfait empêche le suffisamment bon, et ceux qui le veulent peuvent utiliser DANE

  • Quand ils disent qu’ils peuvent « réduire considérablement les coûts d’exploitation pour concentrer les financements sur la protection de la vie privée et l’amélioration de la sécurité », est-ce que cela veut dire qu’ils paient des montants de l’ordre de plusieurs millions de dollars pour la signature croisée ?

    • D’après le Form 990 de 2021, 434 000 dollars ont été versés à Identrust sous l’intitulé « Internet Services ». Je ne sais pas s’ils obtiennent autre chose d’Identrust que la signature croisée, mais il est plausible que cette somme corresponde au coût de la signature croisée
      La même année, les dépenses totales étaient de 5,1 millions de dollars, donc cette dépense représentait presque 10 % du budget
      [0]: https://beta.candid.org/profile/9328188?keyword=46-3344200&a...

  • Est-ce que quelqu’un connaît les coulisses de la manière dont une société de certificats a accepté de fournir une signature croisée ? Let’s Encrypt ne détruit-il pas complètement leur modèle économique ?

    • Ce que Let's Encrypt a détruit, c’est le modèle économique de la vente de certificats à validation de domaine à 10 dollars par an. Et si l’on voulait un wildcard, c’était bien plus cher
      Des sociétés comme RapidSSL ou GoDaddy n’auraient probablement pas fourni de signature croisée à Let’s Encrypt à moins qu’on leur propose une somme du genre « achetez toute notre activité de CA »
      Mais la vente de certificats DV n’était pas le modèle économique d’IdenTrust ; ils ont donc peut-être été disposés à fournir une signature croisée pour une somme à moins de six chiffres, comme d’autres l’ont supposé. Étant donné le fonctionnement des certificats racine TLS, la signature croisée d’IdenTrust était tout aussi utile à LE que celle d’une CA extrêmement rentable
    • Si j’étais une société de certificats dont le marché cible est celui des grandes entreprises, moins susceptibles d’utiliser Let’s Encrypt, j’aurais fourni une signature croisée pour affaiblir des concurrents davantage dépendants des petites entreprises ou d’autres projets attirés par Let’s Encrypt
    • Ils ont probablement été convaincus avec de l’argent. Sinon, quelqu’un d’autre l’aurait fait
      Il ne semble pas qu’IdenTrust ait fait faillite
      1 IdenTrust 48.5% 53.6%
      2 DigiCert Group 13.1% 14.5%
      3 Sectigo (Comodo Cybersecurity) 12.1% 13.4%
      4 GlobalSign 6.1% 6.7%
      5 Let's Encrypt 5.8% 6.4%
      6 GoDaddy Group 4.8% 5.3%
      https://en.wikipedia.org/wiki/Certificate_authority
    • Pas du tout. Les principales autorités de certification vendent toutes à des clients entreprises, et continueront de le faire. La plupart des utilisateurs de Letsencrypt relèvent plutôt du domaine personnel ou amateur

  • Fin 2021, lorsque le certificat intermédiaire à signature croisée et DST Root CA X3 lui-même ont expiré, tous les navigateurs récents faisaient déjà confiance à la racine de LE, mais plus d’un tiers des appareils Android utilisaient encore d’anciens systèmes d’exploitation, si bien que les sites web utilisant des certificats LE risquaient soudain de ne plus être considérés comme fiables
    Je ne l’ai appris que quelques semaines plus tôt, mais il semble que les utilisateurs d’Ubiquiti aient aussi été affectés

  • Récemment, en déplaçant le backend d’AWS vers un serveur local, j’ai dû passer de Letsencrypt, que j’utilisais habituellement, à ZeroSSL
    La raison était que des équipements IoT de 2016 encore pris en charge n’avaient pas le certificat racine nécessaire pour valider les certificats LE. Cela semblait probablement lié à l’expiration en 2021 du certificat racine R3 utilisé par LE
    J’ai trouvé assez choquant qu’un seul certificat expiré puisse transformer en briques toute une gamme de produits déjà vendus. Dans ce cas, ce n’était pas un gros problème, car il existait un certificat racine valide chez un autre fournisseur

    • Lors du retrait progressif de SHA-1, beaucoup d’AC se sont beaucoup plaintes sur mozilla.dev.security.policy parce qu’elles avaient mis des certificats SHA-1 dans des appareils médicaux et des systèmes POS, avec très peu de moyens de les mettre à jour
      Elles ont même continué à en émettre après la date fixée par le CA/Browser Forum. À l’époque, je pensais que tout le monde avait compris qu’utiliser la Web PKI sans moyen de pousser des mises à jour était incompatible, mais apparemment non

  • Depuis juste après l’introduction de la signature croisée, les sites destinés aux utilisateurs sur desktop supprimaient déjà les certificats à signature croisée
    Cela créait des problèmes de compatibilité qui n’existaient pas auparavant, et certains validateurs de certificats trébuchaient sur des certificats racine expirés. Les utilisateurs touchés n’étant pas très techniques, ils n’ont finalement jamais pu identifier la cause profonde