[159293] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Gmail and SSL

daemon@ATHENA.MIT.EDU (Steven Bellovin)
Thu Jan 3 16:26:01 2013

From: Steven Bellovin <smb@cs.columbia.edu>
In-Reply-To: <CALgnk9rag-09KkM4Wu3BMvemFpz3DJWAnjHKvaxn=FusMp0_EA@mail.gmail.com>
Date: Thu, 3 Jan 2013 16:25:45 -0500
To: Matthias Leisi <matthias@leisi.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


On Jan 3, 2013, at 3:52 PM, Matthias Leisi <matthias@leisi.net> wrote:

> On Thu, Jan 3, 2013 at 4:59 AM, Damian Menscher <damian@google.com> =
wrote:
>=20
>=20
>> While I'm writing, I'll also point out that the Diginotar hack which =
came
>> up in this discussion as an example of why CAs can't be trusted was
>> discovered due to a feature of Google's Chrome browser when a cert =
was
>>=20
>=20
> Similar to
> =
http://googleonlinesecurity.blogspot.ch/2013/01/enhancing-digital-certific=
ate-security.html?
>=20
Thanks; I was just about to post that link to this thread.

Certificates don't spread virally, and random browsers don't go looking
for whatever interesting certificates they find.  They also don't like
certs that say "*.google.com" when the user is trying to go somewhere =
else;
that web site would be non-functional unless it was trying to =
impersonate
a Google domain.  Taken all together, this sounds to me like deliberate
mischief by someone.  In fact, were it not for the facts that the blog
post says that Google learned of this on December 24 and this thread =
started
on December 14, I'd wonder if there was a connection -- was this the
incident that made Google reassess its threat model?

Of course, this attack was carried out within the official PKI =
framework...

		--Steve Bellovin, https://www.cs.columbia.edu/~smb







home help back first fref pref prev next nref lref last post