Contexte de la compromission
Le rapport Bugzilla indique une compromise de la clé privée utilisée pour signer les certificats intermédiaires d’eMudhra. Cette information apparaît dans les changements de statut du ticket, passant de NEW à ASSIGNED, et dans les drapeaux needinfo adressés à plusieurs intervenants (naveen.ml, kaushik, djackson). Le ticket porte la mention Private key compromise of eMudhra Intermediate Certificates, ce qui confirme que la faille porte sur les certificats intermédiaires et non sur le certificat racine.
Conséquences techniques
Un certificat intermédiaire signé avec une clé privée compromise permet à un attaquant de délivrer des certificats falsifiés qui s’insèrent dans la chaîne de confiance TLS. Les navigateurs et systèmes qui reconnaissent la racine eMudhra accepteront alors des connexions chiffrées présentées par un certificat émis frauduleusement, ouvrant la porte à des attaques de type man‑in‑the‑middle. La perte de la clé affecte également les processus de révocation : la mise à jour des listes de révocation (CRL) ou des réponses OCSP doit être effectuée rapidement pour empêcher l’exploitation.
Réaction de Mozilla
Le ticket signale que eMudhra a « ignored Mozilla Root investigation deadline », indiquant que la date fixée par le programme de conformité des autorités de certification (CA) de Mozilla n’a pas été respectée. Le champ Whiteboard comporte les balises [ca-compliance] et [external], soulignant que la situation relève du suivi de conformité externe. L’absence de réponse dans les délais impose à Mozilla d’envisager la désactivation de la racine eMudhra du magasin de confiance, ce qui aurait un impact immédiat sur tous les services qui s’appuient sur ces certificats intermédiaires.
Analyse des limites et mesures correctives
Le rapport ne fournit pas de détails sur la portée exacte de la compromission (nombre de certificats affectés, dates d’émission, algorithmes de signature). Cette absence de données empêche d’évaluer précisément le risque résiduel. En pratique, la mitigation passe par la révocation de tous les certificats intermédiaires compromis, la génération de nouvelles paires de clés, et la re‑signature des certificats avec une clé sécurisée. Mozilla devra mettre à jour les listes de révocation et informer les opérateurs de services web de remplacer les certificats affectés. Le processus de re‑émission doit également respecter les exigences de transparence, notamment la publication de logs de certificats (CT) pour garantir la traçabilité.
