专题 · FULL STORY

eMudhra 弱密钥事件：从曝光到玩梗

印度证书机构 eMudhra 的 8 张中间 CA 证书被曝使用近乎全零的灾难性弱私钥。官方回应承认密钥确由 HSM 生成，问题出在密钥仪式缺陷。随后 mitmproxy 甚至新增 --emudhra 选项，用失陷密钥签名以示嘲讽。

2026-10-21 ~ 2026-10-22 · 3 集 · 52 条

第 1 集 · 印度 CA eMudhra 8 张中间证书私钥形同虚设，浏览器紧急拉黑(2026-10-21,44 条)

印度证书机构 eMudhra 的 8 张 P-384 中间 CA 证书被曝使用灾难性弱私钥：除末尾几位外几乎全为零，实际取值仅为 4、56、66、115、155、156、230、237 这类极小数字，熵不足 8 bit。任何人都能在本地几秒内推导出完整私钥，并无成本地为任意网站签发受全球信任的证书，对未及时更新的设备实施中间人（MITM）攻击。Firefox 在获报后约 3 小时内屏蔽涉事证书，Chrome 也据称在数小时内跟进拉黑，但在软件与信任库完成更新前风险将持续存在。

已确认

  • Russ Cox 披露、davidcrawshaw 转述，Mozilla Bugzilla 已公开 eMudhra 中间 CA 私钥泄露细节：相关 P-384 私钥除最后几位外全部为零，极易被推导（m2、m13、m18）。
  • 被指泄露的中间 CA 证书共 8 张，相关证书已遭吊销，受影响系统需要更新信任链（m2、m6、m8、m18）。
  • 研究者 otomir23 的截图显示该 384 位 ECC 私钥几乎全为零、末尾为 4（m7）；Deedy 进一步列出 8 个私钥的实际取值为 4、56、66、115、155、156、230、237（m9、m10）；cyb3rops 转述称其中一把私钥就是数字 4（m2）。
  • 时间线：据 dotey 转述，问题密钥生成于 2025 年 4 月，直到 10 月 17 日才被研究者 Wayne 发现，暴露长达一年半；Wayne 从公开证书直接恢复出 eMudhra 八个中间 CA 的私钥，并用这些密钥签名留言通知各浏览器根证书项目，Mozilla 当天即独立重建了密钥（m8、m15、m16）。这些密钥并非被窃取，而是生成本身就是极小数字（m15）。kingslyj 澄清问题并非发生在「上周」，上周只是被检测发现，并讽刺 eMudhra 在生成这 8 份问题证书两个月后还通过了审计。
  • Firefox 据称在 3 小时内屏蔽涉事证书，该时间细节见于 m13、m14、m17、m18 等多条转述；op7418 称 Chrome 和 Firefox 均在数小时内拉黑（m17）。m12 提供了自查方法：访问特定测试页面若未出现 ERRCERTREVOKED 错误，说明浏览器需要立即更新。
  • 成因分析指向私钥生成时随机数不足：cyb3rops 转述的披露称 TLS 中间证书私钥生成未使用足够随机数（m2）；m7 转述称私钥疑似仅由单个字节生成；m1、m5 的社区讨论调侃该机构可能把「384 位密钥」误解为在 1 到 384 之间取数。
  • paraschopra 补充发现途径：该问题是借助 Google 开源的 paranoidcrypto 仓库「开箱即用」检出的（m11）。另据 evilsocket 转述，安全研究者 IzzatStatus 称又发现印度某证书机构更多泄露的私钥，且都是小数字（m1）。
  • m19 转述的爆料质疑该事件按 CERT-IN 规则应在 6 小时内（10 月 17 日前）上报，而印度电子信息技术部（MeitY）对封禁社交账号反应迅速，对此事件却迟迟没有回应。

尚未确认

  • 部分帖（m13、m14、m18）称私钥「本应是 116 位的大数」，与 P-384 密钥的位数表述存在出入，属转述口径差异；m17 亦称其中一把「70 多位密钥」就是个位数 4。核心事实仍是 384 位 ECC 私钥几乎全零、取值极小；m8、m9 表述为「全部取值小于 256」。
  • iangcarroll 称「未来几天到几周内任何人都可能持有受全球信任的根 CA」（m15）；但一手证据（Bugzilla 披露）集中在中间 CA 层面，根 CA 私钥是否同样失守未见一手细节，可能是对证书层级的夸大或混淆。m4 转述的警告同样以「根证书泄露」表述，与主流披露的中间 CA 口径不一致。
  • IzzatStatus 所谓「更多泄露私钥」的具体范围与是否仍属 eMudhra 未有进一步细节（m1）。

为什么重要

  • 中间 CA 私钥一旦可被任意推导，攻击者即可零成本签发全球受信任的证书，对所有未及时更新信任链或软件的设备实施 MITM 攻击，且该风险在信任库更新前持续存在，无法通过升级单个产品根治（m7、m18）。
  • uwukko 指出，相当一部分设备或系统永远不会打上补丁，漏洞完全修复前相关领域将处于「狂野西部」状态，并质疑这样一家「查无名人」的公司如何持有 CA 资质（m20）。
  • 如此明显的异常密钥暴露一年半、历经多次审计均未被发现（m17 亦提及多次审计未察觉）；安全研究员 Federico Lois 甚至评论称正常人类不可能犯下这种错误，只有 AI 或有缺陷的测试脚本才可能造出这样的数字，侧面凸显自动化扫描工具在审计中的价值（m14）。事件暴露出 CA 运营与审计流程的深层问题；CERT-IN 上报疑似超期又叠加监管回应迟缓，进一步削弱信任（m19、m13）。
  • 事件波及印度数字信任体系与依赖 eMudhra 证书的全球用户，社区以 XKCD「保证随机的数是 4」的经典漫画、Cloudflare 熔岩灯造熵的对比梗图和「全量更新日」的调侃吐槽此事；也有开发者玩梗称可借此在 localhost 上启用受信任的 HTTPS（m3、m5、m6、m18、m17）。

还有 24 条相关讨论 →

第 2 集 · eMudhra 弱根密钥风波：HSM 仪式缺陷致弱密钥入信任库(2026-10-22,6 条)

印度证书颁发机构 eMudhra 陷入根证书弱密钥风波。官方回应承认密钥确实生成于 FIPS 140-2 Level 3 认证的 HSM，问题不在「没用 HSM」，而在证书仪式的一个 key wrap/unwrap 步骤意外生成了第二套弱密钥，而进入浏览器信任库的正是这套弱密钥。缺陷潜伏超过 18 个月、躲过两轮独立审计，最终由研究者借助 AI 工具逆向破解发现，涉事的 8 个中间证书已全部吊销。

已确认

  • eMudhra 官方回应承认密钥生成于 FIPS 140-2 Level 3 认证的 HSM，缺陷位于证书仪式的 key wrap/unwrap 步骤。
  • 据 @tokenbender 转述的官方时间线：2025 年 4 月 30 日密钥生成仪式产生 8 个中间 CA；同年年中进入浏览器信任列表并通过两轮独立审计；2026 年 10 月 17 日研究人员通报问题，次日 8 个中间证书全部吊销。
  • 部分涉事证书有效期到 2028-12-31；eMudhra 声称这些密钥「从未被使用」超过 18 个月。
  • 安全研究者 ghidraninja 公开逐条批驳 eMudhra 的官方回应。

尚未确认

  • @karishnu 认为业界低估了 eMudhra 存在恶意的可能：其推测弱密钥生成步骤是主动添加、再包装成低级失误，并计划以图解和 Python 代码展示分析，目前属分析推测而非结论。
  • @kingslyj 提出两个待解疑问：CA 是否会常规性预生成证书并长期闲置不用？8 张冗余证书是否正常？这些疑点尚无官方解释。

为什么重要

  • 根证书是整个 HTTPS 信任链的基石，CA 仪式流程缺陷能让弱密钥进入全球浏览器信任库并潜伏一年半、躲过两轮审计，说明现有审计机制存在盲区。
  • @basedjensen 与 ghidraninja 呼吁将 eMudhra 踢出全球信任商店（global trust store），若成真将影响其签发的所有证书的信任状态，事件也可能推动业界重新审视密钥仪式与审计标准。

第 3 集 · mitmproxy 新增 --emudhra 选项玩梗失陷 CA 密钥(2026-10-22,2 条)

10 月 22 日,mitmproxy 合并 PR #8500,新增 --emudhra 选项,允许使用已被认定失陷的 eMudhra 中间 CA 密钥签署 TLS 证书,共改动 6 个文件。这一功能迅速在安全圈引发玩梗热潮,有发帖人调侃「是时候更新 mitmproxy 了,不过是为了完全不同的原因」,并 @eMudhra,该事件也与近期 CA 密钥泄露风波相呼应。