Une clé de certificat d’eMudhra valait 4, de quoi usurper n’importe quel site web

La clé secrète d’un des certificats qui attestent l’identité d’un site web s’est révélée être le chiffre quatre. Pas un long nombre aléatoire commençant par quatre : juste quatre. Sept autres clés de la même autorité de certification indienne, eMudhra, étaient à peine plus complexes. Quiconque les détient peut créer un certificat pour n’importe quel site, d’une banque à un service de messagerie, que les logiciels faisant confiance à eMudhra accepteront comme authentique.

Ce sont ces certificats que vérifie le cadenas affiché dans votre navigateur. Avec un faux certificat, un attaquant placé entre vous et Internet — sur le Wi-Fi d’un café, un routeur piraté ou un réseau national hostile — peut se faire passer pour le véritable site et lire ou modifier ce que vous lui envoyez. Chrome, Firefox, Safari et les plateformes de Microsoft ont déjà cessé de faire confiance aux huit certificats. En revanche, de nombreux autres logiciels installés sur vos appareils continuent de leur faire confiance.

Une clé classique de ce type est un nombre aléatoire d’environ 384 bits, soit quelque 10 puissance 115 possibilités. Les clés d’eMudhra comptaient entre 3 et 8 bits : 4, 56, 66, 115, 155, 156, 230 et 237, selon la liste publiée par Ars Technica. Le chercheur en sécurité Scott Helme a expliqué avoir retrouvé les huit clés dans les certificats publics présents sur son ordinateur portable : « et cela a pris moins d’une seconde ». Il a ajouté par la suite qu’Anthropic’s Claude avait fait de même à partir d’une seule instruction.

Personne n’a eu besoin de voler quoi que ce soit. Dans sa réponse à Mozilla, rapportée par BleepingComputer, eMudhra a incriminé un bogue dans le script utilisé lors de la cérémonie de génération des clés : celui-ci avait créé un deuxième jeu de clés, vulnérable, et les employés l’ont sélectionné par erreur parce que ses étiquettes ressemblaient à celles de l’autre jeu. L’entreprise, qui affirme avoir délivré plus de 60 millions de certificats numériques, a indiqué à Mozilla que la plupart des certificats intermédiaires concernés n’avaient jamais été utilisés en production et qu’elle n’avait trouvé aucune preuve qu’ils aient servi à signer des certificats destinés aux utilisateurs finaux. Elle a révoqué les huit certificats et interrompu les émissions sous la racine concernée.

Les navigateurs sont le problème le plus facile à régler. Chrome, Firefox et Safari transmettent discrètement des listes de révocation aux utilisateurs et exigent également que chaque certificat figure dans les journaux publics de Certificate Transparency. Or aucun certificat de site web rattaché à ces clés n’y est jamais apparu : par défaut, les navigateurs à jour n’ont donc pas été exposés. Le problème se trouve partout ailleurs. Les outils en ligne de commande comme curl, les langages comme Python, Node et Go, les clients VPN, les conteneurs Docker et les objets connectés domestiques conservent leur propre liste d’autorités de confiance, vérifient rarement les révocations et ignorent les journaux de transparence. Helme a créé un faux certificat pour l’API de paiement de Stripe et constaté que curl, Python et Node l’acceptaient sur toutes les machines Linux et macOS qu’il a testées.

« Le nettoyage va être colossal, bien plus important que pour Heartbleed », a déclaré à Ars Technica Filippo Valsorda, mainteneur du code cryptographique du langage Go, en évoquant la faille d’OpenSSL dont les conséquences ont mis des années à être résorbées. Il s’attend à « une très, très longue traîne » d’objets connectés, de conteneurs Docker, de vieilles machines Linux oubliées et d’outils qui ne sont plus maintenus, mais embarquent leur propre copie des autorités de confiance. Pour exploiter les clés, un attaquant doit tout de même se trouver sur le trajet du réseau, ce qui rend l’opération accessible à des gouvernements, à un réseau professionnel compromis ou à l’exploitant d’un point d’accès public. Signal, WhatsApp et WireGuard, qui ne s’appuient pas sur ces certificats pour leur chiffrement, ne sont pas concernés, précise Ars.

Les clés pouvaient être retrouvées depuis la création des certificats, en avril 2025, soit pendant environ 17 mois, et il est impossible de savoir si quelqu’un les a utilisées contre des logiciels qui ne vérifient pas les journaux de transparence. En mai 2025, chaque certificat a également été cosigné par la racine AAA Certificate Services de Sectigo, ce qui a élargi l’ensemble des systèmes qui leur faisaient confiance.

Pour la plupart des utilisateurs, la solution consiste à installer les mises à jour. Un chercheur a signalé les clés aux éditeurs de navigateurs le 17 octobre. Mozilla a bloqué les certificats dans Firefox en moins de trois heures, le jour même, puis a publié le 20 octobre Firefox 158.0.1, de nouvelles versions ESR et NSS 3.131.1, qui supprime la racine eMudhra. Apple a ajouté une protection le 19 octobre et Microsoft le 20 octobre, selon le site consacré à l’incident, tenu par Dennis Jackson, ingénieur chez Mozilla. Ars a toutefois constaté, au moment de sa publication, qu’Edge sous Windows 10 se connectait encore aux serveurs de test. Go 1.27.3 et 1.26.10, pip 26.2.2, uv 0.13.4 et certifi 2026.10.19 sont disponibles ; Cloudflare a mis à jour ses applications WARP et 1.1.1.1, et les distributions Linux continuent de publier de nouveaux paquets ca-certificates. Sur macOS, curl reste intégré au système et continue de faire confiance aux clés tant que son fichier de certificats n’est pas modifié manuellement.

Chrome a confirmé que la racine eMudhra serait supprimée de son Chrome Root Store dans la version 43. Tant que tous les appareils n’auront pas été mis à jour, huit bits suffiront à séparer de nombreux logiciels du quotidien d’une copie convaincante de n’importe quel site.

Étiquettes: cybersécurité, Mozilla, Firefox, certificats TLS, chiffrement, eMudhra