印度CA私钥设为4：HTTPS信任体系再曝致命漏洞

一个数字四，击穿了HTTPS的信任基础

据YouTube科技评论频道Lunduke Journal披露，一家名为eMudhra的印度根证书机构（CA）将其八个中间证书的私钥设置成了极简数字——其中一个私钥竟然就是“4”。任何具备基础密码学常识的人都能在几秒内猜出这个密钥，进而伪造任意域名的HTTPS证书。

更令人不安的是时间线：这些弱密钥早在2025年4月就已发布，但直到同年10月17日，才被一位化名“Wayne”的匿名安全研究员发现并公开。在长达一年半的时间里，攻击者完全可以利用这些私钥签发看似合法的HTTPS证书，而外界对此一无所知。

根证书机构（Root CA）与中间证书：在PKI（公钥基础设施）体系中，根CA是信任链的起点，其根证书被预装在浏览器和操作系统中。为了降低根私钥暴露的风险，根CA通常不直接签发终端证书，而是签发中间证书（Intermediate CA），再由中间证书签发网站证书。这样，攻击者若只攻破中间证书，根CA可以吊销它来止损。但中间证书的私钥同样具有签发能力，一旦弱如“4”，攻击者就能伪造任意域名的证书，且由于信任链完整，浏览器不会告警。

证书透明度（Certificate Transparency, CT）：这是一套公开审计日志系统，要求CA签发的每张证书都提交到公开的CT日志中，浏览器可检查网站证书是否被记录。CT能发现异常签发（如伪造证书），但前提是CA诚实提交。若私钥已泄露，攻击者可自行签发而不提交日志，CT只能事后追溯，无法阻止攻击。

漏洞的实质：不是加密强度问题，而是信任锚点失守

很多人第一反应是“加密算法是不是不够强”。这个事件恰恰说明，问题不在AES或RSA的位数，而在整个PKI体系的信任锚点。根证书机构是整个HTTPS信任链的起点，浏览器和操作系统默认信任它们签发的证书。一旦根CA或其下属中间证书的私钥泄露或过于简单，下游所有依赖该信任链的系统都会沦为“帮凶”。

据Lunduke在视频中展示的Mozilla Bugzilla讨论，初步估计约有30,000张证书需要迁移，其中约97%通过ACME协议自动签发。这意味着大量站点可能在不知情的情况下使用了可被伪造的证书链。

Mozilla在得知漏洞后用了三天才更新其证书信任列表（NSS），而这一列表被curl、Python等大量开源项目依赖。三天窗口期内，任何依赖该列表的系统都处于风险之中。截至目前，macOS等系统仍未完成更新，漏洞的尾部影响远未结束。

ACME协议：自动证书管理环境（Automatic Certificate Management Environment）是Let's Encrypt等CA推广的自动化协议，允许服务器自动申请、验证和续期证书。文中约97%的受影响证书通过ACME自动签发，意味着大量站点在不知情下接入了有问题的证书链。ACME提高了效率，但也放大了错误配置的传播速度——一旦CA环节出错，自动化流程会让弱证书快速扩散。

NSS（Network Security Services）：Mozilla维护的网络安全服务库，包含浏览器和许多开源软件共用的根证书信任列表。curl、Python等工具直接依赖NSS的信任库。Mozilla更新NSS的延迟，会直接导致这些工具在窗口期内继续信任被污染的中间证书。

为什么说这是“设计层面”的缺陷

Lunduke在节目中重申了他多年前的观点：HTTPS所依赖的CA体系本质上是“基于信任的安全”，而非“基于数学的安全”。全球有数十家根证书机构，分布在不同的法律管辖区，受不同政府或企业影响。要求其中每一家、每一个环节都不犯低级错误，在逻辑上是不可能的。

他把这次事件比作“把行李箱密码设成12345”——而私钥设为4，比这还要低几个数量级。更关键的是，这个体系的设计使得单一CA的失误可以波及全球，而外界几乎无法审计每家CA的内部操作。这种结构性的信息不对称，才是问题反复出现的根源。

有安全研究者曾制作了一个google.com子域名的伪造证书作为概念验证，证明攻击门槛之低。这并非孤例，而是CA体系长期存在的系统性风险的一次集中暴露。

公钥基础设施（PKI）的信任模型：PKI通过CA层级为公钥绑定身份，其安全性依赖于“所有CA都严格保管私钥”这一假设。但全球有数十家根CA，分布在不同司法管辖区，受不同政府和商业实体影响，审计难以覆盖内部操作。这种“信任传递”模型本质上是社会信任的技术化，而非数学证明。单一CA的失误（如私钥设为4）会沿信任链向下游所有系统扩散，而终端用户无法自主选择信任哪些CA，形成了结构性的信息不对称。

修复困境与后续影响

简单的“升级加密算法”并不能解决这类问题。只要根CA的私钥管理存在人为失误或恶意后门，攻击面就始终存在。可行的缓解措施包括证书透明度（Certificate Transparency）日志的强制审计、CA机构的定期外部审计，以及缩短证书有效期以降低单点失误的影响窗口。

对开发者和运维团队而言，眼下最实际的动作是检查自身证书链是否涉及eMudhra签发的中间证书，并及时更新系统信任库。对普通用户来说，这个事件提醒我们：浏览器地址栏上的那把“锁”只代表连接经过了某个CA的签名，并不等于对方身份绝对可信。

HTTPS仍然是当前最可行的传输安全方案，但它的安全性建立在持续审计和及时响应之上，而非一劳永逸的信任。当一家CA能把私钥设成4，整个生态都需要重新审视“默认信任”的代价。