再见了，OCSP

2024/10/29，Microsoft Root Program 修改了[一个不起眼的文档](https://learn.microsoft.com/en-us/security/trusted-root/program-requirements) 中不起眼的一段，为持续一年多的 OCSP 告别仪式画上了一个句号，结束了 OCSP 大刀阔斧地向 CRL 举起大刀阔斧的时代。 让我们在这里纪念它，最后的 OCSP 强制要求（[时光机](https://web.archive.org/web/20241002221253/https://learn.microsoft.com/en-us/security/trusted-root/program-requirements)），它代表了公开加密基础设施一次长达 20 年的探索，也记录了人类网络基建突飞猛进的 20 年对技术的反向改变： ``` All end-entity certificates must contain an AIA extension with a valid OCSP URL. These certificates may also contain a CDP extension that contains a valid CRL URL. All other certificate types must contain either an AIA extension with an OCSP URL or a CDP extension with a valid CRL URL. ``` ## 什么是 或许我不需要解释什么是 OCSP(Online Certificate Status Protocol，在线证书状态协议)，因为国内开发者早已深受其害：几乎每个 Nginx 优化教程都在教你打开 OCSP Stapling。 正如我们所知，OCSP 本质是一个 HTTP 服务，用户在每次遇到证书时将证书序列号明文发给 CA 的服务器，CA 再明文返回一个是否可用的状态。 这比传统的 CRL(Certificate Revocation List，证书吊销列表) 可酷多了：用户不再需要每次上网就苦哈哈地用 56K modem 从 **每个** CA 那里下个数 M 的文件（其中包含这个 CA 最近吊销的所有没有过期的证书信息）才能安全上网，现在只需要一个小小的请求就行了！ ## 为什么 或许我也不需要解释为什么人们不再喜欢 OCSP 了： - Chrome 在 2012 年，OCSP 标准正式发布前一年（当然 OCSP 在那之前已经以 draft 方式运行了许多年，正如 quic 一样）宣布不再查询 OCSP。 - 苹果在 2020 年 11 月 13 日，用自己 OCSP 服务罢工、所有 macOS 应用无法启动的方式，让 OCSP 和它的运行机制为所有 Mac 用户所知。 相信在知道 OCSP 的工作原理之后，即使是果人也会提出 OCSP 的重要缺陷： - OCSP 是明文的，这代表了链路上每一个服务器，包括 CA 服务器本身，都可以知道用户在某个特定时间有访问某个特定服务。 - OCSP 会引入严重的单点故障风险，某个服务器的罢工就可能造成硬失败策略的客户端全面爆破（如苹果）。而如果允许软失败，OCSP 相当于一个几乎无用的安全机制。 - （苹果特有的）OCSP App 证书验证给了苹果在想要的时候肆意禁止不特定用户使用不特定应用的权力。 这些缺陷让 OCSP 越来越被视为无用的东西，而 OCSP 曾经面对的主要问题，CRL 尺寸过大已经被诸多缓解方案以及网络速度的飞速提升所抹平，告别 OCSP 已经是理所当然的事情。 ## 怎么做 各个软件有自己对于 CRL 现代化理解的方案： - Microsoft 有它的系统级 CRL 缓存（是的就是嘿客大佬们常用的 `certutil –urlcache`），只需要执行 `certutil –urlcache CRL` 即可检查。 - Chrome 在 2012 年宣布停用 OCSP 时发布了自己的 CRLSets，它包含在浏览器中，也会在联网时热更新，不需要重启浏览器即可生效。 - Firefox 在 2015 年推出了 OneCRL，以避免总是为所有中间根证书进行 OCSP 检查；在 2019 年启动了 CRLite，用于提供类似于 CRLSets 的带外全量证书吊销列表功能。 ## 结语 强制 OCSP 的时代过去了，我很怀念它。