Hacker News Reader

Comment by avar | Hacker News Reader

Yes, it doesn't, and can't. But I'm saying that it doesn't matter.

When people visit "foo-bank.com" the easiest way to do a MitM is to simply do a http MitM. Then you don't have to forge any SSL certificates, or rely on the browser not yelling enough.

The only way to guard against that is to train users to recognize that they shouldn't be sending money through a non-CA SSL connection, as indicated by their browser with a friendly "Secure" icon somewhere.

Thus, if browsers treated non-CA signed SSL connections just like normal HTTP connections, i.e. just used encryption, didn't present any "secure" banners etc. you wouldn't make things any less secure.

Non-CA signed SSL traffic is just as secure as unencrypted HTTP traffic (i.e. not), and browsers should treat both of them equivalently.

View on HN

This is why your bank doesn't let you make withdrawals from your account on port 80.

You need to keep re-reading this sentence: there is no difference to the browser between a TLS connection bearing a self-signed cert and a TLS connection that was supposed to bear a CA-signed cert but isn't. It can't tell the difference.

"But that untrusted connection is no less secure than an HTTP connection!", you retort. Wrong. The HTTP connection isn't lying to you about how secure it is. The HTTPS connection with the bogus cert is, as far as Firefox is concerned, lying. And for most users, most of the time, it's right. Something is wrong with the connection.

I understand that it drives you nuts that there is collateral damage to this security warning. Yes. There is collateral damage. You get a very noisy exception dialog even when you wanted a self-signed cert. But the alternative to that dialog allows attackers to spoof Citibank, and the browser vendors have all decided that your self-signed cert is less important than Citibank.

> This is why your bank doesn't let you make withdrawals from your account on port 80.

It doesn't matter that my bank doesn't allow withdrawals on port 80 as long as a MitM allows that, and you can't guard against that unless you train users to expect CA-signed SSL sites for things like that.

> You need to keep re-reading [...]

I've already read that and replied to it at: http://news.ycombinator.com/item?id=1609818

> The HTTP connection isn't lying to you about how secure it is.

A non-CA HTTPS connection isn't lying to me, it's purely a matter of implementation how you treat that sort of thing. You seem to think that certification and encryption are inseparable, they aren't.

You can have SSL encryption presuming that you're talking to a known-good party, while also having the ability to initiate connections to CA-signed parties.

> [...] There is collateral damage.

Yes, but there's no need for it. Browers can decide how they present SSL, if they consistently present a big "You're secure" banner when talking to CA+SSL sites and users get used to that when transferring money they'll spot that something's up when it's missing.

there is no difference to the browser between a TLS connection bearing a self-signed cert and a TLS connection that was supposed to bear a CA-signed cert but isn't.

As long as my browser can tell the difference between a Citibank with a CA-signed cert and a Citibank without one, why should I care about the exact manner in which the wrong Citibank doesn't have what it should? What makes encryption without authentication so much more dangerous than plaintext?

Edit: You talk about forged certificates a lot. Do you mean that browsers acts as if certificates are for a secret club only, and anyone not a member (CA) but using the technology is infringing? I could believe that, as it jives with how I initially understood the business model. The problem, then, is that non-members like to authenticate too, and it is assumed they will do so via other channels and that their users are technologically sophisticated enough to import the certificates - when the key continuity thing is actually more popular.

Since the browsers check your credentials anyway, I see no point in getting paranoid about seeing an unfamiliar signature. That's only a deception if your guards consider the mere existence of a signature as proof of authorization - that is, if they're human. If they always check, there is no point in bluffing, and so an unrecognized signature should not be considered treachery.

I'm kind of confused by your questions, but: to be valid, a certificate needs to be signed by a CA for whom your browser holds a root CA certificate.

Without authentication, anybody who controls routing, ARP, or the DNS can break your encryption; they just stick themselves in the middle.

The original question wasn't "why is encryption without authentication a bad idea"; it was "why is it worse than nothing". The only thing I can come up with is that some users look for https instead of the newer security banners.

The additional question was "is a non-CA-signed certificate irrelevant to authentication, or is it a forgery" - my opinion would be the former, browsers seem to think the latter.

It is my understanding that adding trusted third parties is possible for the client, but considered to be only for advanced users, and that adding security exceptions for self-signed certificates is unexpectedly common. I further consider the terminology unfortunate (servers with valid certificates are not certified, they are authenticated).

How many people look at the 'https' part rather than the padlocks or large green bars telling you it's secure? I can count the number of those people on one hand.

Reply on news.ycombinator.com