Ask HN: It's 2011. Why is web encryption still coupled with verification? | Hacker News Reader

Ask HN: It's 2011. Why is web encryption still coupled with verification?

34 pointsnoduerme20 comments

Seriously. If I want to know I'm looking at the real Paypal website, Paypal can shell out to Verisign or whomever to reassure me. If I want to code a site in my garage, and prevent logins from being scraped on any wifi connection, why the hell should I have to pay for my identity to be validated? Are Mozilla and MS and Google all in business with GeoTrust to the extent that there can't be a header that says, ENCRYPT THIS CONNECTION? With or without validation? With or without warning a user?

Come to think of it, a self-signed SSL cert generates a bazillion warnings in the browser that get worse every year, but have you ever seen a browser warn you that you're about to submit your password over a totally unsecured, unencrypted connection? No!

GeoTrust still wants to see $5M in net worth to "make" you as a CA. What a racket.

View on HN

There was a great discussion about this a month or so ago (http://news.ycombinator.com/item?id=2376431). I'd highly encourage you to read the comments that were made.

As Lanzaa pointed out here, encryption without identity validation is worthless. If anyone can MITM your connection without you knowing about it, your encryption isn't doing you any good. That being said, there is certainly value to the "SSH model", where you verify the destination's fingerprint the first time you connect and any time it changes. That at least gives you the opportunity to know if someone is attacking you.

Why can't encryption still be useful if you (not your browser, you personally) trust what's in your URL bar?

Well, you will have to look at the server's key fingerprint, looking at the URL will not be enough.

If you're being MITM attacked, you will still see trusted.example.com in URL bar.

I think you're talking more about someone hijacking a nameserver in that case. The vast majority of MitM attacks are on open networks between the client and the ISP, are they not?

I'd argue that in order to trust what's in your address bar, you have to have "verification": if you're not sure who's on the other end, you can't trust the address bar. Whether that knowledge comes from a PKI system like browsers use now or an SSH-style system is a separate issue.

The lack of opportunistic encryption in most protocols is indeed depressing. Clearly a case of the perfect (end to end authentication) being the enemy of the good (protection from passive eavesdropping), although in fairness, active MITM attacks are much easier on most IP networks than on something like the PSTN or in-person with which people are more intuitively familiar, at least near the endpoints (or by carriers)

We really need some kind of caching of keys, like ssh does, where users are alerted only if a key changes. Combine that with some smart way to do real authentication after the fact (i.e. start using a site, don't trust it much, but when you're ready to start using it for high trust stuff, do a more in-depth validation), and security for end users would be vastly improved.

Verification is vital to security.

In your example having a self signed certificate would be worthless. If someone is performing a Man In The Middle attack on your users then they can also sign their own certificate while impersonating your site. Without verification your users would not know the connection to your site is compromised.

While the current system is not ideal, you should not try to completely do away with verification.

Yes it's vital to security, but it's one of two components here that should be separated. The encryption itself is crucial to a lot of applications now that simply can't be spoofed. That wasn't really true 20 years ago. But now, just to achieve most kinds of load balancing you need a wildcard cert, and while there's obviously no reason that should cost 10x a single subdomain cert, there's also no obvious reason that the verification itself should be tied to the encryption.

Encryption is good, in and of itself, with or without verification for most security purposes. MitM attacks can happen just as easily if someone fails to notice that there's no little padlock in their URL bar. It's a separate issue, and one shouldn't have to pay a corrupt mafia for access to browsers' encryption capabilities if all you're looking for to secure your users.

You calling it a separate issue because you think about it that way doesn't change the fact that in terms of the current security model for the web... they're very intrisically tied together.

Do I think that RA/CA charging out the wazoo for the privilege of verified identity is right? No. That's what you need to be fighting against. You're trying to hack together some way to avoid buying a verified SSL by cutting corners. It's just not going to work.

Passive MITM is MUCH higher risk in the wild than active MITM. Active MITM also generally disrupts service or otherwise leaves evidence, so it eventually gets found; passive can go on forever.

The best thing would be opportunistic encryption, possibly using cached keys, for all traffic, combined with endpoint authentication (and maybe multiple levels, like SSL, SSL-EV, SSL-Real-Authentication-By-Humans) on top of that. Ideally, as close as possible as end to end, but if some security wasn't end to end, it might still be useful (i.e. various wireless and wired lan security protocols).

Don't forget too that most browsers will poll the user whether to accept a self-signed cert for the page the user's trying to load, but will simply fail when a service in that page tries to pull data over SSL from a domain with a self-signed cert. Flash, JS, etc.

I've been experimenting recently with spreading out databases geographically and letting clients (and to a lesser extent, DNS) do the bulk of the load balancing on data-intensive projects. I've gotten some great results. But right now, users would have to pre-visit a page at each data site and approve it in the browser. Or I could get a massively expensive wildcard cert and then make A-records for each of those sites, but I'd rather just access them straight through their IP addresses for speed.

The whole thing just irks me. All I want to do is make sure this line is encrypted between the end user and their ISP. That should be mandatory these days; but instead I have to pay for a cert on every single DB server?!

All I want to do is make sure this line is encrypted between the end user and their ISP

No you don't. What you want is to make the line secure. Encryption alone does not make a secure line. Period.

Your definition of "worthless" seems pretty hyperbolic. It would protect against some attacks, just not all attacks. The status quo for most pages is to protect against no attacks, so it would be an improvement. Nobody is suggesting that we should do away with verification — but for pages where we aren't doing verification anyway, that doesn't mean we should do away with encryption too.

I think what everyone is missing in this argument is that, with certificate issuers like GoDaddy out there, identity is no longer certain.

At the speed that they turn around certificates, their really can't be much verification going on if any.

That's definitely true. Basic SSL hardly amounts to verification beyond the ability to find a valid credit card, yet browsers will accept the generated certs without a question.

To the OP's point, I'm perfectly happy to generate self signed certs, but I find that browsers make using them more inconvenient than necessary. That's the part that seems a bit conspiratorial to me. It wouldn't be hard at all to pop up a very clearly worded message "this is a self-signed certificate with fingerprint xxx, would you like to accept it [once] [every time]". Safari and Firefox aren't too far far from this, but I find chrome and IE to be obtuse at best.

I remember reading about something like this before (I'll try to find the article if I can). Basically, the reason for verification being so pricy is partially based on the illusion that this is really worth something.

An example (from the article): banks used to build enormous, unreasonably large buildings with pillars and impressive entranceways. People were more likely to trust a bank that could afford such a building because it showed that they would be there for a long time to come.

Similarly, if a website is willing to pay to be verified then it indicates (at least to me) that they didn't put up the site on a whim. They're in it for the long term and this is (supposedly) backed by a company I can trust.

Because if I'm on your wifi in your garage, I can spoof a site that has signed, unverified certificates and steal logins just as easily as if it were over the clear.

All I have to do is drop a machine on the network, say it's paypal.com and give it my own self signed SSL. Your computer looks on the network, finds paypal.com, pulls it up and you just implicitly trust the self signed SSL.

Encrpytion without verification is just security theatre.

so... how about browsers warn when they're pulling a an address off a DNS they've never heard of, and that isn't listed and isn't verified? Wouldn't that be a much saner way of dealing with the problem?

http://www.thoughtcrime.org/software/sslstrip/

DNS has nothing to do with it. They can arp-spoof your machine into thinking their machine is the gateway. Then all your traffic goes through their machine. If you don't verify certificates, then they could just present you a self-signed cert that they used to decrypt your requests, then re-encrypt them and forward to the real site. If your browser didn't warn you, you'd never know.

Seriously, watch the video. Even though your browser warns you, you're still very vulnerable. If you just type bankofamerica.com, anybody on your network could easily trick you in to divulging your password. You have to type the "https" in yourself and trust that your browser verifies certificates correctly.

edit: wrong link. =(

You're just continuing to increase the number of things you have to trust implicitly though.

Reply on news.ycombinator.com