La confiance des navigateurs reste trop fragile pour que cet échec passe inaperçu

Et si l’icône du cadenas faisait bien son travail, mais pas les logiciels qui la sous-tendent ? C’est la leçon dérangeante de la compromission de l’autorité de certification eMudhra. Aucun utilisateur n’a eu besoin de cliquer sur une pièce jointe malveillante ou d’accepter une boîte de dialogue alarmante: la possession des clés privées de huit autorités de certification intermédiaires pouvait permettre à un attaquant de créer des certificats semblant légitimes pour les clients vulnérables.

L’incident a été révélé après qu’un chercheur a identifié, le 17 octobre 2026, une faiblesse cryptographique touchant des certificats exploités par eMudhra dans le cadre de son infrastructure emSign. Mozilla a retrouvé indépendamment les clés concernées et indiqué que le processus de génération des clés sous-jacent était défectueux et facile à exploiter. Six autorités intermédiaires étaient utilisées pour les certificats TLS et deux pour la signature de code. Le risque n’était pas purement théorique: une personne disposant de l’une de ces clés pouvait potentiellement émettre des certificats s’inscrivant dans une chaîne de confiance reconnue.

Les navigateurs ont réagi rapidement. Chrome a déployé un blocage visant les six autorités intermédiaires TLS le 17 octobre, et Firefox a diffusé ce soir-là un blocage via OneCRL. The Hacker News rapporte que Chrome n’avait trouvé aucun certificat frauduleux dans les journaux de transparence des certificats avant son blocage. C’est rassurant, mais cela ne suffit pas à valider le modèle de confiance. Cela montre seulement qu’une couche de défense a fonctionné, pas que tous les clients ont bénéficié de la même protection.

Le navigateur ne constitue pas tout l’écosystème HTTPS

Le débat public traite souvent la sécurité des navigateurs comme si le navigateur était l’arbitre universel de la sécurité sur internet. Ce n’est pas le cas. Les applications, services, équipements, API et environnements d’exécution peuvent valider les certificats au moyen des magasins système, de fichiers intégrés ou de leurs propres règles. Certains ne prennent pas rapidement en compte les informations de révocation, et certains n’appliquent pas la transparence des certificats de la même manière que les navigateurs.

C’est là que CVE-2026-111943 prend son importance. Le projet Go a ajouté une liste de refus à crypto/x509 dans Go 1.26.10 et 1.27.3, faisant échouer la vérification lorsqu’une chaîne contient l’une des clés intermédiaires compromises connues. Red Hat décrit clairement l’exposition sous-jacente: une application Go pouvait accepter un certificat non autorisé signé par une autorité intermédiaire à laquelle la confiance avait été retirée, permettant une attaque de type homme du milieu si l’attaquant pouvait intercepter la connexion.

À notre avis, il s’agit moins d’une histoire concernant un langage vulnérable que d’un problème de maintenance fragmentée de la confiance. Un navigateur peut recevoir rapidement un blocage à distance tandis qu’un service backend continue d’utiliser un ensemble obsolète de certificats. Un utilisateur de bureau peut être protégé alors qu’un client d’API interne ne l’est pas. Le chiffrement reste mathématiquement robuste; le problème est que le système doit d’abord décider quelle clé mérite sa confiance.

La révocation est un patchwork, pas un filet de sécurité

La réponse révèle également une hiérarchie inconfortable entre les mécanismes de défense. Chrome et Firefox ont bloqué les autorités intermédiaires concernées, tandis que Google indiquait que la suppression de l’autorité racine emSign ECC Root CA - G3 du magasin de certificats racines de Chrome devait être répercutée sur les appareils dépendants le 27 octobre 2026. Google a averti que certains certificats légitimes rattachés à cette racine cesseraient de fonctionner et que les exploitants des sites concernés devraient obtenir de nouveaux certificats.

Ce compromis est nécessaire. Dès lors que les clés privées sont considérées comme récupérables, préserver la commodité des détenteurs de certificats ne peut pas être la priorité. Mais cela crée un problème pratique: une mesure défensive peut interrompre des connexions légitimes, tandis qu’une réaction tardive peut maintenir des connexions frauduleuses. Les opérateurs subissent alors la pression de « corriger » les pannes en affaiblissant la vérification — exactement la mauvaise réponse. Comme le souligne Rescana, les clients mis à jour peuvent générer des erreurs TLS avec des partenaires ou des fournisseurs qui utilisent encore les chaînes compromises; ces erreurs doivent déclencher le remplacement des certificats, et non la désactivation de leur validation.

Le point le plus préoccupant est que les utilisateurs ordinaires ne peuvent pas distinguer ces situations de manière fiable. Une alerte du navigateur est visible. Un backend qui accepte une chaîne incorrecte ne l’est pas. L’utilisateur ne peut pas non plus savoir si un service utilise un magasin de certificats à jour, un ensemble de certificats intégré ou un environnement d’exécution ayant reçu son correctif d’urgence. L’architecture de confiance est distribuée, mais la responsabilité de son maillon le plus faible ne l’est pas.

Les blocages rapides des navigateurs ont limité les dégâts — mais aussi masqué les lacunes

Les éléments disponibles ne montrent pas d’exploitation généralisée de certificats TLS frauduleux avant la réaction défensive. L’obligation de transparence des certificats de Chrome semble avoir empêché qu’un certificat publiquement approuvé mais absent des journaux soit accepté par Chrome et les autres navigateurs qui appliquent cette transparence. Le 21 octobre, eMudhra a déclaré ne disposer d’aucun élément prouvant que les clés faibles avaient été récupérées ou exploitées avant leur divulgation, tandis que Mozilla indiquait que plusieurs personnes les avaient retrouvées indépendamment par la suite.

Cette distinction est importante. L’incident a été suffisamment bien contenu pour qu’aucun élément ne fasse état d’une exploitation généralisée dans les navigateurs, mais « aucun abus connu » ne signifie pas « aucune exposition significative ». Les logiciels qui ne prenaient pas en compte les mêmes signaux de révocation et de transparence étaient également concernés. L’avis de Red Hat décrit, pour ses produits, les conséquences d’une compromission de la clé privée d’une autorité de certification tierce sur les systèmes via leurs magasins de certificats.

C’est pourquoi cet incident ne doit pas être classé dans la catégorie « les navigateurs ont réglé le problème ». Les navigateurs n’en ont traité qu’une partie. Le reste du travail s’est déplacé vers les systèmes d’exploitation, les environnements d’exécution, les conteneurs, les équipements d’entreprise et les dépendances applicatives — des domaines où les changements urgents de confiance sont plus difficiles à repérer et plus lents à déployer.

La bonne leçon consiste à réduire la confiance, pas seulement à la réactualiser

Les conseils immédiats sont simples: mettre à jour les environnements d’exécution et les applications concernés, vérifier les chaînes de certificats, remplacer les certificats liés aux autorités intermédiaires compromises et ne jamais désactiver la vérification des certificats pour faire disparaître une erreur. Le correctif de Go est particulièrement important pour les déploiements dont la configuration de confiance du système risque de ne pas être mise à jour rapidement. La fiche CVE consacrée à Go décrit la mesure corrective précise: rejeter les chaînes contenant les autorités intermédiaires compromises.

La recommandation plus générale est moins confortable. Les organisations devraient recenser les systèmes qui valident leurs connexions TLS et la manière dont ils le font, au lieu de supposer que « le navigateur » représente tous les clients. La surveillance des certificats, la mise à jour des dépendances et la désignation claire des responsables des magasins de certificats ne sont pas des mesures spectaculaires, mais cet incident montre leur utilité.

Notre verdict: la réaction des navigateurs a été rapide et les mécanismes de transparence semblent avoir limité les abus publics. Pourtant, le modèle sous-jacent reste trop fragile, car il demande à un nombre immense de systèmes indépendants de s’accorder sur la confiance, tout en ne laissant aux utilisateurs presque aucun moyen de constater ces divergences. HTTPS reste indispensable. L’icône du cadenas reste utile. Mais ni l’un ni l’autre ne doit être pris pour la preuve que toutes les couches qui se trouvent dessous sont à jour.