Once upon a time
Once upon a time, you had a certificate, all properly signed and everything, and everyone knew that whosoever presented this certificate would be the rightful King of England you. And you knew this because you'd already read Brief(ish) explanation of how https works. Good stuff.
But that's not quite right. What a certificate, presented in something like TLS, proves is that the presenter has access to the private key. So what happens if someone else has obtained your private key?
Mitigations against Compromise
The only things security folks like more than weird mathematics that nobody else understands are long words that nobody else understands. Really, these are terms loaded with additional meaning.
To "Mitigate" something means to protect against it, but in the knowledge that the protection isn't perfect. To "Compromise" a key means that some other attacker has got access to it. To "Access" a key means to have the ability to use the key directly or indirectly.
That last statement might sound a bit weird, so let me explain a bit - in most cases, a private key is held in a file on disk. Want to sign something, or encrypt something with it? Load in the private key into memory and Do Maths. If someone wants to steal your key, they can just copy the file - and you might never know.
But it needn't be the case. Hardware Security Modules will Do Maths for you, and just give you the result - you can literally never get the private key out of the device. These are surprisingly cheap - a simple smartcard reader is only a few dollars. This means that you private key is in physical form, now, and cannot be copied. For someone to access the key, they either need to be using the same physical hardware as the smartcard is plugged into, or else steal the smartcard (in which case the compromise is pretty obvious).
Compromised
But what happens if you key is (or might have been) compromised?
First, you need to tell your CA, who (should) get you a replacement certificate. They also "Revoke" the certificate. That's great, but how does anyone else know?
A Certificate, as we know, contains a bunch of stuff, plus a public key. Some of that stuff is how people can check to see if it's still OK to use. There's the simple stuff like if it's within its valid period, but there's also two URLs.
CRLDP
The Certificate Revocation List Distribution Point is a URL we can go to to get a list of revoked certificates signed by the Certificate Authority. It also has a timestamp of when the next CRL will be produced, so you can cache this for a bit. This is somewhat problematic, since it's a snapshot in time - you can't tell if the certificate is revoked between a (perhaps) daily update of the CRL. This results in a potential TOCTOU - Time Of Check, Time Of Use - window.
Nevertheless, CRLs are useful particularly in communities where only a few CAs are used, because a compromise will cache well, and the code is simple.
OCSP
The Online Certificate Status Protocol is also a URL we can go to, this time to get a status report for just this certificate. It's a timely, instant check, so the TOCTOU window is basically as small as it can be. Again, it's signed, and has a (typically short) expiry window.
Both OCSP and CRLDP URLs are typically "http", and not "https" - that's partly because the responses are themselves signed, and partly because otherwise there'd be a sort of chicken-and-egg affair to try to figure out the status of the HTTPS server certificate...
But this does mean that if your web browser is using OCSP, an attacker (or indeed the CA themselves) can see exactly which certificates you're trying to verify, and therefore which websites you're trying to visit.
Stapling
Of course, that's only true if the thing getting the OCSP response is, in fact, your web browser. And an OCSP response needn't come from that. A TLS extension called "OCSP Stapling" allows the web server to make the query, and hand the response to the web browser alongside the certificate itself within the TLS handshake.
This means the only entity that knows you're visiting the website is the website itself, which is exactly as it should be.
Limitations
"A man's got to know his limitations." -- Dirty Harry.
There's a few limitations to be aware of.
- OCSP Stapling only applies to the "end entity" certificate, and not any certificate in the chain.
- OCSP Stapling only applies to the server. The web browser can supply a certificate for user authentication too, and this isn't protected.
In both cases, however, CRLs provide practical protection here, unless the CA itself has been compromised (in which case we are in CASE NIGHTMARE GREEN scenarios as far as security goes anyway).
So we're all good, right?
"He who would trade essential speed for security deserves neither." -- Benjamin Franklin.
Benjamin Franklin was, it must be said, truly terrible at communications security, but nonetheless Google, Apple, and other browser developers have really taken this to heart, and mostly dropped status checking, since they'd rather have speed.
Google, for example, maintain their own list of "important" certificates that have been compromised. And don't bother doing OCSP or CRL checking for anything else. Some web browsers default to trying to do status checking, and if it fails (ie, the URLs aren't reachable), then they give up at that point.
There is an argument that a DoS attack on an OCSP responder would otherwise render vast numbers of sites unavailable. This might be a reasonable tradeoff for, say, Twitter or even dev.to, but probably isn't for your bank. And while there used to be settings available to always check certificates, those were removed.
They do, however, use OCSP stapling if possible.
So the summary? If you're doing "your own" TLS, make sure it's doing some kind of status checking. It'll protect your from a rare, but really nasty case. OCSP Stapling is relatively easy to get going on sites you host yourself, and you should do so. And finally, for critical private keys, try to use a hardware solution like a smartcard.
Top comments (0)