@Anonymous:

Encryption without identity is *nearly* meaningless, since you encrypt to prevent interception, but without identity, the attacker can intercept at will and you’ve got no way of knowing. Now, identity is different than “I paid a CA to verify my domain ownership” – a self-signed certificate can provide identity in that it can be the same from session to session. This is the SSH, or “Key Continuity Management” approach – treat new self-signed certs as valid-but-unattested, and then watch to see from session to session whether the key stays the same, and only make noise when it changes. I opened bug 398721 to ask whether this is something we want to support or not, and I would encourage you to chime in if you think it would be valuable.

We sort of have KCM right now for self-signed certs, but we have it in the annoying SSH way. First time: error page. Add an exception though, tell us you trust this cert, and it’s smooth sailing unless someone swaps that cert for some reason, in which case we make noise again. That’s what SSH does and geeks are basically accustomed to it, but it’s still more invasive than proper KCM, and maybe needlessly so.

The thing is, until KCM is in place, until you get to a point where you are remembering the certs for places you’ve been, it’s upsettingly dangerous to just accept self-signed certs quietly, since it allows a man in the middle attack to pretend to be your bank, right down to your https bookmark. Your bank presented a CA-verified identity last time, if we can remember that, we can be much quieter by default, and only get agitated when your bank’s cert changes; without that memory for what happened last time though, we have to rely on the other useful information we have, which CA-signed-certs are, and which self-signed-certs aren’t.