Apple, Google, Microsoft et Mozilla ont bloqué huit certificats émis par eMudhra, une autorité de certification basée à Bangalore. La raison : les clés privées associées étaient si banales qu’on pouvait les calculer à partir des certificats publics. Pour ceux qui utilisent un Safari, un Chrome ou un Firefox à jour, il n’y a rien à faire. Le risque résiduel concerne les logiciels et appareils qui ne s’appuient pas sur les blocages des navigateurs.
Ce qui s’est passé
Le 17 octobre, un chercheur connu sous le nom de Wayne a signalé le problème aux responsables des programmes de confiance des navigateurs. Pour le prouver, il a signé un message avec chacune des huit clés. Le chercheur Scott Helme les a ensuite reconstituées en moins d’une seconde : l’une d’elles était tout simplement le nombre 4, alors qu’une clé de ce type devrait être un nombre aléatoire de 384 bits.
Les certificats concernés sont huit autorités intermédiaires : six servent à la sécurité des sites, deux à la signature de code. Avec la clé privée d’une autorité, un individu malveillant pourrait émettre de faux certificats pour n’importe quel site et se faire accepter par les navigateurs et les applications. Il faudrait toutefois intercepter le trafic entre les deux parties, ce qui n’est pas une attaque anodine.
Selon eMudhra, l’origine serait une cérémonie de génération de clés du 30 avril 2025 : une étape de chiffrement et de déchiffrement aurait produit un second jeu de clés faibles à côté des clés robustes, et ce sont les premières qui se seraient retrouvées par erreur dans les certificats. L’entreprise exclut toute intrusion dans sa propre infrastructure et affirme enquêter encore sur la cause exacte.
Qui a déjà réagi
- Chrome et Firefox : blocage dans les heures suivant le signalement, sans obligation de mettre à jour ni de redémarrer. Google retirera aussi du Chrome Root Store le certificat racine concerné, emSign ECC Root CA – G3, à partir du 27 octobre.
- Apple : blocage actif depuis le 19 octobre dans Safari, Mail et les applications qui utilisent les frameworks réseau et sécurité du système.
- Android : blocage déployé via Google Play Services, également depuis le 19 octobre.
- Microsoft : blocage depuis le 20 octobre.
Google a précisé qu’aucun certificat de site dérivé de ces autorités n’apparaissait dans les registres publics de Certificate Transparency avant le blocage. À ce jour, aucune preuve d’abus n’a été relevée.
Là où le problème subsiste
Le nœud du problème se situe en dehors des navigateurs. De nombreux programmes ne vérifient ni les révocations ni Certificate Transparency et continuent de faire confiance tant que leur propre liste de certificats n’est pas mise à jour. C’est le cas d’outils en ligne de commande, de conteneurs, de clients d’API et d’appareils dotés de leur propre magasin de confiance.
Sur Mac aussi, il y a une exception : certains outils de terminal peuvent encore accepter les certificats compromis. Apple prépare une mise à jour de macOS qui modifiera le fichier /etc/ssl/cert.pem, sans donner de date. En attendant, ceux qui utilisent ces outils peuvent supprimer à la main les certificats racine concernés de ce fichier.
Côté Linux et développement, des mises à jour sont déjà sorties pour Go, Python (certifi), pip, uv, Electron et pour les paquets ca-certificates d’Ubuntu, Debian, Fedora, Arch et Alpine. D’autres signalements indiquent en revanche que Signal, WhatsApp et WireGuard ne sont pas touchés, car ils ne s’appuient pas sur TLS pour la confidentialité.
Ce que doit faire un utilisateur ordinaire
Peu de choses : garder à jour son système d’exploitation et son navigateur, et installer les mises à jour de macOS à leur arrivée. Quiconque gère un site avec des certificats liés à la racine emSign doit passer à une autre autorité avant le 27 octobre. Et celui qui voit des erreurs de certificat dans des applications d’entreprise ne devrait jamais désactiver la vérification : ce serait retirer la protection qui vient d’être rétablie.
Ce que nous en pensons
La réaction des grands acteurs a été rapide : en quelques heures pour Chrome et Firefox, en trois jours pour Apple et Microsoft. Le cas montre cependant à quel point le système des autorités de certification dépend d’une seule erreur dans une cérémonie de génération que personne n’a revérifiée pendant plus d’un an. Le fait que la clé soit le nombre 4 laisse penser qu’un contrôle automatique élémentaire aurait pu l’arrêter.
La longue traîne en dehors des navigateurs est la partie à surveiller. Pour l’utilisateur lambda, le dommage probable est minime, mais les routeurs, les appareils de maison connectée et les serveurs oubliés reçoivent rarement ces mises à jour. Pour l’Italie, il y a peu à craindre sur le front des signatures numériques nationales : eMudhra déclare que son activité de signature numérique en Inde tourne sur une infrastructure séparée, et l’affaire ne concerne que sa branche mondiale des certificats de sites, environ 1 % du chiffre d’affaires. Pour les professionnels de la sécurité, cela reste un rappel concret : chaque magasin de confiance intégré à une application doit être mis à jour comme n’importe quelle autre dépendance. Comme nous l’avons vu dans notre article sur la protection avancée de Google Messages, les défenses les plus efficaces restent celles qui se mettent à jour toutes seules.
Article de la rédaction de SpazioiTech, rédigé avec l’aide d’outils d’intelligence artificielle à partir de faits vérifiés auprès d’au moins deux médias indépendants, et contrôlé avant publication. Une erreur ? Écrivez-nous.
Traduit de l’original italien. Lire en italien
