Comment by e12e | Hacker News Reader

Comment by e12e | Hacker News Reader

Parent Full thread

Arguably there is a solution: just use self-signed certs and/or your own ca. And have browsers implement some form of trust-on-first use and/or some dns/web-of-trust way of avoiding a big scary warning message. This won't fix everything, but it is more secure than http and more honest thsn the idea that you should trust all the CAs browsers bundle.

Ideally browsers should just bundle their own CA certs, and implement some form of semi-formal wot/have a sane UI for the rest. After all we trust our browsers implicitly - but why should we elevate them to do transitive trust for us?

Lets just build on x509, and get some kind of meaningful trust.

Lets say that Apple, Microsoft, Debian, Red Hat (eaxh distribute their own trusted (self-signed) CA cert. And also work with Mozilla, Google to trust (sign) their certs.

Then let trust-on-first-use or some other distributed method take care of the rest. When let's encrypt work: let distributions trust that too.

The resulting system would not be perfect - but I still think it would have a better trust model than our current mess.

Could not agree more with the first paragraph.

As it stands, we punish people who want "half security" much more than people who go for "no security"

> have a sane UI for the rest

If any solution to this mess exists, it is going to require this UI. A fundamental problem with PKI is the trust decisions are not being made by the people that rely on that trust for protection.

What we need is pluggable trust, where it is easy indicate that I trust the shared-by-hand-only cert a friend made for chats between a few friends, a different cert for communications with my bank that I got a copy of by walking into a local branch, and some well-known CA for everything else. This is not "web of trust", though the concepts may overlap; this is about having a easy way to plug in whatever trust model you care to use and allowing different trust models for different endpoints.

What stops the browser from automatically trusting a self-signed cert for PayPal or your bank?

What stops the browser from automatically trusting a forged certificate signed by a bundled CA? That's not a hypothetical question. It's happened before - either through incompetent CAs, or malignant ones (see: Google/Mozilla vs China).

The problem with the current trust model, is that it's unclear who we trust -- or put in another way, who we empower to betray us. No trust without the possibility of betrayal - no betrayal without trust.

With the current model, the path from who the user trusts (eg: Mozilla, Google and the OS vendor) is abused to extend to way too many CAs. So many, that the user can give up (ie: I use the browser and trust the green bar) -- or get a crippled experience, because the model assumes that you trust all bundled CAs. Sure, power users can in theory remove CAs from the store (and add ones, like I do for cacert.org, as I use them for my domains).

The fact that I add cacert.org reminds me of another thing: There should probably not be any CAs that can sign arbitrary subdomain.TLD. Since I add cacert.org, they can empower someone to mitm all my tls connections. But that is a separate issue - this issue already exist.

Trust decisions is all about meaningful choice -- and choosing between not using the web, and trusting Chinese (and every other) intelligence, along with various foreign corporations (they're all foreign to someone) to not enable/be tricked into mitm my email, my web browsing etc.

Certificate pinning, among other things.

Reply on news.ycombinator.com