Go rejette huit certificats intermédiaires compromis dans les chaînes de confiance
Sommaire
En bref
- Go 1.26, 1.27 et 1.28 bloquent désormais la validation de certificats émis par huit autorités de certification intermédiaires compromise, détectées via Certificate Transparency.
- Cette faille est classée CVE-2026-111943 et nécessite une mise à jour immédiate.
- D'autres implémentations (Node.js, Electron, rustls) déploient des correctifs identiques, signe d'un compromis grave des clés privées.
Ce que dit la source
Go filtrera désormais les chaînes de certificats contenant huit intermédiaires spécifiques dans la fonction Verify(), empêchant leur retour à l'appelant. La raison invoquée : des inquiétudes sécurité graves sur l'exploitation de ces autorités. L'équipe Go qualifie cela d'urgent et recommande une mise à jour immédiate. Le correctif a été backporté dans Go 1.26.10, 1.27.3 et inclus en natif dans 1.28.
- Les certificats bloqués détectés via Certificate Transparency semblent être des certificats de test non malveillants, découverts probablement par le chercheur dont le DNS figure dans le premier certificat.
- Deux implémentations de Certificate Transparency ont été mises à jour hier pour refuser la journalisation de certificats émis par ces autorités, indice d'un compromis total des clés privées ; cette blocage CT empêche le spam potentiel mais interdit aussi l'enregistrement des certificats forgés en circulation.
- Les certificats falsifiés non journalisés dans CT passeront la validation chez les clients n'enforçant pas CT, créant un vecteur d'attaque pour les implémentations Go anciennes et autres outils non CT-aware.
- Node.js, Electron et rustls/webpki déploient des correctifs parallèles ; OpenSSL attend encore un patch.
- Go maintient sa propre liste de CA racines, indépendante du magasin OS, ce qui explique pourquoi le blocage s'applique même si l'OS accepte ces certificats.
Dans les commentaires
Débat peu substantiel mais consensuel sur l'urgence du patch. Critiques portent surtout sur le design fonda du Web PKI plutôt que sur la réponse de Go.
- Plusieurs commentateurs contestent l'architecture du Web PKI elle-même, arguant qu'un système hiérarchique limiterait les dégâts en cas de compromis à un sous-arbre spécifique, plutôt que d'affecter tous les certificats intermédiaires d'une autorité.
- Un commentateur relève que Go maintient sa propre liste de CA, compliquant la gestion centralisée des sauvegardes de confiance à l'échelle du système d'exploitation, parallèle au problème connu avec Java.
- Spéculation minoritaire : une ordonnance de sécurité nationale pourrait être à l'origine de cette réaction calibrée et discrète.
Notre lecture
Urgent, appliquer immédiatement. C'est un compromis réel, pas une théorie : le blocage coordonné par Certificate Transparency et l'adoption cross-platform (Go, Node, Electron, rustls) en témoignent. Aucune indication que les certificats compromis ont déjà permis une usurpation d'identité en production, mais le risque était très réel. À vérifier : l'état du patch OpenSSL pour les applications non-Go. Pour les DSI, l'enjeu court terme est le déploiement des mises à jour ; le débat plus large sur la réforme du Web PKI reste académique à ce stade.