But what kind of technology would think self-signed certificates could ever be better (let alone not infinitely worse) than no encryption at all? That sounds like hell. We should call this new, purely hypothetical protocol, SSHell, or SSH for short. Not that such a thing would ever be used by anyone, of course.
(Yes, I know that technically SSH uses key pairs; but they show you the key, you choose to trust it. Same real chance of a MITM as with a self-signed SSL certificate. But at least you (and others) can now detect when there's a change in who's sending your data, and choose who to trust yourself instead of relying on Mozilla to pick who to trust, like they did CNNIC.)
The trust-on-first-use model makes it hard or impossible to regenerate certificates. If you don't have that problem with SSH it is because you connect to your own servers only.
There have been several attempts for a distributing certificate checks on the wider Internet, but they all come with their own set of problems.
Alternately, you do have that problem with SSH, and you work around it by scratching your head, saying "oh, right, because I switched hosts/reinstalled the OS/ran that mysterious command," and then nuking the key entry.
Alas, this does not scale well into the HTTP realm.
What about trusting not the key itself, but the CA which signed the cert - whose cert came within the cert chain upplied by the server ? Then everyone could get their own "root" CA and renew the certificates to their heart's content.
The problem is it requires knowledgable, involved users if the private key ever needs to change. If I suddenly get an SSH key error on a company server, I can just ask the sysadmin if it's legit. That wouldn't really work on sites intended for the general public - users would just click "ok" on every error or they'd be scared off.
Although I think it could work great on sites intended for small numbers of clueful users. (Web-based admin consoles, etc.) But something else is needed to make HTTPS usable by average people.
Oh, certainly. I agree completely with everything you said.
But right now, the situation is that I go to arstechnica.com, which offers no encryption whatsoever, and Firefox just loads it up like nothing's wrong.
Yet I go to self-signed.example.com, and Firefox presents me with a giant warning screen, followed by a pop-open warning dialog, where I have to click to confirm the security exemption, add the certificate in, and OK another scary prompt. It's so over the top that laymen probably think proceeding will give that site complete interception control over every site they ever go to again in the future.
That's absolutely ridiculous. Worst case, self-signed should be treated like HTTP is now. No padlock, no green address bar.
People who are knowledgeable and able to confirm self-signed certs should be able to very quickly and very easily do so. This will greatly help with developing inside the local network, or for small communities that know what they're doing and don't want to pay hundreds of dollars for wildcard SSL certs.
A self-signed certificate is significantly better than no encryption whatsoever (even if you're being phished, you at least now know that no other phisher has viewed or altered the response in transit), but browsers for reasons that defy explanation treat them like they're worse.
There was even an MTA (exim maybe?) that on seeing an untrusted certificate would actually downgrade to plaintext in some circumstances. Great job, guys; you really dodged a bullet there...
(Yes, I know that technically SSH uses key pairs; but they show you the key, you choose to trust it. Same real chance of a MITM as with a self-signed SSL certificate. But at least you (and others) can now detect when there's a change in who's sending your data, and choose who to trust yourself instead of relying on Mozilla to pick who to trust, like they did CNNIC.)