This is not a hard concept to understand. You can't have secure encryption without trustworthy keys. Without the "authentication" functionality of SSL, you can't trust keys, because a man in the middle can simply swap them out of your session. When we say "you can't have encryption without authentication", we mean that every mechanism for agreeing on an AES key with a counterparty over the Internet relies on some form of authentication.
I understand the concept. I don't understand why you're pointing out the obvious to me, nor how your reply is a relevent response to my post.
I'm asking why an insecure SSL connection is worse than an insecure HTTP connection. If they are both completely insecure, why does Firefox turn one of them into a compete UI nightmare?
If the reasoning is that https:// somehow implies security, then the obvious and sensible solution is to create a new prefix for insecure SSL sites such as httpu://, and throw up a warning page when visiting the https version that links to the insecure SSL version.
I see this as being preferable to the awkward and annoying way Firefox treats self-signed certificates at the moment. I also suspect that had Mozilla taken the lead, the major browsers would have followed suit.
The plain HTTP connection doesn't claim to offer any security. You know not to give it your credit card number or password. What trust can you extend the "poorly encrypted" protocol?
The fact is, even if the browser so much as displays "https" in the addressbar, you are giving the unknowlegable user a form of positive feedback when none whatsoever is warrented. Strong netagive feedback is a much more appropriate solution.
You would use it because it makes encrypted traffic on the network the norm. It makes it impossible to decipher your traffic without an active deliberate security attack instead of a passive sniffing session. It means when a traffic sniffer happens on your traffic they will get (plain text, encrypted data) and they won't know whether the encrypted data is 'good' or 'bad' and will have an easier time with the plain text - the "just have to run faster than the other guy" approach.
It filters out some kinds of common attacks, e.g. most (all?) uses of Firesheep session-cookie snooping at coffee shops. Of course, for us nerd types https isn't really necessary for that, because I can just websurf over an ssh -D proxy to a VPS, to encrypt the coffee-shop side of the link.
