Firefox has become the first and only browser to implement a rapid and thorough certificate revocation checking system that safeguards user browsing activity from being disclosed to any entity, including Mozilla.
Millions of TLS server certificates are issued daily to secure communications between web browsers and websites. These certificates are fundamental to ubiquitous encryption, a crucial element for the web. Although a certificate can remain valid for up to 398 days, it may be revoked at any time. A revoked certificate presents a significant security risk and should not be relied upon for server authentication.
Detecting a revoked certificate is challenging, as revocation information must travel from the certificate’s issuer to individual browsers. This process typically involves two main approaches: a browser can either query an authority in real-time for each encountered certificate, or it can maintain a regularly updated list of revoked certificates. CRLite, Firefox’s innovative mechanism, has now made the latter approach practical.
CRLite enables Firefox to periodically download a compressed representation of all revoked certificates listed in Certificate Transparency logs. This encoding is stored locally by Firefox, updated every 12 hours, and privately queried whenever a new TLS connection is established.
Discussions have often suggested that certificate revocation is flawed or that it does not function effectively. Historically, the web faced difficult compromises between security, privacy, and reliability in this area. This situation has changed. CRLite was activated for all Firefox desktop users (Windows, Linux, MacOS) beginning with Firefox 137, demonstrating that it renders revocation checking functional, dependable, and efficient. There is optimism that this achievement can be extended to other, more resource-limited environments.
Better privacy and performance
Before version 137, Firefox utilized the Online Certificate Status Protocol (OCSP) to query authorities for real-time revocation statuses. Certificate authorities are no longer mandated to support OCSP, and some prominent certificate authorities have already declared their plans to discontinue OCSP services. Multiple factors contribute to this shift, primarily the fact that OCSP constitutes a privacy vulnerability. When a user sends an OCSP request for a certificate, it discloses their intention to visit a specific domain to the server. As OCSP requests are generally transmitted over unencrypted HTTP, this data is also exposed to any observers along the network path.
With proven confidence in the robustness, accuracy, and performance of the CRLite implementation, OCSP will be disabled for domain validated certificates in Firefox 142. Eliminating the OCSP privacy leak aligns with ongoing initiatives to encrypt all internet traffic through the deployment of HTTPS-First, DNS over HTTPS, and Encrypted Client Hello.
Disabling OCSP also offers performance advantages; OCSP requests were observed to delay the TLS handshake by a median of 100 ms. The introduction of CRLite led to significant improvements in TLS handshake times.
Bandwidth requirements of CRLite
CRLite users typically download approximately 300 kB of revocation data daily, comprising a 4 MB snapshot every 45 days and incremental “delta updates” in between. (The precise sizes of snapshots and delta updates vary daily. Detailed data is available on the dashboard.)
To illustrate the compactness of CRLite artifacts, a comparison with Certificate Revocation Lists (CRLs) is useful. A CRL contains serial numbers identifying revoked certificates from a single issuer. Approximately three thousand active CRLs have been reported by certificate authorities in Mozilla’s root store to the Common CA Database. These three thousand CRLs collectively amount to 300 MB, requiring regular re-downloads for updates. CRLite, however, encodes the identical dynamic set of revoked certificates using only 300 kB per day, making it a thousand times more bandwidth-efficient than daily CRL downloads.
Naturally, no browser downloads all CRLs daily. A more relevant comparison can be made with Chrome’s CRLSets, which are curated sets of revocations delivered to Chrome users daily. Recent CRLSets are around 600 kB and cover approximately 1% of all revocations (35,000 out of a total of four million). Firefox’s CRLite implementation, in contrast, uses half the bandwidth, updates twice as often, and encompasses all revocations.
Incorporating all revocations is vital for security, as currently there is no dependable method to differentiate between security-critical and administrative revocations. Approximately half of all revocations occur without a specified reason code, and some of these may stem from security issues that certificate owners preferred not to disclose. When reason codes are employed, they are frequently ambiguous, failing to clearly indicate security risk. In such a scenario, the only secure strategy involves checking all revocations, a capability now provided by CRLite.
State-of-the-art blocklist technology
A series of blog posts from 2020 detailed early experiments with CRLite. These experiments were followed by successful deployments to Nightly, Beta, and a small percentage of Release users. However, the initial CRLite design’s bandwidth demands proved to be excessive.
The bandwidth challenge was addressed through the development of a new data structure: the “Clubcard” set membership test. While the original CRLite design employed “multi-level cascades of Bloom filters,” Clubcard-based CRLite now utilizes a “partitioned two-level cascade of Ribbon filters.” The concept of a “two-level cascade” was introduced by Mike Hamburg at
, and the “partitioning” aspect is an independent innovation, presented in a paper at IEEE S&P 2025 and discussed in a talk at
.
Future improvements
Efforts are underway to further enhance CRLite’s bandwidth efficiency. New Clubcard partitioning strategies are being developed to compress mass revocation events more effectively. Additionally, support for the HTTP compression dictionary transport is being integrated to further compress delta updates. Shorter certificate validity periods have also been successfully advocated for, which will decrease the number of CRLite artifacts required to encode any specific revocation. These improvements are anticipated to reduce CRLite’s bandwidth demands in the coming years, even as the TLS ecosystem expands.
The Clubcard blocklist library, its implementation as Clubcards for CRLite, and the CRLite backend are all openly available for public use. The successful development of fast, private, and comprehensive revocation checking for Firefox is expected to inspire other software vendors to adopt this technology.
