[moobot]

My biggest complaint with the SSL CA chain of trust is the way that self-signed certificates are (mis)handled. The connection is still an encrypted, "secure" connection to the server; it's the server's identity that is in question, and there's rarely any distinction made to the user about that.

I don't want to have to pay or verify my identity to run my own SSL-secured mail server, IRC bouncer, or similar service. Why should I need to? But if I don't, then just about every SSL client in the world falls down and sucks its thumbs or screams bloody murder at me because my certificate isn't signed by the holy gatekeepers...

[tptacek]

No, this is pretty much dead wrong. An SSL connection set up under a self-signed cert is not "secure". Authentication isn't a feature of a secure channel, it's a requirement. Without it, marginal effort by an attacker allows them to silently, quickly, and transparently decrypt your traffic by inserting themselves in the middle.

People on HN can and do argue about this until they are blue in the face, but the fact of the matter is that authenticated connections aren't just a special "bonus" that SSL provides beyond encryption. Every secure encrypted protocol makes arrangements to authenticate keys; this is the same thing that makes your first SSH connection to a new server insecure (demonstrating that problem used to be a sport at security conventions).

[moobot]

If I'm verifying the fingerprint of the server's certificate, is that not doing the same thing that the chain of trust would be doing?

[tptacek]

Nobody is really verifying the fingerprint of the server's certificate, but if you are, fine; you and I are talking about two different issues. You're talking about your own homebrew setup that uses the SSL protocol and manual certificate verification (incidentally, just set up your own CA and forget about the fingerprints; it's not hard). I'm talking about Internet-scale secure web connections to banks.