La Fibre
Télécom => Réseau => 
Protocoles réseaux sécurisés (https) => Discussion démarrée par: vivien le 05 décembre 2020 à 16:52:15
-
En 2021, les versions d'Android antérieures à 7.1.1 ne feront plus confiance aux certificats émis par Let's Encrypt
Je trouve étonnant qu'on en parle si peu, vu la position qu'a pris Let's Encrypt, utilisé par la majorités des sites web aujourd'hui (plus de 225 million de sites web et environ 1,5 millions de certificats émis par jour).
Depuis 2016 Let's Encrypt demande à tous les systèmes d’exploitation d'intégrer son certificat racine: ISRG Root X1. Tous les systèmes d’exploitations ont alors publiées des mises à jour pour intégrer ISRG Root X1.
Tous ? Non, outre Windows XP, beaucoup de Smartphones Android ne reçoivent les nouvelles versions d'Android depuis 4 ans. En septembre 2020, seul 66,2% des smartphones Android en septembre 2020 intègrent le certificat racine de Let's Encrypt ISRG Root X1 (Android 7.1.2 est sorti le 5 décembre 2016, il y a 4 ans jour pour jour, mais de nombreux smartphones ne l'ont pas reçu, comme par exemple le Samsung Galaxy S6, smartphone très populaire sortie en 2015, qui est resté bloqué en 7.0 avec les dernières mises à jour). Certains Smartphones commercialisés en 2017 étaient sous Android 7.0 et n'ont reçus aucune mise à jour vers Android 7.1 ou 8.0.
33,8% des smartphones Android ne feront plus confiance aux certificats émis par Let's Encrypt en 2021 (progressivement à compter du 11 janvier 2021 et le 1er septembre 2021, date d'expiration du certificat racine DST Root X3, les versions d'Android antérieures à 7.1.1). Le certificat «DST Root X3» d'IdenTrust était utilisé temporairement, le temps que le certificat ISRG Root X1 soit intégré dans les différents systèmes d’exploitations.
Seul l'utilisation de Firefox permettra aux versions d'Android antérieures à 7.1.1 d'avoir un accès aux très nombreux sites avec un certificat émis par Let's Encrypt : Firefox est actuellement le seul navigateur à livrer sa propre liste de certificats racine de confiance, elle est donc mise à jour en même temps que le navigateur.
Voici les messages qui s'afficheront avec Google Chrome sur de nombreux sites internet dans quelques mois :
(https://lafibre.info/images/ssl/202012_google_chrome_1.png) (https://lafibre.info/images/ssl/202012_google_chrome_2.png)
La racine ISRG X1 et la certification croisée avec la racine “DST Root CA X3” d’IdenTrust (nommée “TrustID X3 Root”) :
(https://lafibre.info/images/ssl/202012_letsencrypt_relations_entre_certificats.png)
-
Voici la traduction d'un article publié par Let's Encrypt, qui explique la situation et pourquoi il n'y a pas de solutions :
Lorsqu'une nouvelle autorité de certification (CA) entre en scène, elle est confrontée à une énigme: pour être utile aux gens, elle a besoin que son certificat racine soit approuvé par une grande variété de systèmes d'exploitation (OS) et de navigateurs. Cependant, cela peut prendre des années pour que les systèmes d'exploitation et les navigateurs acceptent le nouveau certificat racine, et même plus longtemps pour que les gens mettent à niveau leurs appareils vers les versions plus récentes qui incluent ce changement. La solution courante: une nouvelle autorité de certification demandera souvent à une autorité de certification existante et de confiance une signature croisée, pour qu'elle soit rapidement approuvée par de nombreux appareils.
Il y a cinq ans, lorsque Let's Encrypt a été lancé, c'est exactement ce que nous avons fait. Nous avons obtenu une signature croisée d'IdenTrust. Leur «DST Root X3» existe depuis longtemps, et toutes les principales plates-formes logicielles lui font déjà confiance: Windows, Firefox, macOS, Android, iOS et une variété de distributions Linux. Cette signature croisée nous a permis de commencer à émettre des certificats tout de suite et de les rendre utiles à beaucoup de gens. Sans IdenTrust, Let's Encrypt n'aurait peut-être jamais eu lieu et nous leur sommes reconnaissants pour leur partenariat. Entre-temps, nous avons émis notre propre certificat racine («ISRG Root X1») et demandé qu'il soit approuvé par les principales plates-formes logicielles.
Maintenant, ces plates-formes logicielles font confiance à notre certificat racine depuis des années. Et le certificat racine DST Root X3 sur lequel nous nous sommes appuyés pour nous faire décoller va expirer - le 1er septembre 2021. Heureusement, nous sommes prêts à nous débrouiller seuls et à nous fier uniquement à notre propre certificat racine.
Cependant, cela introduit des problèmes de compatibilité. Certains logiciels qui n'ont pas été mis à jour depuis 2016 (environ lorsque notre racine a été acceptée par de nombreux programmes racine) ne font toujours pas confiance à notre certificat racine, ISRG Root X1. Plus particulièrement, cela inclut les versions d'Android antérieures à 7.1.1. Cela signifie que ces anciennes versions d'Android ne feront plus confiance aux certificats émis par Let's Encrypt.
Android a un problème de longue date et bien connu avec les mises à jour du système d'exploitation. Il existe de nombreux appareils Android dans le monde dotés de systèmes d'exploitation obsolètes. Les causes sont complexes et difficiles à résoudre: pour chaque téléphone, le système d'exploitation Android de base est généralement modifié par le fabricant et un opérateur de téléphonie mobile avant qu'un utilisateur final ne le reçoive. Lorsqu'il y a une mise à jour vers Android, le fabricant et l'opérateur de téléphonie mobile doivent intégrer ces modifications dans leur version personnalisée avant de l'envoyer. Souvent, les fabricants décident que cela ne vaut pas la peine. Le résultat est mauvais pour les personnes qui achètent ces appareils: beaucoup sont bloqués sur des systèmes d'exploitation obsolètes depuis des années.
Google ne fournit plus de numéros de version sur son tableau de bord de distribution, mais vous pouvez toujours obtenir des données en téléchargeant Android Studio.
Voici à quoi ressemblaient les chiffres en septembre 2020:
(https://lafibre.info/testdebit/android/202009_android_distribution_version.png)
Distribution de la version Android à partir de septembre 2020
Actuellement, 66,2% des appareils Android utilisent la version 7.1 ou supérieure. Les 33,8% restants des appareils Android finiront par recevoir des erreurs de certificat lorsque les utilisateurs visitent des sites disposant d'un certificat Let's Encrypt. Dans nos communications avec les grands intégrateurs, nous avons constaté que cela représente environ 1 à 5% du trafic vers leurs sites. Espérons que ces chiffres seront inférieurs à l'expiration de DST Root X3 l'année prochaine, mais le changement n'est peut-être pas très significatif.
Que pouvons-nous faire à ce sujet? Eh bien, même si nous aimerions améliorer la situation des mises à jour Android, nous ne pouvons pas faire grand-chose. Nous ne pouvons pas non plus nous permettre d'acheter un nouveau téléphone au monde. Pouvons-nous obtenir une autre signature croisée? Nous avons exploré cette option et cela semble peu probable. C'est un gros risque pour une autorité de certification de signer le certificat d'une autre autorité de certification, car elle devient responsable de tout ce que fait cette autorité de certification. Cela signifie également que le destinataire de la signature croisée doit suivre toutes les procédures définies par l'AC de signature croisée. Il est important pour nous de pouvoir être autonomes. En outre, le problème de mise à jour Android ne semble pas disparaître. Si nous nous engageons à prendre en charge les anciennes versions d'Android, nous nous engageons à rechercher indéfiniment des signatures croisées auprès d'autres autorités de certification.
C'est assez difficile. Nous nous engageons à ce que tout le monde sur la planète dispose de communications sécurisées et respectueuses de la vie privée. Et nous savons que les personnes les plus touchées par le problème de mise à jour d'Android sont celles que nous souhaitons le plus aider - les personnes qui ne pourront peut-être pas acheter un nouveau téléphone tous les quatre ans. Malheureusement, nous ne nous attendons pas à ce que les chiffres d'utilisation d'Android changent beaucoup avant l'expiration de DST Root X3. En sensibilisant maintenant à ce changement, nous espérons aider notre communauté à trouver la meilleure voie à suivre.
Si vous êtes propriétaire du site
À compter du 11 janvier 2021, nous prévoyons d'apporter une modification à notre API afin que les clients ACME servent, par défaut, une chaîne de certificats menant à ISRG Root X1. Cependant, il sera également possible de servir une chaîne de certificats alternative pour le même certificat qui mène à DST Root X3 et offre une compatibilité plus large. Ceci est implémenté via la relation de liaison «alternative» ACME. Ceci est pris en charge par Certbot à partir de la version 1.6.0. Si vous utilisez un autre client ACME, veuillez consulter la documentation de votre client pour voir si la relation de lien «alternative» est prise en charge.
Il y aura des propriétaires de sites qui recevront des plaintes d'utilisateurs et nous sommes reconnaissants que ce ne soit pas idéal. Nous travaillons dur pour alerter les propriétaires de sites afin que vous puissiez planifier et préparer. Nous encourageons les propriétaires de sites à déployer un correctif temporaire (passage à la chaîne de certificats alternative) pour que votre site continue de fonctionner pendant que vous évaluez ce dont vous avez besoin pour une solution à long terme: si vous devez exécuter une bannière demandant à vos utilisateurs Android sur des systèmes d'exploitation plus anciens de installez Firefox, arrêtez de prendre en charge les anciennes versions d'Android, revenez à HTTP pour les anciennes versions d'Android ou passez à une autorité de certification installée sur ces anciennes versions.
Si vous obtenez des certificats Let's Encrypt via votre fournisseur d'hébergement
Votre fournisseur d'hébergement peut servir le DST Root X3 jusqu'en septembre 2021, ou il peut décider de passer à la chaîne de certificats menant à ISRG Root X1 après le 11 janvier 2021. Veuillez les contacter si vous avez des questions!
Si vous utilisez une ancienne version d'Android
Si vous utilisez une ancienne version d'Android, nous vous recommandons d' installer Firefox Mobile , qui prend en charge Android 5.0 et supérieur au moment de la rédaction.
Pourquoi l'installation de Firefox aide-t-elle? Pour le navigateur intégré d'un téléphone Android, la liste des certificats racine de confiance provient du système d'exploitation - qui est obsolète sur ces anciens téléphones. Cependant, Firefox est actuellement unique parmi les navigateurs - il est livré avec sa propre liste de certificats racine de confiance. Ainsi, toute personne qui installe la dernière version de Firefox bénéficie d'une liste à jour d'autorités de certification de confiance, même si son système d'exploitation est obsolète.
Nous apprécions votre compréhension et votre soutien, maintenant et au fil des ans, alors que nous continuons à grandir en tant qu'autorité de certification, en veillant à ce que les gens du monde entier aient accès au cryptage. Nous fournirons toutes les mises à jour futures sur la façon dont cette transition racine affecte les appareils Android via notre message sur le forum de la communauté (https://community.letsencrypt.org/t/transition-to-isrgs-root-delayed-until-jan-11-2021/125516). Notre communauté est toujours prête à vous aider si vous avez des questions sur ce changement: community.letsencrypt.org (https://community.letsencrypt.org/).
Nous dépendons des contributions de nos supporters pour fournir nos services. Si votre entreprise ou organisation souhaite parrainer Let's Encrypt, veuillez nous envoyer un e-mail à sponsor@letsencrypt.org. Nous vous demandons d'apporter une contribution individuelle si cela est dans vos moyens.
Si vous êtes un développeur d'applications
Si vous développez une application Android, vous pouvez envoyer une mise à jour qui ajoute ISRG Root X1 en tant que racine de confiance dans le contexte de votre application. Il y a une discussion sur les moyens de le faire dans ce fil de discussion du forum (https://community.letsencrypt.org/t/mobile-client-workarounds-for-isrg-issue/137807) et sur ce problème GitHub (https://github.com/square/okhttp/issues/6403).
Source: Let's Encrypt (https://letsencrypt.org/2020/11/06/own-two-feet.html), le 6 novembre 2020 par Jacob Hoffman-Andrews, traduit rapidement par Vivien.
-
Le "classique" problème de la fragmentation d'Android.
-
Enfin là c'est plus qu'un problème, ces version d'Android représentent entre 1 à 5% du trafic en fonction des sites web.
Savez-vous comment vérifier la liste des certificats sur un Smartphone Android ?
-
Seul l'utilisation de Firefox permettra aux versions d'Android antérieures à 7.1.1 d'avoir un accès aux très nombreux sites avec un certificat émis par Let's Encrypt : Firefox est actuellement le seul navigateur à livrer sa propre liste de certificats racine de confiance, elle est donc mise à jour en même temps que le navigateur.
Cela pourrait bientôt changer... Il y a eu une annonce officielle récemment du Chrome Root Program : https://groups.google.com/g/mozilla.dev.security.policy/c/3Q36J4flnQs/m/VyWFiVwrBQAJ (https://groups.google.com/g/mozilla.dev.security.policy/c/3Q36J4flnQs/m/VyWFiVwrBQAJ). On trouve aussi depuis quelques semaines la liste de pré-requis pour les autorités de certification (https://www.chromium.org/Home/chromium-security/root-ca-policy)
A voir, mais si Google est toujours en mesure de pousser des mises à jour de Chrome à ces appareils via le Play Store, cela pourrait changer en partie la donne.
-
Je me demande si cela sera mis dans les navigateurs par défaut (cela ne fait que quelques années que c'est Chrome qui est installé par défaut)
"Samsung Internet Browser" mis par exemple par défaut par Samsung est bien mis à jour via le play store (dernière mise à jour v 13.0.1.64 du 18 novembre 2020) pour un smartphone Samsung Galaxy S6 sous Android 7.0 mais vas-il intégrer les certificats ? (C'est bien un navigateur basé sur Chrome, mais Samsung intègre des correctifs sans forcément mettre à jour Chromium, la version du 18 novembre 2020 se base sur Chromium 83.0.4103, version du 19 mai 2020 !)
Maintenant le problème n'est pas que pour les navigateurs web, les applications ont également besoin du certificat ISRG Root X1 si les ressources https utilisent un certificat Let's Encrypt, ce qui est souvent le cas pour au moins une partie des ressources utilisées.
-
On a des détails sur les autres devices Android non téléphones ?
Je pense surtout aux TV, dont une très grande partie tourne sous Android. Bientôt les frigos ?
Quid des mises à jour de ces devices là ? J'imagine que c'est le même bordel que les téléphones, avec les constructeurs en intermédiaires entre Google et l'utilisateur final, et leurs fameuses surcouches ?
Car Vivien tu l'as bien précisé : Let's Encrypt n'impacte pas que le web pur (aka : la navigation de sites webs), mais toute API ou appli qui en interne a besoin d'appels https sur du Let's Encrypt, c'est à dire beaucoup d'appli (puisqu'aujourd'hui on a la bonne idée de tout encapsuler dans https, même du DNS c'est pour dire ...)
-
Le "classique" problème de la fragmentation d'Android.
Démontré plein de fois que ce n'est pas vraiment un "problème" et encore moins "classique" et au contraire une des forces d'Android qui lui a permis de prendre le dessus et de devenir l'OS mobile dominant. Apres y'a qu'a voir les parts de marché d'Android pour avoir la réponse. Mais on ne va pas refaire ce débat ici.
Le problème de sites n'ayant pas de certifs corrects ou pas adapté a leur visiteurs n'est pas du tout spécifique aux mobiles, j'en croise tout les jours avec un navigateur desktop.
C'est pour moi un faux problème que d'accuser le coté utilisateur/mobile alors que le coupable est du coté des sites web et services.
-
C'est pour moi un faux problème que d'accuser le coté utilisateur/mobile alors que le coupable est du coté des sites web et services.
J'ai un peu de mal à comprendre ta conclusion : c'est aux sites web de ne pas utiliser Let's Encrypt ?
-
J'ai un peu de mal à comprendre ta conclusion : c'est aux sites web de ne pas utiliser Let's Encrypt ?
oui bien sur si une partie significative de tes utilisateurs ont des appareils obsoletes et pas a jour tu t'adaptes a tes utilisateurs et pas l'inverse.
C'est le minimum quand on est pro. Tu ne vas leur dire: ben maintenant changer de smartphone sinon vous pourrez plus accéder a mon service parce que j'ai la flemme de changer mon certificat?
-
Moi j'aurais plutôt mis la faute sur Google, qui aurait du faire bien avant ce qu'il va faire pour Android 12 : Google va permettre d’installer facilement des mises à jour système en passant par le Play Store (project Mainline)
Désormais, Google est capable de déployer une mise à jour de sécurité via le Play Store de son propre chef, sans attendre Samsung, Xiaomi ou OnePlus.
On peut penser que la liste de certificats racine de confiance fera partie du lot qui sera dorénavant géré par Google et donc mis à jour pendant de nombreuses années (si j'ai bien compris Google envisage de le faire pour les émojis, afin de permettre aux utilisateurs de pouvoir bénéficier des dernières émoticônes bien plus rapidement, il serait donc incompréhensible que la mise à jour des émoticônes soit prise en charge et pas les certificats racine)
Un article sur le sujet : These Android users may need to change their phones to brows .. (https://timesofindia.indiatimes.com/gadgets-news/these-android-users-may-need-to-change-their-phones-to-browse-internet-smoothly/articleshow/79109262.cms)
-
Je cherche un site pour vérifier ISRG Root X1 avec un certificat valide.
J'ai pensé à https://valid-isrgrootx1.letsencrypt.org/ mais il a un double chemin ISRG Root X1 + DST Root X3 :
(https://lafibre.info/images/ssl/202012_valid-isrgrootx1_certification_paths.png)
Et donc cela fonctionne même avec Ubuntu 15.04 (installé sans aucune mise à jour) de façon a être certain de ne pas avoir ISRG Root X1 (impossible de l'avoir avant sa création)
Le Firefox ci-dessous passe donc par DST Root X3 pour valider le certificat :
(https://lafibre.info/images/ssl/202012_valid-isrgrootx1_ubuntu_1504.png)
-
oui bien sur si une partie significative de tes utilisateurs ont des appareils obsoletes et pas a jour tu t'adaptes a tes utilisateurs et pas l'inverse.
C'est le minimum quand on est pro. Tu ne vas leur dire: ben maintenant changer de smartphone sinon vous pourrez plus accéder a mon service parce que j'ai la flemme de changer mon certificat?
complètement d'accord !
-
A noter que le focus est sur LetsEncrypt qui change de racine et en profite pour 'accuser' Android et Google.
Il y a d'autres alternatives gratuites depuis, notamment européennes: ZeroSSL et Buypass.
ca prend moins d'une 1 minute pour un site qui aura des soucis avec Android 7 a quitter LetsEncrypt.
-
Je suis plutôt convaincu que les éditeurs de sites et que LE n'ont rien à se reprocher dans l'histoire : si ça n'avait pas été LE c'en aurait été un autre qui aurait eu le problème.
Le soucis c'est que les fabricants Android en ont rien à faire d'updater correctement leurs devices (et que c'est empêtré dans la chaîne OEM->Opérateur->Device pour certains), que Google a laissé faire ça pendant des années sans réellement en avoir quelque chose à faire. Les éditeurs de site n'y peuvent rien.
Dans les faits, même si pas trop à la porté de M/Mme Michu mais faisable, un certificat sur android ça s'installe en trois clics.
C'est quand même scandaleux de laisser autant de devices dans la nature sans aucune mise à jour de sécurité, c'est 100% de la faute des fabricants qui ont réussi à faire croire à leurs utilisateurs que "deux ans de mises à jour ça suffit amplement". Ton device devient une faille de sécurité ambulante et est amputé des derniers certificats, super.
Si on regarde la liste des certificats racines trustés par macOS 11, on y voit une pelletée de certificats qui expirent dans les mois à venir. Les smartphones Android auront le même problème, sauf si les autorités de certifications ciblées ont roll-out un nouveau certificat racine intégré dans ces devices avant 2016 (après vérif, ça a l'air d'être le cas : argument un peu bancal donc, en effet).
EDIT : La seule autorité de certif proposant gratuitement des wildcards, ça a quand même l'air d'être LE.
-
Je suis plutôt convaincu que les éditeurs de sites et que LE n'ont rien à se reprocher dans l'histoire : si ça n'avait pas été LE c'en aurait été un autre qui aurait eu le problème.
je pense que personne n'a dit le contraire.
Le soucis c'est que les fabricants Android en ont rien à faire d'updater correctement leurs devices (et que c'est empêtré dans la chaîne OEM->Opérateur->Device pour certains), que Google a laissé faire ça pendant des années sans réellement en avoir quelque chose à faire.
oui
Les éditeurs de site n'y peuvent rien.
??? ben si...
Dans les faits, même si pas trop à la porté de M/Mme Michu mais faisable, un certificat sur android ça s'installe en trois clics.
C'est quand même scandaleux de laisser autant de devices dans la nature sans aucune mise à jour de sécurité, c'est 100% de la faute des fabricants qui ont réussi à faire croire à leurs utilisateurs que "deux ans de mises à jour ça suffit amplement". Ton device devient une faille de sécurité ambulante et est amputé des derniers certificats, super.
oui oui on a bien compris, les fabricants sont rien que des vilains
Selon moi quand on achete de l'android de toute façon on sait bien que c'est du jetable a court terme non ?
mouarf !
-
C'est dingue cette inversion des responsabilités quand meme.
Si j'achete une bouse de smartphone a 200€ je n'attend pas que dans 5 ans elle fonctionne encore et je ne n'accuse pas le fabricant, Google ou qui sais-je de scandale.
C'est quand même scandaleux de laisser autant de devices dans la nature sans aucune mise à jour de sécurité,
J'attend toujours les témoignages nombreux de problèmes et autres pirateries a cause de ces millions de devices dans la nature sans aucune mise à jour de sécurité. Ce FUD a vite ses limites sans parler de ceux qui font un business avec ca (presse hitech, vendeurs de pseudo antivirus et autre bêtise du genre).
EDIT : La seule autorité de certif proposant gratuitement des wildcars, ça a quand même l'air d'être LE.
ZeroSSL aussi.
-
C'est dingue cette inversion des responsabilités quand meme.
Si j'achete une bouse de smartphone a 200€ je n'attend pas que dans 5 ans elle fonctionne encore et je ne n'accuse pas le fabricant, Google ou qui sais-je de scandale.
C'est vrai que c'est dingue cette inversion de responsabilité dans l'inversion de responsabilité.
Quand j'achète une "bouse de smartphone a 200€", il y a une date de péremption sur l'appareil?
Non?
Donc en tant que "Monsieur Michut", je m'attends à ce qu'il fonctionne ad-vitam.
-
C'est vrai que c'est dingue cette inversion de responsabilité dans l'inversion de responsabilité.
Quand j'achète une "bouse de smartphone a 200€", il y a une date de péremption sur l'appareil?
Non?
Donc en tant que "Monsieur Michut", je m'attends à ce qu'il fonctionne ad-vitam.
Ce qui est la cas pour les usages que tu avais quand tu l'a acheté. Tu n'attend quand meme pas a jouer aux jeux PS5 avec une PS4 ?
-
Dans ce cas, tout va bien.
J'avais compris que des choses qui marchaient lors de l'achat ne marchaient plus quelques années après...
-
C'est dingue cette inversion des responsabilités quand meme.
Si j'achete une bouse de smartphone a 200€ je n'attend pas que dans 5 ans elle fonctionne encore et je ne n'accuse pas le fabricant, Google ou qui sais-je de scandale.
Sauf erreur de ma part, il en est de même avec un smartphone haut de gamme vendu 800 €.
Avec mon S8, je suis passé de Android 7 à 9 et n'irais jamais plus haut malheureusement.
Il est quand même dommage d'avoir des smartphones limités à 2 ans de MAJ.
Alors certes pour le moment j'ai encore des MAJ de sécurité, mais plus pour longtemps il me semble.
Je te rejoinds sur le fait que les sites webs doivent s'adapter à leur clientèle, mais les constructeurs devraient aussi prévoir des MAJ applicatives pour les 4 à 5 ans qui suivent.
-
Samsung propose sur les smartphone haut de gamme deux version majeur d'Android (2 ans) puis encore deux ans de mise à jour de sécurité.
Le S8 est bloqué sur Android 9, mais reçois encore des mises à jour de sécurité (avec le ROM Bouygues Telecom on est sur le correctif du 1er octobre 2020 actuellement)
Par contre 2021 devrait signer la fin de maintenance du S8.
Sur le bas de gamme, les mises à jour sont plus réduites.
=> https://security.samsungmobile.com/workScope.smsb
Le Galaxy A7 version 2017, donc commercialisé encore en 2018 n'a déjà plus de mise à jour régulières.
Par contre, je me demande (j'aimerais vérifier) si les certificat racine sont mis à jour dans les mises à jour de sécurité distribuées par Samsung.
Apple, Google, Samsung, OnePlus, Motorola et Nokia sont les meilleurs élèves pour les smartphones.
Mention assez bien
Honor : Il y a régulièrement des patchs de sécurité, mais peu d'upgrade vers des versions plus récentes d'Android, notamment sur l'entrée de gamme.
Huawei : Les smartphones à moins de 200€ sont abandonnés et n'ont pas de mises à jour version une version plus récente d'Android.
Sony : Seul 16 des 26 smartphones observés ont des mises à jour. C'est le cas de certains mobiles récents comme le Xperia L3, L2 ou XA2.
Xiaomi : 19 de ses 25 portables fonctionnent sous Android 9, les mobiles d'entrée de gamme sont abandonnés (Redmi 6A et 5)
Mention passable : des marques à éviter si possible
Asus : Asus traîne des pieds, les mobiles commercialisés avec Android 6 sont mis à jour vers Android 7 pas plus, ceux commercialisés avec Android 7 sont mis à jour vers Android 8 pas plus,...
LG : LG est défaillant sur les mises à jour de sécurité : elles datent de plus d'un an sur certains appareils (Xcam, K10, Power 2)
Lenovo : Certains mobiles ont la dernière mises à jour de sécurité qui remontent à 2017 (exemple: le K6)
Bonnets d'âne : Des marques qui mettent en danger leurs utilisateurs (vulnérabilités aux attaques)
Alcatel : "Patchs de sécurité obsolètes, un seul smartphone qui a migré sur 15... Alcatel est un cancre."
Wiko : Seulement deux smartphones mis à jour vers la version suivante d'Android sur 19 testés. Les autres sont restés sur la versions dans lequel le smartphone a été commercialisé.
ZTE : Aucun smartphones mis à jour vers la version suivante d'Android et les patchs de sécurité sont anciens
Le classement des marques par catégorie est réalisé par UFC Que Choisir (article dans le N° 589, de mars 2020, actuellement en vente en kiosque).
-
Donc les gens comme moi, c'est à dire les gens "normaux" qui changent de téléphones tous les 10 ans ont des matériels non à jours...
Je vais finir par voter Greta ! ;) ::)
-
Merci Vivien pour la précision, je n'étais plus sûr des 2 années de MAJ de sécurité.
Vue le prix d'un bon smartphone et qu'il devient de plus en plus la base de la sécurité (accès au banque), je trouve ces durées de MAJ vraiment très/trop courtes.
On est face à une consommation de masse et une certaine obsolescence programmée.
À mon sens, il serait temps que l’Europe mette en place certaines obligations en la matière.
-
À mon sens, il serait temps que l’Europe mette en place certaines obligations en la matière.
C'est une des demandes qui est le plus revenu dans les ateliers pour un numérique soutenable : allonger la durée de mise à jour pour avoir comme le propose Microsoft 5 ans de mise à jour de fonctionnalité suivit de 5 ans de mises à jour de sécurité.
-
Donc les gens comme moi, c'est à dire les gens "normaux" qui changent de téléphones tous les 10 ans ont des matériels non à jours...
ben non, prend un iphone...
quoique 10 ans c'est quand meme bcp
-
Je peux prendre un iphone high top si dans 10 ans il marche encore...
Sinon, je prend une merde...
-
Par contre, je me demande (j'aimerais vérifier) si les certificat racine sont mis à jour dans les mises à jour de sécurité distribuées par Samsung.
Apple, Google, Samsung, OnePlus, Motorola et Nokia sont les meilleurs élèves pour les smartphones.
Bonjour Vivien,
J'ai un A5 (2017) que je n'utilise plus car je l'ai endommagé, mais je peux l'allumer, lui faire faire les MAJs et te donner la réponse si tu me dis comment faire.
Pour Motorola, ils ont annoncé ne pas prévoir de mise à jour vers Android 10 pour les smartphones (pas cher) sortis 2019 voire même 2020..
https://www.androidcentral.com/heres-when-your-motorola-phone-will-get-android-10-update
Similarly, the Moto E6 debuted last year with Android 9.0 Pie, and won't be getting the Android 10 update. Then there's the Moto E6s, a phone that launched in March 2020 with Android 9.0 Pie out of the box.
Certes le Moto E6S est surement un dérivé du E6 sorti à l'été 2019, mais du coup il n'aura jamais eu de mise à jour majeure. (après on est d'accord on parle de smartphones à 100/150 euro)
ça serait effectivement bien que Google ou un état/UE oblige les constructeurs à un minimum de MAJ pour les smartphones sortis ou carrément d'indiquer comme le DAS, sur la fiche produit, jusqu'à quand les MAJs sont prévues/garanties.
-
ça serait effectivement bien que Google ou un état/UE oblige les constructeurs à un minimum de MAJ pour les smartphones sortis ou carrément d'indiquer comme le DAS, sur la fiche produit, jusqu'à quand les MAJs sont prévues/garanties.
C'est la moindre des choses que d'indiquer aux couillons, pardon, aux honorables clients, la durée de vie de la merde, encore pardon, du merveilleux matériel qu'ils acquièrent à prix d'or et qu'ils se doivent de jeter aux ordures, ah caramba encore raté, au recyclage deux ans après maximum.
Merci Greta.
-
Je n'ai pas trouvé de solution simple pour savoir si un smartphone a ou non le certificat racine de Let's Encrypt.
J'ai fais une demande sur twitter (https://twitter.com/lafibreinfo/status/1335512861905399813), mais je n'ai pas eu de réponse
-
C'est la moindre des choses que d'indiquer aux couillons, pardon, aux honorables clients, la durée de vie de la merde, encore pardon, du merveilleux matériel qu'ils acquièrent à prix d'or et qu'ils se doivent de jeter aux ordures, ah caramba encore raté, au recyclage deux ans après maximum.
Merci Greta.
iPhone 6S, 5 ans d'âge sous iOS 14.2 soit le dernier en date et même après ça on a encore droit au maj de sécurité car j'ai encore sur un vieil iPad Air bloqué, lui, en 12.x.x mais qui a récemment reçu une maj de sécurité.
Par contre c'est sûr que ma tablette Samsung Galaxy Tab 7" GT-P3110 restera bloquée comme elle l'est depuis peu de temps après sa sortie, en Android 4.1 !
Donc même si on sait qu'aucun fabricant ne maintiendra ses OS 10 ans après leur sortie, il est clair que certains sont bien meilleurs que d'autres sur le sujet et notamment ceux qui fabriquent et vendent en direct leur propre système.
(Et non, ce message reste factuel, même si ça peux sembler pro Apple, ce que je reste malgré tout).
-
ça serait effectivement bien que Google ou un état/UE oblige les constructeurs à un minimum de MAJ pour les smartphones sortis ou carrément d'indiquer comme le DAS, sur la fiche produit, jusqu'à quand les MAJs sont prévues/garanties.
C'est la moindre des choses que d'indiquer aux couillons, pardon, aux honorables clients, la durée de vie de la merde, encore pardon, du merveilleux matériel qu'ils acquièrent à prix d'or et qu'ils se doivent de jeter aux ordures, ah caramba encore raté, au recyclage deux ans après maximum.
Merci Greta.
d'accord mais tu dois faire cela pour tout les produits électroniques connectés (consoles, tv, pc, etc) et pas que les smartphones sinon c'est discriminant et surement anticonstitutionnel
-
d'accord mais tu dois faire cela pour tout les produits électroniques connectés (consoles, tv, pc, etc) et pas que les smartphones sinon c'est discriminant et surement anticonstitutionnel
Ça me parait sage et logique.
J'ai une télé qui a 10 ans; elle va marcher encore 10 ans sans problèmes avec ou sans mise à jour...
-
Ça me parait sage et logique.
J'ai une télé qui a 10 ans; elle va marcher encore 10 ans sans problèmes avec ou sans mise à jour...
ben pourtant toutes les TV n'ont plus marché quand on est passé a la TNT v2... tout le monde a du acheter un nouveau décodeur tnt oui une nouvelle TV.
-
J'ai un petit PC et un déco Sat CGV qui permette de pérenniser la TV...
-
Oui mais tu n'es ni Mme Michu ni Mr Michut ;)
-
Je n'ai pas trouvé de solution simple pour savoir si un smartphone a ou non le certificat racine de Let's Encrypt.
https://valid-isrgrootx1.letsencrypt.org présente bien une chaîne de certificats avec ISRG Root X1.
~ ᐅ openssl s_client -connect valid-isrgrootx1.letsencrypt.org:443
CONNECTED(00000003)
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = valid-isrgrootx1.letsencrypt.org
verify return:1
---
Certificate chain
0 s:CN = valid-isrgrootx1.letsencrypt.org
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
Quand Firefox indique une chaîne avec "DST Root CA X3", c'est à priori qu'il a un "Let's Encrypt Authority X3" signé par celui-ci quelque part :
- dans la liste des certificats (soit fourni avec Firefox, soit système) : à vérifier dans les options
- en cache (il suffit d'avoir visité un site ayant fourni le certificat en question) : avec "firefox -ProfileManager", on peut créer un nouveau profil et ne charger que https://valid-isrgrootx1.letsencrypt.org
L'ennui pour le test est qu'il n'existe pas d'autorité intermédiaire non cross-signée, à part les futures Let's Encrypt E1/E2 qui sont en ECDSA (un autre problème potentiel pour les systèmes non mis à jour, je ne sais pas quelles sont les versions minimales pour tout bien supporter), qui ne sont pas encore utilisées.
On ne peut pas non plus avancer la date au delà de la validité de "DST Root CA X1", parce que c'est trop loin (les certificats émis par Let's Encrypt ne sont valides que 90 jours).
-
https://valid-isrgrootx1.letsencrypt.org présente bien une chaîne de certificats avec ISRG Root X1....
C'est aussi bien en français (https://letsencrypt.org/fr/) ! ;)
-
C'est aussi bien en français (https://letsencrypt.org/fr/) ! ;)
Non, letencrypt.org présente une chaîne de certificats avec DST Root CA X3, donc qui ne permet pas de tester ce qui se passera une fois que cette racine ne sera plus valide, et qu'il faudra obligatoirement utiliser ISRG Root X1.
La configuration recommandée actuelle est d'utiliser DST Root CA X3, mais à partir de janvier certains sites basculeront sur ISRG Root X1, et en septembre tout le monde devra l'avoir fait.
-
L'ennui pour le test est qu'il n'existe pas d'autorité intermédiaire non cross-signée, à part les futures Let's Encrypt E1/E2 qui sont en ECDSA (un autre problème potentiel pour les systèmes non mis à jour, je ne sais pas quelles sont les versions minimales pour tout bien supporter), qui ne sont pas encore utilisées.
Merci, je comprends mieux pourquoi il n'y a pas de site de test.
Quand Firefox indique une chaîne avec "DST Root CA X3", c'est à priori qu'il a un "Let's Encrypt Authority X3" signé par celui-ci quelque part :
- dans la liste des certificats (soit fourni avec Firefox, soit système) : à vérifier dans les options
- en cache (il suffit d'avoir visité un site ayant fourni le certificat en question) : avec "firefox -ProfileManager", on peut créer un nouveau profil et ne charger que https://valid-isrgrootx1.letsencrypt.org
Mon souhait n'est pas de vérifier un Firefox de 2015, mais des smartphone Android < 7.1 pour lesquels il y a eu des mises à jour de sécurité, afin de voir si les mises à jour de sécurité ont mis à jour le certificat racine.
Je vais voir ce qu'affichent Chrome et d'autre navigateurs sur un ancien Android.
-
Tu peux utiliser un produit comme browserstack.com pour tester une url sur plusieurs appareils. La version gratuite donne tres peu de temps par device donc faut pas trainer...
(https://i.imgur.com/zAXABvg.png)
voila sur un Moto x 2nd gen android 6:
(https://i.imgur.com/661lQCD.png)
Sony Xperia Z5 Android 5:
(https://i.imgur.com/r52U5Dz.png)
-
Mais là logiquement si on charge letsencrypt.org avant, ça devrait passer grâce au cache (mais pas après septembre bien sûr).
-
J'ai fait des tests avec mon Samsung Galaxy S6 Edge, smartphone haut de gamme lancé en 2015 et livré avec Android 5.0.2 "Lollipop".
Il a eu le droit aux mises à jour vers Android 6.0.1 "Marshmallow" en 2016 et Android 7.0. "Nougat" en 2017.
Il a ensuite eu des mises à jour de sécurité jusqu'en juin 2018.
Cela fait un total de 3 ans de mise à jour de sécurité.
Voici les informations sur le logiciel :
(https://lafibre.info/images/ssl/202012_samsung_galaxy_s6_edge.png)
Toutes les applications du Smartphone sont dans leur dernière version disponibles, on est donc avec Google Chrome 87 :
(https://lafibre.info/images/ssl/202012_google_chrome_3.png)
Voici ce que donne la page de test https://valid-isrgrootx1.letsencrypt.org/ avec Google Chrome 87 avec Android 7.0 + maj de sécurité jusqu'en juin 2018 :
(https://lafibre.info/images/ssl/202012_google_chrome_1.png) (https://lafibre.info/images/ssl/202012_google_chrome_2.png)
SI je comprends bien, les mises à jour de sécurité jusqu'en juin 2018 n'ont pas mis à jour la liste de certificats racine de confiance ? Pourquoi ?
Autre question, le certificat utilisé a un double chemin ISRG Root X1 + DST Root X3 donc je ne comprends pas qu'il n'utilise pas le chemin alternatif, comme le fait bien un Firefox de 2015 sous Ubuntu 15.04.
(https://lafibre.info/images/ssl/202012_valid-isrgrootx1_certification_paths.png)
-
Après avoir mis en cache le certificat valide en visitant LaFibre.info + reboot du téléphone, cela semble bien fonctionner. (Sans redémarrage du téléphone, je reste avec l'erreur)
A gauche Google Chrome 87, à droite le dernier version de Samsung Internet, la version 13.0.1.64 du 18 novembre 2020 qui se base sur Chromium 83 !
(https://lafibre.info/images/ssl/202012_google_chrome_4.png) (https://lafibre.info/images/ssl/202012_samsung_internet_1.png)
Après avoir supprimé toutes les données + cache de Samsung Internet via les paramètres Android :
(https://lafibre.info/images/ssl/202012_samsung_internet_2.png) (https://lafibre.info/images/ssl/202012_samsung_internet_3.png)
-
Si je comprends bien, les mises à jour de sécurité jusqu'en juin 2018 n'ont pas mis à jour la liste de certificats racine de confiance ? Pourquoi ?
Il faudrait demander à Google...
En regardant https://android.googlesource.com/platform/system/ca-certificates/+log/c36d8eb8071d73528993e024e73d40c6977b1d0d, on voit qu'aucune mise à jour de sécurité d'Android 7.0 (y compris jusqu'en mars 2019, Android 7.0.0 Release 36 (NBD92Y)) n'a mis à jour les certificats racine.
Le commit qui a ajouté ISRG Root X1, en aout 2016 (https://android.googlesource.com/platform/system/ca-certificates/+/51300a813051dcaaf3dc07000e92ed40a27a2b21), n'est effectivement disponible qu'en Android 7.1.
Autre question, le certificat utilisé a un double chemin ISRG Root X1 + DST Root X3 donc je ne comprends pas qu'il n'utilise pas le chemin alternatif, comme le fait bien un Firefox de 2015 sous Ubuntu 15.04.
Je ne vois pas trop comment ferait Firefox, il y a des chances que ça soit un cache.
Comme j'ai expliqué, tu peux vérifier la liste des autorités acceptées par Firefox (une combinaison de celles qui sont intégrées, et celles du système), et lancer avec un nouveau profil.
Après avoir mis en cache le certificat valide en visitant LaFibre.info + reboot du téléphone, cela semble bien fonctionner. (Sans redémarrage du téléphone, je reste avec l'erreur)
Petit détail : c'est le certificat intermédiaire "Let's Encrypt Authority X3" (sa version signée par DST Root CA X3) qui est en cache, pas le certificat racine (ISRG Root X1) auquel le navigateur ne fait toujours pas confiance.
Sinon, redémarrer l'application, voire fermer l'onglet et en ouvrir un nouveau, devrait être suffisant.
En tout cas on voit bien la difficulté que peut poser ce genre de tests, mais ce n'est pas nouveau : un serveur web mal configuré qui enverrait uniquement son certificat (sans les certificats des autorités intermédiaire) aurait le même type de comportement en fonction du cache. Autant c'est probablement rare sur internet, autant sur les intranet des entreprises c'est plus courant.
-
Je ne vois pas trop comment ferait Firefox, il y a des chances que ça soit un cache.
Comme j'ai expliqué, tu peux vérifier la liste des autorités acceptées par Firefox (une combinaison de celles qui sont intégrées, et celles du système), et lancer avec un nouveau profil.
Le navigateur ne peut pas utiliser le chemin alternatif tant qu'il est valide ? (en septembre 2021 ce second chemin ne devrait plus exister)
Dans ma copie d'écran de SSL Labs, c'est le Path#2
(https://lafibre.info/images/ssl/202012_valid-isrgrootx1_certification_paths.png)
Quand Firefox indique une chaîne avec "DST Root CA X3", c'est à priori qu'il a un "Let's Encrypt Authority X3" signé par celui-ci quelque part :
- dans la liste des certificats (soit fourni avec Firefox, soit système) : à vérifier dans les options
- en cache (il suffit d'avoir visité un site ayant fourni le certificat en question) : avec "firefox -ProfileManager", on peut créer un nouveau profil et ne charger que https://valid-isrgrootx1.letsencrypt.org
Pour être sur que ni le système, ni Firefox n'a le certificat n'intègre le certificat racine de Let's Encrypt ISRG Root X1, j'ai mis en place une machine virtuelle Ubuntu 15.04 d'avril 2015. Ubuntu 15.04 n'est plus dans les dépôts, aucune mise à jour n'est possible et ne peut pas intégrer ISRG Root X1 qui n'existait pas encore en avril 2015.
Pour le cache, j'ai juste été sur LaFibre.info pour récupérer l'URL de test, donc par précaution j'ai supprimé le profil de Firefox (~/.mozilla) après avoir enregistré l'URL de test dans un fichier texte. Ensuite, je lance le Firefox 37 tout neuf et je copie / colle l'URL depuis mon fichier texte, mais il accepte bien le site https://valid-isrgrootx1.letsencrypt.org/
(https://lafibre.info/images/ssl/202012_valid-isrgrootx1_ubuntu_1504_2.png)
-
En fait il y a un mécanisme que j'ignorais, et qui est probablement supporté par Firefox (mais peut-être pas les navigateurs mobiles).
Dans le certificat serveur de valid-isrgrootx1.letsencrypt.org, il y a :
Authority Information Access:
OCSP - URI:http://ocsp.int-x3.letsencrypt.org
CA Issuers - URI:http://cert.int-x3.letsencrypt.org/
Et http://cert.int-x3.letsencrypt.org/ fournit (en format DER) le certificat de "Let's Encrypt Authority X3" signé par "DST Root CA X3".
Ils n'évoquent pas ce serveur, donc je ne sais pas quand ils vont lui faire retourner le certificat signé par "ISRG Root X1".
-
J'ai fait des tests avec mon Samsung Galaxy S6 Edge, smartphone haut de gamme lancé en 2015 et livré avec Android 5.0.2 "Lollipop".
Il a eu le droit aux mises à jour vers Android 6.0.1 "Marshmallow" en 2016 et Android 7.0. "Nougat" en 2017.
Il a ensuite eu des mises à jour de sécurité jusqu'en juin 2018.
Cela fait un total de 3 ans de mise à jour de sécurité.
Incroyable, je viens de recevoir une mise à jour pour mon Samsung Galaxy S6 Edge sous Android 7 :
(https://lafibre.info/images/ssl/202012_samsung_galaxy_s6_edge_maj1.png) (https://lafibre.info/images/ssl/202012_samsung_galaxy_s6_edge_maj2.png)
-
Voici les informations sur le logiciel.
Je découvre des mises à jour qui ne changent rien au niveau de correctif sécu d'Android qui reste au 1er 2018 !
En fait, je me demande ce que cette mise à jour de 2020 apporte.
ASKS évolue de la version1.4 à la version 1.4.5, ce serait la raison de la mise à jour ?
à gauche la mise à jour 2018, à droite la mise à jour 2020.
(https://lafibre.info/images/ssl/202012_samsung_galaxy_s6_edge.png) (https://lafibre.info/images/ssl/202012_samsung_galaxy_s6_edge_maj.png)
-
Navigateur par défaut, Samsung Internet version 13.0.1.64, basé sur Chrome 83, toujours pas de confiance dans le certificat racinde de Let's Encrypt ISRG Root X1 :
(https://lafibre.info/images/ssl/202012_samsung_internet_4.png) (https://lafibre.info/images/ssl/202012_samsung_internet_5.png)
Let's Encrypt Autority X3 est le plus haut niveau : A noter qu'il a été émis par «ISRG Root X1» et été émis le 6/10/2016 (la date sera différent avec Chrome)
(https://lafibre.info/images/ssl/202012_samsung_internet_6.png) (https://lafibre.info/images/ssl/202012_samsung_internet_7.png)
-
Pour Chrome, je n'arrive plus à avoir d'erreur, ce serait lié a la version de Chrome qui a évoluée et Chrome 87 serait en mesure d'aller chercher le second chemin dans la chaîne des certificats, comme un vieux Firefox de 2015 non mis à jour ?
En regardant le certificat, je note que la racine est toujours le certificat «DST Root X3» d'IdenTrust (durée de validité de 21ans, rien que ça), donc on va avoir un problème mi-2021 sur ce téléphone.
Le certificat intermédiaire, le Let's Encrypt Authority X3 a été émis le 17 mars 2016 (il expire le 17 mars 2021) car il a été émis par «DST Root CA X3» alors qu'avec Samsung Internet le Let's Encrypt Authority X3 a été émis le 6/10/2016 et expire le 6/10/2021. Pourquoi une telle différence ?
(https://lafibre.info/images/ssl/202012_google_chrome_cert1.png) (https://lafibre.info/images/ssl/202012_google_chrome_cert2.png)
-
Même capture avec la même version de Chrome, mais avec un Samsung Galaxy s8 sous Android 9 :
- le certificat racine utilisé est le certificat de Let's Encrypt «ISRG Root X1»
- le certificat intermédiaire, le Let's Encrypt Authority X3 a été émis par «ISRG Root X1» et été émis le 6 octobre 2016 (il expire le 6 octobre 2021)
(https://lafibre.info/images/ssl/202012_google_chrome_cert3.png) (https://lafibre.info/images/ssl/202012_google_chrome_cert4.png)
-
Le plus simple dans cette histoire, serait de faire une app/tuto pour ajouter manuellement le certificat racine ISRG Root X1, non ?
-
Le plus simple dans cette histoire, serait de faire une app/tuto pour ajouter manuellement le certificat racine ISRG Root X1, non ?
Bon ben, ça ne marche même pas.
Testé avec DigiCert, Github et un Android 4.3
-
Il faut que chaque application, en plus des navigateurs, intègrent le certificat de Let's Encrypt «ISRG Root X1» pour fonctionner sur Android 7.0 et plus ancien :
- Twitter
- Facebook
- SpeedTest
- ...
Bref, je pense que cela va être un carnage, beaucoup d’applications utilisant directement ou indirectement Let's Encrypt vont oublier et ne fonctionneront plus sous Androd 7.0 et inférieur.
-
Le plus simple dans cette histoire, serait de faire une app/tuto pour ajouter manuellement le certificat racine ISRG Root X1, non ?
Ca dépend des versions d'Android, mais à priori avec Android 7 par défaut les applications ne font pas confiance aux certificats utilisateur.
Pour modifier les certificats système, il faut rooter.
-
L'ouverture des liens web dans les applications peut se faire via la fonctionalité "Chrome Custom Tabs", auquel cas si Chrome intègre ISRG Root X1 ça suffit.
Pour les WebView, hors AOSP elles sont soit fournies par Chrome indirectement, ou "Android System Webview" sur le play store.
Le problème est surtout pour les applications qui font des requêtes elles-mêmes, tout dépend quels sont les certificats utilisés pour les services qu'elles utilisent.
-
Let's Encrypt annonce avoir trouvé une solution pour prolonger le support de ses certificats dans Android < 7.1.1. Son partenaire IdenTrust va émettre un certificat croisé pour signer le certificat de Let'sEncrypt ISRG Root X1, qui va étendre de 3 ans la validité des certificats de Let's Encrypt sur ces systèmes :
Extending Android Device Compatibility for Let's Encrypt Certificates
Dec 21, 2020 • Josh Aas and Aaron Gable
We’re happy to announce that we have developed a way for older Android devices to retain their ability to visit sites that use Let’s Encrypt certificates after our cross-signed intermediates expire. We are no longer planning any changes in January that may cause compatibility issues for Let’s Encrypt subscribers.
....
IdenTrust has agreed to issue a 3-year cross-sign for our ISRG Root X1 from their DST Root CA X3. The new cross-sign will be somewhat novel because it extends beyond the expiration of DST Root CA X3. This solution works because Android intentionally does not enforce the expiration dates of certificates used as trust anchors. ISRG and IdenTrust reached out to our auditors and root programs to review this plan and ensure there weren’t any compliance concerns.
As such, we will be able to provide subscribers with a chain which contains both ISRG Root X1 and DST Root CA X3, ensuring uninterrupted service to all users and avoiding the potential breakage we have been concerned about.
...
https://letsencrypt.org/2020/12/21/extending-android-compatibility.html
-
C'est une bonne nouvelle, ces 3 ans vont permettre d'avoir une partie importante des Andoird 7.0 est plus anciens soient renouvelées.
Cela laisse le temps à Chrome d'intégrer son propre magasin de certificat et aux fabricants de terminaux de proposer une mise à jour spéciale pour rajouter les racines nécessaires, même si cela à peu de chance de se produire.
-
C'est légèrement HS, mais il est tout à fait possible de mettre à jour les certificats sur XP, même si ce n'est pas très recommandé de surfer avec, pour dépanner ça marche très bien. Et Chrome reconnaît à priori bien le nouveau cerificat ISRG Root X1.
Pour ce faire, un petit utilitaire a été créé : https://msfn.org/board/topic/175170-root-certificates-and-revoked-certificates-for-windows-xp/page/3/?tab=comments#comment-1110568
-
Cela laisse le temps à Chrome d'intégrer son propre magasin de certificat et aux fabricants de terminaux de proposer une mise à jour spéciale pour rajouter les racines nécessaires, même si cela à peu de chance de se produire.
T'a cru au vieux gars barbu habillé en rouge qui est passé avant-hier soir durant ton repas de noel ? ^^
-
L'absence de mise à jour devient un point de plus en plus remonté comme un facteur qui incite au renouvellement et donc au gaspillage de ressources énergétiques et il y pourrait y avoir des obligations légales pour les smartphones commercialisés en Europe.
Bien sur cela ne s'appliquerait qu'au nouveaux terminaux, mais certaines marques pourraient y voir un facteur de différentiation face à la colère qui monte et on pourrait imaginer que rapidement, comme le nombre de Go de stockage, le nombre d'année de support soit dans les caractéristiques techniques, que ce soit à l'initiative des distributeurs ou des fabricants.
De même si cette fin de vie d'Android 7.0 et inférieur fait du bruit, on pourrait imaginer une petite mise à jour de certains fabricants pour intégrer le certificat Let'sEncrypt ISRG Root X1. Il ne faut pas croire que cela demande un travail monstrueux que de déployer une mise à jour qui rajoute uniquement ISRG Root X1.
-
Tout le monde connait le soucis de l'obsolescence programmée... et peu d'entreprises se sont attelés à le faire.
Vois tu des FAIRPHONE à 5% de part de marché ? Bah non quand on annonce que le WIKO le plus vendu à 119€ fait 349€ chez cet opérateur ca calme direct !
Vois t-on FX avoir une version android 4.4.X ?
-
Fairphone c'est bien la marque qui a sorti un modèle complètement obsolète niveau perf, puis un nouveau qui n'est en aucun cas compatible avec le premier ? Si vous voulez faire un geste pour la planète, achetez un iPhone !
-
Le soucis c'est qu'il est peu utile de payer 3 fois plus cher pour garder un android 2.3.5 avec des pieces détachées dispo 10 ans.
-
Le tout obsolète à sa sortie. Alors 10 ans plus tard...
-
Le tout obsolète à sa sortie. Alors 10 ans plus tard...
J'aime bien le coté antiquaire.
D'ailleurs, si j'avais acheté le premier iphone, je l'utiliserais encore...
https://www.ebay.fr/itm/iPhone-1-premiere-generation-/202999487911?_trksid=p2385738.m4383.l4275.c10
-
Mouais pour moi les gens les plus pollueurs sont ceux qui ont des IPhones et pas forcement a cause de l'IPhone... mais plus a cause de leur niveau de vie. :P
l'écologie c'est comme la sécurité informatique faut voir le tout et pas qu'une petite partie.
-
Un mois après mes tests il y a eu des mises à jour de Chrome et j'ai voulu vérifier si une solution avait été mise en place pour que ISRG Root X1 soit accepté (même si on sait maintenant qu'on a trois ans supplémentaire pour trouver une solution)
La version de Chrome utilisée pour ces tests :
(https://lafibre.info/images/ssl/202101_android7_google_chrome87_01.png)
La page https://valid-isrgrootx1.letsencrypt.org/ est inaccessible, sur un portable réinitialisé avant le test + installation de toutes les mises à jour possible (Samsung et Play strore)
(https://lafibre.info/images/ssl/202101_android7_google_chrome87_02.png) (https://lafibre.info/images/ssl/202101_android7_google_chrome87_03.png)
Quand nous allons dans l'URL :
(https://lafibre.info/images/ssl/202101_android7_google_chrome87_04.png) (https://lafibre.info/images/ssl/202101_android7_google_chrome87_05.png)
-
La chaîne de certification du site :
(https://lafibre.info/images/ssl/202101_android7_google_chrome87_06.png)
(https://lafibre.info/images/ssl/202101_android7_google_chrome87_07.png) (https://lafibre.info/images/ssl/202101_android7_google_chrome87_08.png)
-
Quand on ignore les alertes de sécurités :
(https://lafibre.info/images/ssl/202101_android7_google_chrome87_09.png) (https://lafibre.info/images/ssl/202101_android7_google_chrome87_10.png)
Il est possible de retirer l'autorisation d'utiliser un certificat non valide :
(https://lafibre.info/images/ssl/202101_android7_google_chrome87_11.png)
-
Même test, cette fois-ci avec le navigateur par défaut sur les mobiles Samsung : Samsung Internet version 13.0.2.9 (version du 11 décembre 2020)
(https://lafibre.info/images/ssl/202101_android7_samsung_internet_1.png) (https://lafibre.info/images/ssl/202101_android7_samsung_internet_2.png)
(https://lafibre.info/images/ssl/202101_android7_samsung_internet_3.png) (https://lafibre.info/images/ssl/202101_android7_samsung_internet_4.png)
-
Cela pourrait bientôt changer... Il y a eu une annonce officielle récemment du Chrome Root Program : https://groups.google.com/g/mozilla.dev.security.policy/c/3Q36J4flnQs/m/VyWFiVwrBQAJ (https://groups.google.com/g/mozilla.dev.security.policy/c/3Q36J4flnQs/m/VyWFiVwrBQAJ). On trouve aussi depuis quelques semaines la liste de pré-requis pour les autorités de certification (https://www.chromium.org/Home/chromium-security/root-ca-policy)
A voir, mais si Google est toujours en mesure de pousser des mises à jour de Chrome à ces appareils via le Play Store, cela pourrait changer en partie la donne.
J'ai profité d'un webinar Google France sur Chrome organisé aujourd'hui pour poser la question dans quand arriverait Chrome avec sa propre liste de certificats racine de confiance.
Je n'ai pas eu de date, mais un chantier important et pas que pour la problématique Let's Encrypt, également pour des systèmes d'exploitation qui ont des certificats pour intercepter le trafic https. Une liste de certificats racine de haute qualité sont aujourd'hui nécessaire.
-
Le certificat racine de Let's Encrypt expire !
Le 30 septembre 2021, le certificat racine que Let's Encrypt utilise actuellement, le certificat IdentTrust DST Root CA X3, expirera. Je parie que certaines choses vont probablement casser ce jour-là, alors voici ce que vous devez savoir !
C'est une longue histoire
Tous les certificats qui alimentent HTTPS sur le Web sont émis par une autorité de certification, une organisation de confiance reconnue par votre appareil/OS. Ces certificats sont intégrés à votre système d'exploitation et sont généralement mis à jour dans le cadre du processus normal de mise à jour de votre système d'exploitation. Le certificat ici qui va poser problème est celui-ci, IdenTrust DST Root CA X3.
(https://lafibre.info/images/ssl/202012_google_chrome_cert2.png)
Comme vous pouvez le voir, le temps presse et nous nous rapprochons de la date d'expiration du 30 septembre 2021 mais ce n'est pas seulement une date d'expiration, c'est un horodatage d'expiration : Not After : Sep 30 14:01:15 2021 GMT
Une fois cette autorité de certification racine expirée, les clients, comme les navigateurs Web, ne feront plus confiance aux certificats émis par cette autorité de certification.
La fin est proche!
Ce ne sera pas la première fois qu'un certificat CA racine expirera et j'imagine qu'il suivra la même tendance que les expirations précédentes où les choses se cassent. Si le certificat racine sur lequel votre chaîne de certificats est ancrée a expiré, il y a de fortes chances que cela entraîne un échec. Cela s'est produit l'année dernière, le 30 mai à 10:48:38 GMT 2020 pour être exact, lorsque la racine CA externe AddTrust a expiré et a emporté un tas de choses avec elle. Des organisations comme Roku (https://support.roku.com/en-gb/article/360049417393), Stripe (https://twitter.com/stripestatus/status/1266756286734938116), Spreedly (https://twitter.com/SpreedlySupport/status/1266706205570981888) et bien d'autres ont eu des problèmes et elles n'étaient pas les seules, même RedHat (https://access.redhat.com/articles/5117881) avait quelque chose à dire sur l'événement.
Dans des circonstances normales, cet événement, l'expiration d'une autorité de certification racine, ne vaudrait même pas la peine d'être évoqué car la transition d'un ancien certificat racine vers un nouveau certificat racine est totalement transparente. La raison pour laquelle nous avons un problème est que les clients ne sont pas mis à jour régulièrement et si le client n'est pas mis à jour, la nouvelle autorité de certification racine qui remplace l'ancienne autorité de certification racine expirée n'est pas téléchargée sur l'appareil.
Let's Encrypt a grandi
Au cours de la dernière année seulement, Let's Encrypt a considérablement augmenté sa part de marché et à mesure qu'une autorité de certification devient plus grande, ses certificats permettent à une plus grande partie du Web de fonctionner et, par conséquent, lorsque quelque chose comme cela se produit, ils ont le potentiel de causer plus de problèmes. Cela n'a rien à voir avec ce que Let's Encrypt a fait ou n'a pas fait, cela revient toujours au même problème sous-jacent que les appareils de l'écosystème ne sont pas mis à jour comme ils devraient l'être.
Compte tenu de la différence de taille relative entre Let's Encrypt et AddTrust, j'ai le sentiment que l'expiration de la racine IdenTrust peut potentiellement causer plus de problèmes. Personne ne sait vraiment à quel point cela pourrait être un problème, cela pourrait avoir des conséquences similaires à l'expiration d'AddTrust, ou il pourrait y avoir des circonstances imprévues et cela pourrait être bien pire, votre supposition est aussi bonne que la mienne.
Que fait Let's Encrypt à ce sujet ?
Comme je l'ai dit ci-dessus, ce problème ne se produit pas à cause de tout ce que Let's Encrypt a fait ou n'a pas fait, cela se produit parce que tous les certificats finissent par expirer et si les appareils ne sont pas mis à jour, ils ne recevront pas les nouveaux certificats de remplacement. Cela dit, Let's Encrypt ne s'est pas assis et s'est tourné les pouces à l'approche de la date d'expiration, ils ont travaillé dur pour essayer de trouver une solution.
En avril 2019, j'ai écrit Let's Encrypt prévoit de passer à la racine ISRG (https://scotthelme.co.uk/lets-encrypt-to-transition-to-isrg-root/), où Let's Encrypt avait prévu de passer de la racine IdenTrust à sa propre racine, ISRG Root X1, qui expire le 4 juin 2035, ce qui nous donne un certain nombre d'années. Le problème était que peu d'appareils avaient reçu les mises à jour nécessaires qui incluent ce nouveau ISRG Root X1, publié 4 ans auparavant en 2015 ! Si un grand nombre d'appareils n'ont pas reçu de mise à jour pour inclure ce nouveau certificat racine, ils ne lui feront tout simplement pas confiance. Il s'agit essentiellement du même problème que nous rencontrons actuellement avec l'expiration de la racine IdenTrust, car les périphériques clients n'ont pas été mis à jour, ils n'ont pas non plus reçu la nouvelle racine ISRG X1. La transition a été reportée.
En septembre 2020 je devais écrire un autre article, Let's Encrypt reporte la transition ISRG Root (https://scotthelme.co.uk/lets-encrypt-postpone-isrg-root-transition/), pour expliquer, pour la troisième fois, que Let's Encrypt avait à nouveau reporté la transition. Ils ont cité les préoccupations suivantes : "En raison de préoccupations concernant la propagation insuffisante de la racine ISRG sur les appareils Android, nous avons décidé de déplacer la date à laquelle nous commencerons à servir une chaîne à notre propre racine au 11 janvier 2021."
Cela se traduit vaguement par le fait que les appareils Android n'ont pas reçu de mise à jour depuis plus de 4 ans, ce qui signifie que ces appareils n'avaient toujours pas reçu l'ISRG Root X1, ce qui signifie qu'ils ne lui feraient pas confiance. Let's Encrypt ne peut pas passer à l'émission à partir de la nouvelle racine, mais la racine IdenTrust a encore 1 an de vie et le temps presse maintenant.
En fin de compte, quelque chose d'un peu inattendu s'est produit qui pourrait simplement réduire l'impact grave de cet événement et le rendre un peu plus acceptable. Étant donné que les anciens appareils Android ne vérifient pas la date d'expiration d'un certificat racine lorsqu'ils l'utilisent, Let's Encrypt peut continuer à se connecter au certificat racine expiré sans aucun problème sur ces appareils plus anciens. Cela introduit une certaine complexité à l'avenir, mais en fin de compte, l'objectif est d'étendre la compatibilité des appareils Android pour les certificats Let's Encrypt (https://letsencrypt.org/2020/12/21/extending-android-compatibility.html).
Pour que cela fonctionne, Let's Encrypt a dû obtenir une signature croisée pour son propre certificat racine ISRG X1 de la racine CA X3 IdenTrust DST expirée, mais cela n'aiderait pas du tout à moins que la racine à signature croisée ne soit valide plus longtemps que le racine de signature, ce qui est le cas. Le nouveau certificat ISRG Root X1 est valide plus longtemps que l'IdenTrust DST Root CA X3 qui l'a signé !
Comme nous le savons maintenant, le IdenTrust DST Root CA X3 expire le 30 septembre 2021, mais le nouveau ISRG Root X1 avec signature croisée n'expire que le 30 septembre 2024 !
En étendant la validité de la nouvelle racine à signature croisée au-delà de celle de la racine de signature, Let's Encrypt a trouvé un moyen de contourner les règles et de nous acheter 3 ans supplémentaires jusqu'à ce que ce problème se reproduise. Certaines personnes ne sont pas satisfaites du jeu sournois, mais il semble que cela respecte les règles, même si ce n'est peut-être pas ce que tout le monde aurait attendu ou préféré. Cette nouvelle racine ISRG X1 à signature croisée (https://community.letsencrypt.org/t/production-chain-changes/150739) ne doit pas non plus être confondue avec la racine ISRG X1 (https://censys.io/certificates/96bcec06264976f37460779acf28c5a7cfe8a3c0aae11a8ffcee05c0bddf08c6) existante qui n'a pas changé et plus de détails peuvent être trouvés ici (https://letsencrypt.org/2020/11/06/own-two-feet.html).
Espérons que cela aidera à atténuer de nombreux problèmes en attente, mais ce n'est pas une solution à tous les problèmes, car tout client qui applique la date d'expiration du certificat racine sur lequel il s'ancre échouera toujours.
Les clients affectés
L'un des clients notables qui sera toujours affecté par cette expiration dépend de la bibliothèque OpenSSL 1.0.2 ou antérieure, version 22 janvier 2015 et dernière mise à jour en tant qu'OpenSSL 1.0.2u le 20 décembre 2019. OpenSSL a publié un article de blog détaillant quelles mesures les personnes concernées peuvent prendre, mais elles nécessitent toutes une intervention manuelle pour éviter le blocage, tous les détails sont ici (https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/).
Le bref aperçu des options est :
1 Supprimez le certificat racine IdenTrust DST Root CA X3 et installez manuellement le certificat racine ISRG Root X1 (pas celui à signature croisée).
2 Si vous utilisez des commandes OpenSSL comme verifyou s_clientvous pouvez ajouter le --trusted_firstdrapeau si possible.
3 Demandez au serveur de servir une chaîne de certificats alternative qui va directement à la racine ISRG X1 (pas celle à signature croisée), mais cela cassera les appareils Android mentionnés ci-dessus.
Cette page de documentation de Let's Encrypt (https://letsencrypt.org/docs/certificate-compatibility/) contient une liste de clients qui font uniquement confiance au certificat IdenTrust DST Root CA X3 et ensuite se trouve la liste des plates-formes qui font confiance à ISRG Root X1. J'ai mélangé ces deux listes pour produire la liste suivante de clients qui seront incompatibles Let's Encrypt après l'expiration de IdenTrust DST Root CA X3.
Clients qui seront incompatibles Let's Encrypt à partir du 1er octobre 2021 :
- OpenSSL <= 1.0.2
- Windows < XP SP3
- macOS < 10.12.1
- iOS < 10 (l'iPhone 5 est le modèle le plus bas pouvant accéder à iOS 10)
- Android < 7.1.1 (mais >= 2.3.6 fonctionnera si le signe croisé ISRG Root X1 est servi)
- Mozilla Firefox < 50
- Ubuntu < 16.04
- Debian < 8
- Java 8 < 8u141
- Java 7 < 7u151
- NSS < 3,26
- Amazon FireOS (navigateur Silk)
Les plates-formes dont je ne suis toujours pas sûr et qui auront besoin d'une enquête plus approfondie pour voir si elles échoueront après l'expiration de IdenTrust DST Root CA X3 sont :
- Cyanogène > v10
- Jolla Sailfish OS > v1.1.2.16
- Kindle > v3.4.1
- Blackberry >= 10.3.3
- Console de jeu PS4 avec firmware >= 5.00
- IIS
La réponse à la question « que se passera-t-il lorsque la racine IdenTrust expire ? » dépend de l'étendue des types de clients énumérés ci-dessus. Je ne sais pas ce qui circule sur le Web, et je ne sais pas non plus ce qui dépend de ces choses. Une chose que je sais, cependant, c'est qu'au moins quelque chose, quelque part va se briser.
Mise à jour du 21 septembre 2021
J'ai ajouté IIS à la liste « incertain », car certains rapports [ 1 (https://twitter.com/webprofusion/status/1440125924427517954) ][ 2 (https://twitter.com/Collab_Seth/status/1440171169659834376) ] suggèrent qu'une intervention manuelle est nécessaire pour une transition en douceur.
Source : Scott Helme (https://scotthelme.co.uk/lets-encrypt-old-root-expiration/), chercheur en sécurité, entrepreneur et conférencier international, le 20 septembre 2021
Traduit et légérement raccourci par Vivien
-
Ce qui est gênant, c'est l'opposition entre les vieilles versions d'Android et OpenSSL 1.0.2.
Si le serveur envoie le ISRG Root X1 signé par DST Root CA X3 :
- Les vielles versions d'Android contiennent la racine DST Root CA X3, et ne vérifient pas son expiration, donc ça passe.
- Si la racine DST Root CA X3 est embarquée, OpenSSL 1.0.2 voit la chaîne avec une racine expirée et refuse, même si la racine ISRG Root X1 est présente.
Si le serveur envoie le ISRG Root X1 racine (ou juste le reste de la chaîne) :
- Les vielles versions d'Android n'embarquent pas la racine ISRG Root X1, donc la chaîne est invalide.
- OpenSSL 1.0.2 fonctionne si la racine ISRG Root X1 est embarquée.
-
On a toujours deux chaînes de certification, pour permettre la compatibilité :
(https://lafibre.info/images/ssl/202109_lafibreinfo_certification_paths.png)
Jusqu'au 3 mai 2021 :
Chaîne par défaut : End-entity certificate ← R3 ← DST Root CA X3
Chaîne alternative : End-entity certificate ← R3 ← ISRG Root X1
À partir du 4 mai 2021 :
Chaîne par défaut : End-entity certificate ← R3 ← ISRG Root X1 ← DST Root CA X3
Cette chaîne restera compatible avec de nombreux appareils Android, grâce a la signature croisée étendue expirée.
Chaîne alternative : End-entity certificate ← R3 ← ISRG Root X1
Il s'agit d'une chaîne plus courte, accessible aux personnes via l'API qui n'ont pas besoin de la compatibilité Android de la chaîne plus longue. Vous pouvez choisir cette chaîne avec de nombreux clients ACME, veuillez consulter la documentation du client ACME que vous avez choisi pour plus d'informations.
Après le 29 septembre 2021
Notre chaîne par défaut et notre chaîne alternative ne changeront pas, mais DST Root CA X3 expirera. Les appareils Android depuis la version 2.3.6 continueront de fonctionner. Les appareils non Android qui ne reçoivent pas de mises à jour du système afficheront des erreurs de certificat. Sur certaines plates-formes, l'utilisation de Firefox sera une solution de contournement, car Firefox obtient des mises à jour même sur de nombreux systèmes d'exploitation obsolètes.
Nous publierons périodiquement de nouveaux intermédiaires pour remplacer E1, E2, R3 et R4. Ces intermédiaires seront signés par ISRG Root X1 ou ISRG Root X2, selon leur type de clé.
Septembre 2024
Notre signature croisée étendue DST Root CA X3 expirera. Les appareils Android antérieurs à 7.1.1 afficheront des erreurs de certificat.
Source: community.letsencrypt.org : Modifications de la chaîne de production (https://community.letsencrypt.org/t/production-chain-changes/150739), le 29 avril 2021
-
Pour mieux comprendre la chaîne End-entity certificate ← R3 ← ISRG Root X1 ← DST Root CA X3, utilisée uniquement par Android < 7.1.1 :
Extension de la compatibilité des appareils Android pour les certificats Let's Encrypt
Nous sommes heureux d'annoncer que nous avons développé un moyen pour les anciens appareils Android de conserver leur capacité à visiter les sites qui utilisent les certificats Let's Encrypt après l'expiration de nos intermédiaires à signature croisée. Nous ne prévoyons plus de changements en janvier qui pourraient causer des problèmes de compatibilité pour les abonnés Let's Encrypt.
Un thème récurrent dans nos articles sur notre prochain changement de chaîne a été notre préoccupation concernant les effets sur les utilisateurs de systèmes d'exploitation Android antérieurs à 7.1.1, dont les appareils ne font pas confiance à notre racine ISRG X1. Grâce à la réflexion innovante de notre communauté et de nos merveilleux partenaires d'IdenTrust, nous disposons désormais d'une solution qui nous permet de maintenir une large compatibilité. Un élément essentiel à notre mission en tant qu'organisation à but non lucratif est d'aider à créer un Web plus sûr et plus respectueux de la vie privée pour le plus grand nombre de personnes possible. Ce travail nous rapproche de cet objectif.
IdenTrust a accepté de délivrer un signe croisé de 3 ans pour notre ISRG Root X1 à partir de leur DST Root CA X3. Le nouveau signe croisé sera quelque peu nouveau car il s'étend au-delà de l'expiration de DST Root CA X3. Cette solution fonctionne car Android n'applique intentionnellement pas les dates d'expiration des certificats utilisés comme ancres de confiance. L'ISRG et IdenTrust ont contacté nos auditeurs et nos programmes racine pour examiner ce plan et s'assurer qu'il n'y avait aucun problème de conformité.
En tant que tel, nous serons en mesure de fournir aux abonnés une chaîne contenant à la fois ISRG Root X1 et DST Root CA X3, garantissant un service ininterrompu à tous les utilisateurs et évitant les ruptures potentielles qui nous inquiétaient.
Nous n'effectuerons pas notre changement de chaîne précédemment planifié le 11 janvier 2021. Au lieu de cela, nous passerons pour fournir cette nouvelle chaîne par défaut fin janvier ou début février. La transition ne devrait avoir aucun impact sur les abonnés de Let's Encrypt, tout comme notre passage à notre intermédiaire R3 plus tôt ce mois-ci.
(https://lafibre.info/images/ssl/202012_letsencrypt_chaine_de_certification.png)
Quelques détails techniques supplémentaires suivent.
Je suis un développeur client ACME, que dois-je faire ? Si votre client a géré la transition X3 vers R3 en douceur, vous ne devriez pas avoir besoin d'agir. Assurez-vous que votre client utilise correctement le certificat intermédiaire fourni par l'API ACME à la fin de l'émission et ne récupère pas les intermédiaires par d'autres moyens (par exemple, les coder en dur, réutiliser ce qui est déjà sur le disque ou récupérer des URL AIA).
Je suis abonné à Let's Encrypt, que dois-je faire ? Dans la grande majorité des cas, rien. Si vous souhaitez vérifier, assurez-vous que votre client ACME est à jour.
J'utilise un ancien appareil Android, que dois-je faire ? Rien! Nous essayons de nous assurer que ce changement est complètement invisible pour les utilisateurs finaux.
Qu'est-ce qui change exactement ? Aujourd'hui, lorsqu'un abonné récupère son certificat depuis notre API, nous fournissons la chaîne suivante par défaut : Subscriber Certificate < – R3 < – DST Root CA X3 Après ce changement, nous fournirons à la place cette chaîne par défaut : Subscriber Certificate < – R3 < – ISRG Root X1 < – DST Root CA X3 Cela signifie que la chaîne par défaut que nous fournissons aux abonnés sera plus grande qu'auparavant, car elle contient deux intermédiaires au lieu d'un seul. Cela rendra les poignées de main TLS plus grandes et légèrement moins efficaces, mais le compromis en vaut la peine pour la compatibilité supplémentaire.
Mais DST Root CA X3 n'expire-t-il pas ? Le certificat auto-signé qui représente la paire de clés DST Root CA X3 expire. Mais les magasins racine du navigateur et du système d'exploitation ne contiennent pas de certificats en soi, ils contiennent des « ancres de confiance », et les normes de vérification des certificats permettent aux implémentations de choisir d'utiliser ou non des champs sur les ancres de confiance. Android a volontairement choisi de ne pas utiliser le champ notAfter des ancres de confiance. Tout comme notre ISRG Root X1 n'a pas été ajouté aux anciens magasins de confiance Android, DST Root CA X3 n'a pas été supprimé. Ainsi, il peut émettre un signe croisé dont la validité s'étend au-delà de l'expiration de son propre certificat auto-signé sans aucun problème.
Que se passe-t-il lorsque le nouveau signe croisé expire ? Ce nouveau signe croisé expirera au début de 2024. Avant cela, peut-être dès juin 2021, nous apporterons un changement similaire à ce que nous avions l'intention de faire en janvier. Lorsque nous apporterons cette modification, les abonnés auront la possibilité de continuer à utiliser DST Root CA X3 en configurant leur client ACME pour le demander spécifiquement. Si vous êtes un abonné Let's Encrypt qui travaille déjà à atténuer le changement de chaîne (par exemple en configurant des chaînes alternatives ou en encourageant vos utilisateurs sur d'anciens appareils Android à installer Firefox), continuez ce travail afin d'être bien positionné à l'avenir.
Et la chaîne alternative ? Aujourd'hui, certains clients ACME peuvent demander à la place une chaîne alternative, si leur utilisateur l'a configurée. Nous offrons actuellement la possibilité d'obtenir la chaîne : Certificat d'abonné < – R3 < – ISRG Racine X1 Nous continuerons à offrir cette même chaîne comme alternative. Cependant, notez que la plupart des clients ACME n'ont pas encore la possibilité de sélectionner cette chaîne alternative (par exemple, Certbot sélectionne les chaînes en cherchant si elles contiennent un nom d'émetteur donné, mais cette chaîne ne contient aucun nom d'émetteur que le la chaîne de compatibilité élevée ci-dessus ne le fait pas). Nous travaillerons avec les développeurs de clients ACME pour créer des mécanismes de sélection de chaîne plus flexibles à l'avenir.
Qu'est-ce que cela a à voir avec la future chaîne ECDSA ? Ce changement n'est pas lié à notre émission à venir de l'intermédiaire ISRG Root X2 et E1 basé sur l'ECDSA. Nous sommes impatients de les utiliser pour fournir des certificats et des chaînes plus petits et plus efficaces, mais cette offre future n'est pas liée à ce changement.
Source : Let's Encrypt (https://letsencrypt.org/2020/12/21/extending-android-compatibility.html) le 21 décembre 2020 par Josh Aas et Aaron Gable
-
Au final les vieux Android ne seront pas coupés de Let's Encrypt avec l'exploitation de cette faille de sécurité qui consiste à ne pas vérifier qu'un certificat racine est expiré.
Il y aura par contre de la casse le 30 septembre.
Voici la liste des systèmes qui seront difficilement utilisables sur Internet :
- Windows XP SP1 et SP2 (le SP3 est ok)
- macOS 10.10.x, 10.11.x et 10.12.0
- iOS 8 et iOS 9
- Ubuntu 14.04 LTS
- Debian 7
Firefox utilisant ses propres certificat, la solution est d’utiliser Firefox pour aller sur Internet, enfin Firefox 50 ou plus récent car Mozilla Firefox 49 et plus ancien sera cassé quel que soit le système d'exploitation.
La dernière version de Firefox pour Windows XP est Firefox 52 ESR, donc cela sera ok.
Pour Windows 2000, c'est Firefox 12, donc cela ne fonctionnera plus sans rajouter à la main le certificat (c'est également une solution pour les PC)
-
Il y a aussi le cas d'OpenSSL 1.0.2, qui est gêné par la racine expirée de la chaîne par défaut.
Il faudra enlever le certificat expiré DST Root CA X3, pour que la racine ISRG Root X1 embarquée soit utilisée (cad que la chaîne alternative soit créée en local quand le serveur envoie la chaîne par défaut).
Donc sur un Ubuntu 16.04, ou un 18.04 non mis à jour (ou pour des applications ayant été compilées avec la version d'origine d'OpenSSL), il y aura des problèmes.
Il y aura probablement pas mal de Linux embarqués avec le même problème, car la mise à jour OpenSSL 1.0.x vers 1.1 n'est pas immédiate (il faut tout recompiler, et modifier certaines sources).
-
Est-ce qu'il y a un risque pour les vieilles Freebox (V5HD/Crystal) et certaines vieilles STB style Amino 110 ?
-
OpenSSL en tant que client uniquement, non ?
OpenSSL est massivement utilisé, mais en tant que serveur, non ?
L'article du blog OPenSSL :
OpenSSL 1.0.2 et la la racine expirée de Let's Encrypt
La chaîne de certificats actuellement recommandée telle qu'elle est présentée aux clients Let's Encrypt ACME lorsque de nouveaux certificats sont émis contient un certificat intermédiaire (ISRG Root X1) qui est signé par un ancien certificat DST Root CA X3 qui expire le 2021-09-30. Dans certains cas, la version OpenSSL 1.0.2 considérera les certificats émis par Let's Encrypt CA comme ayant une chaîne de confiance expirée.
Voir plus d'informations sur les chaînes de confiance actuellement émises sur Let's Encrypt (https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/).
La plupart des bundles de confiance de certificats CA à jour, tels que fournis par les systèmes d'exploitation, contiennent ce certificat qui arrive bientôt à expiration. Les ensembles de certificats CA actuels contiennent également un certificat auto-signé ISRG Root X1. Cela signifie que les clients vérifiant les chaînes de certificats peuvent trouver le chemin alternatif non expiré vers le certificat auto-signé ISRG Root X1 dans leur magasin de confiance.
Malheureusement, cela ne s'applique pas à OpenSSL 1.0.2 qui préfère toujours la chaîne non fiable et si cette chaîne contient un chemin menant à un certificat racine de confiance expiré (DST Root CA X3), il sera sélectionné pour la vérification du certificat et l'expiration sera être signalé.
Voici quelques solutions de contournement possibles pour résoudre le problème :
Solution de contournement 1 (sur les clients avec OpenSSL 1.0.2)
Supprimez simplement le certificat racine expiré (DST Root CA X3) du magasin de confiance utilisé par le client OpenSSL 1.0.2 TLS pour vérifier l'identité des serveurs TLS. Si le nouveau certificat auto-signé ISRG Root X1 n'est pas déjà dans le magasin de confiance, ajoutez-le.
Il n'y a aucun inconvénient à cette solution de contournement, à l'exception de la nécessité de modifier tous les magasins de confiance potentiels des hôtes OpenSSL 1.0.2 TLS clients.
La suppression et l'ajout de certificats depuis/dans les magasins de confiance de certificats système est une opération très spécifique selon le système d'exploitation. Par exemple, sur les systèmes basés sur Linux qui gèrent les magasins de confiance de certificats système avec l'outil ca-certificates, un certificat CA peut être supprimé en copiant d'abord le certificat dans le /etc/pki/ca-trust/source/blacklistrépertoire et ajouté en le copiant dans le fichier /etc/pki/ca-trust/source/anchors directory. Le magasin de confiance est ensuite mis à jour en exécutant la update-ca-trustcommande.
Solution de contournement 2 (sur les clients avec OpenSSL 1.0.2)
La -trusted_firstprise en charge de l'option dans openssl verify, openssl s_client, et d'autres commandes openssl similaires, lorsqu'elles sont appliquées, remplace la construction de la chaîne de certificats et préfère donc les certificats du magasin de confiance aux certificats non approuvés dans la chaîne fournie par l'homologue. Cela signifie effectivement qu'avec l'option activée, le problème ne se produit pas.
Cependant, l'option n'est pas activée par défaut et les applications tierces ne permettent généralement pas d'activer cette option. Les applications devraient appeler la fonction X509_VERIFY_PARAM_set_flags() avec le drapeau X509_V_FLAG_TRUSTED_FIRST pour activer cette option.
La prochaine version d'OpenSSL 1.0.2 (1.0.2zb - disponible uniquement pour les clients du support premium) permettra de construire la version avec l'ajout -DOPENSSL_TRUSTED_FIRST_DEFAULT sur la ligne de commande de configuration de construction. Cela rendra l'option -trusted_first activée par défaut par la bibliothèque OpenSSL.
Solution de contournement 3 (sur les serveurs auxquels les clients 1.0.2 se connectent)
Configurez le serveur pour utiliser la chaîne de certificats alternative qui peut être demandée à Let's Encrypt avec la plupart des clients du protocole ACME à jour. Cette chaîne ne contient pas la racine ISRG X1 signée par la racine DST CA X3 bientôt expirée et ainsi aucun client OpenSSL 1.0.2 ne sera induit en erreur par ce chemin expiré.
L'inconvénient est que les serveurs seront considérés comme utilisant un certificat racine non approuvé par certains clients Android plus anciens, car ces clients ne contiennent pas le certificat ISRG Root X1 auto-signé dans leurs magasins de confiance.
Source : Blog OpenSSL (https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/), par Thomas Mraz, le 13 septembre 2021
-
Let's Encrypt en parle également et demande à passer à OpenSSL 1.1.0 :
Expiration du certificat racine DST Root CA X3 en septembre 2021
Le 30 septembre 2021, il y aura un petit changement dans la façon dont les anciens navigateurs et appareils font confiance aux certificats Let's Encrypt. Si vous exploitez un site Web classique, vous ne remarquerez pas de différence - la grande majorité de vos visiteurs accepteront toujours votre certificat Let's Encrypt. Si vous fournissez une API ou devez prendre en charge des appareils IoT, vous devrez peut-être accorder un peu plus d'attention au changement.
Let's Encrypt possède un « certificat racine » appelé ISRG Root X1 . Les navigateurs et appareils modernes font confiance au certificat Let's Encrypt installé sur votre site Web car ils incluent ISRG Root X1 dans leur liste de certificats racine. Pour nous assurer que les certificats que nous émettons sont fiables sur les appareils plus anciens, nous avons également une « signature croisée » à partir d'un ancien certificat racine : DST Root CA X3.
Lorsque nous avons commencé, cet ancien certificat racine (DST Root CA X3) nous a aidés à démarrer et à être immédiatement approuvés par presque tous les appareils. Le nouveau certificat racine (ISRG Root X1) est désormais largement approuvé - mais certains appareils plus anciens ne le feront jamais car ils ne reçoivent pas de mises à jour logicielles (par exemple, un iPhone 4 ou un HTC Dream). Cliquez ici pour obtenir une liste des plates-formes qui font confiance à ISRG Root X1 .
DST Root CA X3 expirera le 30 septembre 2021. Cela signifie que les appareils plus anciens qui ne font pas confiance à ISRG Root X1 commenceront à recevoir des avertissements de certificat lorsqu'ils visiteront des sites qui utilisent des certificats Let's Encrypt. Il y a une exception importante : les anciens appareils Android qui ne font pas confiance à ISRG Root X1 continueront à fonctionner avec Let's Encrypt, grâce à un signe croisé spécial de DST Root CA X3 qui s'étend au-delà de l'expiration de cette racine. Cette exception ne fonctionne que pour Android.
Que faire? Pour la plupart des gens, rien du tout ! Nous avons configuré notre émission de certificats pour que votre site Web fasse ce qu'il faut dans la plupart des cas, favorisant une large compatibilité. Si vous fournissez une API ou devez prendre en charge les appareils IoT, vous devrez vous assurer de deux choses :
(1) tous les clients de votre API doivent faire confiance à ISRG Root X1 (pas seulement DST Root CA X3)
(2) si les clients de votre API utilisent OpenSSL, ils doivent utiliser la version 1.1.0 ou ultérieure . Dans OpenSSL 1.0.x, une bizarrerie dans la vérification des certificats signifie que même les clients qui font confiance à ISRG Root X1 échoueront lorsqu'ils seront présentés avec la chaîne de certificats compatible Android que nous recommandons par défaut.
Source : Documentation Let's Encrypt (https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/), le 7 mai 2021.
-
OpenSSL en tant que client uniquement, non ?
La plupart du temps, c'est effectivement le client qui vérifie les certificats.
On peut faire de l'authentification mutuelle, où le client envoie aussi un certificat, qui est donc vérifié par le serveur. Mais c'est un usage particulier, qui n'a pas vraiment de sens avec Let's Encrypt.
OpenSSL n'est pas utilisé par les principaux navigateurs, sauf en embarqué (un WebKit actuel sous Linux, que ce soit WebKitGtk ou WPE, utilise soit GnuTLS, soit OpenSSL, mais le premier dépend d'une librairie LGPLv3).
En revanche, il sert dans beaucoup de programmes ou librairies, par exemple curl (qui peut aussi utiliser d'autres librairies, comme GnuTLS ou NSS).
-
J'ai trouvé un cas où cela devrait poser problème : Le téléchargement des mises à jour de sécurité pour Ubuntu 14.04 LTS et Ubuntu 16.04 LTS.
Le support de ces distributions sont assurés pendant 10 ans, avec l'Ubuntu Advantage subscription (gratuit pour un usage personnel).
La version d'OpenSSL n'est pas et ne sera mis à jour en OpenSSL version 1.1.0 ou ultérieure (les patchs de sécurité sont backporté dans OpenSSL 1.0.2).
Les mises à jour sont téléchargées https://esm.ubuntu.com/ (c'est bien du https par défaut qu'utilise apt-get pour ce dépôt)
Vous voulez voir avec quel certificat est utilisé par les dépots de mise à jour de sécurité ? C'est Let's Encrypt !
(https://lafibre.info/images/ssl/202109_ubuntu_esm_certification_paths.png)
La solution ? Faire les mises à jour pendant le fenêtre où c'est possible : entre le 23 septembre et 30 septembre 2021
Pour ne pas casser les certificats qui n'auraient pas intégrés ISRG Root X1, la suppression du certificat racine expiré DST Root CA X3 du magasin de confiance utilisé par le client OpenSSL 1.0.2 n'a été proposé en tant que mise à jour de sécurité que le 23 septembre 2021 pour Ubuntu, ce qui laisse une semaine pour faire les mises à jour et éviter le blocage des mise à jour et d'autres choses.
Si vous avez OpenSSL 1.0.2, il est donc très important de faire toutes les mises à jour de sécurité avant le 30 septembre.
(https://lafibre.info/images/ssl/202109_ubuntu_retrait_dst_root_cax3_1.png)
Le certificat racine expiré DST Root CA X3 est supprimé pour toutes les versions d'Ubuntu :
(https://lafibre.info/images/ssl/202109_ubuntu_retrait_dst_root_cax3_2.png)
-
Après le 29 septembre 2021
Notre chaîne par défaut et notre chaîne alternative ne changeront pas, mais DST Root CA X3 expirera. Les appareils Android depuis la version 2.3.6 continueront de fonctionner. Les appareils non Android qui ne reçoivent pas de mises à jour du système afficheront des erreurs de certificat. Sur certaines plates-formes, l'utilisation de Firefox sera une solution de contournement, car Firefox obtient des mises à jour même sur de nombreux systèmes d'exploitation obsolètes.
Nous publierons périodiquement de nouveaux intermédiaires pour remplacer E1, E2, R3 et R4. Ces intermédiaires seront signés par ISRG Root X1 ou ISRG Root X2, selon leur type de clé.
Donc si je comprends bien, je ne devrais pas être gêné avec mon vieux Galaxy A5 premier du nom (2015) qui est est bloqué en 6.0.1 faute de mises à jour de la part de Samsung, du moins jusqu'en 2024 ? Je n'ai pas prévu de changer de téléphone cette année, mais c'était plus ou moins dans l'optique de l'année prochaine...
-
Oui, j'ai modifié le titre du sujet : "1er octobre 2021: nombreux changements pour Let's Encrypt"
Les mobiles Android < 7.1.1 ont le droit à 3 ans de plus fonctionnement. La faille de sécurité exploitée pour permettre aux Android de continuer de fonctionner ne fonctionnera pas avec d'autres vieux systèmes d'exploitation.
Quand l’accès à Internet ne fonctionne pas avec Internet Explorer ou Chrome, il faut passer à Firefox, qui a son propre magasin de certificat de confiance et qui gère ISRG Root X1 depuis Firefox 50.
La problématique la plus importante semble être sur les serveurs où OpenSSL 1.0.2 (encore très rependu) posera problème, si le certificat DST Root CA X3 est encore dans le magasin, tout en étant expiré.
C'est pour cela que plusieurs distributions Linux diffusent des mises à jour pour supprimer DST Root CA X3 afin de forcer OpenSSL a utiliser le chemin alternatif ISRG Root X1.
(https://lafibre.info/images/ssl/202109_ubuntu_retrait_dst_root_cax3_1.png)
Le 1er octobre 2021, les plus grands impacts ne seront pas les PC, mais tout ce qui est embarqué, objet connecté. Si votre enceinte connectée Wi-Fi veut se connecter à une radio Let's Encrypt, il lui faut la mise à jour (ou une version d'OpenSSL récente)
J’espère pour Auchan, que leur caisse n'a pas besoin de se connecter à un domaine sécurisé par Let's Encrypt...
Photo prise en septembre 2020 par @najihel dans un Auchan : Totalement incompréhensible, sur du matériel aussi sensible, complexe et récent.
(https://lafibre.info/testdebit/windows2000/202009_auchan_caisse_automatique_windows2000.jpg)
-
J'ai trouvé un cas où cela devrait poser problème : Le téléchargement des mises à jour de sécurité pour Ubuntu 14.04 LTS et Ubuntu 16.04 LTS.
Le support de ces distributions sont assurés pendant 10 ans, avec l'Ubuntu Advantage subscription (gratuit pour un usage personnel).
La version d'OpenSSL n'est pas et ne sera mis à jour en OpenSSL version 1.1.0 ou ultérieure (les patchs de sécurité sont backporté dans OpenSSL 1.0.2).
Les mises à jour sont téléchargées https://esm.ubuntu.com/ (c'est bien du https par défaut qu'utilise apt-get pour ce dépôt)
Vous voulez voir avec quel certificat est utilisé par les dépots de mise à jour de sécurité ? C'est Let's Encrypt !
La solution ? Faire les mises à jour pendant le fenêtre où c'est possible : entre le 23 septembre et 30 septembre 2021
Pour ne pas casser les certificats qui n'auraient pas intégrés ISRG Root X1, la suppression du certificat racine expiré DST Root CA X3 du magasin de confiance utilisé par le client OpenSSL 1.0.2 n'a été proposé en tant que mise à jour de sécurité que le 23 septembre 2021 pour Ubuntu, ce qui laisse une semaine pour faire les mises à jour et éviter le blocage des mise à jour et d'autres choses.
Si vous avez OpenSSL 1.0.2, il est donc très important de faire toutes les mises à jour de sécurité avant le 30 septembre.
Pour Ubuntu 16.04, il y a déjà une mise à jour qui est passée normalement.
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989 (openssl 1.0.2g-1ubuntu4.20) force X509_V_FLAG_TRUSTED_FIRST (le "Workaround 2" décrit sur le blog OpenSSL).
-
Oui, j'ai modifié le titre du sujet : "1er octobre 2021: nombreux changements pour Let's Encrypt"
Les mobiles Android < 7.1.1 ont le droit à 3 ans de plus fonctionnement. La faille de sécurité exploitée pour permettre aux Android de continuer de fonctionner ne fonctionnera pas avec d'autres vieux systèmes d'exploitation.
Merci pour ces précisions ;)
-
Pour Ubuntu 16.04, il y a déjà une mise à jour qui est passée normalement.
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989 (openssl 1.0.2g-1ubuntu4.20) force X509_V_FLAG_TRUSTED_FIRST (le "Workaround 2" décrit sur le blog OpenSSL).
Exact. Le patch a été mis à disposition à partir du 19 août 2021.
-
Ubuntu 16.04 LTS
J'ai fais le test sur un Ubuntu 16.04 sur lequel j'ai laissé Ubuntu faire les mises à jour de sécurité sans faire les mises à jour qui ne sont pas de sécurité.
Autre point important il n'y a pas d'abonnement Ubuntu Advantage, donc les dernières mises à jour de sécurité pour Let's Encrypt ne sont pas disponibles (cela fait 5 mois qu'il n'y a plus de mises à jour).
Hier tout est ok, en ligne de commande comme pour les navigateurs :
(https://lafibre.info/testdebit/ubuntu/202109_ubuntu1604_certificat_letsencrypt_1.png)
Coté navigateur, Firefox 88 n'a aucune raison de poser problème vu qu'il intègre son propre magasin de certificat racine.
Chrome 90 fait confiance à ISRG Root X1 car le système l'embarque.
Par contre Epiphany 3.18.11 bloque, probablement à cause d'OpenSSL 1.0.2. Après avoir fait les mises à jour qui ne sont pas de sécurité c'est ok.
(https://lafibre.info/testdebit/ubuntu/202109_ubuntu1604_certificat_letsencrypt_3.png)
Wget est OK, mais pas Curl, probablement à cause d'OpenSSL 1.0.2 :
(https://lafibre.info/testdebit/ubuntu/202109_ubuntu1604_certificat_letsencrypt_2.png)
-
Ubuntu 14.04 LTS
Ubuntu 14.04 n'a plus de mise à jour depuis deux ans et demi (hors abonnement Ubuntu Advantage que je n'ai pas)
ISRG Root X1, le certificat racine de Let's Encrypt est bien présent, Les certificats avaient donc bien été maintenu à jour.
(https://lafibre.info/testdebit/ubuntu/202109_ubuntu1404_certificat_letsencrypt_1.png)
A cause de OpenSSL 1.0.1, ni wget, ni Curl ne fonctionnent :
(https://lafibre.info/testdebit/ubuntu/202109_ubuntu1404_certificat_letsencrypt_2.png)
Pour les navigateurs web :
- Firefox 66.0.3 : Tout fonctionne
- Chromium 65 : Tout fonctionne
- Epiphany : 3.10.3 (WebKit 2.4.10) : blocage
- Arora 0.11.0 (WebKit 531.21) : blocage avec une erreur SSL
- Dillo 3.0.3 : blocage avec une erreur SSL
- QupZilla 1.6.0 (WebKit 531.21) : blocage avec une erreur SSL
(https://lafibre.info/testdebit/ubuntu/202109_ubuntu1404_certificat_letsencrypt_3.png)
(https://lafibre.info/testdebit/ubuntu/202109_ubuntu1404_certificat_letsencrypt_4.png)
-
Ca semble passer à 0h08 avec lafibre.info avec un android 5.1 .......
-
.
Par contre Epiphany 3.18.11 bloque, probablement à cause d'OpenSSL 1.0.2. Après avoir fait les mises à jour qui ne sont pas de sécurité c'est ok.
C'est GnuTLS, qui a le mérite bug que OpenSSL 1.0.2.
https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1928648
Wget est OK, mais pas Curl, probablement à cause d'OpenSSL 1.0.2 :
curl >= 7.71 positionne X509_V_FLAG_TRUSTED_FIRST pour OpenSSL 1.0.2.
Les versions plus anciennes faisaient mal le test, et ne l'utilisaient que pour OpenSSL 1.0.2a.
-
Ubuntu 12.04 LTS
Afin de libérer de l'espace de stockage dans les serveurs de téléchargement officiels et dans les serveurs miroirs, les mises à jour d'Ubuntu 12.04 sont aussi retirées des serveurs de téléchargement officiels. Pour avoir les dernières mises à jour, il faut changer les dépôts, cela se fait simplement avec des deux commandes :
sudo sed -i -e "s/fr.archive.ubuntu.com/old-releases.ubuntu.com/g" /etc/apt/sources.list
sudo sed -i -e "s/security.ubuntu.com/old-releases.ubuntu.com/g" /etc/apt/sources.list
Les dernières mises à jour proposées intègrent ISRG Root X1, le certificat racine de Let's Encrypt.
Mais comme Ubuntu 14.04 ou Ubuntu 16.04, on peut avoir des problèmes lié à GnuTLS ou OpenSSL.
La solution ?
Il suffit de supprimer le certificat DST Root CA X3 qui est expiré :
sudo rm /etc/ssl/certs/DST_Root_CA_X3.pem
Ensuite vous arriverez à faire fonctionner parfaitement les sites Let's Encrypt, même avec le navigateur Arora 0.11 (basé sur WebKit 534.34).
(https://lafibre.info/testdebit/ubuntu/202109_ubuntu1204_certificat_letsencrypt_1.png)
-
La solution ?
do-release-upgrade ;)
-
Je ne pousse pas a garder de vieux système d'exploitation, mais il peut y avoir des contraintes, comme les mini-pc Atom équipé de 8 Go de mémoire flash (j'ai même un modèle équipé de 4 Go de mémoire flash). Avaoir aussi peu de disque limite fortement l'installation d'OS récent, plus que la RAM de 1 Go.
Dans l'industrie, c'est fréquent d'avoir de vieux Linux embarqué.
Windows 3.11 est utilisé en 2021 dans les trains par la Deutsche Bahn en Allemagne
Quel système d’exploitation pour un des ordinateur de bord de le Deutsche Bahn en Allemagne ?
Cela pose la question de l'évolution bien trop rapide de l'informatique pour des secteurs où il faut de la stabilité...
C'est un Pentium 100 Mhz avec 16 Mo de mémoire vive, disque dur IBM IDE de 5 Go tournant sous Windows 95.
https://lafibre.info/videos/windows/202108_deutsche_bahn_ordinateur_bord_win95.mp4
(https://lafibre.info/testdebit/windows_old/202108_deutsche_bahn_ordinateur_bord_win95.jpg)
Source : @CptKrustenkaese (https://twitter.com/verathom/status/1426064633933271041)
Il reste des versions qui tournent sous Windows 3.11 :
(https://lafibre.info/testdebit/windows_old/202108_deutsche_bahn_ordinateur_bord_win311.jpg)
-
Bonjour à tous !
Equipé d'un "vieux" (mi 2011) mac qui tourne sous El Capitan, plus possible d’accéder à Lafibre depuis hier avec Chrome, même en forçant les alertes de sécurité. Il me dit que le site est victime d'une attaque de pirates 8) Avec Firefox en version 78 ESR, aucun souci.
Si ce n'était que ça, mais j'ai pas mal de sites dont l'accès fonctionne mal. Je sais que mon OS est vieux (et pour des raisons matérielles j'hésite à faire la mise à jour), mais comme Chrome est toujours maintenu (j'ai la version 94), je pensais que je passerais outre. Bref ça va être chiant de naviguer entre les deux navigateurs.
-
Je conseillerais la mise à jour, si c'est la version suivante : macOS Sierra et macOS High Sierra est supportée sur ton Mac mini 2011.
Sinon, la solution alternative, c'est d'installer manuellement le certificat racine ISRG Root X1.
-
Je conseillerais la mise à jour, si c'est la version suivante : macOS Sierra et macOS High Sierra est supportée sur ton Mac mini 2011.
Sinon, la solution alternative, c'est d'installer manuellement le certificat racine ISRG Root X1.
Voir ce que j'ai mis plus haut : il supporte en théorie, mais depuis que je l'ai fait réparé il y a trois ans, il a plutôt un comportement de hackintosh. Bref, une petite probabilité de me retrouver devant un écran noir à la mise à jour ;)
Et comment on fait pour l'installer ce certificat ?
-
Bon je viens de voir un tuto (pour un autre certificat mais la procédure doit être la même), je garde ça dans un coin et je ferais le truc si vraiment ça devient trop chiant...
-
N'hésites pas a partager la façon de faire (je n'ai pas de mac), j'ai l'impression que les deux principaux impacts de la racine CA X3 IdenTrust DST expirée, c'est :
- Des Mac 10.12.0 ou plus ancien qui n'ont pas la racine, ISRG Root X1.
- Des Linux qui ont la racine, ISRG Root X1, mais qui sont impactés car l'outil utilise la chaînes de certification expirée (OpenSSL 1.0.2, GnuTLS,...).
-
Equipé d'un "vieux" (mi 2011) mac qui tourne sous El Capitan,
pourquoi les guillemets ?
un pc d'il y a 10 ans moi j'appelle ca une vielle bouse non ?
-
Un PC qui a 10ans peut être tout à fait utilisable, si il a un SSD et suffisamment de ram.
Un processeur Intel Core2 Duo 2 cœurs est très bien pour un usage bureautique / vidéo. Avec un Core2 Duo 4 cœurs, on peut faire pas mal de choses si il a 8 Go de ram et un SSD.
Le PC portable de ma femme à 12 ans (Processeur Intel Core2 Duo T8100 à 2,1 GHz lancé au 1er trimestre 2008 et gravé en 45 nm avec GPU Intel Corporation Mobile GM965/GL960 de 4ème génération) permet dans problème de regarder des vidéos. Il n'a plus de batterie, il ne fonctionne que branché. Il est en dual boot Windows 10 / Ubuntu 20.04, je vois un petit avantage à Ubuntu en terme de vitesse, mais Windows 10 reste utilisable. Pour moi c'est la limite de l'acceptable en terme de puissance. Des PC portable bien plus récent (2016) équipés d'un Celeron Nxxxx (base Atom) ont moins de performance CPU.
-
Je ne crois pas qu'il y ait encore eu de Mac core2 en 2011, il me semble que c'était au moins core i5 ou i7, extensible à 16 ou 32 Go de RAM et SSD pour beaucoup de modèles. Ca reste très très utilisable aujourd'hui ;)
-
Le mien est effectivement un core I5 avec 8 go de Ram et un SSD. Il est encore très performant aujourd'hui.
-
Le mien est effectivement un core I5 avec 8 go de Ram et un SSD. Il est encore très performant aujourd'hui.
j'ai pas dis que c'etait pas inutilisable...
une renault 5 de 1982 reste fonctionnelle, ca reste une vielle bouse
"tres performant" => on a le droit de rigoler ou pas ? ;) ou alors tu compares par rapport a un pc des années 2000 ? :)
Non. Ca reste utilisable, rien de plus.
-
Tout dépend des besoins...
-
j'ai pas dis que c'etait pas inutilisable...
une renault 5 de 1982 reste fonctionnelle, ca reste une vielle bouse
"tres performant" => on a le droit de rigoler ou pas ? ;) ou alors tu compares par rapport a un pc des années 2000 ? :)
Non. Ca reste utilisable, rien de plus.
Un i5-2500 a 10 ans, mais est toujours plus performant que certains procos d'entrée de gamme ou embraqués sur des prémontés d'aujourd'hui. On peut encore y faire tourner les jeux d'aujourd'hui en 1080p avec presque tout à fond si la CG suit (j'en ai dans mon parc). Donc non, le matos d'il y a 10 ans n'est pas forcément une vielle bouse ;)
-
j'ai pas dis que c'etait pas inutilisable...
une renault 5 de 1982 reste fonctionnelle, ca reste une vielle bouse
"tres performant" => on a le droit de rigoler ou pas ? ;) ou alors tu compares par rapport a un pc des années 2000 ? :)
Non. Ca reste utilisable, rien de plus.
Vu la stagnation des performance d'Intel, c'est pas un gouffre non plus... Le dernier MacMini Intel (2018) est 2 à 3 fois plus puissant que celui de 2011 (en comparant les i5)... En 7 ans, ça casse pas 3 pattes à un canard, et le gap n'a rien d'extraordinaire... donc de là à rigoler et à parler de vieille bouse... Un peu de mauvaise foi?
-
Finalement quels ont été les principaux impacts des changements de Let's Encrypt ?
Pour l’utilisation de navigateurs web l'impact le plus important semble être coté MacOS : Le support des versions de MacOS est de courte durée et Mac OS X El Capitan (10.11) sortie en juin 2015 n'a pas le droit au certificat ISRG Root X1.
3 solutions sont possibles pour les nombreux utilisateurs impactés :
- Mettre à jour MacOS vers la version suivante (si c'est possible)
- Utiliser Firefox qui a son propre magasin de certificat et qui embarque ISRG Root X1 depuis Firefox 50
- Rajouter manuellement le certificat ISRG Root X1. Je n'ai pas de Mac, donc voici un tutoriel que je n'ai pas testé :
--------------------------------------------
1. Download this Root Certificate:
--------------------------------------------
NAME:
"ISRG Root X1"
(✅ Self-signed, ❌ NOT Cross-signed)
URL:
https://letsencrypt.org/certs/isrgrootx1.der
--------------------------------------------
2. Verify that the fingerprints match:
--------------------------------------------
So you know that the Root Certificate I've linked to is in fact the one that LE provides and Apple has certified/trusted.
This is for *your* safety since you *shouldn't* trust me.
FINGERPRINT (SHA-1):
CABD2A79A1076A31F21D253635CB039D4329A5E8
SOURCE:
https://letsencrypt.org/certificates/ (Active > ISRG Root X1 > Self-signed > der)
https://crt.sh/?id=9314791
WHAT APPLE SHIPS 10.12.1+:
https://support.apple.com/en-us/HT207189
- Search for: "ISRG Root X1"
You should see that the fingerprints match between and .
--------------------------------------------
4. Install the certificate:
--------------------------------------------
- Via "Keychain Access.app"
- `File > Import Items...`
You can install it into either the `login` or `system` keychain. But not `System Roots` (which is where it *would* be, if we were on 10.12.1+)
- login = Current user only
- system = All users
--------------------------------------------
5. Manually "Trust" that certificate:
--------------------------------------------
- Find it ("ISRG Root X1") in the list and double click on it.
- Open the "▶ Trust" area.
- Set: `When using this certificate:` to `Always Trust`
- Close the window, which will ask you to verify with your login password.
🏁 Done!
-
Quels sont les impacts en-dehors des navigateurs web ?
Il y a de nombreux impacts sur des utilitaires Linux (les principaux navigateurs ne sont pas impactés).
Ce n'est pas lié à l'absence de ISRG Root X1, mais au fait que pour maintenir la compatibilité avec les Android < 7.1, le serveur envoie le ISRG Root X1 signé par DST Root CA X3. Certains utilitaires, si la racine DST Root CA X3 est toujours présente voit la chaîne avec une racine expirée et refuse, même si la racine ISRG Root X1 est présente. On a beaucoup parlé de OpenSSL 1.0.2, mais cela va bien au-delà.
Je donne un exemple concret avec Ubuntu 20.04 : J'ai l'habitude de me connecter aux dépôts Ubuntu en https (ce n'est pas le comportement par défaut, mais c'est officiellement supporté, il suffit de choisir un miroir qui gère le https pour la configuration soit automatiquement basculée en https)
Sur un serveur Ubuntu 20.04 et un PC Ubuntu 20.04 qui avaient été mis à jour début septembre, début octobre impossible de faire les mises à jour :
(https://lafibre.info/testdebit/ubuntu/202110_ubuntu2004_certificat_letsencrypt_1.png)
J'ai basculé les dépôt en http et j'ai fais toutes les mises à jour, sauf celle qui retire la racine DST Root CA X3 :
(https://lafibre.info/images/ssl/202109_ubuntu_retrait_dst_root_cax3_1.png)
J'ai ensuite remis les dépôts en https et j'ai testé en ligne de commande pour avoir plus de détail sur l'erreur :
(https://lafibre.info/testdebit/ubuntu/202110_ubuntu2004_certificat_letsencrypt_2.png)
APT est incapable de se connecter en https à un dépôt signé par Let's Encrypt si la racine DST Root CA X3 expirée est encore présente sur le système (elle n'a été retirée par une mise à jour que fin septembre)
A noter que APT d'Ubuntu 16.04 ne semble pas affecté par ce problème, j'avais réalisé le test en oubliant exprès la mise à jour qui retire la racine DST Root CA X3 expirée et cela fonctionnait sur un dépot signé par Let's Encrypt.
-
Le support des versions de macOS est de courte durée, mais les updates sont systématiquement proposées à énormément de Mac/MacBooks, donc au final il faut le vouloir pour être bloqué sur El Captain quand même
-
On a beaucoup parlé de OpenSSL 1.0.2, mais cela va bien au-delà.
Je donne un exemple concret avec Ubuntu 20.04
[...]
APT est incapable de se connecter en https à un dépôt signé par Let's Encrypt si la racine DST Root CA X3 expirée est encore présente sur le système (elle n'a été retirée par une mise à jour que fin septembre)
Si on regarde les dépendances, apt utilise GnuTLS.
GnuTLS avait un bug similaire à OpenSSL 1.0.2, ça a été corrigé en 3.6.14.
Pas de chance, Ubuntu 20.04 a toujours GnuTLS 3.6.13.
-
Oui, sauf erreur, El Capitan concerne les machines de 2009 et moins, les suivantes peuvent être mise à jour en High Sierra au minimum.
Une autre procédure pour mettre à jour le certificat que j'ai trouvée (mais pas testée personnellement) :
- Avec Firefox (à jour) ouvre https://letsencrypt.org/certs/isrgrootx1.pem
- Accepte l'ouverture avec KeyChain (par défaut)
- Accepte l'installation dans le Trousseau
EDIT: Cela va l'installer dans le trousseau Session, donc valable uniquement pour l'utilisateur courant, mais c'est déjà ça ;)
-
Oui, sauf erreur, El Capitan concerne les machines de 2009 et moins, les suivantes peuvent être mise à jour en High Sierra au minimum.
Une autre procédure pour mettre à jour le certificat que j'ai trouvée (mais pas testée personnellement) :
- Avec Firefox (à jour) ouvre https://letsencrypt.org/certs/isrgrootx1.pem
- Accepte l'ouverture avec KeyChain (par défaut)
- Accepte l'installation dans le Trousseau
EDIT: Cela va l'installer dans le trousseau Session, donc valable uniquement pour l'utilisateur courant, mais c'est déjà ça ;)
Comme je l'ai dit plus haut, il y a un risque de me retrouver avec un écran noir si je mets mon OS à jour pour une version plus récente étant donné que depuis sa réparation, c'est comme si mon mac avait été "hacké",, mon en théorie il supporte jusqu'à High Sierra. Il faudrait que je tente une mise à jour un de ces quatre mais en ayant bien pris soin de limiter à fond les risques (installation de l'OS sur une clé USB dans un premier temps, clonage de la partition de restauration...), parce que plus que l'obsolescence matérielle, c'est l'obsolescence logicielle que je commence à sentir passer lentement mais sûrement...
Sinon ta méthode est la bonne. Cependant une fois que le certificat est installé, il faut l'ouvrir en double-cliquant dessus, dérouler le menu "se fier" et "toujours approuver". Bien entendu, pour de telles manipulations, il faut avoir les droits d'administration de la machine.
-
En 2021, les versions d'Android antérieures à 7.1.1 ne feront plus confiance aux certificats émis par Let's Encrypt
Je trouve étonnant qu'on en parle si peu,
Désolé de déterrer, mais ce qui m'alarme le plus, c'est que ce SSL semble bloquer également la connexion de pas mal de choses.
pour avoir travaillé récemment sur les technos blackberry anciennes, c'est étonnant de voir que par ex sur les tablettes vendues en 2016, quand on la réinitialise : l'assistant d'installation abouti sur l'acceptation du cluf, le contrat à accepter.
si il n'est pas accepté, impossible d'utiliser l'appareil. Certains fabricants android (dont les grandes marques) font pareil : sans accepter le contrat de marque, impossible d'avoir accès à l'interface utilisateur.
Or, pour ces appareils bberry vendus en 2016, donc pas si vieux, l'assistant est façonné pour télécharger le CLUF, selon la région.
Et devinez quoi?
meme avec internet, bien que leurs infras aient été débranchées, impossible d'aller plus loin : en wifi ou data, le contrat n'acceptera pas.
j'ai vu plusieurs anciens appareils de cette marque passer à la poubelle à cause de ce satané cluf. Pire encore, les protocoles imap/smtp, bien pratiques pour le mailing, ne semblent plus passer ; cette tendance commence à également s'inscrire sur les android jusqu'en version 4, qui comme les iphone jusqu'au 4, finissent échoués comme des 3310 améliorés (comprendre applis de base+ confort tactile mais zéro usage internet)
quelque chose qui me fait fortement tousser...