Security Experts:

Was SSL3 killed by a POODLE? Surveys says…Maybe!

When presented with a glass that is filled halfway, an optimist will say it is half full. The pessimist will say the glass is half empty. The engineer will say the glass is twice as big as it needs to be.

Is it possible to apply this maxim to global SSL patch rates? Let’s take a look at the most recent SSL vulnerability: POODLE (CVE-2014-35660).

When POODLE was announced in September 2014, it marked the beginning of the end for the old SSL3 protocol. At the time, about 98% of HTTPS web servers supported SSL3. There had been speculation about weaknesses in the SSL3 protocol (which had been superseded by three versions of TLS: 1.0, 1.1, and 1.2), but nothing concrete enough to actively discourage its use.

POODLE changed the situation. Here was a specific, repeatable protocol vulnerability that could theoretically recover sensitive session data (web cookies) from a browser in seconds. Unlike Heartbleed, which affected specific implementations of SSL, POODLE was a protocol vulnerability, which meant that it affected all servers that supported SSL3. The good news was that the solution appeared simple and would require no code changes: just disable SSL3 in your server configuration file, right?

It’s been five months now. Can we stop saying SSL and just start saying TLS? Has the Internet been secured against POODLE?

The answer is, of course: kinda.

Data from Ivan Ristic’s SSL Pulse project show that approximately 50% of the Internet has disabled SSL3 in the months that have passed since POODLE. The optimists will think, “Wow, that’s about 10 million sites that have been modified, that’s impressive! Great job everyone.”

Statistics of SSL3 Support After POODLE Vulnerability



: Source - SSL Pulse

The pessimist will think: “Why wasn’t it 100%?  People didn’t even have to patch their code fer chrissakes, just turn a knob!” It would be nice if we could characterize the miscreants who aren’t part of the solution so that we could claim a moral security high ground. For example, it would be handy to say that, in general, sites still supporting SSL3 today are abandoned sites that no one cares about—but that’s not really true.

Even though sites can disable SSL3 very quickly, there are legions of SSL clients out there that cannot. They are stuck at SSL3 and may never get upgraded. It is for these legacy clients that many sites are still supporting SSL3. One site in particular is interesting: Google. Google reported and publicized POODLE, yet it still negotiates SSL3.

But even if there were no legitimate reasons to continue using SSL3, we would still see a lot of it out there. Here’s the thing. In the first year, patch rates for an arbitrary high-severity vulnerability fall off around 50%. It’s not just POODLE, it was the same for Heartbleed, and for HashDos before that. The decline from the initial 50% to zero is asymptotic. As an example, look at SSLv2, which has been absolutely, completely, irrevocably broken for over a decade, and yet there are still millions of websites that support it.

What does this mean looking forward?

If you haven’t gotten around to disabling SSL3 on your site yet, honestly, it’s not a huge rush. An exploit was never seen in the wild for POODLE. And all the modern browsers are disabling SSL3, which should protect the users. Even though there’s been the initial dropoff from 98% to 50%, we’re going to see SSL3 server support around the Internet for years to come.

So, if you were hoping that we could finally stop saying “SSL” and move on to the “new” acronym, TLS, the answer for that is no. Just ask Ivan Ristic, whose recent book title had to include both: “Bulletproof SSL and TLS.” There is a good chance we’ll always be talking about SSL, no matter when SSLv2 and SSLv3 finally go extinct.

view counter
David Holmes is an evangelist for F5 Networks' security solutions, with an emphasis on distributed denial of service attacks, cryptography and firewall technology. He has spoken at conferences such as RSA, InfoSec and Gartner Data Center. Holmes has authored white papers on security topics from the modern DDoS threat spectrum to new paradigms of firewall management. Since joining F5 in 2001, Holmes has helped design system and core security features of F5's Traffic Management Operating System (TMOS). Prior to joining F5, Holmes served as Vice President of Engineering at Dvorak Development. With more than 20 years of experience in security and product engineering, Holmes has contributed to security-related open source software projects such as OpenSSL. Follow David Holmes on twitter @Dholmesf5.