CRLite: Fast, private, and comprehensive certificate revocation checking in Firefox
28 points by freddyb
28 points by freddyb
This is, in short, cool shit. With this, assuming places outside Firefox adopt it, I could confidently say that revocation actually works (albeit with a delay of up to 12 hours, but that’s better than before)
Yes, anything else would be an understatement. This is the first time I hear someone got their paper into IEEE Security & Privacy as a single author and I think it’s very well deserved. If you’re the kind of person, here’s the research paper. There are also presentations videos on YouTube.
Since OCSP requests are typically made over unencrypted HTTP, this information is also leaked to all on-path observers.
What clownshoes bullshit is this???
The short answer was that OCSP was designed in 1999, and it was a different time. Most traffic on the internet was cleartext. Everyone was logging into their mailserver with cleartext passwords. It wasn’t necessary for the security of the protocol, and the privacy risk wasn’t a top concern when everything else is plaintext already.
TLS would impede caching, too.
There’s a bootstrapping problem with using TLS for revocation checks too, though that’s relatively easy to handwave away as much as cleartext protocols are.
You’d already leaked what name you asked for over DNS, which was never encrypted. Or SNI, which was never encrypted. There was no additional harm in leaking it by making an OCSP request over HTTP. And they could be made over HTTPS as long as the responder’s issuer wasn’t the same as the TLS site’s issuer, which was doable. But it doesn’t matter, really… the OCSP responder has to be delegated by the CA, who you’re trusting to not leak (a lot more details than could be found in) OCSP requests.
And most of this was addressed by stapling.
The threat model changed later, but in the context of its time, I find it hard to call OCSP “clownshoes bullshit.” It’s more that it was addressing different threats than what we care about now.
There’s a reason the system is deprecated.
Sure, but this is like WEP-level incompetence. I don’t understand why it ever worked like that.
There’s no reason it should be encrypted in my view. OCSP responses are already signed and SNI is still almost always unencrypted. There’s no benefit to encrypting it, all it will do is add some extra overhead and make it slower.
Also, if you’re using encrypted SNI you can just staple the OCSP response on the server’s end so that it doesn’t leak out.
OCSP on its own may far from ideal, but OCSP stapling addresses most of the major issues - both latency and privacy - if it’s actually configured and enabled on the server side.
For those unfamiliar: stapling works by having the server include a short-lived timestamped OCSP response in the TLS handshake (typically valid for just a few hours). Instead of each client “leaking” information by querying the OCSP responder directly, the server pre-fetches the response periodically and effectively proxies it. This eliminates latency for the client, which can immediately verify that the certificate wasn’t revoked within the last few hours. There’s even a certificate flag (must-staple) that tells clients to require a stapled response and never fall back to direct OCSP queries for this certificate.
In practice, the detection delay for a revoked certificate is roughly on par between OCSP stapling and CRLite - except stapling doesn’t depend on whether server admins feel like deploying it.
Fun fact: even widely used servers like Nginx have historically mishandled this. For example, it used to skip stapling on the first few connections, which completely undermines must-staple/expect-staple. Even worse: they didn’t consider this bug to be a problem. Presumably because it didn’t affect server performance.
CRLite updates twice a day, but an OCSP response can be valid for up to a week. So CRLite is much faster at detection than stapled OCSP.
Previous discussion: https://lobste.rs/c/cv0s36
Presumably you have a bootstrapping problem over HTTPS. A solveable one, probably, but still.
The threat model was really around integrity of the revocation data because the goal was secure (in terms of confidentiality and integrity) connection to a known endpoint. You connected to a remote server and TLS (SSL? I’m pretty sure this predated TLS) let you establish the identity of the server and, having done that, establish a connection that was secure from snooping and tampering by anyone on the path. Revocation lists were added because certificate renewal was an annoyingly manual process and all of these security guarantees depend on the private key being private.
If an adversary can see your OCSP fetch, they know the server that you’re connected to, but that’s also in the plain-text portion of HTTPS, so anyone who can snoop on your network and see that you’ve made this request got no extra information. OSCP was faster than fetching the entire revocation list (the older alternative), which was very important in the days when most users had a slow MODEM (my connection to the Internet when this was standardised was 26.4 Kb/s).
The change in threat models that means that this is probably a bad idea is that CAs are now less trusted. Letting CAs correlate the traffic for domains that they’ve signed is far from ideal.