There's nothing cryptographically wrong with SSL (TLS and SSL are mostly synonyms in modern systems that disallow SSLv1 and SSLv2). SSL is actually an example of a cryptosystem done very right, which has survived and adapted to 15+ years of attacks. If you read the protocol, you will see lots of places that seem clunky, and almost all of them are countermeasures to older attacks.

The fact that a protocol with the same objectives as SSL that you wrote today would be far simpler and more straightforward than SSL is evidence of how important it is to use SSL, because you are not going to think of all the attacks that people like Paul Kocher thought of when they reviewed and modified the protocol.

As Thomas said, I was treating "SSL" and "TLS" as synonyms.

There are two major problems with SSL:

1. It's very complex and has a lot of optional components an attacker can select. This means that (a) it's very likely that SSL implementations will have bugs; (b) it's very likely that those bugs won't be triggered in common use, and will thus tend to remain unfixed; and (c) if an attacker can find such a bug, he can probably trigger it.

2. It relies on a very large number of single points of failure -- namely, Certificate Authorities. CAs screw up all the time, and an attacker only needs to find one screwy CA in order to pretend to be whoever he wants.

In many situations SSL is the best option available; but that doesn't mean that it's a good option, only that it's the least bad option.

Thanks for the information!

Actually I think I've read something about the different levels of SSL. I suppose it's possible to somehow limit the available modes, to avoid exposing vulnerabilities.

an attacker only needs to find one screwy CA in order to pretend to be whoever he wants.

- What's a screwy CA, and how does the pretending work? .. If it's possible to describe roughly.