Secure Socket Layer (SSL) (Continued)

SSL has gone through multiple iterations. SSL was first released as version 2.0. Version 1.0 was never released, and it was developed by Netscape, who made web browsers many years ago. So version 2.0 was released in 1995, but it was prohibited in 2011. Subsequently, version 3.0 was released in 1996, prohibited in 2015. From that point, SSL effectively became TLS, so Transport Layer Security. So Transport Layer Security version 1.0, was released in 1999 but was deprecated or was due to be deprecated by 2020. TLS version 1.1, released in 2006, is scheduled to be deprecated by 2020 as well. And the recommended minimum, at this point, is TLS 1.2, which was released in 2008.

TLS 1.3 has been around, has now been released in 2018, and the recommendation is we use those later implementations. Certainly, earlier versions of SSL or earlier versions of TLS are not classed as secure. So TLS version 1.0 was defined in RFC 2246 in January 1999 as an upgrade of SSL version 3.0. TLS 1.1 was defined in RFC 4346 in April 2006. We do have some problems in terms of this advance. The desire is to support these more recent implementations of TLS, but not all browsers support these later versions. For example, Internet Explorer, version 10, doesn’t support the later implementations of TLS.

So what we’re trying to do is to balance the use of the appropriate, current version of TLS, against the compatibility. And the implementation that we use depends very much on the type of service that we’re offering. But mostly, we would hope, if we’re using TLS, if we’re requiring a secure service, if we’re requiring HTTPS, there’s probably a requirement for some kind of confidentiality or integrity operation. For that reason, we want to be using one of the more modern versions. Google Chrome and Firefox, by default, as of 2018, support TLS version 1.3. There have been… the reason for this continued evolution in the different SSL versions is because of the many vulnerabilities.

We’ve listed three here: Drown, Decrypting RSA with Obsolete and Weakened eNcryption; Beast, Browser Exploit Against SSL/TLS; and Freak, the Factoring of RSA Keys. So these are different ways of attacking SSL. There are Oracle attacks, which seek to exploit the time it takes to decommit memory and various methods of compromising. So these often rely on requesting that the server reduces the strength of the encryption algorithm in use to an export-compatible one. So because the exportation of encryption can be problematic, there is still legacy support for weaker encryption within SSL/TLS. If we drop, if the client or if the attacker requests a drop in the encryption standard, that makes the attack easier, more likely to be successful.

Two other well-known attacks are Heartbleed, this affected SSL when it was implemented through OpenSSL. So traditionally, Linux-type implementations used OpenSSL. Here, the client and server can be exploited, and it revealed 64k of memory, and this potentially contained keys. This is because of the nature of the transaction, this could be sensitive information. We also had SSL Poodle. This was one of the padding.. this was one of the Oracle attacks. So this was Padding Oracle on Downgraded Legacy Encryption. So again, here we’re looking at the attacker requesting a lower standard of encryption to make the attack more straightforward.