

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

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?<p>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!<p>GeoTrust still wants to see $5M in net worth to "make" you as a CA. What a racket.
======
nbpoole
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.

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

~~~
nbpoole
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.

------
rdl
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.

------
Lanzaa
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.

~~~
rdl
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).

~~~
noduerme
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?!

~~~
Locke1689
_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.

------
elroyjetson
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.

~~~
easel
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.

------
brimpa
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.

------
drivebyacct2
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.

~~~
noduerme
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?

~~~
adamtj
<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. =(

