Comment by Shank | Hacker News Reader

Comment by Shank | Hacker News Reader

Parent Full thread

I feel like a lot of these requirements need to be really solved from first principles. What do you need these certificates for -- specifically, TLS certificates?

If the biggest issue is "we want to encrypt traffic" then the answer really should be something more automated. To put it another way, TLS certificates used to convey a lot of things. We had basic certs that said "you are communicating with the rightful owner of domain example.com" and we had EV certs that said "you are communicating with the rightful legal entity Example Org, who happens to own example.com" and so-on and so-forth.

But the thing is, we've killed off a lot of these certificate types. We don't have EV certs anymore. Let's Encrypt effectively democratized it to the point where you don't need to do any manual work for a normal "we want to encrypt data" certificate. I just don't understand what your specific requirements are, if they aren't directly "encrypt this traffic" focused, where you actually need valid certificates that work across the internet.

Put differently, if you're running an internal CA, you can push out your own certificates via MDM tools and then not worry about this. If you aren't running your own CA but you're implementing all of this pomp and circumstances, what are you trying to solve? Do you really need all of this ceremony for all of your devices and applications?

What do I need these certificates for? I need them because browsers have started equating a vanilla http server to a malware-infested North Korean honeypot

> browsers have started equating a vanilla http server to a malware-infested North Korean honeypot

It isn't that they are equal, just that it is difficult to tell them apart. The change over time is that UAs have more and more erred on the side of not trusting when there is any question.

Of course HTTPS sites with valid certificates could also be malware infested hot zones, but it is less likely. Sites with invalid certs are more likely to be a problem than those with no cert (the situation might imply a DNS poisoning issue for instance), and sites with no cert are a higher risk than those with a valid one.

At least we seem to have dropped the EV cert theatre, the extra checks done before issuing one of those were so easy to fake or work around in many cases that they essentially meant nothing [source: in DayJob we once had an EV cert for a client instance, and I know how easy it was to get because I was the person at our end who applied for it and installed it once issued].

Have they? All I see is a little message saying "not secure". They've backtracked from trying to impose a scare screen, and they've even backtracked from displaying a red line through the letters "http".

They've also blocked JavaScript access to things like cameras and microphones if you're not using HTTPS. If it were up to me they'd always block them and you'd have to install an app, but still.

> But the thing is, we've killed off a lot of these certificate types. We don't have EV certs anymore.

EV certificates are no longer in use? Do you know why?

They turned out to be expensive theater. One major problem is that company names aren't actually unique. An EV cert for "Stripe, Inc" still doesn't tell you that you're talking to the correct "Stripe, Inc". The other big problem was that users had no clue they were a thing, and when browsers tried to emphasize them in the UI it just confused users and made phishing easier.

You can still buy EV certs if you want to donate money to a CA, but that's about all they accomplish.

> You can still buy EV certs if you want to donate money to a CA, but that's about all they accomplish.

To be more precise, the browsers de-emphasized them and removed any distinguishing marks or indicators that made them valuable. EV certs used to display the company name in the URL bar, but they were stripped back.

Reply on news.ycombinator.com