Hacker News Reader

> Forget security concerns, I'm just appalled that to acceptably do encryption today I need to pay some company! That's wrong.

Well, you don't need to pay anyone to do encryption. You do need to do pay people to do identity verification. That's a more-than-pedantic difference, even though encryption without identity verification is generally meaningless.

First off, you're already paying someone to have a domain name. I sorta understand the distaste on principle, but I've never really understood, as a practical matter, why paying $10+/year for a domain name is totally fine, but paying $5/year on top of that for SSL isn't. (And yes, the race-to-the-bottom has hit $5, see ssls.com. This isn't even counting StartCom and the future Let's Encrypt.)

Second, and related to that, what you're paying them for is the human element in key continuity. If you ever lose your key, you're going to want to be able to regain a key for the same website that you've already published everywhere, that everyone already has localStorage for, etc. And be careful about saying that you don't care: Crypto.cat (which, at this point, definitely knows what they're doing) managed to lock themselves out from SSL by requesting a hardcoded public-key pin and then losing all the public keys they'd pinned. This isn't really a risk that you think is realistic until disaster strikes, and the last thing you want in the middle of a disaster is to have to rename your website and convince everyone that they should use the new site.

And the process of maintaining infrastructure to re-provision certificates to people costs money. It's possible that it could be funded in different ways (just like, e.g., all of the work that goes into the browsers themselves is funded in ways that don't involve charging website owners or users). But there is a thing there that involves humans, there are advantages to it involving humans, and humans need to be paid.

> And yes, the race-to-the-bottom has hit $5, see ssls.com

What's the race to the bottom for wildcard certs though? Looks like $80+/year, which is frankly completely ridiculous seeing as it's exactly the same amount of work for the CA.

The whole thing's a racket, we would honestly be better off using self-signed certs and certificate pinning (perhaps with a global list of cert pins stored in the browser/a server the browser implicitly trusts)

I mean, we have to trust the browser anyway, might as well make it handle all the security

Startssl has wildcard certs if you buy their service at 50$/yr, plus many other stuff.

The $59.90 account only buys you identity verification so that you can get a cert for your own personal domains. When you want to get certs for a company's domains, you also have to pay for organisation verification for another $59.50. In neither case are you allowed to request certificates for domains owned by other entities, even if you are authorized to do so by the owner (e.g. as a service provider). See here: https://www.startssl.com/policy.pdf

https://letsencrypt.com will be offering free certificates this year and will hopefully completely transform the SSL business. Given that extended validation certificates have little if any consumer value, letsencrypt could quickly take over the whole SSL world.

It's a dot org: https://letsencrypt.org

Startssl give free certificates, and letsencrypt will be joining the party this year as well.

Just to clarify, when I said "acceptably do encryption" I meant "do encryption without requiring a user to wrestle their browser and install my certificate".

Firefox does opportunistic encryption now. :)

http://arstechnica.com/security/2015/04/new-firefox-version-...

It's just that lots of other browsers are hesitant to follow suit, because OE doesn't protect you from most attacks that the average internet user would expect encryption to protect you from (e.g., you shouldn't type credit card numbers into an OE webpage). And even Firefox treats the site as http, not https, although the physical connection is over TLS on port 443. That's what, in the browsers' eyes, is "acceptable" encryption, which is what translates to the user experience of having to override the browsers' warning.

I don't get how it's ridiculous. How do I know that Bank of America's website is actually Bank of America? At least I know _somebody_ checked that it was BoA who is controlling the domain.

It's obviously far from 100%, but the web of trust has to start somewhere. Distributed web-of-trust works for individuals, but am I supposed to go see Jeff Beezos in meatspace before going to amazon.com?

The solution is, of course, delegation. But the end result is you end up with exactly the same CA system as today!

Somebody checked that in the past, yes, but that check doesn't matter for your current connection. Your browser will accept any CA signed cert as valid for the site it's for... if a hacker hacks into a low-profile CA, not even the one that verified BoA, they can MITM you every bit as easily as if they hacked BoA's actual cert authority.

The problem here is that the delegation is too broad; we're delegating verifying all websites to all CAs and assume that all CAs are absolutely trustworthy for it to work. That's ridiculous.

Chrome has a sort-of-solution built on top of this with certificate pinning where the organization gets a cert from the CA, and then gives it to chrome and claims "Only this cert is valid for our site" rather than all CA's certs...

Continuing with our example of BoA, this doesn't matter because they have not opted in [0] to that and in any case that won't apply to non-chrome requests.

[0]: https://code.google.com/p/chromium/codesearch#chromium/src/n...

"Chrome has a sort-of-solution built on top of this"

… which scales up about as far as every domain Google owns/cares about, and a few of their friends/partners/sites-that're-politically-or-business-beneficial-to-Google-to-pin.

I suspect in my 20 odd years of working with ssl protected websites, there's maybe 2 or 3 sites I've worked on that hav a hope in hell of getting into Chrome's pin list. If you're outside the US Fortune500 or any other countries Fortune100, how easy is it gonne be to get Google to pin your cert? It's nice if you're Twitter - it's _never_ gonna work for mygreatcatphotos.org.au...

It's useful, and a great thing they're doing, but as you say, it's _very much_ a sort-of-solution. Perhaps more like a very good two or three bandaid solution, directed at the problem of someone with 99% full body covered 3rd degree burns. "Here, I've got your left thumb and your right big toe covered!"

They have pretty little form for it :) https://hstspreload.appspot.com/

My guess is no one bothers to fill out the form due to lack of knowledge about its existence.

Surely they let in more than just their friends ... though yes, I do recognize this isn't scalable.

They've been pushing back against new people preloading public key pins because it's hard to make sure that someone else understands exactly what the consequences are. (Cryptocat, notably, got this wrong.)

But yes, HSTS preloading is totally open, and has been scaling as well as it's been needed.

this is a really good point. So would a good solutioon be to divy up the delegation? Though I don't know how that could work (how would you know you're on a bank website? a .bank tld?)

This is tricky, but I still don't get how decentralisation solves things, because the problem is still the same, except now it's a risk of whatever web-of-trust node you're a part of being compromised instead of a CA.

Some pointers for you:

- The Perspectives project (http://perspectives-project.org/) aimed to deploy a range of servers (called notaries), through which you can ask "What cert do you see for https://google.com ?", and compare the response. The idea was that certificates should be mostly the same wherever you're asking from.

- Convergence (https://en.wikipedia.org/wiki/Convergence_(SSL)) is a fork of the same idea.

The issue with both of them is, of course, privacy leaks, which the latest version of convergence (https://github.com/mk-fg/convergence#changes-from-upstream) solves with a custom onion routing. The other problem I see is that it still (in the current form) requires the user to manually edit the notaries list.

So, it does exist, maybe it's just lacking publicity ?

Why you think the PKI sucks but can't do any better:

https://medium.com/@octskyward/why-you-think-the-pki-sucks-b...

I wrote this article for the Bitcoin community but most of the logic stands for the web too.

Trustworthy entities (e.g, Mr Schneier and Krebs and whoever they trust) could just offer a signed list of pub-key - identity pairs which can be stored in the block chain.

The amount of work needed should be pretty low, they start with the current certificate tree and they just need to update in case of a certificate incident (they probably get this info fast and the update should be easy to do via software). Probably they could sustain this service via donations.

A better solution could be viable but there are entire companies based upon the pki infrastructure.