Confirmed in Chrome 59 dev. Visiting chrome://components shows "CRLSet-Version 0" and "Check for update" is disabled.

I believe this is an intentional tradeoff, but passing to rsleevi to confirm.

Yeah.

CRLSets in general are used to update clients quicker than a binary update. Due to binary size constraints, we try to focus only on high-risk revocations due to known compromises.

We made an optimization when delivering these updates - which otherwise would only be used for 'emergency' updates - to also try to optimize for meaningful/important revocations, such as key compromise. This, however, has always been best-effort, and in practice, not as significant.

This has all been discussed before - https://www.imperialviolet.org/2014/04/29/revocationagain.html

If there is a high-profile revocation, it's currently documented at https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/blacklist/README.md

While there are understandable improvements we could make to this to improve the story for intermediates, there are no plans for baking leaf revocations in, nor making CRLSet updates "hard fail" - they remain best-effort optimizations for binary updates.

Considering that we also do not support CRLSets on mobile - as we instead rely on the application update for such revocations, consistent with the various application store policies - this does not seem like it represents a security risk.

There are no plans at this time to include this particular site in every Chrome binary as revoked.

FWIW, I verified that if you wait a bit, the chrome://components updates and shows the current version of the CRLSet has downloaded, and navigation to the site is blocked.

Interestingly, if you've loaded the site before the component updates, even closing the tab/window and reopening it does not result in the site being blocked.

If you log out of the Guest profile and open a new one, the CLRSet version reverts to 0 and you have to wait for the download again.

Hi all, thanks for the quick responses.

Could an approach similar to Mozilla's be implemented, whereby the dynamically-updated list is also baked into the binary releases, such that the list is seeded with known revocations, rather than starting empty? This would provide some protection for fresh installs, Powerwash, Guest Mode etc.

For example, the Mozilla blocklist exists in version control here: https://hg.mozilla.org/mozilla-central/file/tip/browser/app/blocklist.xml

And is automatically kept in sync with the dynamic list as can be seen here: https://hg.mozilla.org/mozilla-central/log/tip/browser/app/blocklist.xml

This then works from first use without having to wait for a blocklist update to kick in.

As noted, Chrome does include a set of known revocations, as documented in https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/blacklist/README.md . It does not start empty - it just does not manifest as a CRLSet.

There are differences in what OneCRL covers versus CRLSets on several dimensions, so directly including CRLSets into the binary is not a goal or intended use of CRLSets. While there is potential opportunity to be more proactive in blocking certain types of certificates, that remains an optimization strategy given the current behaviour, and one with some degree of risk.

I'm marking this as WontFix, because it's currently intended behaviour as described. Having CRLSets be more comprehensive (e.g. to cover intermediates as well) is something that is being considered, but one that has a greater host of compatibility issues compared to Mozilla's OneCRL (due to issues that prevent the discovery of otherwise-valid paths due to differences in the trust store and path building algorithms across platforms)

Certainly, however, one should not ever expect revoked.badssl.com to be baked into the Chrome binary.

Thanks for the response Ryan.

When I said "starting empty" I meant the CRLSet (which shows as version 0 as mentioned by Eric Lawrence above) as opposed to the blacklist in the code (which is not an identical set). The blacklist works well for what it covers (and it is in force from time zero), so thank you for that.

As for revoked.badssl.com, that was just an example from the CRLSet which was the easiest to test with (this bug was filed to cover CRLSets in general and not just for that specific site).

It's good to hear that becoming more comprehensive is something that is being considered. I remain of the view that being more timely in the cases mentioned above is also a worthwhile cause, but will leave that for now.

I hope that clarifies things and thanks for listening.

Right, the CRLSet is meant to be a delta for the blacklist. This means that a number of entries can probably be removed from the CRLSet, now that the blacklist itself has widely deployed to updated clients :)

I think we can remove the view restrictions on this bug; the remaining entries are optimizations while we have the connection (to check for an available update) open and ready, with the core of the CRLSet update ping being to respond more rapidly to high-risk key compromises.

Has this been fixed?

If I sign out of my account on my Chromebook, and then enter Guest Mode, the CRLSet version on about:components shows the latest version immediately (currently 4810), and https://revoked.badssl.com/ (as an example) is blocked.

It appears that CRLSet is now stored in such a way that Guest Mode can access it (and even update it), whereas before the version was shown as 0 (see Eric's first comment).

Can someone confirm?

(After a brief search,  bug 726162  is the only one I found that looks like it could possibly be related to the fix).