So, what really breaks SSL?
After years of being ignored -- which is an unusual situation for the protocol that secures the Web -- SSL became the focus of the interests of the security community at some point in 2008 or thereabout. From then on, a couple of months wouldn't pass between discoveries of one flaw or another. Most problems were with the way SSL is implemented, with one notable exception (the SSL/TLS renegotiation gap) in the protocol itself. As a result of this attention, the effective security of SSL has been continuously improving.
However, for an average web site, the security of the communication channel is rarely compromised by attackers using advanced exploitation techniques. On the contrary, the compromises virtually always come from the flaws in the way SSL is deployed. These problems are created by those implementing and maintaining web sites. And, in most cases, they can relatively easily be fixed.
In the most recent round of our SSL research, SSL Labs focused on programming and deployment errors that compromise SSL security even when SSL is properly configured, with strong cryptographic primitives and up-to-date libraries. None of these issues are new: failure to use SSL (when there is something worth protecting), mixing of encrypted and non-encrypted areas in the same site, mixed page content, insecure session cookies, login forms delivered or submitted over HTTP, and so on.
Although we initially started with the idea to discover how many sites have weaknesses, we discovered that the situation is so bad that we ended up looking for sites that do not have weaknesses. And the number of such sites is very, very small. (You can find the details if you download our presentation slides.) Sites with support for Strict Transport Security are preciously rare.
Why are the weaknesses so prevalent?
On one level, problems come from the way web "standards" have evolved. Slowly, over many years, and without a coherent security strategy. The truth is, it is very easy to break SSL with mistakes that occur on the HTTP level. Thus, our challenge here, short term, is that of education -- making developers aware of these issues.
Businesses are not exactly rushing to secure their sites, either, because there is often little incentive for them to do that. Their money (of which there is never enough), is almost always "better" spent doing other things. As a result, companies today spend on security only when they can't avoid it.
Long term, our only option is to incrementally improve our technology stack to build communication channel security in. Once the option to communicate via plain-text is taken away, there will be no way to subvert SSL. This is a tough goal to achieve, but the journey has already started. A security conscientious site operator can today deploy state of the art SSL configuration (which isn't that difficult, by the way), and achieve pretty good SSL security. Over time, the hope is that we will migrate to better communication protocol that embed SSL in, and that, once communication security becomes invisible, we won't have to worry about it any more.
