The warning says, "Here is a site that claims to be secure. Maybe you thought it was secure, maybe you didn't. Either way, the site is not secure. DO NOT ENTER YOUR PASSWORDS AND CREDIT CARD NUMBERS HERE."
The warning is vibrant because the condition it reports on can be created by an attacker on any SSL connection. That stupid warning might be among the top five security mechanisms on the Internet.
Why is a self-signed site insecure? Why isn't an HTTP site with a credit card prompt equally insecure (please, don't try to tell me that users look at the yellow bar -- we all know from direct experience that they don't)? Why is a properly certed site known to be secure for password use and credit card transactions?
You're assuming all kinds of facts not in evidence. My point was simply that the FireFox tradition (now enhanced) of warning about secure transfers to unverified sites was dumb: it creates a clear incentive for sites not to use HTTPS, so as not to scare their users.
This clear incentive you speak of is not in evidence on the actual Internet: find a site any of us have ever heard of that takes a credit card over a bare HTTP connection by default.
Self-signed certificates are "insecure", if you want to use that word, because there is no way to verify them. If you're Bob sending your certificate to Alice, Alice has absolutely no way to tell if she's seeing your cert or Mallory's.
Self-signed certs get used in non-HTTP apps, and in internal apps, because an out-of-band mechanism (thumb drives, key continuity, etc) is being used to distribute the certificates. If Alice already has your cert, and all you have to do is prove you hold the privkey for it, you and Alice have no problem.
Of course, if you think about this for 5 more seconds, you quickly realize that nobody on the Internet has your cert already, and without Verisign to break the tie between you and Mallory, you're totally fucked.
Imagine your bank's certificate says that they run their web site. If one day the certificate changes to a self-signed one, you have clear evidence of a man in the middle attack.
What should the browser do in this situation? Someone pointed out that an HTTPS connection with an unknown self-signed certificate identifies the site just as well as a plain HTTP connection, suggesting that we should treat both connections as equally insecure: so simply hide the yellow bar.
please, don't try to tell me that users look at the yellow bar
Lets imagine a user who never expects the yellow bar. In the example above, when there is strong evidence of a man in the middle attack, the only warning the user gets is that a UI element which they don't notice is unexpectedly hidden.
You really want to warn the user in this situation, so Firefox gives them a big error message and makes them take positive action (adding the unverified, possibly malicious, certificate to their list of fully trusted root certificates) before they can get past it. That is fair enough.
But then there is the kicker. The browser can only tell that a certificate has changed if it has already recorded the old one. It can't distinguish between a site which has always had a self-signed certificate and one which just happens to have one today, unless it recorded the certificate yesterday. So it treats both as man in the middle attacks, which explains why Firefox will always give you a warning about unverified certificates until you verify them yourself.
Sure, but couldn't the man in the middle just as easily provide a non-SSL server? Or are you assuming that the user is accessing a bookmarked https:// url (in which case the browser should already know the correct certificate)?
The warning is vibrant because the condition it reports on can be created by an attacker on any SSL connection. That stupid warning might be among the top five security mechanisms on the Internet.