Disgraced eMudhra drops out of TLS business after using cert private key of 4
TL;DR · AI 摘要
eMudhra因使用4位私钥导致TLS证书被破解，退出TLS业务，凸显证书安全的重要性。
核心要点
- TLS证书私钥位数应为384位，但eMudhra证书私钥仅3-8位，易被破解。
- 浏览器厂商在发现漏洞后迅速吊销相关证书，防止大规模信任危机。
- eMudhra退出TLS业务主因是行业竞争激烈且合规成本过高。
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- eMudhra TLS事件
- 技术漏洞
- 私钥位数缺陷（3-8位）
- NIST P-384标准（384位）
- 行业影响
- 浏览器厂商快速响应
- CA/Browser Forum资质风险
- 公司决策
- 退出TLS业务
- 合规成本与竞争压力
金句 / Highlights
值得收藏与分享的关键句。
私钥位数从标准384位降至3-8位，破解时间仅需数毫秒。
浏览器厂商在漏洞发现后1-2天内全面阻断相关证书。
eMudhra业务收入中TLS仅占1%，免费证书服务加剧其困境。
被曝光的eMudhra因使用4位私钥证书退出TLS业务 - Ars Technica
HAPPY TRAILS!
被曝光的eMudhra因使用4位私钥证书退出TLS业务
密钥签名仪式失误导致任何人都能伪造网站凭证
Dan Goodin
–
2026年10月22日 下午4:17
|
56
就像这个无头实体一样，Let's Encrypt可以提供加密证书，但不会再通过邮件提醒你续订。
图片来源：Getty Images
按钮
文本设置
面板
正文文本
大小
小号
标准
大号
宽度
*
宽屏
链接颜色
橙色
- 仅限订阅者
了解更多
最小化到导航栏
印度eMudhra Limited公司主席V. Srinivasan表示，这家曾签发过8个中间TLS证书的证书机构将退出TLS业务，这些证书的强度低到任何人都能伪造任何网站或邮件服务器的证书——其中一个证书的私钥仅有4位。
Srinivasan指出，合规要求日益增加的成本和复杂性，加上该业务仅贡献公司1%的收入，是退出的重要原因。他还表示，提供免费TLS证书的组织兴起，进一步降低了该业务的投资回报率，与其他产品和服务相比优势不再。
请别让门夹到屁股
该公司周四在声明中继续表示：“然而，此次事件在社交媒体上的传播程度与SSL/TLS在我们业务中的重要性严重不匹配。”“鉴于此，经过详细讨论，董事会认为eMudhra及其股东的最佳选择是退出全球SSL/TLS业务。”
这项声明发布于研究人员揭露eMudhra曾签发8个私钥存在致命缺陷的证书两天后。这些证书的私钥强度低到只需毫秒级计算就能破解，攻击者可利用它们生成被所有主流浏览器信任的TLS证书，以及无数邮件服务器、物联网设备、Docker容器、被遗忘的Linux机器和未维护的CLI工具中预装的根证书副本。
而eMudhra签发的证书本应使用NIST P-384椭圆曲线密码学私钥，理论上应包含约384位熵值。但被泄露的8个证书私钥位数却仅有3到8位不等。换言之，理论上应存在2^384（一个116位数）种不同密钥可能性，但最强大的缺陷密钥也仅有256种可能性。这些私钥位数分别为：4、56、66、115、155、156、230、237。
浏览器厂商在发现这些中间证书后一两天内就封禁了相关证书。eMudhra几乎可以肯定将面临CA/Browser Forum（证书颁发机构/浏览器论坛）吊销其证书机构资质的风险，这个行业组织制定了TLS证书项目的准入规则。
问题出在哪里？部分解释。
周三，eMudhra对此次事件给出了简要解释。该公司表示，这些证书“是在2025年4月30日举行的密钥生成仪式（KGC）中，使用FIPS 140-2三级硬件安全模块（HSMs）在eMudhra的ECC根证书下创建的。”“KGC中的一个缺陷导致封装/解封装步骤生成了与原始强密钥并存的第二组弱密钥。被发布到浏览器根证书存储中的正是这些弱密钥。eMudhra正在努力查明根本原因。”
HSMs是专门用于存储加密密钥和其他高度敏感数据的专用设备。它们通常与网络的大部分部分隔离，以防止数据泄露。封装和解封装是指在密钥从一个HSM转移到另一个HSM时发生的过程。在交接之前，存储密钥的HSM会使用另一个密钥对它进行封装。当加密后的密钥被转移到新的HSM后，后者会对其进行解封装。
在Mozilla的Bugzilla论坛上的一条线程中，eMudhra提供了更多细节：其中包括：
[T]看起来在那天用于创建这些ECC发行机构的KGC脚本存在缺陷。至于这些ECC密钥，我们对KGC的审查、代码评估以及对HSM密钥的查看表明：a) 一组原始的ECC密钥按预期在设备上生成；b) 为了测试封装/解封装功能，我们引入了对常规KGC的批准偏差，因为这些密钥本应用于此次实例的出口；c) 代码中的缺陷导致在设备上生成了第二组较弱的密钥；d) 这些较弱的第二组密钥由于密钥标签相似而被错误地用于生成CSR（证书签名请求），并由我们的根证书签名；e) 这些较弱密钥生成的CSR也被发送给了[其他证书机构] Sectigo进行交叉签名（我们已验证发送给Sectigo的文件）。
此外，eMudhra还表示：
CRL（证书吊销列表）是使用原始私钥（本应是具有适当熵值的正确密钥）签名的，但由于这导致了错误的签名，因此它们被使用有缺陷的密钥重新签名。在该流程的多个步骤中出现了人为错误，导致此次KGC的密钥生命周期完整性流程出现了重大缺陷。我们现在正在深入挖掘代码缺陷、流程漏洞以及针对此问题的制作者/检查者控制措施。在未来一周内，我们将重新验证我们进行过的所有密钥仪式。
CRL（证书吊销列表）是由证书颁发机构发布的数字签名列表，用于标识在到期日期之前已被撤销的证书。初始签名导致错误CRL签名的这一事实引发了疑问：为什么eMudhra没有调查此次失败的原因？
由于中间证书被浏览器阻止，大部分威胁已经消失。但许多其他依赖相同证书的设备需要更长的时间才能采取相同行动。还有一些设备，例如嵌入式设备，可能永远无法阻止它们。
高级安全编辑
Dan Goodin是Ars Technica的高级安全编辑，负责监督恶意软件、计算机间谍活动、僵尸网络、硬件黑客攻击、加密和密码的报道。在空闲时间，他喜欢园艺、烹饪和关注独立音乐场景。Dan目前驻扎在旧金山。关注他：
here
在Mastodon上和
在Bluesky上。通过Signal联系他，联系方式为DanArs.82。
56条评论