Certificats Emudhra Compromis Bots Crypto Exposés

Vous regardez le petit cadenas à gauche de l’adresse, vous entrez votre mot de passe d’exchange et vous cliquez. Depuis le week-end dernier, ce réflexe rassurant protège un peu moins qu’avant. Huit certificats intermédiaires émis par l’autorité indienne eMudhra ont été générés avec des clés privées tellement faibles qu’un simple ordinateur portable les retrouve en moins d’une seconde. N’importe qui possédant ces clés pouvait signer un faux certificat pour n’importe quel site, y compris les plus gros exchanges. Les navigateurs ont déjà bouché la brèche. Vos bots de trading et vos scripts maison, eux, n’ont probablement rien vu venir.

Comment une clé privée égale à 4 a fait trembler le web

Quand un site se présente en HTTPS, il montre un certificat, une sorte de carte d’identité numérique signée par une autorité de certification. Les navigateurs font confiance à une centaine d’autorités racines. Celles-ci délèguent le travail quotidien à des intermédiaires. Celui qui détient la clé privée d’un intermédiaire peut créer un certificat parfaitement valide pour coinbase.com, binance.com ou n’importe quel autre domaine. Le navigateur affichera alors le cadenas sans la moindre alerte.

C’est exactement ce qui s’est produit. eMudhra, qui commercialise ses certificats sous la marque emSign et affirme avoir émis plus de 60 millions de certificats, a généré le 30 avril 2025 huit intermédiaires. Six destinés au web, deux à la signature de code. Le problème ? Les clés privées correspondantes étaient des entiers inférieurs à 256. L’une d’elles était tout simplement le nombre 4. Une autre valait 56. Une troisième 115. Des chercheurs, dont Scott Helme, les ont extraites des certificats publics en moins d’une seconde.

Une clé P-384 normale est un nombre aléatoire sur 384 bits, soit environ 10 puissance 115 possibilités. Ici, on parlait de nombres que l’on compte sur les doigts d’une main.

Scott Helme

Un membre de la communauté, connu seulement sous le prénom de Wayne, a signé le message « We have a problem here » avec chacune des huit clés et l’a transmis aux programmes racines le samedi 17 octobre. eMudhra a reconnu dans le ticket Bugzilla de Mozilla un défaut du script utilisé lors de la cérémonie de génération des clés, ainsi que « des erreurs humaines à plusieurs étapes du processus ».

Ce que les navigateurs ont fait en quelques heures

La réaction a été ultra-rapide. D’après le billet de Mozilla, le rapport est arrivé à 20 h 06 UTC le 17 octobre. Le blocage via OneCRL était déjà poussé à toutes les installations Firefox à 22 h 59. Chrome avait verrouillé dès 19 h 45 grâce à ses CRLSets. Apple a suivi le 19 octobre, Microsoft le 20. Ces listes de révocation se mettent à jour automatiquement. Aucune réinstallation ni redémarrage n’était nécessaire.

Plus rassurant encore : aucun certificat signé par ces intermédiaires n’apparaît dans les journaux de Certificate Transparency. Ce registre public, obligatoire pour être accepté par Chrome ou Safari, n’a rien enregistré de suspect. Personne n’a donc pu piéger un utilisateur via un navigateur moderne à jour. Le danger se situe ailleurs.

Le vrai angle mort : vos bots et scripts maison

Cloudflare, qui a découvert l’affaire le 19 octobre vers 17 h UTC, le dit sans détour : un attaquant peut créer un certificat forgé pour n’importe quel domaine et s’en servir pour se faire passer pour des serveurs afin d’intercepter ou de modifier le trafic. Les programmes écrits en Go ou les scripts Python qui embarquent le paquet certifi ne consultent aucune liste de révocation. Ils continuent de faire confiance à eMudhra tant qu’on ne les recompile pas.

Go et certifi ont publié leurs correctifs le 20 octobre. Node.js n’en était encore qu’à un brouillon au moment où ces lignes sont écrites. Pour un utilisateur qui se connecte à Binance ou Kraken depuis Chrome ou Firefox à jour, le risque est déjà traité. Il suffit de vérifier qu’aucune mise à jour n’attend et, sur Linux, de mettre à jour le paquet ca-certificates. Ubuntu, Debian et Arch ont déjà livré leur correctif.

Le vrai problème, c’est votre bot de trading ou votre script d’arbitrage qui appelle l’API d’un exchange en Python ou en Go. Un faux certificat signé avec l’une des huit clés y passerait sans alerte, à condition que l’attaquant soit déjà positionné sur votre chemin réseau (wifi public, DNS détourné, proxy malveillant). Il faut mettre à jour les dépendances pour qu’elles rejettent les certificats eMudhra compromis, puis redéployer. Et surtout, si des erreurs de certificat apparaissent après la mise à jour, ne les faites surtout pas disparaître en désactivant la vérification. C’est précisément la protection que vous venez de restaurer.

Pourquoi le cadenas ne suffit plus à vous protéger

Vérifier l’URL ne sert à rien contre un certificat forgé, puisque l’URL est la bonne. Ce qui vous sauve vraiment, c’est que la transaction se signe hors du navigateur. Un wallet matériel qui affiche l’adresse de destination sur son propre écran reste indifférent à ce qui se passe entre votre PC et le serveur. C’est l’une des rares protections qui ne dépendent pas des listes de confiance des navigateurs ou des bibliothèques système.

Mozilla a retiré de sa liste de confiance la racine emSign ECC Root CA – G3, celle qui signait les certificats eMudhra compromis, le 20 octobre. Chrome fera de même dans la version 43 de son magasin et réexamine la seconde racine d’eMudhra. L’autorité indienne a estimé à environ 30 000 le nombre de certificats clients à migrer vers sa racine RSA. C’est la deuxième entaille dans la confiance du web ce mois-ci, après les certificats frauduleux obtenus pour des domaines Google via trois registres nationaux piratés.

Les trois points de contrôle à vérifier absolument

Premier point : votre navigateur. S’il est à jour, le risque lié à ces huit certificats est déjà neutralisé. Deuxième point : vos scripts et bots. Vérifiez la date de mise à jour de vos bibliothèques de certificats. Troisième point : votre façon de signer les transactions. Tout ce qui se signe hors ligne ou sur un écran dédié reste à l’abri de cette attaque précise.

• Navigateur à jour : Chrome, Firefox, Safari ou Edge récents bloquent déjà les certificats concernés
• Dépendances logicielles : Python certifi, Go, Node.js doivent être mis à jour
• Wallet matériel : l’affichage de l’adresse sur l’écran de l’appareil reste la protection ultime

Comment eMudhra a pu générer des clés aussi faibles

La cérémonie de génération de clés d’une autorité de certification est normalement un moment extrêmement contrôlé. Des procédures strictes, du matériel dédié, plusieurs personnes présentes, des scripts audités. Ici, un défaut dans le script combiné à des erreurs humaines à plusieurs étapes a produit des clés privées qui n’avaient rien d’aléatoire. Le résultat ressemble à une blague de développeur junior, sauf que les conséquences touchent potentiellement des millions d’utilisateurs.

eMudhra n’est pas une autorité obscure. Elle revendique plus de 60 millions de certificats émis. Elle est présente dans les magasins de confiance des principaux systèmes d’exploitation et navigateurs. C’est précisément pour cette raison que l’incident a été traité avec une telle urgence. Une autorité de second rang aurait peut-être mis plusieurs jours à être révoquée. Ici, les équipes de Mozilla, Google, Apple et Microsoft ont agi en quelques heures.

Ce que cela change concrètement pour un trader crypto

Si vous tradez uniquement via un navigateur à jour et que vous confirmez chaque transaction sur un ledger ou un Trezor, votre exposition est quasi nulle. Si vous faites tourner des bots d’arbitrage, des market makers ou des scripts de monitoring qui parlent directement aux API des exchanges, vous devez vérifier vos dépendances dès maintenant. Un man-in-the-middle sur un wifi d’aéroport ou un DNS compromis pourrait autrement intercepter vos appels API sans déclencher d’alerte.

Les exchanges eux-mêmes ne sont pas en cause. Leurs certificats légitimes n’ont pas été falsifiés. Le risque vient de la possibilité de créer un faux certificat indiscernable pour un client qui ne vérifie pas les listes de révocation. C’est un classique de la sécurité : la chaîne de confiance est aussi solide que son maillon le plus faible. Ici, le maillon faible était un script de génération de clés défectueux.

Les leçons à retenir pour la suite

Première leçon : la confiance dans les autorités de certification n’est jamais absolue. Même les acteurs établis peuvent commettre des erreurs graves. Deuxième leçon : les navigateurs modernes sont bien protégés grâce aux mécanismes de révocation automatiques et à Certificate Transparency. Les applications et scripts maison le sont beaucoup moins. Troisième leçon : le hardware wallet reste l’une des meilleures protections contre ce type d’attaque, car il sort la signature hors du chemin réseau potentiellement compromis.

Ce n’est pas la première fois que le web tremble à cause d’une autorité de certification. DigiNotar en 2011, Symantec en 2017, et plus récemment d’autres incidents ont déjà montré que la chaîne de confiance peut se rompre. Chaque fois, les navigateurs ont renforcé leurs contrôles. Chaque fois, les applications non navigateur ont mis plus de temps à rattraper le retard.

Que faire concrètement dès aujourd’hui

Commencez par vérifier que votre navigateur est à jour. Sur Linux, mettez à jour le paquet ca-certificates. Ensuite, regardez les dépendances de vos bots. Si vous utilisez Python, mettez à jour le paquet certifi. Si vous utilisez Go, recompilez avec la dernière version. Pour Node.js, surveillez les mises à jour à venir. Enfin, si vous n’utilisez pas encore de wallet matériel pour les montants importants, c’est peut-être le moment d’y réfléchir.

Ne désactivez jamais la vérification des certificats pour faire taire une erreur. C’est exactement ce que l’attaquant espère. Une erreur de certificat après une mise à jour signifie que la protection fonctionne. Il faut corriger la cause, pas supprimer l’alerte.

Un incident qui s’inscrit dans un contexte plus large

Ce n’est pas un événement isolé. Le même mois a vu des certificats frauduleux obtenus pour des domaines Google via des registres nationaux piratés. La France a connu une vague de cyberattaques le 17 octobre touchant plusieurs millions de personnes. Le web devient un terrain de plus en plus disputé, et les autorités de certification restent un point de pression majeur pour les attaquants.

Pour le monde de la crypto, la leçon est particulièrement claire. Les montants en jeu sont élevés, les API sont souvent appelées de manière automatisée, et les traders utilisent fréquemment des environnements non navigateur. Chaque faille dans la chaîne de confiance HTTPS se transforme potentiellement en vecteur de vol de fonds. D’où l’importance de ne pas se contenter du cadenas vert.

Pourquoi Certificate Transparency a limité les dégâts

Certificate Transparency est un registre public où tout certificat web doit être consigné pour être accepté par les navigateurs modernes. Aucun des certificats signés par les intermédiaires eMudhra compromis n’y figure. Cela signifie qu’un attaquant n’aurait de toute façon pas pu déployer un faux certificat sur un site grand public sans être immédiatement détecté. Les navigateurs refusent les certificats absents de ces journaux.

Cette protection n’existe pas pour les clients non navigateur. Un script Python qui utilise la bibliothèque standard ou un ancien paquet certifi ne regarde pas Certificate Transparency. Il se contente de vérifier que la chaîne de certificats remonte à une racine qu’il connaît. C’est pourquoi les correctifs côté bibliothèques étaient indispensables.

Le rôle des listes de révocation automatiques

OneCRL chez Firefox et les CRLSets de Chrome sont des mécanismes de révocation poussés directement aux clients. Ils permettent de bloquer des certificats ou des intermédiaires sans attendre la prochaine version du navigateur. Dans le cas eMudhra, ces mécanismes ont fonctionné en quelques heures. C’est l’une des raisons pour lesquelles les utilisateurs de navigateurs à jour n’ont quasiment rien eu à faire.

Les applications et scripts n’ont pas d’équivalent aussi réactif. Ils dépendent des mises à jour manuelles des paquets système ou des bibliothèques. C’est un écart de maturité qui se paie à chaque incident de ce type.

Ce que l’autorité indienne doit encore clarifier

eMudhra a reconnu le défaut de script et les erreurs humaines. Elle a commencé la migration des certificats clients vers sa racine RSA. Environ 30 000 certificats sont concernés. Reste à savoir comment une procédure aussi critique a pu produire des clés privées aussi faibles. Les autorités de certification sont censées appliquer des contrôles strictes. Ici, la faille semble purement opérationnelle.

Mozilla a déjà retiré la racine emSign ECC Root CA – G3. Chrome s’apprête à faire de même. L’avenir de la seconde racine d’eMudhra reste sous surveillance. Pour une autorité qui revendique des dizaines de millions de certificats, l’impact réputationnel n’est pas négligeable.

Les risques résiduels pour les prochains mois

Même après les révocations, des machines non mises à jour continueront d’accepter les certificats eMudhra compromis. Les serveurs Linux oubliés, les conteneurs Docker non reconstruits, les scripts de trading qui tournent depuis des mois sans mise à jour constituent autant de cibles potentielles. Un attaquant patient pourrait encore trouver des victimes.

Le risque diminue chaque jour que les correctifs se propagent. Mais il ne disparaîtra complètement que lorsque la quasi-totalité des clients auront cessé de faire confiance à ces intermédiaires. D’où l’importance de ne pas attendre.

Une opportunité de revoir ses pratiques de sécurité

Cet incident peut servir de déclencheur. Beaucoup de traders et de développeurs crypto négligent la mise à jour des dépendances système. Ils se concentrent sur le code métier et oublient la couche de confiance sous-jacente. Or c’est souvent cette couche qui est attaquée en premier.

Mettre en place une routine de mise à jour des paquets de certificats, surveiller les annonces de sécurité des bibliothèques utilisées, et systématiquement confirmer les transactions importantes sur un dispositif hors ligne sont des habitudes simples qui réduisent considérablement la surface d’attaque.

Conclusion : le cadenas n’est qu’une partie de l’histoire

Huit certificats générés avec des clés privées dérisoires ont suffi à rappeler que la confiance numérique repose sur des procédures humaines et des scripts. Les navigateurs ont réagi avec une efficacité remarquable. Les bots et scripts, eux, dépendent encore de la vigilance de leurs opérateurs. Pour le trader crypto, la règle reste simple : ne jamais faire entièrement confiance à ce qui se passe entre son ordinateur et le serveur, et toujours confirmer les mouvements de fonds sur un support indépendant.

La faille eMudhra est déjà largement contenue côté navigateurs. Elle ne le sera complètement pour tout le monde que lorsque chaque bot, chaque script et chaque serveur aura reçu sa mise à jour. C’est le moment de vérifier les vôtres.