Ing. Calogero Bono
Cloudflare a publié une analyse de suivi sur les huit clés cryptographiques faibles de l'autorité de certification indienne eMudhra, découvertes le 19 octobre 2026. Selon l'entreprise, les systèmes les plus critiques sont déjà protégés et aucune interception de ses connexions n'a été constatée. Pourtant, de faux certificats sont apparus en quelques heures, et de nombreux navigateurs, bots et applications intégrées continuent d'accepter la chaîne compromise. Pour qui gère des sites et des services en ligne, le risque n'est pas théorique.
Quelques termes, avant d'entrer dans les faits. CA (certificate authority) est l'organisme qui émet les certificats sur lesquels repose le cadenas HTTPS. Clé intermédiaire est la clé avec laquelle la CA signe les certificats des sites. CRL est la liste des certificats révoqués. Certificate Transparency est le registre public des certificats émis, et les SCT en sont les reçus. SAN et SNI désignent les noms de domaine présents dans le certificat et celui demandé par le client.
Que s'est-il passé avec les clés d'eMudhra ?
Selon Cloudflare, eMudhra devait choisir un nombre de 115 chiffres pour protéger ses clés et a utilisé le nombre 4. Les sept autres clés étaient tout aussi faibles, avec des valeurs comme 56, 66, 115, 155, 156, 230 et 237.
Cloudflare explique que les clés intermédiaires peuvent être reconstruites presque immédiatement par n'importe qui, à partir des certificats publics. N'importe qui peut donc créer des certificats pour n'importe quel domaine, que un client non mis à jour et sans contrôle de Certificate Transparency accepterait.
Pour l'entreprise, le cas est sans précédent. Des incidents comme DigiNotar, TÜRKTRUST et TrustWave n'avaient donné le pouvoir d'émettre de faux certificats qu'à quelques acteurs.
Comment Cloudflare a-t-elle réagi ?
Le 19 octobre, les correctifs ont commencé sur les systèmes à fort impact, à commencer par les proxys Pingora tournés vers les serveurs des clients, qui gèrent la majeure partie des connexions sortantes. En quelques heures, ils ont commencé à rejeter les clés vulnérables.
En parallèle, une analyse du code assistée par l'IA a identifié en quatre heures les autres systèmes qui faisaient confiance à ces clés. Un ticket a été ouvert pour chacun. Les interventions urgentes devaient être faites immédiatement, les autres d'ici la fin de la semaine dernière. Au moment de la publication, il reste à clore quelques tickets à faible impact.
Les clés ont-elles déjà servi à falsifier des certificats ?
Oui, selon Cloudflare. Depuis le 21 octobre, un journal dans Pingora enregistre les certificats signés avec les clés faibles. En une semaine environ, il a compté près de 22 000 tentatives de handshake. Les deux tiers visaient des sites de test, presque tout le reste des serveurs qui semblent s'être créé eux-mêmes un certificat avec l'intermédiaire faible. Chaque handshake avec vérification active a été rejeté.
Environ 160 cas étaient anormaux, avec des noms de domaine d'autres organisations, certains liés à des appareils IoT grand public. Certains certificats étaient valables plus de deux ans, plus que ce qu'une CA publique peut émettre. L'un remonte au 20 octobre à 18 h 19 UTC, moins d'une heure après la publication du signalement de Mozilla.
Pour Cloudflare, il semble toutefois s'agir de certificats par défaut des serveurs, et non de tentatives d'interception. Le cas ressemble à d'autres où une vulnérabilité est sondée immédiatement, comme celui d'Oracle E-Business Suite.
Combien de visiteurs sont encore vulnérables ?
Cloudflare ne peut pas tester directement les visiteurs sans interrompre les connexions. Elle a donc ajouté deux sondes aux pages de vérification, l'une avec un certificat eMudhra et l'autre de contrôle. En une semaine, elle a recueilli 50 millions de sondages.
Le tableau qu'elle dresse est le suivant.
- Les navigateurs modernes et à jour sont pour la plupart protégés.
- Les bots et les anciens navigateurs ne le sont pas.
- Les applications avec navigateur intégré, comme Android WebView, acceptent encore la chaîne dans 30 à 40 % des cas.
- Dans les grands réseaux, plus de la moitié des sondes acceptent la chaîne compromise.
Après quelques progrès lors du premier week-end, la tendance est stable. Le trafic reste toutefois biaisé par des bots non confirmés, et seuls les clients qui exécutent JavaScript envoient des sondes.
Limites à connaître
eMudhra déclare une erreur dans un script de génération des clés, mais ne l'a pas encore partagé. Restent à éclaircir le rôle des auditeurs et des cross-signers, et pourquoi une CRL a été signée d'abord avec une clé peut-être correcte, puis avec la clé faible. Cloudflare écarte les interceptions uniquement sur la base de signaux indirects. Une interception ciblée n'est pas exclue. Les données sur les visiteurs sont par ailleurs faussées par les bots.
Ce qui change pour qui travaille dans le numérique
Si tu gères des sites, des applications ou des logiciels de gestion, vérifie que serveurs, bibliothèques et clients rejettent les clés eMudhra. Comptent aussi les logiciels qui se connectent à des services externes, comme les applications mobiles avec WebView et les scripts automatiques, car ils sont souvent en retard. Si tu développes sur macOS, suis attentivement les instructions indiquées par Cloudflare. Si tu disposes d'un hébergement avec mises à jour de sécurité gérées, vérifie avec le fournisseur l'état du correctif. Le sujet concerne aussi ceux qui utilisent des certificats pour la signature numérique.
Notre avis
Le constat le plus alarmant n'est pas le bug, mais la lenteur des mises à jour. Une clé reconstructible par n'importe qui est une erreur énorme, et le fait que plus de la moitié des sondes acceptent encore la chaîne révèle un problème plus large, celui des logiciels que personne ne met à jour. Le cas rappelle à quel point les clés cryptographiques comptent, comme avec le malware KeyDrift sur Cisco SD-WAN. Subsiste enfin un doute sur le système de contrôle, puisque audits et cross-signing n'ont rien arrêté.
Questions fréquentes
Que sont les clés faibles d'eMudhra ?
Ce sont huit clés intermédiaires d'une CA, générées avec de petits nombres comme 4 ou 56. C'est pourquoi n'importe qui peut les reconstruire à partir des certificats publics et signer de faux certificats.
Cloudflare a-t-elle été compromise ?
Selon Cloudflare, rien ne prouve une interception de ses connexions. Les systèmes à haute priorité ont été mis à jour et il ne reste que quelques tickets à faible impact.
Quel est le risque pour un site ou une application ?
Cela dépend du client. Un client non mis à jour et sans contrôle de Certificate Transparency peut accepter de faux certificats pour n'importe quel domaine, ce qui permet une éventuelle interception.
Quels logiciels restent les plus exposés ?
Les bots, les anciens navigateurs et les navigateurs intégrés comme Android WebView. Pour ces derniers, selon Cloudflare, 30 à 40 % acceptent encore la chaîne compromise.
Que dois-je faire maintenant ?
Mets à jour tes systèmes et suis les instructions du site tenu par Dennis Jackson, cité par Cloudflare. Si tu développes sur macOS, donne la priorité à ces indications.
Ce qu'il faut surveiller dans les prochaines semaines sur l'affaire eMudhra
L'affaire est ouverte sur deux fronts, les explications d'eMudhra et le rythme des mises à jour. Il est utile de suivre les deux.
- Vérifie si eMudhra publie le script de génération des clés et les conclusions sur les audits et les cross-signers.
- Suis les mises à jour des navigateurs et des runtimes utilisés par tes applications, en particulier les WebView.
- Contrôle dans les journaux de tes serveurs les certificats portant des noms de domaine qui ne correspondent pas à ceux demandés.
