Mostly a problem of trust, broken CRL and bad programming then?
So it seems that most of the problems here are either as a result of -
1. Sloppy string validation in Common Names and URL bars
2. Massive proliferation of "trusted" entities who may or may not have good security practises or even be trustworthy at all
3. Broken revocation methods
4. Un-revoked certificates using obsolete hashing or encryption methods
I've been working with SSL/TLS for a bunch of years now and 2, 3 and 4 have been obvious for a LONG time. 1 is more interesting because you would have thought you'd be extra, extra careful in a security application, if only because the programmers are working on security systems!
Apart from CN validation though, the problems here are HTTPS problems, not SSL or TLS problems. SSL has many wider applications than securing the web. These frequently do not involve any public authority trust at all, have manual revocation methods, cipher suite restrictions and no plaintext-to-encrypted bridge.
The fundamental difficulty here is that the problem is almost impossible to completely solve. A little like DRM (which can be summed up as "how do I give the content and the key to someone, but prevent them using the two together in ways I dislike?"), the trust problem comes down to "How do we establish a relationship of trust between two parties that have never met?". The solution we have been using so far is to involve a third party that the user has never met either. When there were only a handful of these third parties it was perhaps not too much of a stretch; now I look at firefox and there at least 50 "authorities" each with a couple or more root certificates. I know several of them have issued bad certificates in the past and others have been compromised. But if I get rid of them I lose the ability to 'secure' a lot of comms, though secure is the wrong word. Tricky.
tl;dr - The HTTPS infrastructure is in need of a lot of work. SSL/TLS itself less so.