| |||||||||||||
Langley: Revocation checking and Chrome's CRLLangley: Revocation checking and Chrome's CRLPosted Feb 7, 2012 18:58 UTC (Tue) by josh (subscriber, #17465)In reply to: Langley: Revocation checking and Chrome's CRL by PO8 Parent article: Langley: Revocation checking and Chrome's CRL
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.
(Log in to post comments)
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.
|
|||||||||||||