TLS and SSL Explained

Introduction to Public Key Cryptography

Before we go into details, we should review some key concepts that are crucial to understanding the subject. Both Transport Layer Security (TLS) and Secure Socket Layer (SSL) take advantage of public (asymmetric) key cryptography for establishing a secure communication channel.

While conventional symmetric cryptography has been around since at least ancient Egypt, public key cryptography has been discovered in the 1970s. It utilizes a pair of keys. If you encrypt something with one key, for all practical purposes, it can only be decrypted with the other. Discussing why this is the case would involve math that is well outside the scope of this article.

What is the Difference Between TLS and SSL?

Both TLS and SSL use public key cryptography to share a more conventional, symmetric key (choice of multiple cipher types is available) between two hosts. This process is called the handshake. The shared key is then used to encrypt the subsequent communication. So, what is the difference?

TLS 1.0 was introduced in 1999 as the successor to SSL 3.0. Some people think of it as SSL 4.0, and it is a very reasonable way to look at it. The SSL is technically proprietary to Netscape and TLS is an Internet Engineering Task Force standard, hence the difference in name — to avoid potential legal issues. You can check this article for more details.

From a more technical perspective, TLS performs the handshake slightly differently from SSL. The connection starts as “insecure” and is then later “upgraded” with STARTTLS command. The name of the command is somewhat misleading as it can be used to start TLS and SSL connections. Please see this for more details.

The idea behind it was to allow upgrading to secure communication via normally insecure application ports. This way an application only has to listen on one port instead of two. It turned out to be impractical as a lot of client applications would send user credentials in plain text before the server could even tell them: “plaintext is not supported”. The request would fail, of course, but the credentials would already be compromised.

Why is TLS more secure than SSL?

Computer security is an arms race. SSL 3.0 has been declared obsolete in 2015 because it has unfixable security vulnerabilities. To be fair, TLS 1.0 is not much of an improvement as the attacker can force the client application to downgrade to SSL 3.0 by interrupting the handshake. TLS 1.1+ addresses this particular issue.

The main reason why SSL 3.0 is simply not secure anymore is, largely, because it does not support ciphers strong enough to counter increases in the computational (and sometimes legal) power that is available to the attackers. It is simply obsolete. On top of that, it does not use the ciphers that it does support as well as it should. For example, it does not have a mechanism to check padding contents when using block ciphers and the infamous POODLE (among others) attack exploits this.

What measures to take?

This thread gives a really good overview of the measures you can take. Let’s summarize them briefly here.

From the client perspective, it is relatively simple. All modern (such as Firefox 27+) web browsers support TLS 1.2, so making sure that your browser is up to date is a good start. In fact, most of them will warn you if the website has outdated TLS among other things. So, if you visit a website and your browser tells you that there is a problem with connection security, do take it seriously.

On the server end, you should consider displaying a warning to your customers if they are using an outdated security protocol. Assuming you are using Apache you can do something like this:

  SSLOptions +StdEnvVars  RequestHeader set X-SSL-Protocol %{SSL_PROTOCOL}s  RequestHeader set X-SSL-Cipher %{SSL_CIPHER}s

Then, in case of PHP for example, you can access those values using $_SERVER inside your code. If you detect an older TLS version you can say something along the lines of “Starting 30 June 2018 we will no longer be supporting TLS 1.0, as per PCI Security Standards Council mandate. Please upgrade your web browser”. By the way, the council has been founded by the major credit card companies and any eCommerce business that is operating in the US needs to comply with their security standards.

It is worth mentioning that there are free third party tools you can use to scan for SSL/TLS vulnerabilities and even generate configuration for your server. The Mozilla SSL Configuration Generator tool basically generates TLS configuration appropriate for your server all you need to do is make some choices.

The SSL Server Test by Qualys SSL Labs allows you to enter the hostname and click “Submit”. It will run a plethora of tests against you server and will inform you of vulnerabilities… if any.