In the early days of the internet, considerations such as data security were nowhere near as important as they are today. Back then, most communication was transmitted unencrypted between servers. Just like with postcards, any postman could read their contents.

The TLS protocol – also known as SSL/TLS – introduced the encryption of transmitted content. To continue with the example above, this can be likened to a sealed envelope that only the recipient can open and read.

What is TLS?

The abbreviation TLS stands for Transport Layer Security. It was originally intended to run on top of transport protocols similar to the TCP/IP models. The TLS protocol essentially encrypts data transmission online or between devices to ensure that only authorised recipients can access it. Its predecessor was the well-known SSL (Secure Sockets Layer), which is why TLS is often referred to as SSL/TLS to avoid confusion.

How does TLS work?

TLS encrypts data sent over the internet and is generally implemented on top of TCP using symmetric cryptography.

Whilst this sounds simple in theory, in reality it is rather complicated. As part of the secure transmission process, the server must share the access key with the customer – before any communication can be secured via TLS. You may be familiar with this issue if you regularly send encrypted email attachments: to encrypt the attachment, you need to share the password with the recipient, for example over the phone.

The TLS protocol resolves this issue by taking the following measures:

1. When a client, such as a web browser, connects to the web server, it receives a certificate. This SSL certificate verifies that the sender is genuine and is not, for example, hiding behind a false identity.
2. The customer verifies the certificate and sends a randomly encrypted number to the server using a public key.
3. The server generates a session key from this public key to encrypt communications. As the public key originates from the customer, the server can be certain that the session key comes from the correct sender.
4. The server then sends the encrypted session key to the client. The encryption is based on the Diffie-Hellman key exchange method.
5. Both parties are now able to encrypt their data using the session key.

The reason why asymmetric encryption is used only for the session key (but not for encrypting the data streams themselves) is speed: asymmetric encryption is relatively slow and would slow down data communication.

The advantages and disadvantages of TLS

TLS is a relatively elegant solution for secure internet data transmission, as it does not require the parties involved to encrypt the content being exchanged. Instead, it is sufficient for the transmission to take place solely via the TLS protocol, regardless of the operating systems or software applications used by the parties concerned. All data streams are then automatically encrypted during transmission.

However, this added layer of security comes at the expense of speed, as processes such as authentication and the generation of public and session keys are computationally intensive.

Areas of application for TLS

TLS is universally applicable, as it does not rely on specific operating systems or applications. Accordingly, there are numerous TLS-secured versions available for various user protocols. The naming convention is simple: the protocol name ends with the letter ‘s’ if the protocol communicates via TLS.

The most important area of application for TLS is the World Wide Web, or more specifically, the HTTP protocol. The encrypted version is known as HTTPS.

Other common areas of application include the following:

• POP3S: retrieving emails from a server using the POP3 protocol
• IMAPS: synchronises the mailbox with the server using the IMAP protocol.
• SMTPS: sending emails
• FTPS: file transfer via the FTP protocol
• SIPS: Voice-over-IP calls via the SIP protocol
• IRCS: encrypted chats

TLS in practice

The most important implementations of TLS in applications are as follows:

• OpenSSL – the most widely used implementation on most HTTPS websites.
• GnuTLS (Free Software Foundation)
• LibreSSL (OpenBSD)
• NSS (network security services)
• BoringSSL (Google)
• Cryptlib (Peter Gutmann)
• Botan (BSD licence, Jack Lloyd)
• JSSE (Java Secure Socket Extension, Oracle)
• S2n (Amazon)

This list is not exhaustive. Wikipedia is an excellent source for further information on the implementation of TLS.

Known TLS attacks

However, TLS is not immune to attacks and data leaks. Some well-known attack vectors and vulnerabilities are as follows:

• Programming errors: The Heartbleed Bug became notorious for a serious programming error in some earlier versions of OpenSSL. This was fixed in 2014.
• Weak encryption: As a result of US export restrictions on cryptography, exportable versions were developed. However, these were easier to crack than earlier versions.
• Compression attacks: If HTTP compression is used instead of TLS compression, hackers are able to deduce TLS-encrypted content using specialised techniques.
• The BEAST attack affected version 1.0 of TLS and was made public in 2014. Current versions of TLS are secure.
• The Padding Oracle attack was discovered in 2002 and posed a threat up to and including SSL version 3.0. It does not affect the current TLS 1.3 version.

At the same time, there have been attempts to circumvent fully secure TLS encryption so that the authorities can access encrypted communications, for example, to monitor fraudulent activity in financial transactions. The European Telecommunications Standards Institute was one of the organisations at the forefront of developing specific breaking points in the protocol.