Hi,
On 02/07/2012 03:52 AM, Steven Bellovin wrote:
http://arstechnica.com/business/guides/2012/02/google-strips-chrome-of-ssl-revocation-checking.ars
While I am no fan of CRLs, I think it's worth mentioning that Google's
primary objective here does not at all seem to be the security of
On Tue, Feb 7, 2012 at 9:56 AM, Marcus Brinkmann
marcus.brinkm...@ruhr-uni-bochum.de wrote:
Hi,
On 02/07/2012 03:52 AM, Steven Bellovin wrote:
http://arstechnica.com/business/guides/2012/02/google-strips-chrome-of-ssl-revocation-checking.ars
While I am no fan of CRLs, I think it's worth
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
On 02/07/2012 11:51 AM, Ben Laurie wrote:
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
On 7/02/12 20:56 PM, Marcus Brinkmann wrote:
Hi,
On 02/07/2012 03:52 AM, Steven Bellovin wrote:
http://arstechnica.com/business/guides/2012/02/google-strips-chrome-of-ssl-revocation-checking.ars
While I am no fan of CRLs, I think it's worth mentioning that Google's
primary objective here
On 02/07/2012 01:36 PM, ianG wrote:
On 7/02/12 20:56 PM, Marcus Brinkmann wrote:
Hi,
On 02/07/2012 03:52 AM, Steven Bellovin wrote:
http://arstechnica.com/business/guides/2012/02/google-strips-chrome-of-ssl-revocation-checking.ars
While I am no fan of CRLs, I think it's worth mentioning
* Marcus Brinkmann:
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.
The CRL check is also done locally (but
On Tue, Feb 7, 2012 at 12:07 PM, Ralph Holz h...@net.in.tum.de wrote:
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
On Tue, Feb 7, 2012 at 6:05 AM, Marcus Brinkmann
marcus.brinkm...@ruhr-uni-bochum.de wrote:
That's a false dilemma. You could also extract trust from your cache, ie
your past experience with the same server (the SSH model), and/or from your
past connections with the internet (CRL or
On 02/07/2012 05:41 PM, Andy Steingruebl wrote:
I don't remember Adam saying in his blog post or in any other posts,
etc. that this is the only change they will make to Chrome.
Surely.
At the
same time I think they did get fairly tired or hard-coding a CRL list
into the Chrome binary
On Tue, Feb 7, 2012 at 7:25 AM, Alexandre Dulaunoy a...@foo.be wrote:
$ ./crlset dump crl-set | wc -l
1656
Maybe they use a bloomfilter-like format or something like that. But
it seems that their current bundle is
not matching the numbers of the revoked certificate especially the
ones with
http://arstechnica.com/business/guides/2012/02/google-strips-chrome-of-ssl-revocation-checking.ars
--Steve Bellovin, https://www.cs.columbia.edu/~smb
___
cryptography mailing list
cryptography@randombit.net
On Mon, Feb 6, 2012 at 9:52 PM, Steven Bellovin s...@cs.columbia.edu wrote:
http://arstechnica.com/business/guides/2012/02/google-strips-chrome-of-ssl-revocation-checking.ars
--Steve Bellovin, https://www.cs.columbia.edu/~smb
Interesting blog post on this topic by Adam Langley
On 02/06/2012 09:00 PM, Jonathan Katz wrote:
One question, though. Langley writes: If the attacker is close to
the server then online revocation checks can be effective, but an
attacker close to the server can get certificates issued from many
CAs and deploy different certificates as needed.
On 2012-02-07 12:52 PM, Steven Bellovin wrote:
http://arstechnica.com/business/guides/2012/02/google-strips-chrome-of-ssl-revocation-checking.ars
A major, and long needed, improvement in reliability, security, and
performance.
___
cryptography
15 matches
Mail list logo