01 · 共同动因：浏览器为何要自建吊销管道
当Chrome在2012年默认关闭在线吊销检查时，行业的反应不是修复OCSP，而是承认一个工程判决：依赖订户主动查询的吊销机制，在软失败约束下无法提供对抗主动攻击的能力。浏览器厂商的共同出路是把吊销数据做成自己控制的分发管道：由浏览器生态聚合吊销源、按自己的节奏推送到客户端、在本地做硬失败判定。这条路线牺牲了“全量实时”，换来了三个决定性优势——隐私（无逐次查询）、可用性（本地判定无外部依赖）、可控性（推送内容完全由浏览器根程序治理）。CRLSets、OneCRL、CRLite是同一思想的三代实现，覆盖能力递增。
02 · CRLSets：Chrome的应急优先策略
- 机制：Google维护一份小型吊销条目集合（经Google安全团队筛选的高优先级吊销，主要为中间CA证书与重大事件涉及的订户证书），以内置组件形式随Chrome更新推送。集合为紧凑的二进制格式，量级约数百KB。
- 判定语义：证书在CRLSet中→硬失败拒绝；不在集合中→按未吊销处理。集合之外不做任何在线检查（2012年Chrome 19起对普通证书停用OCSP；2022年起EV证书也不再执行在线检查，CRLSet成为Chrome吊销判断的唯一依据）。
- 覆盖边界：Mozilla披露的对照数据显示，CRLSet级精选集仅覆盖全球吊销量的约1%（约数万条 vs 全量数百万条活跃吊销）。这不是疏漏而是设计——CRLSets的目标从来是“挡住信任链级别的灾难性吊销”，而非逐张覆盖订户证书。
- 更新通道：经Chrome组件更新机制分发，重大事件可加速推送（如CA误签事件）。
定位判读：CRLSets是“最低保障+最高确定性”的策略——它对CA级事件（中间CA被吊销）几乎100%硬失败生效，对普通私钥泄露事件则几乎完全依赖其他环节（短寿命、域名处置）。组织做应急决策时应假设：Chrome用户仅在“事件足够大到进入CRLSet”时才被保护。
03 · OneCRL：Firefox的中间CA快车道
OneCRL（Firefox，2015年起）与CRLSets同构，但有两个特点：①侧重中间CA与根级吊销——订户证书的吊销历史上极少进入OneCRL；②分发通道不同——经Firefox的Kinto远程配置/blocklist体系推送，历史上也支撑过插件与证书的紧急封锁。OneCRL的教训在于：即使推送管道完全受控，只要“吊销源→浏览器”的内容选择依赖人工策展，覆盖就无法全量化——这为CRLite的全量编码路线提供了动机。
04 · CRLite：全量吊销的压缩推送
4.1 设计前提与数据结构
CRLite（Larisch等，IEEE S&P 2017）的关键洞察是：CT日志可以枚举出当前未过期的全部公开信任证书，因此可以为每张证书预计算“吊销状态位图”，再用级联布隆过滤器把位图压缩到可推送的体积。过滤器只会有假阳性（把未吊销误判为吊销）而不会假阴性（把吊销误判为未吊销）——但假阳性同样不可接受，于是CRLite叠加一层分层缓存（缓存过滤器假阳性条目对应的签名证据，即“过滤器+补丁”两级结构）：命中过滤器疑似吊销的证书，回查小体积的签名补丁集合确认真伪。2024年Mozilla进一步将底层过滤器升级为Clubcard数据结构（2024年12月公开论文与Rust实现，正式发表于IEEE S&P 2025），2024年10月的Firefox 132起支持Clubcard编码，11月的Firefox 133起支持增量更新。
4.2 数据源与覆盖
CRLite每天从CCADB聚合的约3000张CRL（合计约300MB原始数据）构建过滤器，结合CT日志提供的全量证书清单计算覆盖率元数据。截至Mozilla 2026年部署经验论文（ACM CCS 2026）报告：有效吊销覆盖率约87.8%（Firefox遥测，截至2026年1月的90天窗口）；未覆盖部分主要源于个别CA未按规范提供CRL或覆盖元数据缺口，浏览器对未覆盖证书回退到传统策略。更新节奏为每12小时一次增量推送。
4.3 带宽经济性
Mozilla官方披露的运行数据：客户端平均每日下载约300KB增量、每45天左右一次约4MB的完整快照。对比“直接订阅全量CRL需数百MB”，压缩比达到三个数量级——这是“全量吊销可推送”假设的实证。
4.4 部署里程碑（全部公开可查）
| 时间 | 里程碑 |
|---|---|
| 2017 | CRLite论文发表于IEEE S&P 2017（级联布隆过滤器+缓存补丁的两级结构） |
| 2019.10 | Firefox 70加入CRLite客户端支持（需手动开启） |
| 2021 | 回退遥测机制上线：过滤器与事实冲突时上报，用于度量误报 |
| 2022.5 | Firefox 100开启“Confirm Revocations”混合模式：CRLite判定吊销时回查OCSP确认 |
| 2024.9—11 | Firefox 128.2引入过滤器通道；132支持Clubcard编码；133支持增量更新 |
| 2025.2—4 | 135 Nightly进入执行模式；137（2025年4月）桌面用户默认执行：CRLite判定吊销即硬失败，不再回查OCSP |
| 2025.8 | Firefox 142对DV证书停用OCSP回退（CRLite自此成为Firefox桌面唯一吊销判定来源，全量执行自137版起）；期间处理了2025年3月的预证书签名证书CT条目误报事件（详见第6页） |
| 2025.11 | 移动端上线高优先级吊销子集通道（受流量约束的分档策略） |
4.5 2025年压力测试：微软7700万张批量吊销
微软2025年5—11月分周撤销超7700万张证书，被Mozilla称为CRLite的“极端压力测试”：活跃吊销总量从约400万激增至约610万，其间增量更新体积一度达到约400KB/期。CRLite流水线经受住了数量级跃迁，验证了Clubcard+增量架构的容量弹性（ACM CCS 2026部署论文）。
05 · 供给侧革命：Let's Encrypt停用OCSP
推送式方案能否成立，取决于CA侧的吊销数据源是否仍然可聚合。2024—2025年Let's Encrypt的OCSP退役是供给侧的标志性事件：
| 时间 | 动作 |
|---|---|
| 2024.7.23 | 宣布计划以CRL替代OCSP（《Replacing OCSP with CRLs》） |
| 2024.12.5 | 正式宣布2025年结束OCSP支持（《Ending OCSP Support in 2025》） |
| 2025.1.30 | 停止签发带Must-Staple扩展的新证书（OCSP供应端开始收缩） |
| 2025.5.7 | 新签发证书不再内嵌OCSP URL（此前数月已加入CRL URL） |
| 2025.8.6 | OCSP服务永久关闭——运营压力之大致使此举被行业视为里程碑：峰值期每周约830亿次请求经CDN承载（约87%由CDN缓存吸收） |
同期，CA/B论坛Ballot SC-063v4（2023年7月通过）已使OCSP服务对CA由强制转为可选，多家头部CA陆续收缩OCSP服务。补充事实：Let's Encrypt自2022年9月起即已并行发布CRL，吊销数据的连续性为本次切换提供了缓冲。查询式吊销的供给侧正在系统性收缩，CRL+推送式过滤器成为唯一被生态共同押注的路线——这构成本课题“后OCSP时代”判断的事实基础。
06 · 三方方案对比与失效模式
| 维度 | CRLSets（Chrome） | OneCRL（Firefox） | CRLite（Firefox） |
|---|---|---|---|
| 覆盖目标 | 高优先级精选（CA级为主） | 中间CA为主 | 全量（当前约87.8%） |
| 条目量级 | 约600KB集合，覆盖约1%吊销量 | 小型集合 | 全量数百万条编码为日均约300KB增量 |
| 更新节奏 | 组件更新驱动，事件可加速 | Kinto远程配置 | 每12小时增量+约45天全量快照 |
| 判定语义 | 集合内硬失败，集合外不查 | 同上 | 过滤器命中→补丁层确证→硬失败 |
| 主要失效模式 | 普通订户证书吊销不可见 | 覆盖窄 | 未覆盖CA回退软失败；过滤器误报（2025年3月事件）需补丁层兜底 |
| 隐私 | 完全本地 | 完全本地 | 完全本地（含回退确认阶段后的纯本地判定） |
对组织决策的含义：不要以“我的证书已吊销”作为安全事件的收尾标准。2025年后比较稳健的心智模型是——吊销对Chrome用户≈仅CA级事件有效；对Firefox桌面用户≈87.8%有效；对移动端与Safari用户效果更弱。事件收尾标准应是“私钥/域名控制已收回+CA吊销+域名与内容处置+用户侧通知”四件套（第7页SOP）。
本节参考来源（本页）
以下均为真实可查的权威来源，用于支撑本页事实性表述。
Adam Langley：《CRLSets》（2012）：imperialviolet.org/2012/02/05/crlsets.html；《Revocation checking and Chrome》（2011）：imperialviolet.org/2011/03/18/revocation.html。
Larisch, J. et al.：《CRLite: A Scalable System for Pushing All TLS Revocations to All Browsers》，IEEE S&P 2017（级联布隆过滤器+缓存补丁两级结构）：jhalderm.com/pub/papers/crlite-sec17.pdf。
Mozilla Hacks：《CRLite: Fast, private, and comprehensive certificate revocation checking in Firefox》（2025年8月19日，部署里程碑、带宽与遥测数据）：hacks.mozilla.org。
Fooda等：《The Deployment of CRLite in Mozilla Firefox》，ACM CCS 2026（87.8%覆盖率、微软2025压力测试、移动端通道）：taejoong.github.io/files/publications/fooda-2026-tls.pdf。
Mozilla安全博客CRLite四部曲（2020年1—12月，Nightly/Beta/1% Release分阶段灰度验证）：blog.mozilla.org/security；Let's Encrypt：《Replacing OCSP with CRLs》（2024年7月23日）：letsencrypt.org/2024/07/23/replacing-ocsp-with-crls.html；《Ending OCSP Support in 2025》（2024年12月5日）：letsencrypt.org/2024/12/05/ending-ocsp。
Mozilla Wiki：OneCRL项目页（中间CA吊销推送机制）：wiki.mozilla.org/Security/OneCRL；Firefox版本发布说明（128.2/132/133/137/142相关条目）：mozilla.org/firefox/releases。
Let's Encrypt：Clubcard论文与Rust实现（2024年12月，CRLite底层数据结构升级）：letsencrypt.org/2024/12/11/introducing-clubcard。