You are here

SSL is dead, long live TLS

Secure Socket Layer – SSL – the connection or transport layer protocol developed by Netscape to help secure the web, is now 20 years old.

The original, never released version 1.0 of SSL dates back to 1994 with the first public version, 2.0, being released in February 1995. This was updated the following year by SSL v3.0 which was a substantial overhaul of the protocol and addressed a number of security weaknesses in version 2.0.

The Internet Engineering Task Force (IETF) then moved to adopt the protocol, renaming it as Transport Layer Security (TLS) and releasing the TLS v1.0 specification asRFC 2246 in January 1999. The changes between SSLv3 and TLS1 were considered to be “not dramatic” – more refinement that revolution – as evidenced by internally TLS 1.0 using a binary version number of 0x03 0x01 (3.1), while the newer TLS v1.1 and 1.2 continue the trend using the numbering 0x03 0x02 (3.2) and 0x03 0x03 (3.3) respectively. TLS’s heritage is firmly with SSL.

Although the changes between SSLv3 and TLS1 were considered to be “not dramatic”, the differences that do exist have suddenly become significant since the discovery of the POODLE (“Padding Oracle On Downgraded Legacy Encryption”) attack. The rather awkwardly named vulnerability (CVE-2014-3566) exploits a feature of SSLv3 when used with block ciphers in CBC (cipher block chaining) mode.

In simple terms, the issue relates to a message being extended with ‘padding bytes’ to make the message length a complete number of cipher blocks. SSLv3 then considers these padding bytes (well strictly speaking, all but the last padding byte which describes how many padding bytes there are) as inconsequential as they are after all, simply padding. The problem with this approach is while the padding bytes are inconsequential to the decrypted message, they are consequential to the encrypted form, and by not checking these bytes, an attacker can manipulate them and by then observing how the server responds to this manipulated message, start to unpick the encryption. Surprisingly, this does not take as many iterations as you might expect, making the attack quite feasible. If you want to get a real insight to how the attack works, there’s a very readable article on Information Security Stack Exchange.

The real issue with POODLE is that it is a protocol error; it’s not a bug in code that can be patched, it’s a ‘bug’ – an oversight – in the protocol, in that it doesn’t check what appeared to be inconsequential padding bytes, but which due to being ignored, can be manipulated to reveal data. The result of this is that any valid SSLv3 implementation will be vulnerable to this attack, consequently to ‘fix’ POODLE you would need to revise the SSLv3 protocol itself, which would get you close to redefining TLS 1.0. Clearly this isn’t going to happen.

Consequently the only sure option to protect against POODLE is to disable the use of SSLv3, or to be very precise, the use of any block ciphers under SSLv3. However, disabling all the block ciphers disables most of the available SSLv3 ciphers and restricts options to RC2 or RC4. These then bring their own issues. To further compound the matter, it’s often not possible to limit cipher suites by protocol within systems that make use of SSL/TLS, and so these ciphers then also become unavailable under TLS where due to differences in the handling of padding bytes, the POODLE vulnerability does not exist. Hence attempting to mitigate POODLE by limiting the ciphers available isn’t a practical solution to the problem.

Removing support for SSLv3 can of course introduce backwards compatibility issues, not so much for modern browsers, but more likely for machine-to-machine interactions which might use older encryption libraries that support SSLv3, but not the newer TLS protocols. Corporate users required to use IE6 and/or Windows XP can use TLS 1.0 and so should not be impacted, although they may need to check their Advanced Settings include the enabling of TLS 1.0.

Although the POODLE attack is based on SSLv3 and is ineffective against TLS, the attack can also impact clients connecting by TLS and so attack modern browsers and clients. This apparent contradiction is caused because the attack can also incorporate a protocol downgrade from a secure TLS connection to an insecure SSLv3 connection. Once the protocol downgrade is achieved, the padding bytes attack can commence. This protocol downgrade is an inherent TLS mechanism to assist in backwards compatibility, but sadly this compatibility now comes with the unintentional side effect of permitting the POODLE attack, even against clients using an established secure TLS connection.

Therefore, to prevent an attack you either need to disable SSLv3 support entirely, thereby preventing any SSLv3 connections including a fall-back, or you need to ensure that your servers recognise the ‘TLS Fall-back Signalling Cipher Suite Value (SCSV)’ (TLS_FALLBACK_SCSV). This is a value passed by the client to the server during the establishment of the session and it used to prevent unintended protocol downgrades. This has the effect of preventing the downgrade of a TLS session to SSLv3 and so prevents an attack against a TLS-connected client. It doesn’t of course provide any mitigation for SSLv3 connections, but it does prevent a TLS-connected client becoming downgraded to SSLv3 and then attacked.

There have also been reports of a ‘second bite of POODLE’. These relate to the exact-same vulnerability and that some TLS implementations fail to check the padding bytes used with block ciphers in CBC mode. This means these implementations are vulnerable as from a padding byte perspective, the implementations are similar to the protocol failure in SSLv3. However, unlike SSLv3, this issue can be resolved by software patches so that the vulnerable service starts to correctly check padding bytes.

All this upheaval in the SSL/TLS world comes at a time when big changes were already pending. The most recent TLS version, 1.2, was released in 2008, 6 years ago, and is expected to be superseded by TLS 1.3 during 2015. TLS 1.3 was already expected to bring big changes and to break backwards compatibility, and the recent POODLE issues will likely reinforce this move. It’s also likely that over the coming years we shall see an accelerated rate of new TLS and associated security releases as Internet traffic moves towards becoming entirely encrypted and more research is done seeking weaknesses in systems already in use. The scale of cyber-crime and data capture being reported daily, amplified by the shockwaves from the Snowden revelations, are all moving towards a much greater use of encryption technologies.

TLS 1.3 is becoming bound-up with HTTP/2 which is based on Google’s SPDY (Speedy) protocol, with both Google (Chrome) and Mozilla (Firefox et al) saying they will enforce TLS 1.3 only on secure HTTP/2 connections. Added to this, version 1.3 is liable to make substantial changes to TLS with it looking likely that it will incorporate:

Removal of support for static key exchange due to the forward secrecy implications:

The rapid turnover and automated update of browsers means that currently in excess of 85% of all browsers would be classified as ‘current’ and so capable of supporting the higher levels of TLS protocol, including the new TLS 1.3 when it arrives. Only a few Corporate desktop build policies maintain older browsers and as mentioned, even IE6 can manage TLS 1.0. However, how prepared are all the site operators and of course it is not simply browsers that use HTTP, but thousands of SOAP and SOAP-like data exchanges over HTTP, plus non-HTTP protocols that also sit atop TLS; we are talking about a much more significant change in all Internet communication as both consumers and suppliers look to secure their services, restrict cyber-crime and address privacy concerns.

So the near future looks likely to see substantial developments in ‘SSL’, although really, we should all educate ourselves to now say ‘TLS’, as with POODLE, SSL is really dead. Long live TLS!