Transport Layer Security (TLS/SSL)

Transport Layer Security (TLS) is the standard security principle that establishes a secure and encrypted connection between a web server and a browser. When your browser attempts to talk with a server, say google.com, it has to use the public internet to complete the request. The issue is that without a proper means of protecting the communication anyone can listen into the conversation occurring between your browser and the server and steal personal information and other critical data. This was the reality on the internet pre-1995 when SSL 2.0 was released. (SSL 1.0 had too many security vulnerabilities and was never officially released). SSL (secure sockets layer) introduced the following 3 principles that are the staple of communication on today’s modern internet.

• The connection is Private because the data is encrypted between the client and the server.
• The communicating parties are Authenticated to ensure each party is talking with their intended host.
• The connection is Reliable in that no modification of the communication can occur without detection.

Since its introduction in 1995 SSL has undergone multiple revisions to improve security and to mitigate attacks. Following SSL 3.0’s release, SSL 3.1 was introduced and due to a lack of interoperability with SSL 3.0 (and a change of maintainer) SSL 3.1 got rebranded to Transport Layer Security (TLS). Although the terms SSL and TLS are often used interchangeably it should be important to note that all SSL versions (2.0 and 3.0) are deprecated due to numerous security vulnerabilities. All web servers should be only using TLS — ideally the latest version: TLS 1.3.

Lets discuss the underlying principles that allow SSL/TLS to work. It should be noted that a lot of the concepts discussed here (especially the cryptographic ciphers) can fill multiple university courses with their complexity. The goal of this article is to explain how SSL/TLS works and not how encryption works.

Before SSL/TLS communication can be setup, both parties must know something about each other so that they can setup a secure connection that both parties will be able to understand. The process of securely transmitting the data between the client and the server is handled by what the SSL/TLS protocol refers to as the “cipher suite.” This cipher suite is composed of multiple parts with various algorithms for each part.

• Authentication Algorithm — Determines how authentication of both parties is performed (relates to certificates) — Provides Authentication
• Key Exchange Algorithm — Determines how encryption keys (keys used to encrypt the data) are exchanged
• Bulk Encryption Algorithm — Determines which algorithm to use to encrypt the data between client and server — Makes the data Private
• Message Authentication Code Algorithm — Determines which algorithm to verify the integrity of the data — Makes the data Reliable

Before a client application and a server can exchange data over a SSL/TLS connection, these two parties need to agree first on a common set of algorithms to secure the connection. If the two parties fail to reach an agreement, then a connection won’t be established. The negotiation process takes place during what is commonly known as the SSL handshake. In the SSL handshake, the client begins by informing the server what cipher suites it supports. The cipher suites are usually arranged in order of security with the most secure cipher suite being the first choice. The server then compares those cipher suites with the cipher suites that are enabled on its side. As soon as it finds a match, it then informs the client, and the chosen cipher suite’s algorithms used in the subsequent communication.

Ingredients for SSL/TLS

To start with SSL/TLS ensures that when a user is connecting to a server, they can be sure that they are talking with the authorized server and not some impersonator. To do this, each server is able to get a certificate vouching for their authenticity that a client can check and verify. These certificates are unforgeable as these certificates are cryptographically secured by a certificate authority that is responsible for issuing the certificates. The certificate authority is one of a handful organizations located globally that all devices connecting to the internet agree to trust and agree to trust any and all certificates issued by the certificate authority. The details about certificates and how they are secured and issued by certificate authorities is best saved for another article, for now just trust that if a certificate is issued by a certificate authority, it cannot be duplicated by an attacker.

When a client connects to the server, the server replies back with the certificate it has, and if the domain name (google.com) matches the domain listed on the certificate, then the client can be sure that they are talking with the correct party and not some impostor.

The certificate also provides a way to perform the key exchange over a secure channel as the certificate uses something called an asymmetrical key pair as part of the Authentication Algorithm. The math behind this method is out of the scope of this article, but in essence, there are two parts to the asymmetric key pair, a private key that only the server knows, and a public key that is the certificate used to verify the authenticity of the server. The keys are constructed in such a way that when data is “signed” (encrypted) with the server’s private key, only the public key can decrypt it, and visa versa, where something encrypted with the public key is only readable with the private key. In this manner, any message sent to the server can only be read by the server and no one ease dropping on the communication can read said message. (The same is not the same in reverse as the server’s public key is, well public, meaning that anyone can decrypt the messages coming from the server. Thus another encryption method is needed to ensure both directions of communication are secured).

There are many ways of setting up a completely secure communication channel including setting up another asymmetric key pair (only this time the client has the private key, and the public key is only given to the server), or using a preshared key. However, the best method for the Key Exchange Algorithm (and the only ones supported by TLS 1.3) ensure forward security. Forward security just means that should a private key from either the Authentication Algorithm or the Key Exchange Algorithm be compromised in the future, the past messages will not be compromised. Without forward secrecy, if the server’s private key is compromised, not only will all future TLS-encrypted sessions using that server certificate be compromised, but also any past sessions that used it as well. The only algorithm capable of providing this security is the Diffie-Hellman key exchange and its derivatives. Diffie-Hellman is unique in that the shared secret is created by both client and host together and not shared over the communication channel where it would be vulnerable to future compromises. (Computerphile did an explanation of how Diffie-Hellman works — probably better than I ever could).

Once the session key has been exchanged between the server and the client, the Bulk Encryption Algorithm secures all subsequent communication for the communication session. Unlike the Authentication Algorithm, the Bulk Encryption Algorithm makes use of a symmetric encryption algorithm meaning that the same key (which has already been negotiated by the Key Exchange Algorithm) is used to both encrypt and then decrypt the data. The Bulk Encryption Algorithm utilizes symmetric encryption due to the fact that asymmetric encryption requires significantly more compute power and is thus much slower to encrypt and decrypt, yet is just as secure as symmetric encryption (provided the keys have been shared securely of course). The encrypted data is then sent over the network and is verified against tampering by using the Message Authentication Code Algorithm. This algorithm uses clever mathematics to ensure that even if one value in the data set is altered, the algorithm will detect the alteration and either request the data again, or simply close the connection.

The general workflow is as follows:

TLS Example Workflow

• A client tries to open up a communication with a target server. A part of the greeting, the client sends a list of its supported cipher suites.
• The server responds with the most secure cipher suite supported by both the client and the server. The server also sends its public certificate.
• The client then verifies the signature is from a trusted certificate authority. Depending on the Authentication Algorithm the server will have hashed a message with its private key. If the client decrypts the message with the public key of the server, and the message is correct, then the client knows that the server is authorized.
• The client will then attempt to negotiate a symmetric key using the Key Exchange Algorithm (This will result in back and forth communication between the client and the server. The exact number of messages depends on the algorithm).
• Once the key has been negotiated, both parties are now able to start communicating securely
• The client sends its first HTTP request and encrypts it with the Bulk Encryption Algorithm. The server is able to decrypt the request with the negotiated key (same key as the client). The server will also verify the integrity of the data by using the Message Authentication Code Algorithm.
• The server then sends its encrypted HTTP Response to the client. The client then decrypts the message and verifies its integrity.
• This back and forth will continue for as long as the session is active. Once the session is over, new session keys will need to be exchanged to start a new round of secure communication.

TLS 1.3 Adoption

TLS Adoption as of February 2019 (Source:Qualys)

If TLS is so important, you may be asking yourself why latest figures show that TLS 1.3 is only accepted by 11% of sites on the internet, and why the biggest vendors including Apple’s Safari (mobile and desktop versions), Android’s mobile chrome browser, and Microsoft’s Edge browser (iOS’s next feature update will include support for TLS 1.3) do not include support for TLS 1.3 as of this writing. The main issue with attempts to upgrade TLS to the latest version is an issue of incompatibility with older devices. TLS as a protocol is of course backwards compatible with all previous versions of TLS, however that requires that device manufactures implement TLS exactly as the original specifications called for. This is however, is not always the case because TLS was designed with flexibility in mind with various options for future changes and improvements. As a device manufacturer, it is time consuming and costly to implement TLS with all the flexibility TLS was designed for, especially if a vast majority of this “flexibility” has not been used yet. As a result they make assumptions about how TLS will evolve over time. Thus when given a version that breaks these assumptions, the appliance will behave unpredictably and fail. A famous example of this issue occurred with TLS 1.2 in something known as the POODLE Attack. When rolling out TLS 1.2 a lot of browsers found that connections with servers on TLS 1.0 did not negotiate version negotiation correctly (the process in which the most secure TLS protocol supported by server and browser was selected). As a result the server would close the connection immediately. To fix this, browsers used an insecure downgrade technique where it would try older and less secure versions of TLS and SSL until it was able to establish a connection (If TLS 1.2 fails, try again with 1.1, then TLS 1.0, and then if that failed too, SSLv3). The problem with this of course is that this downgrade is “insecure” because it occurs as a result of a network failure, one that can easily be spoofed. This means that an attacker can force a communication down to SSLv3 rather easily even if both browser and server support TLS 1.2. This was acceptable at first, since SSLv3 was still thought to be secure. That was until October 2014 when the POODLE attack was made public, where in-network attackers could reveal encrypted information from the SSLv3 protocol. The combination of the POODLE vulnerability in SSLv3 and the insecure downgrade technique used to stem the issues caused by TLS 1.2 upgrades, created the perfect environment for attackers to listen-in on secure communication, negating everything SSL/TLS was designed to prevent. Fortunately for the world at this point in time SSLv3 was rarely used with TLS 1.0 being the de-facto version supported by servers. Thus turning off SSLv3 support to stop POODLE was an easy enough fix.

POODLE Vulnerability Figures at height (Source:Qualys)

This same issue with insecure downgrade threatened to plague TLS 1.3 as well, with the original draft of the protocol breaking on around 3–7% of connections (a large number considering the size of the internet). The fix came not through insecure downgrading, but instead a revision to the TLS 1.3 protocol that made it look like it was TLS 1.2 at first to engage in version negotiation. This was a controversial fix, as it basically ensured that should a future TLS version want to change this negotiation protocol, major breakage far greater than 7% would be expected. In the end TLS 1.3 is a major upgrade in security for the internet and hopefully in the next few years it will be support completely by all servers and all browsers. To check on the latest numbers you can check out Qualys’ monthly report on SSL adoption and security