Ask HN: It's 2011. Why is web encryption still coupled with verification?
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.
22 comments
[ 5.0 ms ] story [ 64.4 ms ] threadIn 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.
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.
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.
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).
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?!
No you don't. What you want is to make the line secure. Encryption alone does not make a secure line. Period.
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.
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.
If you're being MITM attacked, you will still see trusted.example.com in URL bar.
At the speed that they turn around certificates, their really can't be much verification going on if any.
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.
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.
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. =(
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.