印度一家证书公司造了八把私钥，其中一把的值是 4。
上周五晚上八点零六分，一个叫 Wayne 的研究员把这事报给了火狐和 Chrome。当晚九点四十八分，Mozilla 的人在自己这边把八把钥匙全算了出来。没问对方用的什么办法。十点五十九分，屏蔽名单推到了默认配置的火狐上。三个小时不到。
这几把本该是 P-384 曲线私钥，正常有相当于一百一十六位十进制数的搜索空间。
实测值分别是 4、56 和 115，最大的一个也只有 237，全都小于 256。研究员 Scott Helme 说，他从公开证书里把八把全捞出来，用不到一秒。捞出来。就这么快。
很多人以为证书出事就是被黑了。这次没有。其实机房没进人，数据没丢，物理和逻辑控制全部完好，这是 eMudhra 给孟买证交所和印度国家证券交易所那份公告里写的。那这把钥匙是怎么变弱的？生成脚本写错了。去年四月三十号那场密钥生成仪式，一场按 FIPS 140-2 三级硬件模块、一步不落走完的仪式，wrap 和 unwrap 那一步多做了一套弱钥匙出来。偏偏标签长得像。后来做签名请求的时候拿错了，把弱的那套发了出去。
审计连过两年，那会儿是二〇二五年年中，就进了浏览器信任列表。结果十八个月，愣是没人发现。审计查的是流程有没有按文档跑完，不查这把钥匙的随机性够不够。
麻烦还长在信任链的形状上。中间 CA 签出去的证书，下游一律认下来。八把中间钥匙里六把管 TLS，两把管代码签名。Security Brigade 的 Yash Kadakia 估，大约三万张还在用的正经证书得迁移。他还说，全球互联网的信任链，一个公司失手能拖从没跟它打过交道的组织一起下水。
四家浏览器的反应速度可以看一眼。Chrome 和火狐十七号当天封。苹果十九号。微软二十号。Cloudflare 十九号收到消息，二十号出报告。谷歌封的是公钥哈希，所以拿同一把钥匙做的交叉签名证书也一起挡住了，连重启都不用。这部分做得干脆。
真正没盖住的是浏览器外头。Go 写的服务、用 certifi 的 Python 程序、Rust 的 webpki-roots、一批打包了自家证书库的安卓应用、机房里的老 Java 系统、企业网关、摄像头、路由器，它们的信任列表跟 Chrome 压根不是同一份，浏览器那边三小时就修完了，这些部件只能等自己那个版本更新，而修得快不快取决于这个部件多久更新一次，跟事故多大关系不大。你家路由器多久更新一次，你知道吗。没人统计过，到现在也没个准话。
Mozilla 的 Dennis Jackson 放了个测试页，能查客户端还认不认这几张证书。几十秒的事。自己去点一下。
剩下的部分才值得琢磨。整套 HTTPS 其实是建立在名单上，我给你一份我认的公司，名单外的不认。出事之后能做的最强动作就是把名字划掉。划得掉。名单攥在浏览器手里，反正不在出事那家手里。
链上那套反着来。比特币没有哪家公司签个字全体就认。每个节点从第一笔交易开始自己验一遍全部历史。慢。笨。费电。可它出岔子之后不用等四家浏览器分别发名单。代价也实在，链上干脆没有撤销这回事，发错了就永远躺在账本上。
跨链桥的多签、预言机的喂价、稳定币的储备证明，干的活跟中间 CA 一模一样。上游签了字，下游就信。要出事，形状跟这次不会差太多。
分野只在事后能不能重算。证书这条链，你只能等名单更新。账本那条链，你能把每一笔重新验一遍。
真落到手上，两件事。翻一遍常开的服务，看还有没有靠一张老证书撑着。再去钱包和交易所里看一眼提币白名单，那三个多签的签名人，是不是同一个办公室、同一台云、同一个手机号在管。这三样里有两样撞在一起，剩下的安全等级就剩一样。
$BTC $ETH $LINK
#比特币 #以太坊 #网络安全 #证书链
上周五晚上八点零六分，一个叫 Wayne 的研究员把这事报给了火狐和 Chrome。当晚九点四十八分，Mozilla 的人在自己这边把八把钥匙全算了出来。没问对方用的什么办法。十点五十九分，屏蔽名单推到了默认配置的火狐上。三个小时不到。
这几把本该是 P-384 曲线私钥，正常有相当于一百一十六位十进制数的搜索空间。
实测值分别是 4、56 和 115，最大的一个也只有 237，全都小于 256。研究员 Scott Helme 说，他从公开证书里把八把全捞出来，用不到一秒。捞出来。就这么快。
很多人以为证书出事就是被黑了。这次没有。其实机房没进人，数据没丢，物理和逻辑控制全部完好，这是 eMudhra 给孟买证交所和印度国家证券交易所那份公告里写的。那这把钥匙是怎么变弱的？生成脚本写错了。去年四月三十号那场密钥生成仪式，一场按 FIPS 140-2 三级硬件模块、一步不落走完的仪式，wrap 和 unwrap 那一步多做了一套弱钥匙出来。偏偏标签长得像。后来做签名请求的时候拿错了，把弱的那套发了出去。
审计连过两年，那会儿是二〇二五年年中，就进了浏览器信任列表。结果十八个月，愣是没人发现。审计查的是流程有没有按文档跑完，不查这把钥匙的随机性够不够。
麻烦还长在信任链的形状上。中间 CA 签出去的证书，下游一律认下来。八把中间钥匙里六把管 TLS，两把管代码签名。Security Brigade 的 Yash Kadakia 估，大约三万张还在用的正经证书得迁移。他还说，全球互联网的信任链，一个公司失手能拖从没跟它打过交道的组织一起下水。
四家浏览器的反应速度可以看一眼。Chrome 和火狐十七号当天封。苹果十九号。微软二十号。Cloudflare 十九号收到消息，二十号出报告。谷歌封的是公钥哈希，所以拿同一把钥匙做的交叉签名证书也一起挡住了，连重启都不用。这部分做得干脆。
真正没盖住的是浏览器外头。Go 写的服务、用 certifi 的 Python 程序、Rust 的 webpki-roots、一批打包了自家证书库的安卓应用、机房里的老 Java 系统、企业网关、摄像头、路由器，它们的信任列表跟 Chrome 压根不是同一份，浏览器那边三小时就修完了，这些部件只能等自己那个版本更新，而修得快不快取决于这个部件多久更新一次，跟事故多大关系不大。你家路由器多久更新一次，你知道吗。没人统计过，到现在也没个准话。
Mozilla 的 Dennis Jackson 放了个测试页，能查客户端还认不认这几张证书。几十秒的事。自己去点一下。
剩下的部分才值得琢磨。整套 HTTPS 其实是建立在名单上，我给你一份我认的公司，名单外的不认。出事之后能做的最强动作就是把名字划掉。划得掉。名单攥在浏览器手里，反正不在出事那家手里。
链上那套反着来。比特币没有哪家公司签个字全体就认。每个节点从第一笔交易开始自己验一遍全部历史。慢。笨。费电。可它出岔子之后不用等四家浏览器分别发名单。代价也实在，链上干脆没有撤销这回事，发错了就永远躺在账本上。
跨链桥的多签、预言机的喂价、稳定币的储备证明，干的活跟中间 CA 一模一样。上游签了字，下游就信。要出事，形状跟这次不会差太多。
分野只在事后能不能重算。证书这条链，你只能等名单更新。账本那条链，你能把每一笔重新验一遍。
真落到手上，两件事。翻一遍常开的服务，看还有没有靠一张老证书撑着。再去钱包和交易所里看一眼提币白名单，那三个多签的签名人，是不是同一个办公室、同一台云、同一个手机号在管。这三样里有两样撞在一起，剩下的安全等级就剩一样。
$BTC $ETH $LINK
#比特币 #以太坊 #网络安全 #证书链