| |||||||||||||
Langley: Revocation checking and Chrome's CRLLangley: Revocation checking and Chrome's CRLPosted Feb 7, 2012 16:26 UTC (Tue) by PO8 (guest, #41661)Parent article: Langley: Revocation checking and Chrome's CRL
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?
(Log in to post comments)
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.
|
|||||||||||||