La compromission d’une AC eMudhra transforme les mises à jour de confiance des navigateurs en audit du parc informatique

Ce qui a été compromis — et ce qui ne l’a pas été

Le 17 octobre, l’incident eMudhra est passé d’un problème de gestion des certificats à une décision de confiance plus large. Les enquêteurs ont découvert que les clés privées de huit autorités de certification eMudhra subordonnées pouvaient être reconstituées, car elles avaient été générées avec une entropie cryptographique insuffisante. Ce détail est important : une clé privée d’AC compromise peut permettre à un attaquant de créer des certificats semblant remonter jusqu’à une autorité de confiance. La réponse ne peut donc pas se limiter à vérifier si un site donné a été consulté. Il faut identifier précisément les autorités émettrices concernées et distinguer l’exposition confirmée des suppositions concernant le reste de la hiérarchie eMudhra.

Les huit AC subordonnées concernées se répartissent en deux groupes distincts. Six étaient des AC intermédiaires TLS, utilisées dans les chaînes de certificats pour les connexions réseau chiffrées. Les deux autres étaient des AC intermédiaires de signature de code, utilisées pour appuyer les signatures de logiciels ou d’autres contenus signés. Traiter ces catégories comme interchangeables brouillerait deux questions de validation différentes. Un navigateur ou un système d’exploitation peut évaluer une chaîne TLS lors de la connexion à un service, tandis qu’un vérificateur de signature de code évalue une signature et sa chaîne de certificats pour décider si un logiciel doit être approuvé. Les deux reposent sur une infrastructure de certificats, mais les usages concernés et les systèmes qui mettent en cache ou imposent la confiance ne sont pas identiques.

Les avis de Google et de Mozilla décrivent la compromission comme touchant ces huit AC intermédiaires eMudhra. Leurs recommandations fixent également une limite importante à ce qui a été établi : rien dans les avis cités n’indique que tous les certificats racine eMudhra, ni tous les autres certificats intermédiaires eMudhra, ont été compromis. Cela ne justifie pas de laisser intacts tous les certificats eMudhra, pas plus que cela ne permet de considérer l’ensemble de l’autorité de certification comme uniformément peu fiable. La question pratique, plus précise et plus utile, est la suivante : un système dépend-il de l’une des AC intermédiaires identifiées, ou d’une chaîne passant par une racine ou un chemin de signature croisée que les fournisseurs sont en train de retirer de leurs magasins de confiance ?

Cette distinction explique pourquoi la réponse repose sur des mesures de défiance ciblées plutôt que sur l’affirmation générale que tout certificat émis par eMudhra serait invalide. Les contrôles des fournisseurs peuvent bloquer les certificats associés au matériel de clé publique concerné ou supprimer certains chemins de confiance, tandis que les administrateurs doivent encore déterminer si leurs propres certificats, leur infrastructure d’inspection, leurs processus de validation logicielle ou leurs magasins de confiance intégrés dépendent de ces chemins. Autrement dit, la compromission confirmée identifie l’ensemble des clés qui doivent être considérées comme exposées ; elle ne permet pas, à elle seule, de savoir quels services d’une organisation cesseront de fonctionner lorsque la confiance sera renforcée.

La cause technique est tout aussi importante. La possibilité de reconstituer les clés privées a été attribuée à une entropie insuffisante lors de leur génération cryptographique. Il ne s’agit pas d’éléments montrant qu’un attaquant aurait deviné un mot de passe ou obtenu une clé privée au moyen d’une intrusion ordinaire sur un serveur. Une fois le matériel de clé sous-jacent reconstituable, la conséquence opérationnelle est toutefois similaire pour les parties utilisatrices : les certificats émis par les AC subordonnées concernées ne peuvent plus être considérés comme fiables simplement parce qu’ils portent un nom eMudhra familier ou remontent jusqu’à une racine reconnue. La validation doit tenir compte de l’émetteur compromis précis et des contrôles désormais utilisés pour lui retirer sa confiance.

Pour les équipes informatiques, la première limite de l’inventaire doit donc être la chaîne de certificats, et non la marque affichée dans un visualiseur de certificats. Il faut noter si les certificats aboutissent à l’une des six AC intermédiaires TLS concernées, si des logiciels signés reposent sur l’une des deux AC intermédiaires de signature de code, et si la chaîne atteint une racine ou un chemin de signature croisée concerné dont un fournisseur a programmé le retrait. Il faut également conserver la constatation négative : les systèmes utilisant des racines ou des certificats intermédiaires eMudhra sans lien ne sont pas automatiquement présentés comme compromis par les avis cités ici. Cette séparation rend les mesures correctives ultérieures plus précises, conserve une trace défendable des vérifications effectuées et évite de remplacer une mise à jour ciblée du magasin de confiance par une interruption inutilement étendue.

Pourquoi les utilisateurs de navigateurs ont été protégés plus rapidement que les autres logiciels

La première protection a atteint les navigateurs grand public parce que leurs éditeurs peuvent diffuser les décisions de défiance par des mécanismes de mise à jour gérés de manière centralisée. Chrome a utilisé un blocage SPKI dans une CRLSet pour rejeter les certificats associés aux clés intermédiaires eMudhra compromises. Le point important est que cette action cible l’identité de la clé publique de l’autorité de certification, et pas seulement le numéro de série d’un certificat. Le navigateur peut ainsi interrompre les chaînes concernées même lorsque le certificat présenté est nouveau, remplacé ou n’est pas référencé individuellement. Sur Android, Google a également utilisé Google Play Services pour étendre la protection au-delà du navigateur, afin que la réponse de défiance concernée atteigne les appareils compatibles par l’intermédiaire d’un service de la plateforme, sans attendre que chaque application déploie sa propre logique de gestion des certificats.

Firefox a poursuivi un objectif similaire avec OneCRL, le mécanisme de Mozilla qui distribue aux clients Firefox les décisions de révocation des certificats. Mozilla a aussi décrit des changements du magasin de racines, qui agissent à une frontière de confiance plus large : au lieu de rejeter uniquement les certificats émis sous une intermédiaire donnée, un client peut cesser de faire confiance à une racine ou à un chemin associé dans son ensemble. Cette portée est utile lorsque le même écosystème peut être atteint par différents arrangements d’autorités intermédiaires ou de signatures croisées, mais elle explique aussi pourquoi les changements de confiance doivent être évalués avec soin. Une mise à jour du navigateur peut fermer l’exposition lors des sessions web ordinaires tout en laissant d’autres logiciels adopter une interprétation différente de la même chaîne de certificats.

La transparence des certificats a contribué à réduire la fenêtre d’exposition pour les clients qui l’appliquent, car les certificats TLS approuvés publiquement sont censés laisser une trace vérifiable dans des journaux publics. Pour un client qui l’impose, cette trace peut faciliter la détection et les décisions de politique concernant des certificats qui n’auraient pas dû être émis ou approuvés. Elle ne transforme toutefois pas tout consommateur TLS en client appliquant cette règle. Les contrôles de transparence des certificats, les mécanismes de révocation et les mises à jour des magasins de confiance sont des mesures distinctes. Une application peut en mettre en œuvre certaines, aucune, ou une variante interne dont le comportement diffère de celui d’un navigateur récent.

C’est pourquoi l’expression « les utilisateurs de navigateurs ont été protégés » ne doit pas être comprise comme « tous les systèmes utilisant TLS ont été protégés ». Un navigateur reçoit normalement des politiques et des mises à jour de magasin de confiance gérées par son éditeur, mais une organisation peut aussi dépendre des ensembles de certificats du système d’exploitation, de magasins intégrés aux applications, d’ensembles Java ou d’autres environnements d’exécution, d’équipements réseau, de systèmes d’inspection TLS, d’images de conteneurs et de bibliothèques autonomes. Ces composants peuvent être actualisés selon des calendriers différents ou nécessiter qu’un administrateur remplace directement un paquet. Certaines applications effectuent leurs propres vérifications de révocation ; d’autres dépendent du système d’exploitation hôte. Un service qui ne consulte pas le magasin mis à jour peut continuer à construire une chaîne qu’un navigateur à jour rejette.

Le mode de défaillance peut aussi s’inverser. Un client peut disposer d’une fonction de révocation, mais considérer une réponse indisponible comme acceptable, ou échouer en mode ouvert lorsqu’il ne parvient pas à terminer la vérification. Dans ce cas, l’existence d’un signal de révocation ne garantit pas son application. La politique locale, l’accessibilité du réseau, les décisions mises en cache et le comportement de l’application jouent tous un rôle. Il en va de même pour les appareils qui terminent ou inspectent TLS : le navigateur du terminal peut être à jour tandis que l’équipement intermédiaire conserve un ancien ensemble de confiance et continue d’accepter ou de générer des chaînes selon sa propre configuration.

Pour les équipes informatiques, la distinction pratique se situe donc entre la protection du navigateur contrôlée par l’éditeur et les décisions de confiance contrôlées localement. La réponse CRLSet de Chrome, les protections de Google Play Services, l’action OneCRL de Firefox et les changements du magasin de racines réduisent le risque pour les clients qui les reçoivent et les appliquent. Ils ne prouvent pas que chaque composant d’un parc consommant des certificats bénéficie de la même couverture. La question restante n’est pas simplement de savoir si les utilisateurs disposent de navigateurs à jour, mais si l’organisation a recensé les logiciels et les appareils qui gèrent des magasins de confiance distincts, effectuent des vérifications de révocation indépendantes ou continuent de fonctionner lorsque ces vérifications échouent.

Les perturbations opérationnelles auxquelles les équipes informatiques doivent s’attendre

Retirer la confiance accordée à une autorité de certification compromise est nécessaire pour les clients capables d’appliquer ce changement, mais l’opération n’est pas neutre sur le plan opérationnel. Les recommandations de Google avertissent que la suppression de emSign ECC Root CA - G3 peut interrompre des certificats légitimes qui dépendent encore de cette racine ou d’une chaîne associée. L’analyse de Mozilla identifie également plusieurs chemins concernés, notamment des chemins de racines et de signatures croisées. Pour les équipes informatiques, la question pratique n’est donc pas simplement de savoir si un navigateur signale qu’un certificat est approuvé. Il faut déterminer si un service métier, un dispositif d’inspection, un paquet logiciel ou un processus de validation dépend encore d’un chemin qui est sur le point de ne plus être approuvé.

Les sites web doivent être considérés comme une catégorie d’inventaire parmi d’autres, et non comme un indicateur de l’ensemble du parc. Un service public peut présenter un certificat au moyen d’une chaîne que les navigateurs mettent rapidement à jour, tandis qu’un service interne, un point de terminaison ancien ou un client qui n’est pas un navigateur continue de construire cette chaîne différemment. La même distinction s’applique aux serveurs : un serveur peut être correctement configuré pour les connexions entrantes tout en dépendant encore d’un certificat concerné lorsqu’il effectue des appels sortants. La découverte des certificats doit donc couvrir à la fois les certificats présentés par les services détenus par l’organisation et ceux approuvés par les systèmes qui les exploitent.

L’inspection TLS introduit un autre mode de défaillance. Les appliances réseau et les proxys d’entreprise terminent souvent une connexion, l’inspectent, puis établissent une seconde connexion au nom de l’utilisateur. Si une appliance possède son propre magasin de confiance, son bundle de certificats intégré ou une logique de validation gérée par le fournisseur, une mise à jour du navigateur sur le poste client peut ne rien changer à la façon dont cette appliance évalue la chaîne concernée. À l’inverse, le remplacement ou la suppression d’un certificat utilisé par un système d’inspection peut interrompre le trafic de nombreux utilisateurs en même temps. Les passerelles d’inspection, les équilibreurs de charge et les autres intermédiaires doivent être examinés comme des consommateurs de confiance indépendants, en consignant séparément leur configuration et leurs mécanismes de mise à jour de ceux des navigateurs des postes clients.

Les images de conteneurs et les environnements applicatifs créent une séparation similaire entre le système d’exploitation et la charge de travail. Une image peut contenir un bundle d’autorités de certification fourni au niveau des paquets, qui reste inchangé après la mise à jour de l’hôte. Les déploiements Java et les autres applications dotées de leurs propres bundles de certificats peuvent également continuer à utiliser un magasin de confiance intégré plutôt que celui de la plateforme. L’image, l’environnement d’exécution et le bundle applicatif constituent donc des questions d’inventaire distinctes. Les équipes doivent déterminer quels services héritent de la confiance de l’hôte, lesquels copient des certificats dans l’image et lesquels gèrent un bundle privé à mettre à jour via leur propre processus de publication applicative.

La validation des signatures de code doit être vérifiée indépendamment de HTTPS. Les certificats intermédiaires eMudhra compromis comprennent des intermédiaires de signature de code ainsi que des intermédiaires TLS ; une réponse centrée sur les navigateurs ne prouve donc pas que les chemins de validation des logiciels ont été examinés. Les systèmes de compilation, les outils de sécurité des terminaux, les gestionnaires de paquets et les autres systèmes qui valident les signatures peuvent utiliser des racines, des intermédiaires ou des comportements de révocation différents. Ils peuvent aussi appliquer leurs politiques à un moment différent de celui d’un navigateur ou d’un magasin de confiance du système d’exploitation. La question pertinente n’est pas de savoir si un poste de travail a reçu une mise à jour du navigateur, mais si chaque système qui accepte des logiciels signés a évalué les chemins de signature concernés.

Le risque de panne est le plus élevé lorsque la confiance est dupliquée, intégrée ou gérée par des appliances. Une suppression étendue peut fermer un chemin compromis pour les clients qui respectent la nouvelle politique, tout en rendant indisponible un service légitime lorsque sa chaîne de certificats n’a pas été remplacée. Une réponse limitée peut préserver la disponibilité tout en laissant des clients non gérés exposés. Ce compromis plaide pour une cartographie des dépendances avant toute modification à l’échelle du parc : consignez le certificat, la chaîne, le magasin de confiance, le composant de validation et le service métier concernés, puis testez le résultat dans l’environnement qui effectue réellement la validation.

Pour les parcs mixtes, « mis à jour » doit donc désigner davantage qu’une version récente du navigateur. Cela signifie que les chaînes utilisées par les sites concernés, les configurations des serveurs, les équipements d’inspection, les magasins de confiance des conteneurs et de Java, les bundles applicatifs et les validateurs de signatures de code ont été pris en compte. Lorsqu’une modification du magasin de racines peut affecter des certificats légitimes, les équipes doivent la déployer par étapes et prévoir un plan de retour arrière associé à des dépendances de service testées. L’objectif est une défiance maîtrisée : supprimer la dépendance aux chemins compromis tout en conservant une procédure claire, fondée sur des éléments vérifiables, pour rétablir le service si une chaîne légitime a été négligée.

Un plan de réponse défendable pour les parcs mixtes

La réponse la plus sûre consiste à traiter l’incident eMudhra comme un exercice d’inventaire des magasins de confiance et des certificats, et non comme une simple tâche de mise à jour des navigateurs. Commencez par déterminer où les certificats intermédiaires eMudhra concernés et leurs racines parentes sont approuvés dans le parc : postes de travail administrés, serveurs, conteneurs, bundles Java et applicatifs, équipements réseau, dispositifs d’inspection TLS, appareils mobiles, ainsi que systèmes de compilation ou de signature. La question pertinente n’est pas seulement de savoir si un navigateur est à jour. Il faut déterminer si une connexion critique pour l’activité, une bibliothèque de validation, un équipement ou un processus de signature de logiciels peut encore accepter une chaîne qui ne devrait plus être considérée comme fiable.

Utilisez les recommandations des éditeurs comme premier point de contrôle. Appliquez les mises à jour pertinentes de Chrome, Firefox, Android, Ubuntu et des autres paquets selon le processus habituel de gestion des changements, puis vérifiez que la modification attendue du magasin de confiance ou de la révocation est bien présente sur des systèmes représentatifs. La mise à jour Ubuntu de ca-certificates est particulièrement importante pour les systèmes qui s’appuient sur le bundle de confiance de la distribution, tandis que les navigateurs et applications disposant de leurs propres magasins doivent être contrôlés séparément. Consignez, pour chaque plateforme prise en charge, la version du paquet ou du navigateur, l’état de la mise à jour et l’état du magasin de confiance, afin que la mention « corrigé » repose sur une vérification concrète plutôt que sur le seul enregistrement de connexion de l’appareil.

Cartographiez ensuite les certificats et les chemins de validation. Recherchez les certificats intermédiaires eMudhra concernés et les racines associées dans les inventaires de certificats, les configurations des répartiteurs de charge et des serveurs web, les maillages de services, les images de conteneurs, les keystores Java, les bundles applicatifs, les profils d’inspection et les règles des équipements. Pour les certificats exposés aux clients, identifiez la chaîne complète réellement fournie par chaque point de terminaison ; un certificat peut être valide dans un navigateur alors qu’un autre client, un proxy ou une bibliothèque côté serveur emprunte un chemin différent. Pour le trafic émis en interne ou inspecté, examinez les deux côtés de la connexion : la configuration de confiance du dispositif d’inspection et le magasin de confiance du client qui reçoit le certificat réémis. Gardez la validation des signatures de code distincte de l’analyse TLS, car un certificat de signature peut affecter la distribution et l’exécution des logiciels même lorsqu’aucun navigateur web n’est concerné.

Le remplacement doit précéder la modification du Chrome Root Store prévue le 27 octobre. Tout certificat client qui dépend d’un chemin concerné doit être réémis ou remplacé par une chaîne ne dépendant ni des certificats intermédiaires compromis ni d’une racine dont la défiance est programmée, puis déployé selon une séquence contrôlée. Le but opérationnel est d’éliminer la dépendance risquée avant que les clients n’appliquent le nouvel état, et non d’attendre des échecs de connexion pour découvrir quel service a été oublié. Le remplacement des certificats doit couvrir la chaîne fournie, le déploiement des certificats intermédiaires, l’automatisation du renouvellement ainsi que tout lien de confiance épinglé ou explicitement configuré qui pourrait empêcher l’acceptation de la nouvelle chaîne.

Les tests doivent couvrir les chemins que les contrôles habituels dans les navigateurs ne détectent pas. Constituez une matrice réduite mais représentative des sites web critiques pour l’activité, des API, des intégrations sortantes, des consoles d’administration, des itinéraires d’inspection, des services conteneurisés, des applications Java, des flux mobiles et des processus de signature ou de mise à jour des logiciels. Effectuez les tests depuis les segments réseau administrés et non administrés lorsqu’ils sont tous deux concernés, avec les magasins de confiance et les versions de navigateur mis à jour que recevront les systèmes de production. Le simple chargement réussi d’une page ne constitue qu’un résultat parmi d’autres ; consignez la validation de la chaîne de certificats, le comportement du proxy, celui des bibliothèques applicatives et la possibilité d’installer ou de valider des logiciels signés lorsque ces fonctions sont importantes.

Comme la suppression d’une racine peut interrompre des certificats légitimes, la mise en place de la méfiance doit être progressive lorsque l’environnement ne peut pas être évalué entièrement durant une seule fenêtre de maintenance. Commencez par inventorier les actifs et identifier les dépendances, puis mettez à jour un groupe pilote contrôlé, observez les défaillances et élargissez la couverture une fois les chemins critiques validés. Lorsqu’un service dépend d’un certificat désormais rejeté, le retour en arrière à privilégier consiste à corriger, côté service, le certificat ou la chaîne, en le documentant. Si une exception de confiance temporaire est inévitable, traitez-la comme une décision explicite de prise de risque, limitée dans le temps, avec un responsable et une date de retrait, plutôt que de rétablir discrètement une confiance étendue dans tout le parc.

Enfin, conservez les éléments prouvant à la fois les actions menées et leur couverture : actifs concernés découverts, certificats remplacés, mises à jour des fournisseurs installées, magasins de confiance inspectés, cas de test réalisés, exceptions approuvées et lacunes restantes attribuées. Ce dossier permet de distinguer une absence réelle d’exposition d’un système qui n’a pas été testé et facilite le suivi lorsque d’autres paquets, applications ou appliances publient leurs propres consignes de correction. Le résultat défendable ne se résume pas au changement de comportement des principaux navigateurs : l’organisation doit pouvoir montrer où la confiance a été appliquée, où elle a été supprimée, quels services ont été testés et comment l’incertitude restante est gérée.