What is TLS (Transport Layer Security)?

During the Internet’s early days, aspects such as data security weren’t nearly as important as they are today. Most communications were transmitted unencrypted between servers during these times. Much like postcards, any mailman was able to read their content.

The TLS protocol – also referred to as SSL/TLS – introduced encryption for transmitted contents. Following on from the above example, this is comparable to a sealed envelope which only the addressed recipient can open and read.

The abbreviation TLS stands for Transport Layer Security. It was originally designated to run on top of transport protocols such as TCP/IP-Models. The TLS protocol essentially encrypts data transmissions online or between devices to ensure they are only accessed by the authorised recipients. The protocol’s predecessor was the well-known SSL (Secure Socket Layer) which is why TLS is often referred to as SSL/TLS to avoid confusion.

TLS encrypts data sent via the Internet and is normally implemented on top of TCP using symmetric cryptography.

What may sound simple in theory, is quite complicated in reality. As part of the secure transmission process, the server has to share the access key with the client – before any communication is secured via TLS. You may be well-aware of the issue if you regularly send encrypted e-mail attachments: by encrypting an attachment, you need to share the password with the recipient, for example, via telephone.

The TLS protocol uses the following measures to solve this problem:

1. If a client, such as a web browser, contacts the web server, it receives a certificate. This SSL certificate verifies that a sender is authentic and is not, for example, hiding behind a fraudulent identity.
2. The client verifies the certificate and sends the server a randomly encrypted number with a public key to the server.
3. The server produces a session key from this public key to encrypt the communication. Because the public key originates from the client, the server can be certain that the session key stems 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. Now, both parties are able to encrypt their data using the session key.

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

TLS is a relatively elegant solution to secure data transfer on the web because it doesn’t require parties to encrypt the content they exchange. Instead, it suffices for the transport only to be conducted via the TLS protocol, irrespective of the operating system or software applications used by the parties involved. All data streams are then automatically encrypted during transmission.

However, the added layer of security comes at the cost of speed because processes such as certification, and public and session key generation are computationally intensive.

TLS is universally deployable because it doesn’t rely on specific operating systems or applications. Accordingly, a variety of TLS-secured versions are available for various user protocols. The naming scheme is simple: the name of the protocol concludes on the letter “s” if the protocol communicates via TLS.

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

Other frequent fields of application include:

• POP3S: collect e-mails from a server using the POP3 protocol
• IMAPS: synchronise inbox with server using the IMAP protocol
• SMTPS: send e-mails
• FTPS: file transfer via FTP protocol
• SIPS: Voice-over-IP calls via the SIP protocol
• IRCS: encrypted chats

OpenVPN, which is a free software for Virtual Private Networks (VPN), also uses a TLS protocol.

Among the most important implementations of TLS are:

• OpenSSL – the most common implementation used by 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)

The list is not complete. For more information on the implementation of TLS, Wikipedia is an excellent source.

However, TLS is not immune to attacks and data leaks. Some well-known points of attack and weak spots include:

• Programming errors: The Heartbleed Bug became famous for being a serious programming error in some of the earlier versions of OpenSSL. It was fixed in 2014.
• Weak encryption: As a consequence of export restrictions to cryptography in the US, exportable versions were developed. However, these were easier to crack than previous versions.
• Compression attacks: If HTTP compression is used instead of TLS compression, hackers are able to guess TLS -encrypted contents using dedicated techniques.
• The BEAST attack affected TLS version 1.0 and was disclosed in 2014. Current TLS versions are safe.
• The Padding Oracle attack was discovered in 2002 and remained a threat until SSL version 3.0. The current TLS version 1.3 is not affected.

At the same time, there have been attempts to avoid a fully secure TLS encryption in order for authorities to access encrypted communications, for example, to monitor the fraudulent activity of financial transactions. The European Telecommunications Standards Institute has been among the organisations at the forefront of creating defined breaking points in the protocol.