Weekly Edition
Return to the Security page
| |||||||||||||
Langley: Revocation checking and Chrome's CRL
On his blog, Adam Langley writes about plans for removing online certificate revocation checking in the Chrome/Chromium browser. Instead of OCSP and CRL checks, Google will be pushing lists of revoked certificates to the browser.
"While the benefits of online revocation checking are hard to find, the costs are clear: online revocation checks are slow and compromise privacy. The median time for a successful OCSP check is ~300ms and the mean is nearly a second. This delays page loading and discourages sites from using HTTPS. They are also a privacy concern because the CA learns the IP address of users and which sites they're visiting.
[...]
On this basis, we're currently planning on disabling online revocation checks in a future version of Chrome. (There is a class of higher-security certificate, called an EV certificate, where we haven't made a decision about what to do yet.)"
(Log in to post comments)
Langley: Revocation checking and Chrome's CRL Posted Feb 7, 2012 16:26 UTC (Tue) by PO8 (guest, #41661) [Link]
It seems to me that inventing a new browser-specific mechanism for pushing revocation lists to Chrome is a bad plan. Rather, the CRL mechanism could be adapted in a way that would serve all browsers.
At a quick glance it looks like all that is needed is (a) to ignore the TTL of the revocations in the CRL and instead use the TTL of the cert being revoked (why is this not the default?), and (b) to offer a way to request CRLs in blocks by date so that browsers need only pull revocations that they may not have seen yet. This combination of features would serve the same purpose as the Chrome "browser update": browsers could refresh their cache of revoked certs whenever feasible, without delaying in-flight https requests or exposing the users' browsing information.
Given the modest nature of the proposed changes, it doesn't seem so hard to get all actively-developed browsers to play along. It would be nice to have a standardized mechanism, and it seems like it might even be less work for Google.
Am I missing something?
Langley: Revocation checking and Chrome's CRL Posted Feb 7, 2012 16:58 UTC (Tue) by Kit (guest, #55925) [Link]
If I understand how the CRL system works, that would then require every browser to periodically check not just one source, but every single Certificate Authorities' CRL server for any new revocations. Just based on a quick Google search, the EFF's SSL Observatory project has identified at least 1,400 different CA certificates (likely several are from the same CA). Still, even regularly pinging _100_ different entities (I'm sure it's far more than that!) wouldn't be a small amount of extra overhead. Plus, every time a new CA comes about, every browser would then have to learn about it some how, so they can know to check their revocation server.
And this isn't just for the root CAs, but every intermediate.
Seems to me that Google's plan is quite simple, and doesn't depend on technologies that are still struggling to be rolled out. I don't see anything intrinsic in this plan that would benefit Google other than 'making SSL suck less', so I'd imagine they're more than willing to hear alternatives to improve the system further.
Chrome, Firefox, and IE (maybe the others also) already include their own internal blacklist, because the CAs don't always do a great job at revoking things they should revoke, so this wouldn't require a huge amount of new infrastructure for Chrome, just to have the list updatable without requiring a restart of Chrome. There will be some work done on the CA and Google (and whoever else wants to distribute lists, nothing would stop Mozilla from crawling to update the list they already ship). Seems that Google's solution is very straight forward, and puts the least amount of trust in the CA actually doing their job.
Langley: Revocation checking and Chrome's CRL Posted Feb 7, 2012 18:58 UTC (Tue) by josh (subscriber, #17465) [Link]
You can't sensibly just download a full list of revoked certificates to every system; that represents a *huge* list.
How about aggregating all revoked certificates at one or more intermediate services managed (perhaps jointly) by browser vendors, using a hashed lookup system similar to the one currently used for the "safe browsing" blacklist? Take a look at http://www.morbo.org/2012/02/new-safebrowsing-backend.html for a few of the details on how that system works.
Langley: Revocation checking and Chrome's CRL Posted Feb 7, 2012 19:53 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Actually, you can. CRLs are not "huge" and comfortably fit in several megabytes.
Langley: Revocation checking and Chrome's CRL Posted Feb 7, 2012 20:00 UTC (Tue) by josh (subscriber, #17465) [Link]
I don't have the specific numbers in front of me, but as I understand it, the CRLs from *each* major certificate provider take up many megabytes each, which would make the full list a couple of orders of magnitude larger.
And on top of that, you still need an efficient way for browsers to update those lists, without having to regularly contact a thousand servers for updates.
Langley: Revocation checking and Chrome's CRL Posted Feb 7, 2012 20:12 UTC (Tue) by raven667 (subscriber, #5198) [Link]
At some level though all the information which is contained in all the CRLs spread across all the CAs will have to be included in this system so either the current CRL file format is wildly inefficient or you will ultimately need many tens or hundreds of megabytes of CRL cached on the client. The upside is a new distribution mechanism could send update diffs which would be a large efficiency improvement for keeping up to date.
Langley: Revocation checking and Chrome's CRL Posted Feb 7, 2012 20:27 UTC (Tue) by josh (subscriber, #17465) [Link]
<blockquote>At some level though all the information which is contained in all the CRLs spread across all the CAs will have to be included in this system so either the current CRL file format is wildly inefficient or you will ultimately need many tens or hundreds of megabytes of CRL cached on the client.</blockquote>
Somehow I managed to completely not think of that. I do think the format could become much more efficient (for instance, making use of radix trees), but nonetheless this does seem likely to produce a non-trivial increase in the size of browser downloads and/or their regular bandwidth usage.
Langley: Revocation checking and Chrome's CRL Posted Feb 7, 2012 20:52 UTC (Tue) by wahern (subscriber, #37304) [Link]
A simple binary search over a sorted array of the 16 or 20 byte public key checksums would be far more efficient. A tree structure could easily double or triple the amount of memory needed. With a sorted array your memory is exactly sizeof checksum * number-of-revocations.
The slides over at the EFF SSL Observatory said that as of 2010 there were only 1.5M valid and unique certificates. I would imagine the number which have been revoked is a small fraction of that. And a smaller fraction still which are revoked but otherwise within their expiration.
Langley: Revocation checking and Chrome's CRL Posted Feb 7, 2012 20:54 UTC (Tue) by arjan (subscriber, #36785) [Link]
Actually... you only need to track ones that are not expired yet.. so the list is also self-culling, not on a growth-only path.
Langley: Revocation checking and Chrome's CRL Posted Feb 7, 2012 22:39 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
The current CRL format is way too bloated (it was never meant to be used for large transfers).
A better format would allow to pack each revoked certificate in 16 bytes or even less. Creating effective diff format is not complex as well, since CRLs are addition-only in practice.
Langley: Revocation checking and Chrome's CRL Posted Feb 7, 2012 22:46 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
why create a new format instead of just using diff -u0? Then the file can just be a list of the certificate fingerprints (and I think it's worth doing it as text instead of binary)
Langley: Revocation checking and Chrome's CRL Posted Feb 7, 2012 22:55 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Because you want it to be effective and compact.
I'm thinking about something like: 14 bytes of hash followed by 2 bytes for expiration time (in days since the epoch - 179 years should be enough for anybody).
Langley: Revocation checking and Chrome's CRL Posted Feb 8, 2012 0:29 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
you don't need the expiration on the client, the server that is sending the updates just sends 'delete this list' messages.
also, you want to be paranoid about false positives, so the full hash would be better than a partial hash.
Langley: Revocation checking and Chrome's CRL Posted Feb 8, 2012 0:36 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
>you don't need the expiration on the client, the server that is sending the updates just sends 'delete this list' messages.
Explicit deletion is bad - it complicates everything.
>also, you want to be paranoid about false positives, so the full hash would be better than a partial hash.
Though adding a few bytes for a longer hash is not hard.
Langley: Revocation checking and Chrome's CRL Posted Feb 14, 2012 22:20 UTC (Tue) by kleptog (subscriber, #1183) [Link]
While I'm sure the format can be improved I think estimates like 14 bytes are a bit low. It's not sufficient to simply provide the hashes of revoked certificates, the list needs to be authenticated in some way. You're not supposed to be able to revoke other peoples certificates. The signing will add overhead.
Now, an improvement may to be sign the transfer rather than the individual hashes. That would make it difficult to validate the CRLs offline though.
Google has experience distributing large lists to clients, see safebrowse, I'm sure they thought it through.
Langley: Revocation checking and Chrome's CRL Posted Feb 14, 2012 22:35 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
>While I'm sure the format can be improved I think estimates like 14 bytes are a bit low. It's not sufficient to simply provide the hashes of revoked certificates, the list needs to be authenticated in some way. You're not supposed to be able to revoke other peoples certificates. The signing will add overhead.
So the whole list should be signed by browser's vendor (you have to trust it in any case). Additional metainformation can be downloaded and verified separately but it's not required in every copy of the CRL archive.
We can do even better, the CRL archive can be counter-signed by another trusted party (say, EFF) which can check that all revocations are valid.
Langley: Revocation checking and Chrome's CRL Posted Feb 7, 2012 19:09 UTC (Tue) by istenrot (subscriber, #69564) [Link]
There are existing methods to make CRL/OCSP side checking obsolete in a safe way:
- http://en.wikipedia.org/wiki/OCSP_stapling - http://tools.ietf.org/html/draft-ietf-dane-protocol-15
Onlie certificate status checking is a must! Chrome developers at Google aren't thinking clearly :(
Langley: Revocation checking and Chrome's CRL Posted Feb 7, 2012 19:29 UTC (Tue) by raven667 (subscriber, #5198) [Link]
A locally cached and frequently updated status database seems to be a good compromise. It's fast, functional and doesn't disclose all browsing history to a third party, the only downside is that it won't instantaneously notice a revocation but that's way better than the current circumstance where effectively certs are never revoked because clients never check (and the checks fail open in any case).
OCSP pinning seems interesting and fundamentally changes the trust model to that of Kerberos. Actually this seems like it might be a new revenue stream for CAs as they could rent their authentication at an hourly rate.
Langley: Revocation checking and Chrome's CRL Posted Feb 7, 2012 20:24 UTC (Tue) by josh (subscriber, #17465) [Link]
Seems like something that would have actually made EV certs mean something, yeah.
Langley: Revocation checking and Chrome's CRL Posted Feb 7, 2012 20:36 UTC (Tue) by raven667 (subscriber, #5198) [Link]
Unfortunately all most certs mean in practical use is that someone at some point had a few dollars to buy one, they cannot reliably tell you anything interesting about the party you are communicating with.
Langley: Revocation checking and Chrome's CRL Posted Feb 7, 2012 23:04 UTC (Tue) by josh (subscriber, #17465) [Link]
The quote I've always liked: Certificate Authorities protect you from anyone whose money they won't take.
Langley: Revocation checking and Chrome's CRL Posted Feb 8, 2012 0:31 UTC (Wed) by Lennie (subscriber, #49641) [Link]
The problem is, currently as mentioned at the bottom of the OCSP stapeling page on Wikipedia, it doesn't work well for large sites.
Langley: Revocation checking and Chrome's CRL Posted Feb 7, 2012 19:42 UTC (Tue) by josh (subscriber, #17465) [Link]
I don't think stapling suffices. While latency and privacy gives sites an incentive to provide it, most sites will never bother, and more importantly malicious sites will *definitely* not bother. I don't think a system which requires cooperation from every site owner (as opposed to just every CA) has much hope of succeeding anytime soon.
Langley: Revocation checking and Chrome's CRL Posted Feb 8, 2012 0:29 UTC (Wed) by Lennie (subscriber, #49641) [Link]
You obviously can make OCSP mandatory for non-stapled sites. Doesn't matter what the malicious sites do in that case.
Langley: Revocation checking and Chrome's CRL Posted Feb 8, 2012 7:14 UTC (Wed) by geofft (subscriber, #59789) [Link]
I don't see any reason why Chrome would need to desupport OCSP stapling in order to desupport regular OCSP and CRLs. In fact, the best way to encourage people to move to OCSP stapling is to turn off regular OCSP and CRLs.
The Chrome developers have already spent a while looking whether certificate checking via DNSSEC is feasible; I believe they've been the most active folks on this front recently, and concluded it wasn't feasible right now.
DANE? Posted Feb 8, 2012 14:09 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
When you say "certificate checking via DNSSEC" do you mean DANE? Or something else?
In general terms we already have proof by example that it can work, because SSH already supports this functionality as SSHFP.
Deployment is something else entirely of course, but that's true of any potential way forward. The browser vendors have been very slow to obtain a clue largely because in reality their users don't care, seeing that funny cat video is far more important than being protected from fraud. Until it actually happens.
|
|||||||||||||