
 Revocation checking and Chrome's CRL - wglb
https://www.imperialviolet.org/2012/02/05/crlsets.html
======
sveiss
I agree with the issues around OCSP and soft-fail, but I don't think shipping
a subset CRL list of 'important' revocations is ideal, either.

I've just re-keyed certificates I'm responsible for as a precaution after
patching for Heartbleed. For one of the certificate providers used, GoDaddy,
re-keying automatically revokes the old certificate, which is exactly what's
wanted in this case.

But would that be considered an 'important' revocation? I have no way to be
sure, but I'm assuming not -- as this is the same mechanism used by GoDaddy
for routine rekeying.

Perhaps this is simply a problem with GoDaddy's certificate management tools,
but I'm uncomfortable with two tiers of revocation, one of which is a "real"
revocation and one of which is ignored by browsers.

------
j_s
Back when this was written in 2012, Chrome was (transitioning to?) pushing
revoked certs as a software update. Post-heartbleed, "We have to be mindful of
size" doesn't seem like a valid option.

~~~
thirsteh
That does seem like a strange argument given that the safebrowsing database is
essentially just a giant bloom filter containing many more entries (probably)
than there are revoked SSL certificates.

The false positive verification could be done (for anything other than e.g.
google.com's cert) with a call to Google's servers, I suppose.

~~~
zaroth
A ~20MB bloom filter could have room for 10 million revoked certificates, with
a .001 (1 in 1000) false positive rate. Moving either the false positive rate
or the number of revoked certificates by an order of magnitude also increases
size of the bloom filter an order of magnitude.

For privacy reasons you don't want the browser asking 'is certificate X
revoked' (OSCP) you want the browser asking 'give me the latest list of
revoked certificates under Root CA X' (CRLs) and that starts to become a
prohibitively large download.

"OSCP Stapling" fixes the privacy problem, because the web server is the one
asking for the OSCP response, and then caching it and providing it proactively
to clients when they first connect.

What we could do is extend the HSTS header to provide a way for the web server
to indicate OSCP MUST be Stapled, then the browser can fail hard if OSCP is
not provided.

There's still a privacy issue of your browser basically bookmarking every HSTS
site that you visit, and probably not providing an easy way to know that
happening or clear that out. For example, if I clear my browsing history,
should it reset my HSTS lists?

~~~
thirsteh
> There's still a privacy issue of your browser basically bookmarking every
> HSTS site that you visit, and probably not providing an easy way to know
> that happening or clear that out. For example, if I clear my browsing
> history, should it reset my HSTS lists?

Agree. I'm suggesting the client maintains an up-to-date bloom filter for all
revoked certificates, and only contacts Google when something detects as
positive (to verify that it is not a false positive.) You will still leak "I
visited foo.com" if someone has compromised your SSL connection to google.com,
but at least it doesn't leak your entire browsing history.

------
quinndupont
I'm confused: I thought that Chrome didn't automatically [edit: by default]
check for server certificate revocation (under Preferences->Advanced)? This
post indicates that it does, but that the process is flawed.

~~~
evmar
The post is from 2012 and says "we're currently planning on disabling online
revocation checks in a future version of Chrome", which is presumably what
happened.

