Cloudflare suit les clés faibles d’eMudhra : environ 22 000 tentatives TLS, sans preuve d’interception de ses connexions

Published · AI Daily — AI-assisted deep research, methodology & disclosure

Le 30 octobre 2026, Cloudflare a publié un suivi de l'incident touchant l'autorité de certification eMudhra, révélé plus tôt dans le mois. Huit clés de signature intermédiaires étaient si faibles que n'importe qui pouvait les retrouver à partir des certificats publics. Pour l'une d'elles, la valeur privée était simplement 4, au lieu d'un nombre imprévisible de 115 chiffres.

Le 30 octobre 2026, Cloudflare a publié un suivi de l'incident touchant l'autorité de certification eMudhra, révélé plus tôt dans le mois. Huit clés de signature intermédiaires étaient si faibles que n'importe qui pouvait les retrouver à partir des certificats publics. Pour l'une d'elles, la valeur privée était simplement 4, au lieu d'un nombre imprévisible de 115 chiffres. Le suivi sépare les certificats falsifiés, les tentatives de négociation TLS et l'interception effectivement démontrée. Le « 4 real ? » du titre est une question rhétorique, pas le décompte de quatre attaques confirmées.

Cloudflare affirme avoir commencé à corriger ses systèmes à fort impact le 19 octobre. Pingora, responsable d'une grande partie des connexions sortantes vers les origines des clients, a été modifié en quelques heures pour refuser les chaînes fondées sur ces clés faibles. Une analyse du code assistée par IA a repéré d'autres systèmes en quatre heures ; leurs responsables ont ensuite vérifié l'impact et traité les chemins prioritaires. À la publication, tous les systèmes Cloudflare à priorité élevée étaient corrigés, mais quelques tickets à faible impact restaient ouverts. Il s'agit de l'état des systèmes du fournisseur, pas d'une preuve que tous les clients Internet ont mis à jour leurs magasins de confiance.

Le déploiement de la journalisation dans Pingora s'est terminé le 21 octobre. Environ 22 000 tentatives de négociation impliquant les clés faibles ont été observées pendant la semaine suivante. Près des deux tiers correspondaient à des visites de sites de test que Cloudflare avait elle-même mentionnés ; presque tout le reste semblait provenir d'origines ayant installé leurs propres certificats. Les négociations configurées pour vérifier le certificat ont toutes été rejetées par les systèmes corrigés. Ce nombre mesure des tentatives de négociation, et non des victimes, des sites uniques ou des attaques réussies.

Environ 160 tentatives se distinguaient : les noms alternatifs des certificats falsifiés désignaient des domaines d'autres organisations qui ne correspondaient pas au SNI demandé. Certains certificats avaient été créés après la divulgation et leur validité dépassait la durée permise aux certificats d'une autorité publique. Cloudflare estime qu'ils ressemblaient aux certificats par défaut des serveurs : le nom incorrect aurait échoué à la vérification de l'hôte et un même serveur renvoyait le même certificat à plusieurs points Cloudflare. Un certificat falsifié portait la date du 20 octobre à 18 h 19 UTC, moins d'une heure après la publication du rapport de bogue Mozilla. Cela montre une falsification rapide, mais Cloudflare dit n'avoir aucune preuve d'interception de ses connexions ; une interception ciblée reste possible.

Pour estimer combien de visiteurs acceptaient encore la chaîne compromise, Cloudflare a déclenché deux connexions de sondage depuis une partie de ses pages de défi et indique environ 50 millions de sondages sur une semaine. L'échantillon ne comprend que des clients exécutant JavaScript et rencontrant ces pages, avec beaucoup de robots non confirmés ; il ne représente pas tous les internautes. Le protocole de mesure a changé en cours de route : certificat de contrôle, horodatages de transparence, signature croisée G3 et chaîne racine ont été modifiés. Un retour arrière sans rapport avec l'incident a interrompu les sondages jusqu'au 27 octobre, puis la couverture est passée de 1 % à 10 % des pages admissibles. Une rupture sur le graphique peut donc venir de la mesure elle-même et non d'une mise à jour des clients.

Dans cet échantillon limité, Cloudflare juge les navigateurs modernes courants largement corrigés, contrairement à des navigateurs anciens, robots et navigateurs intégrés. Environ 30 à 40 % des sondages Android WebView acceptaient encore la chaîne. Pour de grands réseaux, plus de la moitié des sondages de la ventilation publiée l'acceptaient, sans que ce taux puisse être extrapolé à toute la population. Le 29 octobre, un nouveau classement des robots se présentant comme Chrome 150 à 154 sur macOS a donné l'impression d'une amélioration sur une courbe ; le groupe signalé comme robot a augmenté en contrepartie. La baisse du groupe Linux est compatible avec des corrections, sans prouver un effet causal global dans un trafic changeant. Cloudflare invite à mettre à jour produits et magasins de confiance et à accélérer les mécanismes de révocation.

Sources

FAQ

Les 22 000 négociations et les 160 cas atypiques donnent-ils le nombre d’attaques réelles ?

Non. Les 22 000 sont des tentatives de négociation, dont environ deux tiers visaient des sites de test. Les quelque 160 cas atypiques ressemblaient plutôt à des certificats par défaut de serveurs. Cloudflare n'a pas trouvé de preuve d'interception de ses connexions, sans exclure une interception ciblée. Le « 4 real ? » du titre n'est pas un nombre d'incidents.

Les 50 millions de sondages mesurent-ils le taux de correction de tous les internautes ?

Non. Les 50 millions de sondages environ ne couvrent que les clients exécutant JavaScript sur certaines pages de défi, avec beaucoup de robots. Des changements de chaîne, une interruption et l'élargissement de l'échantillon ont influencé les graphiques. Les 30 à 40 % pour Android WebView et les chiffres des grands réseaux concernent ces sondages, pas tous les internautes.

Qu’a corrigé Cloudflare, et que doivent faire les utilisateurs concernés ?

Cloudflare dit avoir corrigé ses systèmes prioritaires ; Pingora refusait les chaînes faibles quelques heures après le début des travaux le 19 octobre. Quelques tickets à faible impact restaient ouverts. Les clients concernés doivent suivre les consignes propres à leurs produits et les utilisateurs mettre à jour logiciels et magasins de confiance. La correction interne du fournisseur ne protège pas automatiquement tous les appareils.