Cloudflare 追踪 eMudhra 弱密钥：约 2.2 万次握手尝试，未见自身连接遭拦截证据

Cloudflare 在 2026 年 10 月 30 日发布 eMudhra 证书机构事故的后续分析。此前披露的八把中间签名密钥极其薄弱，任何人都能从公开证书中迅速还原；其中一把私钥值竟为 4，而非不可预测的长整数。本次更新区分了伪造证书、尝试的 TLS 握手与确实发生的流量拦截。文章标题里的“4 real?”是设问，不表示已经确认四起真实攻击。

Cloudflare 称 10 月 19 日开始修补自身高影响系统。负责大量外连源站请求的 Pingora 在数小时内加入拒绝弱密钥证书链的机制。团队还借助 AI 分析源码，四小时内找出可能信任弱密钥的其他系统，再让负责人确认影响并处理。公告发布时高优先级系统已完成修补，少量已确认的低影响工单仍在办理。这只说明 Cloudflare 自身的进度，不能推出互联网所有客户端都已更新。

Pingora 的相关日志于 10 月 21 日完成部署。此后一周，Cloudflare 观察到约 2.2 万次涉及弱 eMudhra 密钥的尝试握手，约三分之二访问了厂商此前自己提及的测试站点。余下部分几乎都像是源站自行配置的证书。凡已配置证书验证的握手，Cloudflare 修补后的系统都予以拒绝。这是握手尝试次数，不能当作独立受害者、网站或成功攻击次数。

约 160 次握手较为异常：伪造证书的 SAN 域名属于其他组织，与连接请求的 SNI 不匹配。一些证书在漏洞公开后制作，有效期甚至超过公共证书机构允许的上限。Cloudflare 判断它们更像服务器自行提供的默认证书，因为域名不匹配会使主机名验证失败，而且同一服务器向不同 Cloudflare 地点提供相同证书。一张伪造证书标记为 10 月 20 日 18:19 UTC，距离 Mozilla 公开报告不到一小时，说明伪造发生得很快；但 Cloudflare 尚未发现弱密钥被用来拦截其连接的证据，也没有排除精心定向的拦截。

为估计访客是否仍信任有问题的证书链，Cloudflare 在部分挑战页面上设置两条探测连接，一周收集约 5000 万次探测。这个样本只覆盖运行 JavaScript、遇到挑战页面的客户端，并高度混入疑似机器人，不能代表全部互联网用户。探测方案期间还调整了对照证书、证书透明度时间戳、G3 交叉签名及根证书链；一次无关回滚造成监测空档，10 月 27 日才恢复；覆盖比例又从符合条件页面的 1% 提高到 10%。图中的跳变可能由这些变动造成，不能直接解释成补丁成效。

探测数据还有一个具体的时间解释陷阱。10 月 23 日，Cloudflare 改了对照端点的证书与透明度时间戳处理，随后一次无关的挑战平台回滚让探测暂停；10 月 27 日恢复时，又补上 G3 交叉签名、调整 ca2 的根链，并把非付费客户区域中符合条件的挑战页面抽样比例从 1% 提到 10%。这些改动会改变哪些客户端参与以及它们看到哪条链，所以图形的阶跃不能简单标为“客户端打了补丁”。10 月 29 日对自称 macOS Chrome 150 至 154 的流量启用机器人识别后，一组曲线改善而另一组相应恶化，也主要是分类变化。

安全结论同样须限于观察范围。Cloudflare 在修补后拒绝了所有配置为验证证书的相关握手，说明其受保护路径没有接受这些链；它并不能据此排除所有网站或每条网络路径的风险。异常证书迅速出现，却可能是源站自己设置的默认证书，不能把 SAN 与 SNI 不符的 160 次握手都定性为中间人攻击。普通客户应按自身使用的 WARP、Tunnel 等产品指引修补，而不是只看 Cloudflare 边缘侧完成补丁就停止更新。

在这一受限样本中，Cloudflare 认为现代主流浏览器大多已修补，旧浏览器、机器人和嵌入式浏览器较慢；Android WebView 探测仍有约 30% 至 40% 接受有问题的链。大型网络图表中，超过一半探测仍接受该链，但不能把这个比例外推到所有用户。10 月 29 日对自称 macOS Chrome 150–154 的机器人流量重新分类，也使曲线看似改善。Linux 同版本群体的下降与持续修补相符，却不足以作总体因果结论。厂商建议客户更新相关产品和信任库，并推动更快的撤销机制。