— This post is part of a series of monthly blog posts about all kinds of Security topics for Developers —
TLS stands for Transport Layer Security and it is a cryptographic protocol to secure communication over a network. This is what is used when you type ‘https’ instead of ‘http’ in your browser to communicate with a server, but it is also used to secure other end-to-end communications like email, voice-over-IP or DNS. TLS is the successor of SSL (Secure Sockets Layer). Many people still use the word SSL when they actually mean a TLS connection. SSL is old and deprecated. Just like SSL, TLS 1.0 has been found to be insecure. This is why TOPdesk is slowly going to drop support for this protocol version in favor of version 1.2 (and soon also 1.3). Here we’ll discuss what you need to know of TLS 1.0.
Let’s start with a bit of history. SSL was originally developed by Netscape in the early nineties. The first version appeared to be so insecure, that it never has been published. The next version (2.0) was released in 1995. This version too was soon found to contain vulnerabilities, so a year later version 3.0 was published.
Although SSL was widely used, it was never officially considered an Internet standard. So when the next version did get officially recognized by the IETF in 1999, presumably the creators wanted a new name. TLS 1.0 was born. Later versions contain improvements and extra protection against a range of different attacks. Version 1.2 (which was released in 2008) is by far the most used version. The last big update to 1.3 was published only very recently and has not yet been widely adopted.
TLS (and SSL) were designed with confidentiality and integrity in mind. This means that the data that is sent should not leak to third parties (no eavesdropping), and that if data was modified in transit, the receiving party can recognize this (no alteration).
Setting up a secure connection
Before secure end-to-end communication can start and data can be exchanged, the client and the server should reach agreement upon some things. This is called the ‘handshake’. During this handshake the client and server negotiate which cipher suite to use, the client verifies the authenticity of the server and a session key is exchanged.
Selecting the cipher suite
Throughout the message exchange, a cipher suite is used. These suites contain a set of algorithms, for example for key exchange and authentication. Think of algorithms like RSA, ECDA and Diffie-Hellman of which you may have heard. An example would be: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256. As you may have guessed, this name is not just random. It’s very descriptive actually: The TLS part specifies the protocol. The key exchange algorithm is done with DHE (Diffie-Hellman). Authentication is done with RSA. The bulk encryption algorithm is 128-bits AES operating in CBC (cipher block chaining) mode. Finally, SHA256 is the MAC algorithm. The client gives an order of preference for cipher suites, hoping the server will support the most secure algorithms.
During the authentication phase the server proves its authenticity to the client. The client basically encrypts some data with the server’s public key. It knows that the server can only decrypt the secret key if it has the right private key, and it only has the right private key if it is the real server.
To create a session key, the client encrypts a random number with the public key of the server and sends that to the server. Only the server can decrypt it (with its private key). Both sides can now generate a session key based on this random number.
Optionally, the client can use a key exchange algorithm to generate a random and unique session key. Using those algorithms you also get the benefit of forward secrecy, which means that even if the server’s private key gets compromised in the future and past network traffic was captured and recorded, it cannot be used to decrypt this session’s data.
After the handshake, both the server and the client have the secret key and can be pretty convinced that no man-in-the-middle has intercepted it. All messages sent will be encrypted with the secret key and only the client and the server can decrypt it. At least, that’s the theory …
So, why should we stop supporting TLS 1.0?
This early version of TLS has been found insecure and has multiple drawbacks. What exactly is wrong then? And why do companies around the world want to drop support rather sooner than later? Here are a few of our reasons:
- TLS 1.0 is vulnerable to the BEAST (Browser Exploit Against SSL/TLS) attack, of which the details were published in September 2011. This allows a hacker to perform a man-in-the-middle attack and decrypt traffic. See https://blogs.akamai.com/2012/05/what-you-need-to-know-about-beast.html for a nice explanation. Essentially the vulnerability is a client side problem, so upgrading to a modern browser fixes this. One way that is often mentioned to solve this on the server side, is to only use RC4 ciphers, but those are very weak themselves and would open us up to vulnerabilities that are perhaps even worse.
- TLS 1.0 is vulnerable to CRIME (Compression Ratio Info-leak Made Easy). The client can specify whether compression should be used or not. Because most compression algorithms work with repeating patterns, a hacker can learn the contents of the session cookie by just adding cookie-like data and watching the size of the response to see if it was compressed or not, and therefore if it was already contained in the original request. Therefore, by trial and error the contents of the session cookie can be learned. See https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/ for a nice writeup on how this works.
You might wonder, why not leave 1.0 enabled, and let users with clients that can handle it just use the latest version. That way every user could decide for himself to use the most secure connection or not. Unfortunately this reasoning does not hold. Many vulnerabilities exist because a man-in-the-middle can manipulate the handshake process and tell the server that it can only use old TLS versions and less secure cipher suites. This approach is called a downgrade attack. Again, see the Acunetix blog for a nice explanation of how this works. The only way to protect our users is therefore to disable it altogether.
Although most vulnerabilities have seen patches, the National Institute of Standards & Technology (NIST) of which we spoke in an earlier blog says that patches will never adequately fix all the problems. In 2014, they declared SSL and TLS 1.0 unsafe. In 2015 the Payment Card Industry Security Standards Council (PCI SSC) did the same and decided to deprecate both TLS 1.0 and TLS 1.1 by the end of June 2018.
Knowing all of this, you can understand that we want to get rid of TLS 1.0. We don’t want to serve our customer’s sensitive data over a possibly less secure connection.
In the past few months we have been monitoring the usage of TLS 1.0 with our users. Roughly around 0.55% of all connections were using this version. Since our servers are configured to always use the most secure protocol and version a client supports, we know that those connections will break when we drop support for TLS 1.0. We consider this number too high to ‘block’ them immediately. However, soon we will announce to customers when we will do so. Most likely we’ll also drop support for TLS 1.1 by that time, since usage of that version is negligible (< 0.005%) and there are not many clients that do support TLS 1.1, but don’t support TLS 1.2. There just doesn’t seem to be a good reason to still support TLS 1.1.
You might be wondering if there’s anything you can do to prevent security issues with TLS 1.0 now. It is always a good idea to keep your OS and browser up-to-date. Furthermore by using the SaaS version of TOPdesk, you don’t have to worry about the server-side security anymore. Finally, if you really want to be certain about this, you can disable support for TLS 1.0 in your own browser.
Want to read more about security? Find all our security blogs here: https://techblog.topdesk.com/tag/security/