The reason your browser goes "ZOMG" when it sees a self-signed certificate is that there is no way to distinguish the "'avar made himself a handy self-signed certificate" case from the "someone has substituted a random certificate into my Bank of America login". Think about it.
Long story short: don't hold your breath waiting for browsers to chill out about self-signed certs.
Bank of America has a CA signed cert, so when you go there you display a golden "YOU ARE SECURE, CITIZEN" banner at the top with a lock icon etc.
But if someone doesn't have a CA signed SSL cert you treat it no differently than normal HTTP traffic.
Then you train users not to submit their financial information to sites that don't have a CA signed SSL certificate (as indicated by the giant "YOU ARE SECURE, CITIZEN" banner).
You have to do that anyway, when I go do my online banking I visit a plain http site and then click on my private banking link that takes me to a https site.
The easiest way for a MitM to spoof that would be to just direct the user to a plain HTTP site when he goes to do his private banking. So even today users have to understand that they must submit this sort of data over SSL and that the cert involved has to be CA-signed.
Think harder. How does Firefox know, when it sees a self-signed certificate, that that site wasn't supported to have a certificate signed by a CA?
It doesn't, and can't.
If the "ZOMG" warning --- which, let's just keep calling it that, because I think it's funny that you think one of the most important pieces of UI in Internet security is a "ZOMG" measure --- didn't exist, attackers could substitute their own "self-signed" certificates for Bank of America's Verisign-signed cert when hijacking www.bankofamerica.com.
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.
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.
> 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.
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.
There's a few problems with your hypothetical, from the browser implementor point of view:
1) "Then you train users..." -- if your security mechanism relies on this you have already failed.
2) In the attack case, the user would have to look for the absence of an indicator. It's very hard to notice absence of an indicator as a sign of danger, especially if there are are many normal situations where it's fine for the indicator to not be there. Imagine this design for a car engine warning light:
- Normally it's always off.
- Whenever you turn left, it goes on if everything is fine.
- However, if your engine needs service, then when you turn left, the warning light stays off.
Do you think this would do a good job of alerting people to engine trouble? Your suggestion is the same thing. It's hard to train yourself to notice the lock icon not appearing, even if you are very security-aware (which most users are not).
3) If the user has a bookmark, Top Sites/Speed Dial page, or URL autocomplete entry for the SSL URL to their bank, it's hard to redirect them to vanilla HTTP. So in fact, silently accepting self-signed certs creates more MITM opportunity.
4) Srict Transport Security will likely close the remaining gaps in #3 (e.g. typing the domain name in a fresh browser instance) over time.
That's not strictly true. It doesn't have to be like that. Why can't it be handled like SSH? You can cache the certificate and raise the ZOMG flags when a known site changes behavior.
As it is today, browsers scream bloody murder and then require you to store a permanent security exception for the site.
It is strictly true that in the HTTPS security model, there is no difference between a self-signed certificate and a forged certificate. The browser can't know which sites are supposed to have real certs and which are supposed to have fake ones. Secure channel protocols are tricky, and this is one of the reasons why.
You propose key continuity as a (drastic) extension to the HTTPS security model. I'm ambivalent about key continuity. It sort of works with SSH, but also used to be one of the more often-exploited weaknesses with that protocol, before we entered an 8-year span where memory corruption flaws in sshd were an even easier way to mess with it.
Key continuity works when you have long-term relationships between clients and servers. It doesn't work, at all, when multiple people share machines (as at kiosks), or when people change machines or reinstall. Also, unlike cookies, which gracefully repopulate themselves when you clean them up, the "HTTPS key continuity" model requires you to store certificates, for every website you ever talk to and every site those sites depend on, forever.
Instead of the (I think kind of hacky) key continuity idea, browsers should just come up with a way to allow users to opt-in easily to new CA's.
Meanwhile, it's pretty annoying when people talk as if the Firefox bogus-certificate UI is an affront to everyone's intelligence. No, without that dialog, HTTPS wouldn't work.
It's because all these self-taught PHP developers think it's some kind of affront to have to pay $25 for a CA-signed certificate for their shopping cart application.
Long story short: don't hold your breath waiting for browsers to chill out about self-signed certs.