[Cryptography] distrusted root CA: WoSign

[Peter Gutmann]

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.

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

>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.
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.

(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).

>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.

>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).
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.

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".