跳到正文
Zainan Victor Zhou, zThink author and Ethereum EIP Editor zThink by Victor Zhou

导航
← 所有文章
ZTHINK technology

互联网的天塌下来了

eMudhra 部分中间 CA 私钥竟然小到整数 4。互联网的身份信任为何会出错，DNSSEC 和去中心化又能解决什么？

Zainan Victor Zhou
作者：
互联网的天塌下来了 — Zainan Victor Zhou
本文目录

卧槽，真是草台班子啊。

你给手机设个六位解锁码，还怕别人猜出来。结果，互联网里一种用来给网站证明身份的关键私钥，数值居然是：

4。

对，就是整数 4。

如果你不知道我在说什么，最近两天，互联网安全圈出了这么一件事。

一家叫 eMudhra 的公司，负责给网站签发“数字证书”。你可以先把数字证书理解成网站的身份证：你打开银行、邮箱或者购物网站，浏览器会检查证书，帮助确认连接对面是不是你要找的网站。

负责签发证书的机构，叫作 CA（Certificate Authority，证书颁发机构）。普通人可能一辈子没听过这些机构，但每天输入密码、查看邮件、付款，都在依赖浏览器的身份检查。

这次，eMudhra 的部分中间 CA 生成了极其薄弱的签名私钥。私钥本来应该难以猜中，研究者却发现，有一把居然就是整数 4。外人拿着公开资料，就能恢复出这些本该严格保护的私钥。安全研究者 Scott Helme 公布了恢复结果。

危险在哪里？别人拿到这种私钥，就有机会给假网站签出看起来可信的“身份证”。

如果攻击者还能把你的连接拦过去，而你的浏览器或应用又接受了伪造证书，你明明输入了正确网址，也可能把密码交给冒充者。连接甚至可以正常加密——只是加密连接的另一头，坐着骗子。

这不代表所有网站已经失守，也没有证据证明所有人的密码已经泄露。Google、Mozilla 已经采取了拦截措施，不同客户端的保护情况也不同。让人愤怒的是：负责替大家证明身份的关键环节，竟然出了这种低级错误。

普通人遮住手机的六位解锁码，几位专家却隆重展示保险柜里孤零零的红色数字 4

包装很专业，里面是 4。

这件事相当于什么呢？

想象一座城市。人们看到警服和警徽，会把对方认作警察。大家默认，警服、警徽有严格的发放和核验。

结果，负责发放的地方，把警服、警徽摆在了马路边的桌子上。没人看管，谁都能顺手拿走，穿起来冒充警察。

桌上甚至还放着制作警徽的模具。别人拿到模具，就能继续造新的假警徽。

你以为有人在认真保管身份认证的凭据，人家把冒充身份需要的东西，摆成了路边自取。

所以，看到“私钥是 4”的时候，我的反应就是：

天哪，这么关键的地方，怎么能草台成这样？

路人从标着自取的桌上领取制服和警徽，桌上还摆着警徽模具，值班人员专注阅读保管制度

身份认证，自助领取。

CA 私钥的危险，更接近后半段。机构用私钥给证书签名。攻击者掌握私钥，就可能签出新的伪造证书。出问题的，是替别人证明身份的签发权限。

这就是我看到事故时，那种“卧槽，草台班子啊”的感觉。我们把重要的身份判断交给专业机构。专业机构的一组关键私钥，却弱到了外人可以恢复的程度。

当然，比喻只解释了签发权限。现实中的客户端还有其他检查。攻击者也得接触目标流量，才能尝试中间人攻击。穿上假警服的比喻，不能证明本次事件已经造成了大规模冒充。

更离谱的细节，还在公司自己的声明里。

eMudhra 表示，密钥生成使用了经过认证的硬件安全模块。按照公司的解释，一个密钥包装与解包步骤产生了另一组弱密钥。公司还说，问题约十八个月没有被发现，期间经历了两轮独立审计。这些细节来自 eMudhra 自己的声明。公司同时表示，确切根因仍在调查。

硬件有认证，流程有审计。最基础的密钥强度，却出了问题。

合规材料能交齐，不等于关键环节真的做对了。

检查人员在厚厚的报告上盖已认证和已审计印章，身后的数字信任大楼却仅靠一个小小的红色数字 4 支撑

报告很厚，地基很薄。

我们平时谈互联网安全，很容易把专业机构想得特别稳妥。密码学、数字证书、认证硬件、独立审计，哪一个词都听起来很可靠。普通人自然会觉得：这么重要的东西，总有人在认真把关吧。

然后，现实给你看了一眼后台。

所谓专业、认证、审计，最后都得落到具体操作上。一组本该保密的签名私钥，就可能让整套身份认证暴露风险。“天塌下来了”的火气，就来自这种严肃与草率的落差。

但愤怒归愤怒，事实得讲准确。弱密钥已经确认，客户遭到大规模窃听并没有因此得到证实。 浏览器厂商也已经采取了措施。后面会具体说清楚哪些客户端获得了保护。

普通人为什么需要关心？因为受影响的判断，可能就在你每天输入密码之前发生。

先想象一个场景。

晚上，你打开一个每天都用的网站。网址是你亲手输入的。页面看起来也和平时一样。浏览器没有弹出证书警告。你输入密码，然后继续处理自己的事情。

可如果连接对面坐着的，恰好是一个冒充者呢？

假设场景里还有一个反直觉的细节：连接可能确实经过了加密。你和冒充者之间的加密，甚至可以正常工作。只要攻击者能拦截连接，又拿出客户端接受的伪造证书，冒充就可能成立。

加密回答了“别人能不能偷看”。身份验证还得回答“我到底在和谁说话”。

前面的场景是假设，用来说明风险。本文没有证据证明 eMudhra 事件已经造成同样的客户遭遇。Google 还确认，强制执行相关证书透明度要求的客户端，在本次事件中有额外保护。Chrome 就属于 Google 点明的客户端。Google 的公告解释了保护条件。

但为什么安全圈会认真对待一个普通人没听过的名字？

因为 eMudhra 涉及一项非常特殊的工作：签发数字证书。

普通人可以先把网站证书理解成一份“身份材料”。网站拿出证书，说明自己有资格为哪些域名证明身份。浏览器再检查证书背后的签名与信任关系。证书颁发机构通常简称 CA。证书颁发机构参与了建立信任的过程。

现实中的证书检查比“看身份证”复杂得多。证书还要经过用途、有效期和其他客户端策略检查。网站还得证明自己持有相应私钥。但“身份材料”足以帮助我们理解问题：攻击者如果能伪造客户端认可的身份材料，浏览器就可能认错人。

eMudhra 本次出问题的，是中间证书所对应的签名密钥。相关密钥的强度出了问题。Mozilla 独立恢复出了受影响的私钥。八张受影响证书里，六张用于 TLS，两张用于代码签名。Mozilla 的事件记录列出了范围。

签名密钥为什么值得如此紧张？

因为签名密钥代表着签发权限。攻击者掌握受影响的权限，就可能为无权控制的域名伪造证书。客户端是否接受，还取决于证书约束和客户端检查。Mozilla 的公告说明了网站冒充风险。

所以，读到这里，网站经营者可能会冒出一个念头：“我的证书又不是找 eMudhra 买的。”

问题恰恰在访问者的客户端。

你的网站可能根本没有购买 eMudhra 的证书。攻击者仍可能尝试用另一个受信任的签发体系冒充你的网站。攻击者还得拦截访问者的连接，伪造证书也必须通过客户端检查。你选择了哪家 CA，并不能单独决定访问者信任哪些 CA。

浏览器要连接世界各地的网站。浏览器会按照自己的信任列表和规则检查证书。网站经营者很难只靠自己的采购决定，消除整个信任体系的风险。

对于普通用户，风险可能出现在输入密码的那一刻。对于创业团队，风险可能出现在客户登录产品的那一刻。对于 Web3 团队，风险还可能发生在用户通过网页操作钱包的那一刻。业务可以有不同形态，访问者都得先确认连接对面的身份。

所以，我对这场事故的情绪是愤怒和难以置信。

我们每天把密码和业务交给浏览器。多数时候，浏览器的身份检查不会引人注意。如今，关键环节出了问题，普通人还得跟着关心更新和补救。

风险值得警惕，影响范围仍然要靠证据说话。

新闻并没有证明所有网站同时失守。eMudhra 也表示，公司没有发现披露前遭到利用的证据。eMudhra 同时承认，确切根因的调查尚未完成。公司声明保留了调查边界。

Google 和 Mozilla 已经采取了拦截措施。普通用户现在应当安装相关安全更新。运营者还得检查具体应用采用的证书验证路径。浏览器收到保护，不代表同一台设备上的每个程序都收到保护。

但普通读者还值得追问：如果域名本身没有写错，连接又确实加密了，我们还能增加哪一层检查？

域名圈经常提到一个名字：DNSSEC。DNSSEC 能验证 DNS 数据。另一个机制 DANE，则尝试把服务身份和签名后的 DNS 联系起来。

听起来，答案似乎已经出现了。

真正需要讲清楚的，是每种机制检查什么，又在哪些条件下起作用。 DNSSEC 不会修复一把已经失陷的 CA 密钥。发布 DANE 记录，也不会让所有浏览器自动获得保护。

接下来，我们把整条链拆开。我们先看 CA 如何建立身份信任，再看中间人攻击需要什么条件。最后，我们再看 DNSSEC、DANE、CAA 和证书透明度分别能帮上什么忙。

技术分析按 2026 年 10 月 22 日已核查的材料展开。 调查仍在继续。确认密钥失陷，不等于确认攻击者已拦截客户流量。

事件暴露了单个网站之上的签名权限风险

证书颁发机构简称 CA，负责签发数字证书，将身份与公钥关联起来。在 HTTPS 中，证书标明服务器可以证明控制权的域名。CA 在签发证书前检查适用的身份要求。浏览器检查证书链，以及服务器持有相应私钥的证明。RFC 5280 描述了证书模型。

根 CA 提供信任锚。中间证书颁发机构持有根之下的委托签名权限。网站证书通常位于中间证书颁发机构之下。网站密钥失陷，威胁的是相应证书中的身份。中间密钥失陷则可能威胁许多互不相关的域名，具体影响取决于证书约束和客户端检查。

Mozilla 的事件记录列出了八张受影响的中间证书：六张用于 TLS，两张用于代码签名。Mozilla 独立恢复出了薄弱的私钥。eMudhra 于 10 月 18 日将证书标记为已吊销。事实表明密钥生成存在故障，并不证明有人窃取了每一位客户的私钥。

在 10 月 21 日的声明中，eMudhra 将薄弱密钥归因于 2025 年 4 月 30 日密钥仪式中的包装与解包步骤。eMudhra 表示，受影响的中间证书没有签发过终端实体证书，并称公司没有发现披露前遭到利用的证据。公司还表示，确切根因的调查尚未完成。声明反映了 eMudhra 的调查结果，不构成对全部历史流量的独立保证。

浏览器保护措施改变了实际暴露程度

Google 表示，Chrome 于 10 月 17 日通过 CRLSet 更新拦截了受影响的密钥。Google 还报告，在拦截前，CT 日志中没有出现六张受影响 TLS 中间证书下的 TLS 证书。因此，针对强制执行相关 CT 要求的客户端，攻击者无法利用相关中间证书签发的欺诈证书成功冒充。Google 的通告将 Chrome 列为执行相关要求的客户端之一。

Mozilla 于当晚分发了 OneCRL 拦截更新。Mozilla 还为可能无法获得 OneCRL 保护的配置发布了 Firefox 更新。浏览器更新不能证明同一设备上的每个应用都获得相同保护。Cloudflare 特别提醒，不同应用可能使用不同的证书验证器。

Google 的 10 月 20 日通告计划于太平洋夏令时 2026 年 10 月 27 日，在使用 Chrome Root Store 的客户端中移除 emSign ECC Root CA - G3。Google 要求受影响的网站运营者，将证书迁移至另一个受信任的证书体系。运营者必须区分即时安全拦截与后续根证书失去信任导致的服务中断。

中间人攻击需要流量访问能力和客户端接受的身份

中间人攻击（Man-in-the-Middle，中间人攻击）简称 MITM，让攻击者介入通信双方之间。以下是假设攻击，并非已经观察到的 eMudhra 漏洞利用：

  1. 攻击者通过恶意 DNS 响应或其他网络拦截方法，将访问者重定向到攻击者。
  2. 攻击者出示目标域名的伪造证书。
  3. 缺乏保护的客户端接受证书，并与攻击者建立 TLS 连接。
  4. 攻击者向真实服务转发流量，同时读取或修改应用数据。

持有 CA 密钥不会自动重定向流量。仅有证书，也不能解密此前记录的所有会话。在 TLS 1.3 所述假设成立时，前向保密保护早先会话，防止长期身份验证密钥后来失陷造成解密。RFC 8446 解释了相关区别。

Namefi 的 Fox-IT 案例研究分析了产生类似结果的另一条路径：注册商失陷使攻击者能够获取欺诈证书。Namefi 的 MyEtherWallet 案例研究分析了路由和 DNS 操纵。域名安全必须同时处理流量去向和端点身份验证。

DNSSEC 验证 DNS 响应，但不修复 CA 密钥

DNSSEC（域名系统安全扩展）为 DNS 数据添加数字签名。执行验证的解析器通过信任链检查签名。如果区域签名正确且验证链完整，攻击者替换伪造地址响应便会触发检测。RFC 4033 规定了保护范围与限制。

客户端必须在本地验证，或同时信任验证解析器及通往解析器的已认证连接。RFC 4033 讨论了最后一跳的要求。

满足前述条件时，DNSSEC 可以阻止假设攻击中的 DNS 伪造步骤。DNSSEC 不会吊销中间证书颁发机构，不会验证 HTTPS 证书，也不会加密网页流量。通过其他路径拦截流量的攻击者，仍可向存在风险的客户端出示伪造证书。

仅有签名也不能保护注册商账户或权威 DNS 控制面板。掌握授权 DNS 变更权限的攻击者，可以发布有害记录，并让服务提供商签名。运营者除了部署 DNSSEC 验证，还需要保护账户、监测变更，并正确配置父区域的 DS 记录。

检查员确认指向真实网站的路牌地址正确，冒牌接待员却在途中拦下访问者，并通过线路向真实网站转接通信

路牌是真的，接你的人呢？

客户端强制执行 DANE 关联后，DANE 可以将服务密钥绑定到已签名 DNS

DANE通过 TLSA 记录将 DNSSEC 与 TLS 身份验证连接起来。域名运营者在已签名的 DNS 中发布预期证书、密钥或信任锚。支持 DANE 的客户端验证 DNSSEC，并强制执行 TLSA 关联。RFC 6698 规定了关联机制。

例如，DANE-EE 用途可以将服务直接绑定到公钥。使用无关 CA 密钥伪造的证书无法满足绑定要求。保护效果要求安全的 DNSSEC 验证、正确的 TLSA 数据，以及客户端实际强制执行关联。密钥轮换还需要协调 TLSA 更新。RFC 7671 提供了运维指导。

发布 TLSA 记录，不会自动保护普通浏览器访问者。Firefox 的 DANE 实现请求仍处于拒绝状态。运营者必须核实具体客户端的支持情况。DANE 已有针对 SMTP 传输安全的标准化应用。

CAA 和 CT 提供不同的证书控制措施

控制措施保护能力限制
DNSSEC执行验证的解析器验证已签名 DNS 数据的真实性。DNSSEC 不会修复失陷的 CA 密钥。
DANE支持 DANE 的客户端检查经 DNSSEC 认证的 TLSA 关联。客户端必须强制执行关联。
CAA遵循规范的 CA 检查域名授权了哪些颁发机构。伪造者可以绕过 CA 的签发流程。
CT日志公开证书签发情况，供监测和客户端策略检查。仅有日志不能阻止所有伪造，也不能保护所有客户端。

CAA在 DNS 中公布获授权的颁发机构。RFC 8659 区分了签发授权与客户端证书验证。遭窃或可被恢复的签名密钥，让伪造者能够忽略 CAA 检查。

证书透明度（Certificate Transparency，证书透明度）简称 CT，让公众能够审计证书签发。监测可以标记非预期证书，客户端强制执行策略则可以拒绝缺少必要日志证明的证书。RFC 9162 描述了日志机制。前述 Google 调查结果说明了 CA 事件中强制执行策略的重要性。

域名运营者现在应检查客户端信任与证书依赖

  • 安装最新的浏览器、操作系统、运行时和 CA 软件包安全更新。
  • 盘点网站、API、移动应用、容器和 TLS 检查网关的证书链。
  • 遵循供应商针对受影响中间证书和根证书移除的指导，包括替代证书路径。
  • 在适用客户端的截止日期前，更换连接到失去信任证书体系的证书。
  • 完成修复后，测试每个应用实际使用的 TLS 验证器。
  • 保持证书验证开启，并在出现证书错误时停止访问。
  • 正确配置 DS 委派，启用 DNSSEC，并使用执行验证的解析服务。
  • 通过 CAA 限制获授权的颁发机构，监测 CT，并保护注册商与 DNS 账户。

VPN 可以改变流量路径。VPN 不会修复客户端的证书信任判断。HSTS 要求使用 HTTPS，但客户端接受伪造的 HTTPS 身份后，保护仍会失效。RFC 6797 描述了 HSTS 的安全限制。

对于域名持有人和 Web3 团队，域名所有权、DNS 管理、TLS 身份验证和钱包授权需要分别设置控制措施。域名代币化不会自动取代浏览器 CA 信任，也不会自动启用 DNSSEC。Namefi 的代币化域名 DNS 指南解释了运维层面的联系。Namefi 的 Curve Finance 案例研究说明了 Web3 团队保护界面域名的必要性。

现在就检查你的网站，别等浏览器替你报错

吐槽完草台班子，先打开你自己的网站。

你的网站正在用哪家 CA？你能说出来吗？ 如果你运营网站、管理产品，或者负责团队的域名，今天就把下面几项查清楚。没有技术背景，也可以把这份清单直接发给负责网站的同事。

  1. 检查真正对外提供服务的证书链。 在浏览器的连接信息中打开证书查看器，检查证书覆盖的域名、有效期、颁发者，以及中间 CA 和根 CA。主域名、www、登录域名和 API 域名都要检查。只看到 HTTPS，检查还没有完成。
  2. 确认网站已经避开受影响的证书体系。 如果证书链涉及 eMudhra／emSign，先核对具体的中间证书、根证书和供应商公告。尤其检查链中有没有 emSign ECC Root CA - G3。Google 要求相关网站在 Chrome 的移除措施生效前更换证书路径。我给自己的保守选择是：换到另一家 CA，并确认实际部署的完整证书链。 Google 的公告列明了受影响根证书和迁移要求。
  3. 让独立工具检查 HTTPS 配置。 你可以在 Qualys SSL Labs 输入自己公开网站的主机名，检查服务端证书链和 TLS 配置。报告中的错误需要逐项处理。换了一家 CA，也不代表其余配置自动合格。
  4. 检查 DNS 和 DNSSEC。 你可以在 DNSViz 输入域名，检查解析路径和 DNSSEC 信任链。确认 DNS 记录指向预期服务，并区分“没有启用 DNSSEC”和“启用了却验证失败”。DNSSEC 验证失败需要修复，不能靠关闭客户端检查来掩盖。
  5. 更换之后再测一次。 如果网站经过 CDN、负载均衡或多个服务节点，确认所有对外入口都部署了新证书。浏览器、移动应用和 API 客户端还需要各自检查更新与信任配置。

今天的行动很简单：查证书链，查域名解析，查 DNSSEC；发现问题，就修复后复测。

这份清单不能保证整个网站安全。网站采用另一家 CA，也不能让访问者的客户端自动拒绝失陷 CA 签出的伪造证书。客户端更新、证书验证和流量路径仍然重要。我们需要能够重复的检查，不能只靠一句“应该没问题”。

我们建设去中心化，是为了让关键权力接受独立验证

写到这里，我想说说，我们为什么还要建设去中心化系统。

中心化当然有价值。中心化可以带来效率、专业分工和快速响应。一个认真负责的专业团队，也可以把安全工作做得很好。

问题是，你不能保证，某个最关键的安全环节，永远都由认真负责的人掌握。你可能一直以为，专业机构已经替你把关。直到某天你才发现，关键私钥落在了 eMudhra 这种让人直呼“草台班子”的机构手上。

你连关键权限由谁掌握都未必清楚，却可能要替对方的失误承担后果。

所以，我关心的去中心化，是给每个环节重新分配验证能力和安全责任。终端用户需要保护自己的密钥、核对自己的授权。服务提供者需要对代码、密钥和操作负责。独立节点则按照公开规则，检查交易和状态。

以以太坊为例，完整节点会验证区块和状态。参与者也可以运行自己的节点，检查收到的数据。以太坊的节点与客户端文档解释了验证分工。普通用户可以选择验证方式，但用户使用某项服务，也意味着用户需要理解相应的信任假设。

我们要争取的，是让检验变得容易，让伪造变得困难。

服务提供者声称一笔交易有效，就需要提供能够核对的数据。用户授权一项操作，就需要知道自己签了什么。一个参与者出了问题，系统也应尽量让其他参与者发现问题、拒绝错误。

比特币白皮书提出用密码学证明处理交易，并明确了诚实算力等安全前提。白皮书的引言与交易章节讨论了证明、签名和验证。不同区块链采用不同机制，安全结论也有各自的前提。

当然，区块链不会让整数 4 变成安全的私钥。钱包生成弱密钥，同样会让持有者面临风险。恶意授权、终端入侵、软件漏洞和验证服务的集中化，也都需要继续处理。网站仍然需要正确的证书检查和域名安全配置。

所以，我希望建设的系统，要让用户有能力检查，让服务方有东西可供检查，让关键权力受到其他参与者的约束。

一家机构把流程写得再漂亮，我们也应该能够继续问：证据在哪里？我能不能自己验证？如果对方出了错，谁还能发现？

一手来源记录了事件与防护措施

以下来源均于 2026 年 10 月 22 日查阅。随着调查推进，事件声明可能发生变化。

↑ 回到顶部