It’s almost impossible to deploy SSL (and its successor, TLS) in a way that leaves everybody actually secure. SSL is great at providing a false sense of security, and not too much else. But, HTTPS (which is a variation of the HTTP protocol that enforces the use of SSL) is even worse, because it is impossible to protect everybody with it.
First, let’s look at applications built using SSL. With most APIs, you can connect easily, with very little code, but the connection isn’t validated. You just connect, and you have no idea who you’re talking to. The server has even less idea. Usually you do some sort of login jig after that, but there’s no guarantee that someone isn’t sitting in the middle.
Well, maybe you’re a smarter developer than that, and you do certificate checking. It’s rare, but it does happen. Or maybe you’re using an API that does some certificate checking. There are still a million ways to get shot in the foot. Many apps check to see that a server certificate is actually signed, but don’t validate anything else about the certificate. Many apps check all the data in the certificate but allow self-signed certificates—hey, the bad guy can self-sign a certificate. Many apps give you the option to trust or even revert to no encryption if something fails, and people never expect that the worst will happen to them.
The makers of HTTPS were smarter than that. The HTTPS protocol specifies the validation that has to happen, and it is all the ...