黑客伪造出 Google 及其他大型服务的 TLS 证书

Hackers obtain counterfeit TLS certificates for Google and other large services — arstechnica.com · 3 小时前 · 🔒 安全

攻击者通过控制国家代码顶级域名并篡改其下的权威 DNS 记录，成功骗过域名控制权的自动验证流程，为 Google 旗下若干域名以及多家全球知名品牌和常用在线服务签发出了未经授权的 TLS 证书。Google 在周二披露了这起事件，称攻击集中在 .gh、.sl 与 .as 三个国家代码顶级域名上；一旦掌握这些命名空间的解析权，攻击者就能把指定域名的验证记录指向自己控制的服务器，使证书颁发机构在自动化校验中确认申请人「拥有」该域名，最终拿到签名合法但对象错误的 x.509 证书。Google 表示已更新 Chrome 浏览器，拦截其识别出的全部未授权证书，并与相关证书颁发机构合作，确保为 Google 资产签发的伪造证书被吊销。文章强调，TLS 证书是网站、邮件服务器及其他互联网基础设施进行身份认证与加密的密码学凭据：证书用数字签名把 google.com 之类的域名与一个公钥绑定，公钥公开可查，私钥仅由站点运营者持有，连接双方公钥匹配即认为对端是真实站点；因此持有未授权证书的攻击者可以在密码学层面冒充受影响的设施。作者的核心结论是，证书签发链条中真正脆弱的一环并不在加密算法本身，而在于域名控制权验证所依赖的 DNS 与顶级域名治理体系，一旦注册局或注册商层面的控制被夺走，整条信任链就会从源头被击穿。

核心信息

攻击链条可以拆成四步：劫持顶级域名、篡改权威 DNS 记录、通过自动化的域名控制验证、拿到证书。.gh（加纳）、.sl（塞拉利昂）、.as（美属萨摩亚）三个国家代码顶级域名先后被攻破，攻击者随后修改这些命名空间内选定域名的权威解析记录，让签发机构在自动校验时把验证记录解析到攻击者控制的服务器，从而为 Google 的若干域名以及多家全球知名品牌和广泛使用的在线服务签出了未授权的 x.509 证书。
缓解措施方面，Google 表示已更新 Chrome 浏览器，拦截其识别出的全部未授权证书，并与签发这些证书的证书颁发机构协作，确保针对 Google 资产的伪造证书被吊销；但披露内容没有给出受影响域名的完整清单、涉事签发机构名称、伪造证书的具体数量，以及从签发到吊销之间相隔多久，也没有说明攻击者是否已经利用这些证书实施中间人攻击或邮件拦截。
证书机制层面：TLS 证书是网站、邮件服务器和其他互联网基础设施用于认证与加密的密码学凭据，x.509 证书通过数字签名把类似 google.com 的域名与一个公钥绑定；公钥公开可查，私钥只由站点运营者持有，访问方只要确认两者匹配，就能判断自己连上的是真实站点而不是冒名者，因此掌握未授权证书的攻击者可以在密码学意义上冒充受影响的设施，且这种冒充对依赖证书校验的软件而言几乎无法分辨。

💡 为什么值得读: 它把一次真实的证书伪造事件拆解成可复用的攻击链条，并提醒人们信任链最脆弱的一环往往不在算法，而在域名治理与吊销流程。

✍️ 小编看法: 这次事件最值得记住的一点是：密码学本身没有被打败，被打败的是域名控制权的验证流程。攻击者不需要破解 RSA 或椭圆曲线，只要拿下 .gh、.sl、.as 这类小型国家代码顶级域名的注册与解析控制权，就能让证书颁发机构心甘情愿地签出「合法但错误」的证书。对小岛屿和欠发达地区的 ccTLD 来说，注册局往往人手有限、审计薄弱，却握有与大型商业注册局等价的信任权重，这种不对称是整个生态长期被忽视的成本。另一个被忽略的代价是吊销与拦截的滞后性：Chrome 的黑名单更新只保护用浏览器访问网页的用户，邮件客户端、移动应用内置的证书校验、物联网设备与老旧的 Java 运行时并不会自动跟进，只要有一个证书存活到有效期结束，攻击窗口就一直敞开。反过来看，这也是推进更强验证机制的机会：多视角域名控制验证、CAA 记录、DNSSEC、基于 DNS 的随机挑战以及强制证书透明度日志比对，都能把单点劫持的收益大幅压低；证书有效期持续缩短同样在压缩滥用的时间窗。下一步值得观察的是：哪些证书颁发机构牵涉其中、透明度日志能否还原完整的签发时间线、相关 ccTLD 是否会公开事后审计结果，以及浏览器之外的基础设施厂商会不会建立独立于浏览器的吊销同步渠道。信任链的根不在算法里，而在流程和人的手里。

🏷️ TLS, certificates, DNS, ccTLD