本月，Let's Encrypt 正在启用新的基础设施来支持通过证书吊销列表吊销证书。尽管证书吊销列表在十多年前就被在线证书状态协议 (OCSP) 大大取代，但随着最近的浏览器更新，CRLs 正在获得新的生命力。通过为用户收集和汇总 CRLs，浏览器正在使证书的可靠吊销成为现实，从而提高了网络的安全性和隐私性。让我们谈谈这种新的基础设施究竟做了什么，以及为什么它很重要。

吊销简史

当证书变得不可信时（例如，因为它的私钥被泄露），该证书必须被吊销，并且该信息必须公开，以便将来没有人依赖它。然而，在 Web 公钥基础设施 (Web PKI) 的世界里，有一句耳熟能详的格言：吊销机制已经失效。在 Web PKI 的历史上，主要有两种机制用于声明 TLS/SSL 证书不再可信：证书吊销列表 (CRLs) 和在线证书状态协议 (OCSP)。不幸的是，两者都存在重大缺陷。

CRLs 基本上只是一份清单，列出了给定证书颁发机构 (CA) 颁发的所有已被吊销的证书。这意味着它们通常非常大 - 轻松地达到一部完整电影的大小。对于您的浏览器来说，下载一个巨大的吊销证书列表只是为了检查您正在访问的网站的单个证书是否已被吊销，这是非常低效的。这些缓慢的下载和检查会导致网页加载速度变慢，因此 OCSP 被开发出来作为一种替代方案。

OCSP 有点像“如果每个证书都有一个单独的 CRL”: 当您想要检查给定证书是否已被吊销时，您的浏览器可以通过联系 CA 的 OCSP 服务来检查该证书的状态。但由于 OCSP 基础设施必须持续运行，并且像任何其他 Web 服务一样可能出现停机，因此大多数浏览器将完全没有响应视为等同于收到“未吊销”响应。这意味着攻击者可以通过阻止您对 OCSP 信息的所有请求，来阻止您发现证书已被吊销。为了帮助减少 CA 的 OCSP 服务上的负载，OCSP 响应是有效的，并且可以缓存大约一周。但这意味着客户端不会经常检索更新，并且经常在证书被吊销后一周内继续信任证书。也许最糟糕的是：由于您的浏览器对您访问的每个网站都发出了 OCSP 请求，因此恶意 (或受法律强制) 的 CA 可以 跟踪您的浏览行为，方法是跟踪您请求 OCSP 的网站。

因此，现有的两种解决方案都无法真正解决问题：CRLs 效率太低，以至于大多数浏览器都不会检查它们，而 OCSP 的可靠性太差，以至于大多数浏览器也不会检查它。我们需要更好的东西。

浏览器汇总的 CRLs

最近取得进展的一个可能的解决方案是专有、浏览器特定的 CRLs 的想法。虽然不同的浏览器正在以不同的方式实现这一点（例如，Mozilla 将他们的称为 CRLite，而 Chrome 的称为 CRLSets），但基本思想是相同的。

浏览器供应商会集中下载 CRLs，而不是让每个用户的浏览器在他们想要检查吊销时下载大型 CRLs。他们将 CRLs 处理成更小的格式，例如 布隆过滤器，然后使用预先存在的快速更新机制将新的压缩对象推送到所有已安装的浏览器实例。例如，Firefox 每 6 小时就会尽可能快地推送更新。

这意味着浏览器可以提前下载吊销列表，从而保持页面加载速度，并减轻普通 CRLs 的最严重问题。它使吊销检查保持本地化，并且推送的更新可以立即生效，而无需等待可能长达数天的 OCSP 缓存过期，从而避免了 OCSP 的所有最严重问题。

由于这些浏览器汇总的 CRLs 的承诺，Apple 和 Mozilla 根程序都要求所有 CA 在 2022 年 10 月 1 日之前开始颁发 CRLs。具体而言，他们要求 CA 开始颁发一个或多个 CRLs，这些 CRLs 共同涵盖该 CA 颁发的所有证书，并且指向这些 CRLs 的 URL 列表应在通用 CA 数据库 (CCADB) 中公开。这将允许 Safari 和 Firefox 切换到使用浏览器汇总的 CRL 检查来进行吊销。

我们的新基础设施

Let's Encrypt 成立之初，我们明确决定只支持 OCSP，而不生产 CRLs。这是因为当时的根程序要求只强制执行 OCSP，而维护两种吊销机制会增加出现 bug 导致合规性事件的可能性。

当我们着手开发 CRL 基础设施时，我们知道我们需要为可扩展性构建，并且以反映我们对效率和简单性的重视的方式进行构建。在过去几个月里，我们已经开发了一些新的基础设施来使我们能够发布符合即将发布的规定的 CRLs。每个组件都很轻量级，专用于执行一项任务并将其执行好，并且能够扩展到超出我们当前需求的水平。

Let's Encrypt 目前每天都有超过 2 亿个活动证书。如果我们发生需要同时吊销所有这些证书的事件，那么生成的 CRL 将超过 8 GB。为了使事情变得更易于管理，我们将把我们的 CRL 分成 128 个分片，每个分片的最大容量为 70 MB。我们使用一些精心构建的数学公式来确保 - 只要分片数量不变 - 所有证书在重新发布 CRL 时将保留在它们各自的分片中，以便每个分片可以被视为具有稳定范围的微型 CRL。

与我们证书颁发流程中遵循的最佳实践一致，我们所有的 CRL 都将在由我们的颁发中间机构签名之前，对其进行 RFC 5280 和 基本要求 的合规性进行检查。尽管流行的 linting 库 zlint 还不支持 linting CRLs，但我们已经编写了自己的检查集合，并希望将来将其上游到 zlint。这些检查将有助于防止合规性事件，并确保颁发和续订流程顺利进行。

在开发这些新功能的过程中，我们还对 Go 标准库的 CRL 生成和解析实现进行了几个 改进。我们期待在未来与 Go 社区和其他成员一起更频繁地使用 CRLs 时，贡献更多改进。

虽然我们将发布涵盖我们颁发的所有证书的 CRL，但我们不会将这些 URL 包含在证书的 CRL 分发点扩展中。目前，根据基本要求，我们的证书将继续包含一个 OCSP URL，任何人都可以使用它来获取每个证书的吊销信息。我们的新的 CRL URL 仅在 CCADB 中公开，以便 Apple 和 Mozilla 根程序可以消费它们，而不会将它们暴露给来自互联网上其他用户的潜在大量下载流量。

吊销的未来

在 Web PKI 中的吊销真正得到修复之前，还有很长的路要走。只有在所有客户端都停止依赖 OCSP 后，围绕 OCSP 的隐私问题才会得到缓解，我们仍然需要开发出良好的方法，让非浏览器客户端可靠地检查吊销信息。

我们期待继续与 Web PKI 社区中的其他成员合作，使每个人都能私密、可靠和高效地进行吊销检查。

如果您对我们开发更强大、更私密的吊销机制的工作感到兴奋，您可以通过捐赠来支持我们，或者鼓励您的公司或组织赞助我们的工作。作为一个非营利项目，我们 100% 的资金来自社区和支持者的贡献，我们依赖您的支持。