Mozilla公司 关于在 Firefox 的夜间版本中开始测试检测已撤销证书的新机制 - 。 CRLite 允许您针对用户系统上托管的数据库组织有效的证书吊销检查。 Mozilla 的 CRLite 实现 根据免费的 MPL 2.0 许可证。 生成数据库和服务器组件的代码写在 去。 添加到 Firefox 的客户端部件用于从数据库读取数据 用 Rust 语言。
使用基于仍在使用的协议的外部服务进行证书验证 （在线证书状态协议）需要保证网络访问，导致请求处理有明显延迟（平均350ms）并且在确保机密性方面存在问题（响应请求的OCSP服务器会收到有关特定证书的信息，可以用来判断是否有什么证书）用户打开的网站）。 还可以根据列表进行本地检查 （证书吊销列表），但这种方法的缺点是下载的数据非常大——目前吊销证书的数据库占用约300 MB，并且还在持续增长。
为了阻止已被泄露并被证书颁发机构撤销的证书，Firefox 自 2015 年起使用了集中式黑名单 与服务电话相结合 识别可能的恶意活动。 一个CRL，比如 在 Chrome 中，充当中间链接，聚合来自证书颁发机构的 CRL 列表，并提供单个集中式 OCSP 服务来检查已吊销的证书，从而可以不直接向证书颁发机构发送请求。 尽管在提高在线证书验证服务的可靠性方面做了很多工作，但遥测数据显示，超过 7% 的 OCSP 请求超时（几年前这个数字为 15%）。
默认情况下，如果无法通过 OCSP 进行验证，浏览器会认为该证书有效。 该服务可能由于网络问题和内部网络限制而不可用，或者被攻击者阻止——要在 MITM 攻击期间绕过 OCSP 检查，只需阻止对检查服务的访问即可。 部分为了防止此类攻击，已经实施了一项技术 ，它允许您将 OCSP 访问错误或 OCSP 不可用视为证书问题，但此功能是可选的，需要对证书进行特殊注册。
CRLite 允许您将所有已撤销证书的完整信息整合到一个易于更新的结构中，大小仅为 1 MB，这使得在客户端存储完整的 CRL 数据库成为可能。
浏览器将能够每天同步其有关已撤销证书的数据副本，并且该数据库在任何条件下都可用。
CRLite 结合了来自 、所有已颁发和吊销证书的公共日志以及互联网上扫描证书的结果（收集证书颁发机构的各种 CRL 列表并汇总有关所有已知证书的信息）。 数据采用级联方式打包 ，一种概率结构，允许错误检测缺失的元素，但排除现有元素的遗漏（即，以一定的概率，可能会误报正确的证书，但保证可以识别已撤销的证书）。
为了消除误报，CRLite 引入了额外的校正过滤级别。 生成结构后，将搜索所有源记录并识别任何误报。 根据此检查的结果，创建一个附加结构，该结构级联到第一个结构并纠正由此产生的误报。 重复该操作，直到完全消除控制检查期间的误报。 通常，创建 7-10 层足以完全覆盖所有数据。 由于数据库的状态由于定期同步而稍微滞后于 CRL 的当前状态，因此使用 OCSP 协议对 CRLite 数据库上次更新后颁发的新证书进行检查，包括使用 （在协商 TLS 连接时，由证书颁发机构认证的 OCSP 响应由服务站点的服务器传输）。
使用布隆过滤器，来自 WebPKI 的 100 月份信息片段（涵盖 750 亿个有效证书和 1.3 万个已撤销证书）能够打包成 16 MB 大小的结构。 结构生成过程非常消耗资源，但它是在 Mozilla 服务器上执行的，并且为用户提供了现成的更新。 例如，以二进制形式，生成过程中使用的源数据存储在 Redis DBMS 中时需要大约 6.7 GB 的内存，而以十六进制形式，所有证书序列号的转储大约需要 40 GB 的内存。 聚合所有已撤销和活动证书的过程大约需要 20 分钟，基于布隆过滤器生成打包结构的过程还需要 XNUMX 分钟。
Mozilla 目前确保 CRLite 数据库每天更新四次（并非所有更新都会传递给客户端）。 增量更新的生成尚未实现 - 使用 bsdiff4（用于为版本创建增量更新）无法为 CRLite 提供足够的效率，并且更新量过大。 为了消除这个缺点，计划重新设计存储结构的格式，以消除不必要的层重建和删除。
CRLite 目前在 Firefox 中以被动模式工作，并与 OCSP 并行使用，以累积有关正确操作的统计信息。 CRLite 可以切换到主扫描模式；为此，您需要在 about:config 中设置参数 security.pki.crlite_mode = 2。
来源： opennet.ru