[Cryptography] distrusted root CA: WoSign

Ben Laurie ben at links.org
Mon Oct 3 01:35:53 EDT 2016


On 3 October 2016 at 03:54, Peter Gutmann <pgut001 at cs.auckland.ac.nz> wrote:
> Ben Laurie <ben at links.org> writes:
>
>>anon-DH is not the same thing. Not saying browsers should not have allowed
>>it, but clearly it has different properties - in particular, revocation is
>>impossible.
>
> Given that browsers mostly don't do revocation either except for a token
> subset of certs, I'd say it's 0 : 0 to both sides there.  It's also a bit of a
> red herring, going through each of the revocation reason codes, we find that
> "key compromise" is unlikely to be useful unless the attacker helpfully
> informs the server administrator that they’ve stolen their key, "affiliation
> changed" is handled by obtaining a new certificate for the changed server URL,
> "superseded" is handled in the same way, and "cessation of operation" is
> handled by shutting down the server.  In none of these cases is revocation of
> much use, which is why browsers mostly ignore it.

Seems a bit circular - you claim revocation is only done for a "token
subset" and then explain why it is only needed for a subset (token or
otherwise).

> Now, let's talk about proper mutual authentication, and browser PKI's failure
> to provide any of that...

How do you do proper mutual authentication? I don't mean at the
protocol level, I mean how do I authenticate the keys used to secure
the exchange "properly"? This is precisely my point about identity...

>>I am confused by this claim: you can add your own roots to browsers...
>
> Firstly, that means reconfiguring each install of each browser on each PC with
> custom roots, which is more or less unmanageable on any kind of scale.

Installation of a browser is manageable, but installation of a second
thing alongside is not? Still confused.

> Secondly, re-read Jerry's message, a cert (as implemented in browsers) is OK
> if what you care about is that you've apparently connected to the server or
> device at FQDN/IP address X, but not that you've connected to the booster pump
> controller for the south machine hall.  The IP address doesn't matter, you
> want to know that you've connected to a particular device.

I know. But I didn't read a proposal for actually doing that.

> (And, by extension for browser PKI, whether I've connected to www.amazon.com
> doesn't matter, I want to know that I've connected to Amazon the global
> retailer, not some random FQDN.  This is why phishing works).

I know. And I haven't read a proposal for actually doing that either.
Other than EV, that is.

In the case of Amazon I am fine with knowing I've connected to
www.amazon.com, because I know that _is_ Amazon.

>>The problem PKI demonstrably does solve is that when I connect to google.com
>>(or a host of other well-know domains) I really am connecting to them.
>
> That's only because Chrome uses cert pinning.  In fact what you're talking
> about there is a symptom of the *failure* of PKI, if PKI worked then Chrome
> wouldn't need to use cert pinning.  When you hardcode in "only trust these
> certs for Google" then you're bypassing CAs and PKI, all that's left is a
> convenient bit-bagging mechanism.  Like SSH does, without any PKI, or need to
> pay a CA to be allowed to encrypt.

Cert pinning doesn't scale - that's why I developed CT.

>>I don't know why you'd expect it to solve phishing - that is to do with
>>linking identity to domain names, something the PKI doesn't really claim to
>>do (well, maybe EV, but studies show that isn't a great success). Or malware,
>>which seems like an entirely orthogonal problem.
>
> Right, and that's the standard excuse for PKI, "it's not guaranteed to do
> anything, and that's exactly what it does".  So why are we paying millions?
> billions? of dollars a year for it then?  It's pure snake oil [0].
>
>>Of course, it is easy to claim that PKI should be "sort of expected" to solve
>>these problems - but in the absence of any plausible proposal to solve them,
>>I call bullshit. I "sort of expect" you to solve these problems, but you
>>demonstrably have not. Nor even proposed a viable way to do so.
>
> Oh gawd, how many times have we already gone round this loop before?  See
> chapters 1 and 3-4 of my book (and in fact the rest of the book in general).

I did see last time you raised this, and I responded, and you ignored
my response, because it inconveniently pointed out that your solution
has been demonstrated not to work.

> And I'm not claiming that's the one true solution, in addition see 20 years of
> work by security researchers on ways of dealing with this, quite a bit of
> which I reference in the book so you can start from there.

My part of this loop is to decline to read 1,000 references. Point me
to a single one that proposes a workable solution, don't hide behind
an unmanageable number of references.

> Peter.
>
> [0] Again, this may be a bit of a difficult claim to substantiate, because
>     snake oil at least claims to solve all manner of problems, while PKI
>     just is.  As Ben rightly points out, it doesn't address phishing, it
>     doesn't address malware, it doesn't...  Perhaps we should paraphrase
>     Pauli to say that "it's not even snake oil".

I agree the whole thing sucks. I don't think we'd be better of with
nothing in its place.


More information about the cryptography mailing list