[cryptography] Chrome to drop CRL checking

Ralph Holz holz at net.in.tum.de
Tue Feb 7 06:07:10 EST 2012


Hi,

>> The security argument itself seems very weak.  There is no evidence yet that
>> the alternative strategy that Google proposes, namely letting them control
>> the CRL list (and thus another part of the internet infrastructure), is any
>> safer for the user in the long run.
> 
> The point is that using this mechanism means Chrome always has an
> up-to-date revocation list - as it is now, revocation checking can be
> blocked and Chrome will allow revoked certs as a result.

What is the point in disabling OCSP, then? Chrome could always use its
own revocation database as a primary reference, and use OCSP
additionally if there is no hit. I like that Chrome pulls revocations
via the update mechanism, but this does not sound very scalable - where
do you draw the line? Do you have data how many CRL entries come with a
reason (those are preferred by Chrome). How do you make sure no false
reason is given by CAs as a consequence - i.e. they always just put fake
entries there saying "cert renewed" even though it may actually have
been a compromise.

So, yes, Chrome does raise the barriers a bit, but I fail to see how
this could be a long-term solution and how it could extend to anything
but a small selected subset of the Web.

>> Certainly the privacy concern that Google expresses "because the CA learns
>> the IP address of users and which sites they're visiting" does not extend to
>> Google itself, which already has much more detailed information about its
>> users.
> 
> Since it is a push mechanism, Google does not get which sites the user
> is visiting.

I think Markus' point is: it is not an advance in privacy for the user.
Many people just type a keyword into the omnibox to land on the desired
page ("facebook"). Thus, Google already knows what they do; they do not
need the information from online revocation checking.


-- 
Dipl.-Inform. Ralph Holz
I8: Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20120207/2621d8ab/attachment.asc>


More information about the cryptography mailing list