Nails in the Coffin: What put SSL in the grave?

In light of new PCI-DSS requirements stating that SSLv3 no longer meets the specification for “strong cryptography” prescribed by PCI standards, we wanted to give you a brief history of how the industry got here and why SSLv3 is no longer considered secure.The first stop on this adventure in security history takes us back to 1995, when Netscape Navigator reigned supreme, and you would be lucky to be cruising at 28.8kbps. Netscape was the first to implement the Secure Socket Layer (SSL) protocol inside a web browser to allow for HTTPS communications. The first public release of the SSL protocol was SSLv2 in 1995. SSLv3 was released just a year later due to security flaws already discovered within SSLv2. (1.0 had enough security flaws that it was never publically released.) I want to take a moment here to note this: SSLv2 was the first public version of the SSL protocol; it was superseded in 1996, and I am still seeing servers that support it during penetration tests today. There’s backwards compatibility, and then there’s this.An interesting note to inject here is that cryptologists in the US had already noted problems in Cipher-Block Chaining (CBC) ciphers before SSL ever started using them. At CRYPTO ’94, UC Davis professor Phillip Rogaway presented work which outlined theoretical attacks against CBC, which were later published in a paper in 2000. While it may be dry, this paper opened the landscape for future researchers.In 1999, Transport-Layer Security (TLS) v1.0 was released, as an upgrade over SSLv3, with the option to downgrade to SSL. TLS version 1.1 was released in 2006, and included protections against CBC attacks which SSL versions 2 and 3 had already shown weakness to. TLSv1.2, released in 2008, removed the protocol’s ability to downgrade TLS sessions to SSLv2 because of SSL’s growing litany of sins.Without taking the time to outline every exploit in detail, we want to explain a few that grabbed the security community’s attention:

• May 2011 – BEAST - CVE-2011-3389 - Browser Exploit Against SSL/TLS - Paper BEAST allows an attacker to retrieve sensitive data about the user’s connection, such as a cookie or other token that may be transmitted in an HTTPS request. To exploit this, an attacker must be able to inject content into the same origin as the targeted website, must be able to sniff/intercept the user’s communication with the server, and the SSL cipher being used must be a block cipher.
• September 2012 - CRIME - CVE-2012-4929 - Compression Ratio Info-leak Made Easy - Paper Compression before encryption is a common programming mistake, and in this case, allows an attacker to leak the contents of an encrypted connection by modifying the contents of the request many times; each time observing the length of the response to determine how it was compressed. Most major browsers have removed support for SSL and SPDY compression, which has effectively mitigated this vulnerability.
• February 2013 - LUCKY13 – CVE-2013-0169 - Lucky Thirteen – Paper Lucky13 is an attack which affects both SSL3.0 and TLS1.0. It is a padding oracle attack against CBC ciphers. This Man-in-the-Middle attack is considered to be more efficient than either BEAST or CRIME.
• August 2013 - BREACH – CVE-2013-3587 - Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext - Paper BREACH is very similar to CRIME, in that it is dealing with compression and encryption, however instead of attacking SSL-level compression, BREACH attacks HTTP-level compression. This attack requires that the web application reflect some piece of user-controlled data, and that a token (e.g. CRSF), must also be present in the HTTP response body. It is estimated that this attack can be completed in under a minute, but depends on the size of the secret to be guessed.
• September 2014 - POODLE - CVE-2014-3566 - Padding Oracle On Downgraded Legacy Encryption - Paper POODLE is another padding oracle attack against SSLv3 when CBC ciphers are used. This attack also requires the attacker to be man-in-the-middle on the user’s session to the webserver so that they can intercept and modify the client’s requests. This attack requires that the attacker make at most 256 requests per character of secret to be leaked.

Those are just a few of the nails in SSL’s coffin – what are some of the details we can glean from these? Each of them allowed an attacker to leak details about the user’s communication with the webserver. Some of them required the page to reflect some piece of attacker-controlled data. Most of them required that the attacker be in a privileged position within the network relative to the targeted user – That’s a key point to take away as well – these are attacks against your users, not necessarily against the server itself, however they could be used as a means to that end. Consider the following attack scenarios:You are an IT admin for BigCorp Inc, and you stop at Starbucks every morning for coffee. There’s an attacker waiting there, listening on the wireless network. Your phone automatically joins the wireless, because you’ve connected here before, and then authenticates to your OWA server over HTTPS to retrieve your latest emails. The attacker intercepts this connection, and starts running one of the above attacks. By the time the barista is done making your vente triple latte, the attacker has already stolen your cookie, logged into OWA as you, and is searching for passwords or other sensitive data. Perhaps instead of OWA, you need to check out something on the corporate network, so you connect into your SSL VPN. Now, the attacker is logged into the VPN with your level of access, and is able to create tunnels to protected systems. This is the real danger with attacks like these – targeted user attacks to facilitate further access; not wholesale exploitation of end-users.Where do we go from here? Well, TLS 1.3 is currently in draft, so we will be seeing some more great changes soon, such as the complete removal of both compression and re-negotiation from the protocol, in order to prevent vulnerabilities similar to those which have occurred in the past. If you’re wondering at this point whom to trust when it comes to which SSL ciphers you should be enabling on your server, we currently suggest following Mozilla’s recommendations -- as a browser vendor, they are well-placed to help make suggestions that take both browser compatibility and security into account. We here at NetWorks Group hope this has given you a better understanding of why SSLv3.0 is dead, and why you need to be moving all of your servers to TLS 1.2 as soon as possible.Addendum: As mentioned earlier in the article, new SSL/TLS vulnerabilities come out every few months, and indeed while we were getting this article ready to be published, two new vulnerabilities called SKIP-TLS and FREAK were disclosed. Check out the new research here.As of this writing, we are anxiously awaiting YET ANOTHER SSL vulnerability (CVE-2015-0288) to be released as well...details yet forthcoming...

Topics: Ethical Hacking, Information Security, Security Architecture Review, Penetration Testing