Not very well.
In theory, the system should work. In practice, it doesn't. The implementations intended to manage revocation - namely CRL and OCSP - both have problems. Most of this answer is based on this article by Alexey Samoshkin, as well as this article by Scott Helme.
What about CRLs?
A certificate revocation list is a remarkably simple way of determining if a certificate is valid or not. It is in essence a list of all certificates that have been revoked. If you would like to check if a certificate has been revoked, you need to check the associated revocation list.
This list is potentially very large, slow to download and requires you to be online in order to be able to verify the validity of a certificate. While the online requirement seems like a non-issue for browsers, there are more uses for certificates than to authenticate a web-server, which may indeed be offline.
In practice, CRLs are considered an outdated mechanism, that deliver far too much overhead and are infeasible to do in practice.
What about OCSP?
OCSP was designed to be the golden goose that solves all the problems with CRLs. In practice, it introduced a set of new problems.
- Increased latency due to the need to make an inline request to the OCSP endpoint.
- Dependency of OSCP endpoint availability.
- Privacy compromise to the CA, since you need to transmit for which certificate (and thus which domains) you would like to have OCSP information.
What about failures?
What happens if a CRL or OCSP endpoint is not available? Turns out, nothing. If the status of the certificate can't be validated, browsers default to considering them legitimate. This means an attacker that can successfully get my browser to "give up" on trying to get OCSP data (e.g. by dropping all packets intended to go to an OCSP endpoint), even revoked certificates are considered valid.
Will we ever fix revocation or should we just give up?
There are attempts to mitigate these problems. Chrome uses CRLSet, and Mozilla uses OneCRL. The idea is basically that my browser contains a list of all CRLs and periodically (e.g. once per day) updates them.
Another attempt made is OCSP Stapling, which shifts the burden of proof to the server again. The idea is that the server periodically asks the CA if the certificate is still valid, and then gets a timed response, which the server includes with the certificate.
This fixes several of the above mentioned problems:
- The certificate and its revocation status are sent in one transmission, reducing latency.
- The CA does not get information about which domains are requested by the user.
- The OSCP endpoint of the CA can have reduced availability, since messages are valid for some time.
- The OCSP endpoint has a lower load, since it is distributed more among web servers.
So where is the catch?
I mentioned that the current status of certificate revocation is bad, so obviously there must be a catch. Turns out that web servers aren't really that good at implementing OCSP stapling. I won't go into all the details, since Alexey's article does a fine job at explaining it. The basic gist is that even if enabled, some servers may not immediately send out stapled responses. Some servers, like nginx, don't send a response if the certificate has been revoked. This means even if the web server knows the certificate is revoked, it will not tell the user because...reasons?
Glad you asked! The idea is simple, the certificate includes a flag that indicates that a server must staple an OCSP response, or otherwise verification will fail. Sounds good in theory, so where is the catch?
The catch is that browsers react weirdly to this flag. Firefox throws
MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING, which only somewhat makes kind of sense when you already know what it's supposed to mean - only slightly better than throwing us a
T_PAAMAYIM_NEKUDOTAYIM. Chrome, on the other hand, doesn't care at all. Chrome doesn't support OCSP at all, so it's only logical that an extension that requires it is just being ignored.
In conclusion, certificate revocation is broken and there is very little each of us can do to fix it.