How did this all come about?
During 2014-5 there were some horrendous security alerts which showed that some of the most trusted protocols on the Internet were no longer safe. These alerts were given names, and some of them are still recognized by many of us today because of their severity and publicity. They include Beast, Heartbleed, Poodle, Logjam, Freak, Drown and RC4.
The target of these security threats was largely aimed at flaws in the Secure Sockets Layer (SSL) that had been used to encrypt web traffic since the early days of the Internet and had been thought to be safe and reliable. SSL was thought up in the early ‘90s by Netscape and went through two further upgrades by the end of this decade before Transport Layer Security (TLS) was proposed. Even though TLS looked to replace SSL at the end of the ‘90s, SSL was so well embedded and never thought of as a problem, so it remained mainstream for the best part of the noughties. We continued to use it and rely on it as most of our online browsing started to encrypt our web traffic as standard.
The shock that such a trusted system could then be at risk was something that no one had expected or planned for. Browsers simply hadn’t kept up and web servers couldn’t afford to upgrade to TLS. Fortunately, when the alerts came, TLS was a sound replacement but, as always, there was a catch in the way version 1.0 had been proposed and implemented to transition out of the SSL era. To prevent a “bump” as SSL was switched off, TLS 1.0 was meant to give us all a “soft transition” working in conjunction with the older SSL versions. This left inherent flaws in TLS 1.0 related to those found in SSL.
So, what happened and what went wrong?
Let’s first begin by understanding what is happening when we look at a web site via an encrypted link. The Secure Sockets Layer (SSL) and the newer Transport Layer Security (TLS) cryptographic protocols are designed to provide authentication and secure communications.
If, as in the case of these security alerts, it is possible to intercept these messages from the browser to the web server and decrypt the final private content being sent, a Man-in-the-Middle (MitM) attack may collect personal information, user credentials and other confidential information from the end user.
This all seems too difficult and improbable but, in truth, the power of modern computers to crack encryption ciphers and the ingenuity of hackers to exploit flaws in this process mean that it is a very real threat. Basically, the hacker simply has to “understand” one small piece of encrypted message to crack the rest of it. Padding errors (Padding is the P in Poodle) in message encryption expose this small piece and the rest is simple. Older block and weak ciphers that encrypt the messages don’t help either.
What’s wrong with TLS 1.0 and why do we need to care about it?
TLS provides a different type of handshake between the user and the web server which addresses the flaws that were found in SSL. It also manages the Padding issue, and the handling of ciphers is better than that in the older SSL in general. But TLS 1.0, as we mentioned, was designed to support transition. For instance, if a user cannot make a TLS 1.0 connection the web server downgrades them to SSL 3.0 as a legitimate TLS session. Clearly this just reopens the SSL door and makes us vulnerable to Beast and Poodle attacks again. Furthermore, we see additional alerts for new flaws such as Crime that require us to upgrade from TLS 1.0.
Finally, we also know that there are weak cipher associations with TLS 1.0 that we need to remove, such as DES, which can be broken in a few hours and RC4 has been found to be weaker than was previously thought. Ironically we had been advised to use RC4 to mitigate BEAST attacks in the past! They could be removed on their own but this would, in any case, severely limit the operation of TLS 1.0.
What are the reasons for removing TLS 1.0 and what else can we expect from Kurtosys going forward?
The longer-term trend is towards upgrading and the deprecation of the older standards. Removal of TLS 1.0 is going to be painful for users with older, unpatched browsers. By this we mean users who are running unsupported software and those that have not upgraded their systems in 3 years. As we can see from above, it is necessary to keep up with this as it still exposes security risk. For some of our customers, the data content, anonymous browsing and lack of authenticated credentials means that the risk poses no threat, but for others it is quite the reverse and we must maintain a uniform secure platform for all customers.
There are various recommendations and trends that we have been following in this story. Here are a few of the notices that have influenced our decisions:
- 2014: the National Institute of Standards & Technology (NIST) declared SSL and TLS 1.0 unsafe. In January this year, NIST began transitioning off TLS 1.0.
- 2015: the Payment Card Industry Security Standards Council (PCI SSC) followed suit calling for removal of SSL and early TLS. Full deprecation of TLS 1.0 and 1.1 is now required by June 30th, 2018.
- 2017: Salesforce are removing TLS 1.0 support from their platform. The deadline has recently been pushed forward but is currently planned for July 2017.
On a slightly tangential note, we read last year how much more serious this actually is. Apparently only 1 in 20 servers correctly implements HTTP Strict Transport Security that prevents visitors making unencrypted HTTP connections to a server. The remaining 95% are therefore vulnerable to trivial connection hijacking attacks, which can be exploited to carry out effective phishing, pharming and Man-in-the-Middle attacks. An attacker does not even need to spoof a valid TLS certificate and decrypt the traffic. Because no crypto-wizardry is required to hijack an HTTP connection, these attacks are far easier to carry out than those that target HTTPS connections. This and other web server settings will be more strictly monitored and hardened going forward.
Payment Card Industry Data Security Standard (PCI DSS) has been updated and their requirements now call for a full deprecation of both TLS 1.0 and 1.1 until June 30th, 2018. This will drive yet another upgrade to TLS 1.2 which most browsers will, happily, be ready for.
Latest posts by Harry Thompson (see all)
- Why we are deprecating TLS 1.0 - May 3, 2017
- Improving Client Service Through Cloud Application Monitoring - June 30, 2015
- How to Adapt to the Ever-Changing Nature of Internet Security - January 13, 2015