CRLSet

When you visit a website with “https://”, your browser checks a security certificate — a kind of digital ID that confirms the site is genuine. Such certificates can become invalid, for example because a company was hacked or the certificate was issued incorrectly. In that case, the browser needs to know quickly. A CRLSet is a list, regularly updated by Google, of exactly these revoked certificates. Chrome automatically downloads it in the background and can thus immediately decide whether a certificate can still be trusted.

The problem CRLSet solves

In the past, so-called CRLs — Certificate Revocation Lists — served this purpose. The principle is the same: a list of revoked certificates. The difference lies in delivery. With a classic CRL, the browser sends a request to an external server every time an HTTPS page is loaded, in order to check whether the certificate is still valid. That costs time and doesn’t work at all if the checking server happens to be unreachable.

For a long time, browsers solved this problem by simply doing nothing when the checking server was unreachable — that is, silently treating the certificate as valid. That sounds pragmatic, but it’s a security problem: an attacker could deliberately make the checking server unreachable in order to keep using a revoked certificate. This pattern is called “soft fail.”

How Google distributes the list

Google works around the problem by having Chrome not fetch the list at the moment a page is visited, but instead download it regularly in advance — as a compact data package that is built directly into the browser. When Chrome then visits an HTTPS page, it only checks this list locally. There is no longer any external request, no checking server that could go down.

The updates arrive via the same mechanism Chrome uses to update other components — independent of a full browser update. This means Google can respond to a newly discovered certificate misuse within hours, without users having to restart their browser or install a new version. Just how fast this can be in practice became clear in 2011: when the certificate authority DigiNotar was compromised and had issued hundreds of fraudulent certificates, Google was able to block the affected certificates for all Chrome users within a few days.

An important difference from the classic CRL: the CRLSet is deliberately kept small. It doesn’t contain every certificate ever revoked, but instead focuses on security-critical cases — above all root and intermediate certificates, whose compromise would affect many websites at once. For less critical cases, Chrome relies on other mechanisms.

CRLSet in practice and in the news

For most users, the CRLSet remains invisible. It works quietly in the background, and if Chrome blocks a page because of a revoked certificate, a simple error page appears. Nevertheless, the term keeps popping up in security reports — for example, when researchers publicly discuss how quickly browsers respond to new certificate problems.

Other browsers have developed similar systems. Firefox, for example, uses OneCRL, which works on the same basic principle: a centrally maintained, locally stored revocation list instead of individual server requests. The key difference lies in administration: Firefox’s OneCRL is maintained by Mozilla, Google’s CRLSet by Google itself — which in each case means that the respective company decides which certificates are classified as dangerous.

For anyone dealing with web security — whether in computer science class, while reading tech news, or when developing their own websites — the CRLSet is a good example of how security and speed are weighed against each other in modern systems: a complete list would be more secure, but too large; a server request would be more complete, but too slow and too vulnerable.