Cloudflare a publié une mise à jour concernant l’exploitation et la correction de huit clés privées intermédiaires d’eMudhra qui pouvaient être récupérées à partir de certificats publics. Les clés comprenaient des valeurs telles que 4, 56, 66 et 115, ce qui permettait à n’importe qui de dériver les clés de signature correspondantes et de créer des certificats que des clients vulnérables auraient pu accepter.
L’entreprise affirme que tous les systèmes prioritaires de Cloudflare ont désormais été corrigés. Ses proxys orientés vers les origines des clients, qui gèrent la plupart des connexions sortantes, ont été mis à jour dans les heures suivant l’identification du problème, le 19 octobre 2026. Cloudflare a ensuite utilisé un examen de son code source assisté par l’IA pour localiser d’autres systèmes qui faisaient confiance aux clés faibles et a attribué les tâches de correction en fonction de leur impact potentiel.
Pour surveiller d’éventuels abus, Cloudflare a ajouté une journalisation à son service sortant Pingora. Durant la semaine suivant le déploiement de cette journalisation, l’entreprise a enregistré environ 22 000 tentatives de poignées de main TLS impliquant des certificats signés avec les clés eMudhra concernées. Environ deux tiers concernaient des sites de test, notamment emudhra.we-have-a-problem.com. La plupart des tentatives restantes provenaient d’origines qui semblaient avoir configuré des certificats signés par l’autorité intermédiaire faible.
Environ 160 poignées de main impliquaient des certificats dont les noms alternatifs du sujet faisaient référence à des domaines sans rapport avec l’indication de nom de serveur demandée. Certains étaient associés à des appareils grand public de l’Internet des objets. Cloudflare a indiqué que ces certificats semblaient avoir été créés après que la faiblesse est devenue publique, l’un d’eux au moins étant daté du 20 octobre à 18 h 19 UTC, moins d’une heure après la publication du rapport de Mozilla.
Toutefois, l’entreprise a déclaré que les éléments disponibles n’indiquaient pas actuellement que les certificats aient été utilisés pour intercepter des connexions Cloudflare. Les certificats apparaissaient souvent comme les certificats par défaut des propres serveurs, utilisaient des noms qui n’auraient pas satisfait à la vérification du nom d’hôte et, dans plusieurs cas, étaient présentés depuis plusieurs sites Cloudflare. Cloudflare n’a également relevé aucun signe indirect d’une campagne d’interception ciblée.
L’entreprise a mesuré séparément combien de visiteurs faisaient encore confiance à la chaîne de certificats compromise. Elle a utilisé deux connexions de test sur une partie de ses pages de vérification : un point d’accès fournissait un certificat signé par eMudhra et l’autre agissait initialement comme contrôle avec un certificat signé normalement. Au cours de la semaine suivante, Cloudflare a recueilli 50 millions de tests, tout en avertissant que les résultats étaient affectés par le trafic de robots et n’incluaient que les clients capables d’exécuter JavaScript.
Les mesures indiquaient que les navigateurs grand public actuels avaient été en grande partie corrigés, tandis que les navigateurs plus anciens et les navigateurs intégrés restaient davantage exposés. Cloudflare a estimé que 30 à 40 % du trafic Android WebView acceptait encore la chaîne concernée. Plus de la moitié des tests provenant de plusieurs grands réseaux continuaient de l’accepter, même si l’entreprise a précisé que la composition du trafic était fortement influencée par des robots non confirmés et que les données devaient être considérées comme indicatives plutôt que définitives.
Cloudflare a exhorté les utilisateurs et les développeurs à installer les mises à jour pertinentes, en accordant une attention particulière aux développeurs utilisant macOS. L’entreprise a également orienté ses clients vers des recommandations concernant des produits tels que WARP et Tunnel. À l’avenir, Cloudflare a déclaré vouloir mettre en place des mécanismes plus rapides pour actualiser les décisions de confiance, notamment grâce à une utilisation plus large de systèmes capables de distribuer les informations de révocation et de transparence des certificats sans dépendre de magasins de confiance statiques.
Sources: Cloudflare Blog.