How Firefox's CRLite Verifies Certificates Privately

This article explains how Mozilla Firefox's CRLite technology verifies the revocation status of SSL/TLS certificates locally on your device, completely eliminating the privacy risks associated with traditional verification methods. By compressing global certificate data into tiny, downloadable filters, CRLite allows Firefox to confirm whether a website's security certificate is valid without ever exposing your browsing history to third-party Certificate Authorities.

The Privacy Problem with Traditional Verification

To understand how CRLite protects your privacy, it is necessary to understand the flaw it fixes. Websites use SSL/TLS certificates to encrypt traffic and prove their identity. Sometimes, these certificates are compromised and must be revoked by the issuing Certificate Authority (CA) before their expiration date.

Historically, browsers checked if a certificate was revoked using the Online Certificate Status Protocol (OCSP). When you visited a website, your browser paused the connection, sent the website's certificate serial number to the CA's server, and asked if it was still valid. This process leaked your browsing history in real-time, as the CA could see every website you visited and when you visited it.

Step 1: Aggregating Global Certificate Data

CRLite solves the OCSP privacy leak by moving the verification process from the CA's servers directly onto your computer. To make this possible, Mozilla acts as a central aggregator.

Mozilla servers continuously scan public Certificate Transparency (CT) logs to gather a complete list of all known, active, and valid SSL/TLS certificates on the internet. Simultaneously, Mozilla downloads the revocation data (lists of bad certificates) directly from all the major Certificate Authorities. This creates a massive database containing both legitimate and revoked certificates.

Step 2: Compression via Cascading Bloom Filters

A raw list of every revoked and valid certificate on the internet is too large to send to every Firefox user. CRLite overcomes this by compressing the data using a mathematical data structure called a "cascading Bloom filter."

A standard Bloom filter is a space-efficient way to test whether an element is a member of a set, though it can occasionally produce false positives (incorrectly flagging a good certificate as revoked). CRLite solves this by stacking multiple Bloom filters together in a cascade:

  1. Filter 1: The first filter checks all known certificates against the list of revoked certificates. It catches all revoked certificates, plus a small number of false positives.
  2. Filter 2: A second, smaller filter is created specifically to identify and exclude those false positives.
  3. Subsequent Filters: This process repeats, layering smaller and smaller filters on top of each other until there are zero false positives and zero false negatives left.

Through this cascading method, CRLite compresses gigabytes of global certificate revocation data down to a file that is only a few megabytes in size.

Step 3: Local, Private Verification

Once Mozilla generates the compressed CRLite filter, it pushes the file to Firefox browsers around the world using the browser's built-in update mechanism. After the initial download of a few megabytes, Mozilla sends daily differential updates—stashes of new revocations—that are typically only a few kilobytes in size.

When you type a URL into Firefox and connect to a website, the verification process now looks like this:

  1. The website presents its SSL/TLS certificate to Firefox.
  2. Firefox takes the certificate information and runs it through the CRLite filter stored locally on your hard drive.
  3. The filter instantly returns a "valid" or "revoked" status.

Because the entire check happens locally using pre-downloaded data, Firefox never contacts the Certificate Authority. There is no outbound network request tied to your browsing session. The CA remains completely blind to the websites you visit, your browsing history remains strictly private, and webpages load faster because the browser no longer has to wait for an external OCSP server to respond.