What is TLS (Transport Layer Security)? The protocol explained

TLS (Transport Layer Security) is an en­cryp­tion protocol that ensures secure data trans­mis­sions on the internet. It is the successor to the outdated SSL and is now almost ex­clu­sive­ly used in the TLS 1.3 version.

What is TLS?

In the early days of the internet, data security wasn’t as important as it is today. All com­mu­ni­ca­tion was sent openly and un­en­crypt­ed from one computer to another. You can think of it like a postcard: every mail carrier could read it.

The TLS protocol—also known as SSL/TLS—in­tro­duced en­cryp­tion of trans­mit­ted content. To continue the analogy, this en­cryp­tion is like a sealed envelope that only the rightful recipient can open.

The ab­bre­vi­a­tion TLS stands for Transport Layer Security. This term refers to the transport layer of the TCP/IP model. TLS is a method that encrypts internet data streams, allowing only au­tho­rized re­cip­i­ents to read them.

How does TLS work?

TLS encrypts data sent via the internet and is normally im­ple­ment­ed on top of TCP using symmetric cryp­tog­ra­phy.

What sounds simple in practice is more com­pli­cat­ed in reality. The fun­da­men­tal problem is that the server must com­mu­ni­cate the key to the client—before the com­mu­ni­ca­tion is secured with TLS. Anyone who sends encrypted email at­tach­ments knows this issue: You encrypt a file and have to share the secret password with the recipient, e.g., over the phone.

The TLS protocol, whose current standard has been version 1.3 since 2018, uses the following procedure to solve this problem:

1. Clien­tHel­lo: The client (e.g., a browser) sends an initial message to the server with in­for­ma­tion about the supported en­cryp­tions. This includes cipher suites, protocol versions, a random value, and its own Elliptic-Curve-Diffie-Hellman key exchange value (ECDHE value). Op­tion­al­ly, the first encrypted data block can already be sent.
2. Server­Hel­lo: The server selects the ap­pro­pri­ate pa­ra­me­ters and sends its response— including its ECDHE value and its digital cer­tifi­cate. This SSL cer­tifi­cate proves that the server is authentic and not pre­tend­ing to be someone else. At the same time, the session key cal­cu­la­tion begins.
3. Key cal­cu­la­tion: Both sides now in­de­pen­dent­ly calculate the same session key based on the jointly agreed key.
4. The server completes the handshake and begins encrypted com­mu­ni­ca­tion. The client does the same; the con­nec­tion is now fully secured.

The reason why asym­met­ric en­cryp­tion with Diffie-Hellman is only used for trans­mit­ting the session key (but not for en­crypt­ing the data streams them­selves) is the speed advantage; asym­met­ric en­cryp­tion is rel­a­tive­ly slow and would delay data com­mu­ni­ca­tion.

The pros and cons of TLS

TLS is an elegant solution for making web traffic more secure. It doesn’t require the two parties to encrypt the content them­selves, such as form data. Instead, it’s suf­fi­cient if the traffic is routed through the TLS protocol, re­gard­less of the par­tic­i­pants’ operating systems and software ap­pli­ca­tions. All data streams are then au­to­mat­i­cal­ly encrypted during trans­mis­sion.

The price of security is a slightly slower con­nec­tion setup because the process steps mentioned above—cer­tifi­cate, random number, key exchange—are com­pu­ta­tion­al­ly intensive.

Uses of TLS

As mentioned, TLS can be used uni­ver­sal­ly because it is in­de­pen­dent of ap­pli­ca­tions and operating systems. Ac­cord­ing­ly, there is a TLS-secured version for a variety of ap­pli­ca­tion protocols. The naming scheme is quite simple in most cases: the letter “S” is added to the protocol’s name when the protocol com­mu­ni­cates via TLS.

The most important ap­pli­ca­tion area of TLS is the World Wide Web, specif­i­cal­ly the HTTP protocol. Its encrypted version is called HTTPS.

Alongside these, the following common use cases should be mentioned:

• POP3S: Retrieve emails from the server using the POP3 protocol
• IMAPS: Syn­chro­nize inbox with the server using the IMAP protocol
• SMTPS: Send emails
• FTPS: File transfer via FTP protocol
• SIPS: Voice-over-IP telephony over the SIP protocol
• IRCS: Encrypted chats
• QUIC: Google’s transport protocol that directly in­te­grates TLS 1.3; an al­ter­na­tive to TCP for faster and more secure web con­nec­tions (e.g., with HTTP/3)

OpenVPN, a free software for es­tab­lish­ing a Virtual Private Network (VPN), also utilizes the TLS protocol.

Key TLS im­ple­men­ta­tions

Some of the most widely used im­ple­men­ta­tions of TLS include:

• OpenSSL – by far the most common im­ple­men­ta­tion used by most HTTPS websites
• GnuTLS (Free Software Foun­da­tion)
• LibreSSL (OpenBSD)
• NSS (Network Security Services)
• BoringSSL (Google)
• Rustls (Joe Birr-Pixton, Dirkjan Ochtman, Daniel McCarney, Josh Aas and Open-Source Community)
• Botan (BSD License, Jack Lloyd)
• JSSE (Java Secure Socket Extension, Oracle)
• S2n (Amazon)

This list is not ex­haus­tive. Detailed in­for­ma­tion about TLS im­ple­men­ta­tions can be found on Wikipedia.

Well-known TLS attacks

Although TLS is designed for secure com­mu­ni­ca­tion, it still has known weak­ness­es. These include:

• Pro­gram­ming errors: The Heart­bleed Bug became famous as a critical pro­gram­ming error in earlier versions of OpenSSL. It was fixed in 2014.
• Weak en­cryp­tions: As a result of US cryp­tog­ra­phy export re­stric­tions, “export-grade” versions were developed that were easier to crack than the originals.
• Com­pres­sion attacks: When HTTP com­pres­sion is used instead of TLS com­pres­sion, it becomes possible for hackers to guess TLS-encrypted content through certain methods.
• The BEAST attack affected TLS version 1.0 and was described as early as 2014. Current TLS versions are secure against it.
• The Padding Oracle attack was dis­cov­ered in 2002 and was possible up to SSL version 3.0. The current TLS version 1.3 is not affected.
• The ALPACA attack from 2021 shows how TLS cer­tifi­cates on mis­con­fig­ured servers can be exploited to redirect users to other services, in­ter­cept­ing or ma­nip­u­lat­ing data.

There have also been efforts to prevent fully secure TLS en­cryp­tion in order to allow au­thor­i­ties to access encrypted com­mu­ni­ca­tions—for example, in con­nec­tion with financial trans­ac­tions and criminal activity. One of the or­ga­ni­za­tions that advocated for such a “de­lib­er­ate vul­ner­a­bil­i­ty” in TLS was ETSI (the European Telecom­mu­ni­ca­tions Standards Institute).