我们对 eMudhra 密钥泄露事件的回应

# 我们对 eMudhra 密钥泄露事件的响应 - Go 编程语言 来源：https://go.dev/blog/emudhra-incident 10 月 19 日，Go 团队启动了一次加急安全发布 (https://groups.google.com/g/golang-announce/c/66pojueaQek)，以保护 Go 用户及其应用程序免受一起涉及 eMudhra 所颁发证书的严重公钥基础设施 \(PKI\) 安全失陷事件的影响。在收到通知后约七个半小时内，我们发布了一个针对性补丁，并将其纳入我们首次采用 URGENT 通道 (https://go.dev/doc/security/policy#urgent)的安全发布。本文将介绍此次事件的背景、Go 为何在运行时层面采取措施保护用户，以及我们的事件响应过程。 ## eMudhra 事件 10 月 17 日，Mozilla 将由 eMudhra 控制的根证书所颁发的八个中间证书（六个用于 TLS，两个用于代码签名）加入了 OneCRL，从而有效阻止了它们在 Firefox 中的使用。不久后，多名安全研究人员注意到了这一变化，并开始调查其可能的原因。10 月 19 日，Go 安全团队获悉了这些调查及其结论：与这些中间证书关联的密钥极其薄弱，只需几微秒即可恢复私钥。由于 eMudhra 的根证书存在于大多数受信任根证书计划中，恢复这些私钥后，任何攻击者都可以为任意域名签署 TLS 证书，而无需按通常要求证明自己控制着该域名。这将使攻击者能够对 TLS 连接实施中间人 \(MITM\) 攻击，并为自己并不控制的域名出示有效证书，从而冒充目标计算机尝试连接的任何 TLS 服务器。Go 的标准库内置了 TLS 证书验证器。当用户使用 `net/http` (https://pkg.go.dev/net/http) 或 `crypto/tls` (https://pkg.go.dev/crypto/tls) 连接 TLS 服务时，系统会调用该验证器，检查连接另一端出示的证书是否有效。在 Windows 和 macOS 上，我们将这些检查委托给平台 API；而在缺少此类平台 API 的 Linux 上，我们使用自己的验证器实现。由于 Linux 没有统一的内置机制来检查证书吊销状态，同时为了及时修复其他平台上可能无法收到平台更新的用户所面临的问题，我们认为，保护 Go 用户的最佳方式是通过 URGENT 通道 (https://go.dev/doc/security/policy#urgent)进行一次安全发布，同样移除对这些证书的信任。 ## 事件时间线 典型的 Go 安全发布流程会持续数天，并提前发布预告，以便依赖 Go 的用户做好准备。在此次事件中，由于我们认为私钥即将泄露，团队决定首次使用 URGENT 通道，以便在公开的主动利用开始之前提供防护。 **11:45 PDT** 一名独立的外部研究人员向我们的安全团队发出警报，提及 Mozilla 和其他组织尚未公开的行动：移除对八个 eMudhra 中间证书的信任。我们很快确认，原因是这些证书所使用的私钥过于薄弱。 **12:30 PDT** Mozilla 独立向我们的安全团队报告了此问题，确认了问题的存在，并要求我们不要立即披露，但鼓励我们尽快发布修复。 **14:00 PDT** 我们完成了补丁，阻止使用证书链通向已失陷中间证书的证书。最初向我们发出警报的研究人员还提供了一组使用恢复出的密钥签署的证书，供我们测试。 **15:00 PDT** 我们开始发布包含补丁的 Go 次要版本 1\.27\.3 和 1\.26\.10。鉴于此问题的紧迫性和可利用性，以及我们认为私钥很可能在数小时内公开，我们决定立即发布是最审慎的选择。 **19:13 PDT** 我们完成发布并对外公告。此时，底层问题仍未广为人知。为了让其他防御方有机会保护尽可能多的用户，同时避免向攻击者透露利用方式，我们的补丁和公告有意保持了一定的模糊性，告知用户我们“出于对一小部分中间证书运行方式的特定安全顾虑，正在阻止对这些证书的信任”，并敦促用户立即升级到此次发布的版本。从最初收到通知到带有补丁的 Go 版本在全球上线，用时不到七个半小时。这让用户在密钥公开之前，就拥有了保护其部署所需的一切。到 10 月 20 日上午，多名独立研究人员已公开披露了这些薄弱密钥。 ## 经验教训与未来改进 这是我们首次通过 URGENT 通道进行安全发布。在发布过程中，我们遇到了若干问题，导致发布时间超出预期。虽然我们很高兴能在收到问题通知的当天完成发布，但在当今的安全环境下，我们认为应当能够在更短的时间内提供新版本。这些问题使整个发布流程从开始到结束耗时接近四小时十五分钟。此前，它们并未造成困扰，因为常规发布流程分散在数天内完成。此后，我们已做出多项调整以提高发布效率，这应当能够显著缩短发布所需的时间，增强我们快速响应紧急安全威胁的能力。PRIVATE 通道的安全修复会在发布前三至七天预告。URGENT 通道的修复时间更紧，但我们本可以在启动发布流程时就预告即将发布的版本，让用户至少有几个小时做好准备。在 Windows 和 macOS 上，我们依赖平台 API 提供的吊销机制，但在 Linux 上，目前还没有类似机制。缺少这项支持是促使我们进行加急安全发布的主要原因之一，因为我们不希望 Linux 用户暴露于此问题的时间超过必要范围。因此，我们计划优先推进相关工作，使 Linux 上的吊销支持达到同等水平，以帮助缓解未来出现的此类问题。其中一部分工作将研究添加对 upki 项目 (https://github.com/rustls/upki)的支持。该项目旨在为 Linux“提供可靠、保护隐私且高效的证书吊销机制”（参见议题 \#82402 (https://go.dev/issue/82402)）。 ## 升级并验证你的部署 如果你运行的 Go 二进制文件使用 TLS 与网络服务交互（例如直接通过 `net/http` 或 `crypto/tls`，或通过 gRPC 等依赖项），请确保使用最新的次要版本。使用 Go 1\.27\.3 和 1\.26\.10 重新构建的二进制文件，将自动拒绝由已失陷的 eMudhra 中间证书所颁发的证书。你可以使用 `go version` 验证当前工具链版本，也可以使用 `go version \-m ` 检查构建某个二进制文件所用的 Go 版本。还可以使用 govulncheck 工具 (https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck)判断二进制文件是否受此问题影响： `` $ GOTOOLCHAIN=go1.27.3+auto go install golang.org/x/vuln/cmd/govulncheck@latest $ govulncheck -mode=binary `` ## 保障各处 Go 部署的安全 对我们而言，保障 Go 及其用户的安全，不仅包括修复我们所提供的运行时和库中的直接安全漏洞。为了维护生态系统的安全，我们认为还需要为用户提供编写安全软件的适当工具，着眼于密码算法与协议的未来发展，并在能力范围内主动响应影响整个生态系统的问题。我们感谢独立安全研究人员和 Mozilla 安全团队在此次事件中的迅速通报与协调。