[cryptography] Gmail and SSL

Ben Laurie ben at links.org
Sun Dec 16 06:20:24 EST 2012

On Sun, Dec 16, 2012 at 7:52 AM, ianG <iang at iang.org> wrote:
> On 16/12/12 02:41 AM, Ben Laurie wrote:
>> On Sat, Dec 15, 2012 at 10:01 PM, James A. Donald <jamesd at echeque.com>
>> wrote:
>>> On 2012-12-16 6:23 AM, Andy Steingruebl wrote:
>>>> given some of the more recent attacks against Google (and Facebook's)
>>>> customers they believe that active MiTM is actually a real threat, and
>>>> would
>>>> rather not pretend to protect you from it when they aren't, by using a
>>>> self-signed certificate that they haven't verified in any way, even by
>>>> you
>>>> presenting it.
>>> Recent MITM attacks have been by entities that are likely to be able to
>>> coerce a CA.
>> This is why you need Certificate Transparency.
> Actually, we need a secure and private authentication system.  If I was
> reading that in Gmail I'd suppose that it would transparently link to here:
> http://www.certificate-transparency.org/
> ;)  As you say, that idea is a research idea.

I didn't say that (that site may say it, I don't know, I haven't been
keeping that site updated). In fact, Google is building it, right now.

>  We can only want it, we
> cannot need it.  I see several issues (4).
> Just looking at CAcert, by way of counter example.  CAcert does not publish
> its certificates because of privacy.  That's actually quite a strong result,
> and hard to avoid [1].

CT applies to public certificates. By definition, these are not
private. If CAcert wants to issue private certs in a CT world, then I
suspect some changes will be needed...

>  If one looks at Bitcoin or the recent many efforts
> to track all certificates, this represents a gold mine of datamining
> opportunities.  Do our customers really want their security model to become
> a public spectacle?

Public certificates are already a public spectacle. I have no idea
what Bitcoin has to do with this.

> Also (2), the notion that an auditor would be a fair arbiter of what the
> public wants is dead in the water.  It's a non-starter.

CT is not an arbiter of anything, it is an audit trail.

>  Also (3), as you
> acknowledge, getting the CAs to change anything is difficult, the OODA cycle
> is estimable at about a decade.

I think we can move faster than that. CAs have already signed up to CT.

> Which (thinking aloud) leaves cryptographic proofs that test the audit claim
> needed, without revealing the certificate body.  But that's a fairly tough
> burden.  Proving that my certificate is in the chain seems doable.  But what
> we are trying to prove is that every certificate is in the chain.  Without
> seeing every certificate.

I do not agree that that is a goal.

> Or more importantly, we want to prove that a certificate found in an MITM
> was in the chain or not.
> But (4) we already have that, in a non-cryptographic way.  If we find a
> certificate that is apparently signed by say VeriSign root and was found in
> an MITM, we can simply publish it with the facts.  Verisign are then
> encouraged to disclose (a) it was ours, (b) it wasn't ours, or (c)
> mmmmummm...

The point of CT is precisely to make it possible to find MITM certs
even when you are not the victim.

More information about the cryptography mailing list