Compromission d'une autorité de certification intermédiaire d'eMudhra : clés privées récupérables
Sommaire
En bref
- L'autorité de certification eMudhra a généré huit clés de signature intermédiaires avec une faiblesse cryptographique grave : les clés privées peuvent être récupérées à partir des certificats publics.
- N'importe qui peut donc émettre des certificats HTTPS valides usurpant n'importe quel site (banques, GitHub, PyPI, etc.).
- Les distributions Linux (Gentoo, Red Hat) et les runtimes (Go, Python) diffusent des mises à jour ou des contournements pour révoquer les certificats compromis du magasin d'appareils de confiance.
Ce que dit la source
eMudhra, une autorité de certification, a commis une erreur de génération de clés lors de la création de huit certificats de signature intermédiaires. La faille permet de dériver les clés privées directement depuis les clés publiques exposées : une violation majeure de la PKI.
- Les huit certificats intermédiaires compromis ont été signés par des certificats Comodo racine.
- Go a bloqué proactivement ces certificats au niveau du runtime, indépendamment du magasin système de l'appareil (détails : GO-2026-6809).
- Gentoo Linux propose une mise à jour via `emerge` pour mettre à jour `app-misc/ca-certificates` à la version 20260816.3.125 ou supérieure (GLSA 202610-01).
- Red Hat diffuse uniquement un contournement temporaire qui désactive deux certificats racine Comodo, sans correctif complet (statut: En cours).
- Python a émis des directives spécifiques aux utilisateurs, via sa discussion officielle.
- Plusieurs tests de validation sont disponibles en testant les domaines compromis (par ex. avec `curl` : une erreur d'émetteur manquant indique que la révocation fonctionne).
Dans les commentaires
Débat partagé sur l'ampleur et les implications, mais accord sur la gravité du problème : une AC a exposé son pouvoir de signature. Le fil mélange explications techniques, constats de divergence entre les mises à jour (Go proactif vs Red Hat en retard), et des observations cyniques sur la fragilité de l'infrastructure PKI.
- Plusieurs commentateurs notent que certaines distributions (notamment Red Hat) traînent à fournir des mises à jour complètes, proposant des contournements au lieu de correctifs durables.
- Un participant soulève que le problème était connu depuis quelques jours au-delà du périmètre NIST, le catalogage CVE arrivant après coup.
- Divergence sur la portée : l'un des commentaires suggère que seul Go serait affecté, tandis que d'autres soulignent que le problème touche tout navigateur/client qui accepte ces certificats du magasin système.
- Une observation cynique compare l'évolution technologique à un système qui crée ses propres vulnérabilités, reflétant une inquiétude générale sur la robustesse de la PKI moderne.
Notre lecture
C'est grave pour tout responsable d'infrastructure ou de sécurité : une AC de facto vient de compromettre le modèle de confiance sur lequel repose HTTPS. L'urgence est de réviser le magasin de certificats et de vérifier que les clients (navigateurs, runtimes) bloquent bien les certificats compromis, indépendamment des délais de mise à jour du système d'exploitation. Le fait que Go réagisse plus vite que Red Hat pose une question structurelle : qui contrôle la révocation, l'OS ou le runtime ? À surveiller : la synchronisation des correctifs sur l'ensemble de la pile (système, navigateurs, langages). Pour les équipes concernées par HTTPS (donc toutes les équipes), valider l'impact dans l'environnement.