Firefox is now the first and the only browser to deploy fast and comprehensive certificate revocation checking that does not reveal your browsing activity to anyone (not even to Mozilla).
Tens of millions of TLS server certificates are issued each day to secure communications between browsers and websites. These certificates are the cornerstones of ubiquitous encryption and a key part of our vision for the web. While a certificate can be valid for up to 398 days, it can also be revoked at any point in its lifetime. A revoked certificate poses a serious security risk and should not be trusted to authenticate a server.
Identifying a revoked certificate is difficult because information needs to flow from the certificate’s issuer out to each browser. There are basically two ways to handle this. The browser either needs to ask an authority in real time about each certificate that it encounters, or it needs to maintain a frequently-updated list of revoked certificates. Firefox’s new mechanism, CRLite, has made the latter strategy feasible for the first time.
With CRLite, Firefox periodically downloads a compact encoding of the set of all revoked certificates that appear in Certificate Transparency logs. Firefox stores this encoding locally, updates it every 12 hours, and queries it privately every time a new TLS connection is created.
You may have heard that revocation is broken or that revocation doesn’t work. For a long time, the web was stuck with bad tradeoffs between security, privacy, and reliability in this space. That’s no longer the case. We enabled CRLite for all Firefox desktop (Windows, Linux, MacOS) users starting in Firefox 137, and we have seen that it makes revocation checking functional, reliable, and performant. We are hopeful that we can replicate our success in other, more constrained, environments as well.
Better privacy and performance
Prior to version 137, Firefox used the Online Certificate Status Protocol (OCSP) to ask authorities about revocation statuses in real time. Certificate authorities are no longer required to support OCSP, and some major certificate authorities have already announced their intention to wind down their OCSP services. There are several reasons for this, but the foremost is that OCSP is a privacy leak. When a user asks an OCSP server about a certificate, they reveal to the server that they intend to visit a certain domain. Since OCSP requests are typically made over unencrypted HTTP, this information is also leaked to all on-path observers.
Having gained confidence in the robustness, accuracy and performance of our CRLite implementation, we will be disabling OCSP for domain validated certificates in Firefox 142. Sealing the OCSP privacy leak complements our ongoing efforts to encrypt everything on the internet by rolling out HTTPS-First, DNS over HTTPS, and Encrypted Client Hello.
Disabling OCSP also has performance benefits: we have found that OCSP requests block the TLS handshake for 100 ms at the median. As we rolled out CRLite, we saw notable improvements in TLS handshake times.
Bandwidth requirements of CRLite
Users with CRLite download an average of 300 kB of revocation data per day: a 4 MB snapshot every 45 days and a sequence of “delta updates” in-between. (The exact sizes of snapshots and delta updates fluctuate day by day. You can explore the real data on our dashboard.)
To get a sense for how compact CRLite artifacts are, let’s compare them with Certificate Revocation Lists (CRLs). A CRL is a list of serial numbers that each identify a revoked certificate from a single issuer. Certificate authorities in Mozilla’s root store have disclosed approximately three thousand active CRLs to the Common CA Database. In total, these three thousand CRLs are 300 MB in size, and the only way to keep a copy of them up-to-date is to redownload them regularly. CRLite encodes the same dynamic set of revoked certificates in 300 kB per day. In other words, CRLite is one thousand times more bandwidth-efficient than daily CRL downloads.
Of course, no browser is performing daily downloads of all CRLs. For a more meaningful comparison, we can consider Chrome’s CRLSets. These are hand-picked sets of revocations that are delivered to Chrome users daily. Recent CRLSets weigh in at 600 kB and include about 1% of all revocations (thirty-five thousand of the four million total). Firefox’s CRLite implementation uses half the bandwidth, updates twice as frequently, and includes all revocations.
Including all revocations is essential for security as there is no reliable way today to distinguish security-critical revocations from administrative revocations. Roughly half of all revocations are made without a specified reason code, and some of these revocations are likely due to security concerns that the certificate’s owner did not wish to highlight. When reason codes are used, they are often used in an ambiguous way that does not clearly map to security risk. In this environment, the only secure approach is to check all revocations, which is now possible with CRLite.
State-of-the-art blocklist technology
You may recall a series of blog posts on our experiments with CRLite back in 2020. We followed these experiments with successful deployments to Nightly, Beta, and 1% of Release users. But the bandwidth requirements for this early CRLite design turned out to be prohibitive.
We solved our bandwidth issue by developing a novel data structure—the “Clubcard” set membership test. Where the original CRLite design used a “multi-level cascades of Bloom filters”, Clubcard-based CRLite uses a “partitioned two-level cascade of Ribbon filters”. The “two-level cascade” idea was presented by Mike Hamburg at RWC 2022, and “partitioning” is an innovation of our own that we presented in a paper at IEEE S&P 2025 and a talk at RWC 2025.
Future improvements
We are working on making CRLite even more bandwidth efficient. We are developing new Clubcard partitioning strategies that will compress mass revocation events more efficiently. We are also integrating support for the HTTP compression dictionary transport, which will further compress delta updates. And we have successfully advocated for shorter certificate validity periods, which will reduce the number of CRLite artifacts that need to encode any given revocation. With these enhancements, we expect the bandwidth requirements of CRLite to trend down over the coming years, even as the TLS ecosystem itself continues to grow.
Our Clubcard blocklist library, our instantiation of Clubcards for CRLite, and our CRLite backend are freely available for anyone to use. We hope that our success in building fast, private, and comprehensive revocation checking for Firefox will encourage other software vendors to adopt this technology.
The post CRLite: Fast, private, and comprehensive certificate revocation checking in Firefox appeared first on Mozilla Hacks – the Web developer blog.
