[Cryptography] distrusted root CA: WoSign

Ben Laurie ben at links.org
Sun Oct 2 13:50:35 EDT 2016


On 2 October 2016 at 13:45, Jerry Leichter <leichter at lrw.com> wrote:
>> More polite version: yes, it is a hard problem, but how do you solve
>> it without some kind of central authority? On what basis can the end
>> user validate a certificate, other than some authority doing it on
>> their behalf?
> As I've pointed out before:
>
> 1.  Trusted introduction is a psuedo-problem.  The original idea was that I know Macy's because I've seen the stores around, they've been around for decades, I've shopped there - so I trust them.  When I type macys.com into my browser, I know (how, exactly?) that I'm going to a site owned by the same store.  When I get a signed cert from macys.com, I know I really reached macys.com, so I can trust it really is Macy's - and it's safe to shop.

Clearly that is a dumb idea.

> Let's now look at the reality.  I see an ad for cheap socks from SocksRUs.com.  I connect to SocksRUs.com and get a signed cert that it really is SocksRUs.com, so I can trust ... what, exactly?  Do I even have any reason to believe that the SocksRUs.com I reached had anything to do with the ad I saw?  And even if I can trust they are the same - just what did that trust gain me?
>
> Or I get email claiming to be from Bank Of America, which has an embedded link that goes to bank0famerica.com, which has a signed cert that it really is bank0famerica.com - so I can trust that ... I've safely and securely reached a fake site.
>
> The fact of the matter is that the trusted introduction problem - safely binding a first connection to a site to some real-world knowledge about that site - comes up so infrequently as to be of vanishing importance.  Sure, you can construct examples that actually work - I give you a business card with my printed web address (or the bank gives me a brochure with the same), I type it in and can get reasonable confidence that the site I reached is the one belonging to the person/organization handing out the pieces of paper.
>
> But ... who types web addresses any more?  People find web addresses by doing searches.  So I *search* for Bank of America, go to the indicated link (which sure enough has a cert saying it is, indeed, the link it says it is), and proceed.  So *I can trust that I reached the site the search engine told me about*, *not* that I reached Bank of America.  To gain *that* level of trust, I need to trust the results of my search engine.  If my search engine handed me the public key that corresponded to the URL directly - or if one of the standard techniques for embedding trust *in the link itself* were used (not practical in a world where people type URL's, but that's not the world we live in), the elements I have to trust are *reduced*.  The CA never added anything here, because it simply was not in a position to do so by the nature of the problem.

But this is key: how would a search engine acquire this public key,
other than by doing exactly what CAs do? All you are doing is rolling
the CA function into the search engine function. No actual difference
has been made. Apart from a massive reduction in competition, that is.

> 2.  The vast majority of my connections to a site occur *after* the first.  Why would I need a CA for those?  What I really want is ssh-style key continuity.  The CA simply gets in the way here - and in fact the introduce a whole level of extra vulnerability, because it *may* lead to to trust a fake site *even when I have reliable information about the real one*.  Oh, and of course the site doesn't need the CA to change keys - it simply needs to sign the new ones using its old ones, maintaining continuity.

You can have ssh-style continuity, that is what pinning gives you.
Turns out that's a large gun aimed squarely at your foot for most
sites.

> 3.  Ultimately, any trust I might have based on cryptography has to rely on trusting the browser vendor.  His code can do whatever it likes.  In the CA world, beyond trusting his code, I also have to trust his list of CA's.  (Yes, I can create my own list of CA's, but who does that?)  So before I even get to an individual CA, I'm trusting the browser vendor at two different levels - and on the second level, choice of CA's, the browser vendors have limited credibility, because they are embedded in a political system that would make it very hard for them to say no to a CA except in really exceptional situations (like WoSign).

Not sure what point you're making here. The "really exceptional
situation" was a CA demonstrably failing to do their job.

> So if you want alternatives to the *real* problem of secure connections on the Internet, not the pseudo-problem of secure introductions, there are at least two:
>
> a.  I've previously on this list worked the numbers and shown that it would be perfectly possible for browser vendors - or others who want to provide an equivalent service - to regularly distribute the public keys of, say, the top 100,000 sites on the Internet.  Once you get beyond those, there's frankly not much to be gained in knowing that SocksRUs.com really is SocksRUs.com.

Once more, all you are doing here is renaming "CA" to "browser vendor".

> b.  As I outlined above - people don't really use URL's, they use searches.  Fortunately, the top search engines are pretty good - actually, *really* good - at returning URL's that match the *intent* of the search.  Why can't they extend that so that if you click on the link they offer, you can trust that you got to the *intended* site?  A CA doesn't help here *because it establishes trust in a URL, and the URL is not what I intended to reach!*

Isn't that exactly what CT does? Implemented, btw, by one of the top
search engines.

i.e. the search engine returns the URL, CT ensures that the
corresponding cert is actually the one the owner of the URL intended.
The CA does the paperwork.


More information about the cryptography mailing list