

An Evaluation of the Effectiveness of Chrome's CRLSets - pnyheim
https://www.grc.com/revocation/crlsets.htm

======
agl
The primary aim[1] of CRLSets was always to be a mechanism via which we could
quickly react to CA situations like DigiNotar, ANSSI etc. Doing full binary
pushes like we did during a few years back was too heavy.

As a secondary aim, we tried to make them do something more. Quoting
myself[2]:

"The original hope with CRLSets was that we could get revocations categorised
into important and administrative and push only the important ones.
(Administrative revocations occur when a certificate is changed with no reason
to suspect that any key compromise occurred.)".

Certainly at the time, and probably even now with the large number of post-
Heartbleed revocations, most revocations are not done because key compromise
is feared, but because a certificate is getting rotated for other reasons.
(E.g. a site asked for a certificate to be reissued with different names but
the same key. The old certificate now hangs around as a revocation for years.)

It seemed reasonable that a few tens of thousands of revocations would be
enough to cover the cases where actual key compromise worries had occured - if
the CAs would sort them. Again, quoting myself[2]: "Sadly, that mostly hasn't
happened."

The text even contains a situation where online revocation checking is
supposed to help, except it probably doesn't as usual:

The claim is that a user will download and cache a CRL while not being
attacked and then be protected from a local attacker using a certificate that
was included on that CRL.

The problem is that OCSP only covers a single certificate. OCSP is used in
preference because it's so much smaller and thus removes the need to download
CRLs. So the user isn't expected to download and cache the CRL anyway. So that
doesn't work.

However, it's clear that /someone/ is downloading CRLs because Cloudflare are
spending half a million dollars a month[3] to serve Globalsign's CRLs.
Possibily it's non-browser clients but the bulk is probably CAPI (the library
that IE, Chrome and other software on Windows typically uses - although not
Firefox). CAPI will download a CRL when it has 50 or more OCSP responses
cached for a given CA certificate. But CAs know this and /split/ their CRLs so
that they _don 't_ get hit with huge bandwidth bills. But a split CRL renders
the "protection" from caching ineffective.

So that argument is actually for something like CRLSets (download and cache
revocations) over online checking. It's just a clumsy way of arguing that the
downloaded data should be much larger so that it covers most or all
revocations. Quoting myself again:

"Perhaps we need to consider a system that can handle much larger numbers of
revocations, but the data in that case is likely to be two orders of magnitude
larger and it's very unlikely that the current CRLSet design is still optimal
when the goal moves that far. It's also a lot of data for every user to be
downloading and perhaps efforts would be better spent elsewhere. It's still
the case that an attacker that can intercept traffic can easily perform an SSL
Stripping attack on most sites; they hardly need to fight revoked
certificates."

The conclusions in the text that follow from that reasoning are then mostly
wrong, although OCSP Must Staple is still a nice idea. If Firefox implement it
first then good for them. It's tougher for Chrome because we use the
platform's verification libraries.

(I wrote a bunch of thoughts about what a good design for a "large" CRLSet
would look like[5].)

[1]
[https://www.imperialviolet.org/2012/02/05/crlsets.html](https://www.imperialviolet.org/2012/02/05/crlsets.html)
[2]
[https://www.imperialviolet.org/2014/04/19/revchecking.html](https://www.imperialviolet.org/2014/04/19/revchecking.html)
[3] [http://blog.cloudflare.com/the-hard-costs-of-
heartbleed](http://blog.cloudflare.com/the-hard-costs-of-heartbleed) [4]
[http://technet.microsoft.com/en-
us/library/ee619754(v=ws.10)...](http://technet.microsoft.com/en-
us/library/ee619754\(v=ws.10\).aspx) [5]
[https://www.imperialviolet.org/2011/04/29/filters.html](https://www.imperialviolet.org/2011/04/29/filters.html)

~~~
mjs
Is it true that Chrome has special-cased the revocation of a handful of
domains, including revoked.grc.com, because they aren't blocked by CRLSets?

I more or less follow the argument that CRLSets are superior overall, but
special-casing a few domains (especially benign test domains) because this
mechanism doesn't block them seems like a cheat.

