Des clés trop faibles chez l'émetteur de certificats eMudhra imposent des correctifs urgents à Go et Java

En avril 2025, l'autorité de certification indienne eMudhra a créé huit certificats intermédiaires dotés de clés extrêmement faibles, faute d'un aléa suffisant. Selon Help Net Security, chaque clé privée était inférieure à 256, si bien qu'un attaquant avait besoin de 256 essais au maximum. Des chercheurs ont extrait les clés des certificats publics en moins d'une seconde, rapporte CSO Online. Six certificats servaient au TLS, deux à la signature de logiciels. Quiconque détenait ces clés pouvait émettre des certificats de confiance pour n'importe quel domaine et usurper ainsi des sites web.

Un chercheur a découvert le problème le 17 octobre. Chrome et Firefox ont bloqué les certificats le jour même, Apple et Microsoft ont suivi dans les jours suivants. Google retire en outre de Chrome le certificat racine sous-jacent, emSign ECC Root CA G3. eMudhra affirme qu'un seul certificat intermédiaire était en service et qu'aucun certificat client n'a été émis avec ces clés. Quelque 30.000 certificats doivent malgré tout être migrés, et l'entreprise se retire du marché mondial des certificats TLS, écrit Inc42.

Dans un bilan publié le 26 octobre, l'équipe de Go explique pourquoi elle a recouru pour la première fois à une procédure d'urgence. Sous Linux, Go vérifie les certificats avec son propre outil, dépourvu de mécanisme de révocation intégré. Moins de 7 heures et demie après le signalement, Go 1.27.3 et 1.26.10 étaient en ligne et rejetaient les certificats concernés. La publication elle-même a pris près de 4 heures et quart à cause de goulets d'étranglement jamais apparus auparavant. La prochaine fois, l'équipe veut annoncer une telle version à l'avance, et elle souhaite offrir sous Linux la même prise en charge de la révocation que sous Windows et macOS. Les programmes Go qui établissent des connexions TLS doivent être recompilés avec les dernières versions.

Java a également dû réagir, rapporte InfoQ. Oracle a publié une alerte de sécurité et Azul a sorti le 21 octobre, hors du cycle habituel, une mise à jour qui bloque les certificats dans le JDK. Azul rappelle que Java ne vérifie pas par défaut la révocation des certificats, de sorte qu'une application Java peut accepter un certificat falsifié tant que le JDK ne le bloque pas. Interrogé par CSO Online, un analyste conseille aux entreprises de vérifier surtout les anciennes applications Java, ainsi que les plateformes de paiement, les applications mobiles et les équipements réseau qui utilisent leur propre liste de confiance.