What is Transport Layer Security (TLS)?

Through various asymmetric and symmetric cryptography techniques, TLS provides end-to-end authentication, confidentiality and data integrity. These protections apply to a wide range of network communications, including email, messaging, voice over IP (VoIP) and virtual private networks (VPNs).

TLS is widely recognized for establishing secure connections for web browsing. It’s the foundation of Hypertext Transfer Protocol Secure (HTTPS), an application layer protocol that enables encrypted data exchanges between web applications and most major web browsers.

The TLS encryption protocol has two layers: the TLS handshake protocol and the TLS record protocol. The handshake protocol authenticates the web server and the client (the device connecting to the server). The record protocol verifies and secures the data for transport.

These layers sit above a transport protocol, such as that within the Transmission Control Protocol/Internet Protocol (TCP/IP) model—a suite of protocols that specify communications standards between computers and are considered “the glue that holds the Internet together.”¹

The TLS protocol is the successor to the Secure Sockets Layer (SSL) protocol standard developed by Netscape Communications Corporation. In 1996, the Internet Engineering Task Force (IETF) formally standardized the SSL protocol.

In January 1999, the IETF made improvements and addressed vulnerabilities to the latest SSL version (SSL 3.0), changing the name to Transport Layer Security. It was formally defined in the Request for Comments (RFC) 2246. Today, the terms “TLS” and “SSL” are often used interchangeably or stylized as TLS/SSL.

Called “the most important security protocol on the Internet” by the IETF, TLS is critical to protecting online communication from unauthorized access. Its latest version, TLS 1.3, delivers stronger, faster security—and serves as the backbone of today’s safe digital world.

Nearly 68% of the global population is online,² with billions relying on the Internet daily for everything from shopping and banking to healthcare and personal communications. In all these use cases, safeguarding sensitive data is essential. That means protecting it from hackers, tampering, eavesdropping and other cybersecurity threats such as data breaches, malware or man-in-the-middle attacks.

TLS specifically underpins HTTPS, the standard security protocol for websites. The HTTPS padlock icon, now a familiar feature in web browsers, signals to users that a website is trustworthy and secure.

The icon also indicates that a website has a valid TLS certificate (also known as an SSL certificate). This digital credential, issued by a certificate authority (CA), verifies a website’s identity and enables an encrypted connection. To illustrate the scale of TLS and HTTPS usage: one major TLS certificate provider issues over 340,000 certificates per hour. 

TLS ensures secure Internet communication by enforcing three core properties of a secure channel:

Transport Layer Security is effective because it relies on cryptographic processes to secure transmitted information.

Cryptography comes from the Greek word “kryptos,” meaning “hidden.” The primary purpose of cryptography is to secure and obscure communications using encryption—a process in which complex algorithms convert readable messages (plaintext) into encoded messages (ciphertext). The ciphertext can only be decrypted into a readable format by an authorized recipient using a specific key.

In the context of cryptography—such as TLS encryption—a key is a random string of numbers or letters. When used with a cryptographic algorithm it encrypts (locks) or decrypts (unlocks) information. The algorithms used to encrypt and decrypt data transferred over a network typically come in two categories: secret key cryptography and public key cryptography.

Also known as symmetric encryption or symmetric key cryptography, this system creates a single shared key to encrypt and decrypt sensitive data. Symmetric encryption is simple and efficient but relies on secure key exchange and meticulous key management.

Most of the sensitive data sent in a TLS session is sent using secret-key cryptography. TLS uses cryptographic hash functions to help ensure privacy and data integrity. Hash functions generate a fixed-size hash value from input data. This value acts as a digital fingerprint that can be compared before and after transmission. If the hash has changed, that means someone has tampered with the data.

A message authentication code (MAC) is like a cryptographic hash, except it also authenticates the sender. It applies a secret key to hashed messages, with the resulting hash being known as a hashed message authentication code (HMAC).

Also referred to as asymmetric cryptography or public key encryption, this system uses a mathematically linked pair of keys—one public, one private—to encrypt and decrypt data. It allows people and systems to exchange sensitive information without needing to share a secret key in advance. It's comparable to a mailbox: anyone can insert a letter, but only the owner can unlock and retrieve its contents.

These capabilities help establish trust when integrated with public key infrastructure (PKI). For instance, public key certificates (also known as digital certificates or SSL/TLS certificates), bind public keys to verified identities through a certificate authority.

They also provide the basis for digital signatures—a component of digital certificates used in TLS to authenticate a client or a web server. Once a cryptographic hash is created for a message, the hash is encrypted with the sender's private key.

This encrypted hash is the digital signature. The signature can be verified by anyone using the public key, providing validation of the sender's identity and the data's integrity.

The TLS protocol has two sub-protocols: the TLS handshake protocol and the TLS record protocol. The exact steps may vary depending on the version of TLS.

The TLS handshake establishes a secure connection between the client and the web server. Using public key cryptography, the server is authenticated (and sometimes the client) using a digital certificate. The client and server then agree on a cipher suite (a set of encryption algorithms) and perform a key exchange to securely establish shared session keys (secret keys for encryption and hashing).

Once the session keys are established, the secure session is considered set up. From this point on, public key encryption is no longer used, and all subsequent data transmitted is encrypted and authenticated using secret key cryptography.

(For further detail, see: “What are the steps of a TLS handshake?”)

The record protocol is responsible for securing data transmitted during the TLS connection. To do so, it uses the cipher suite and keys negotiated during the handshake as a kind of recipe for how to protect data.

The cipher suite defines which algorithms should be used for key exchange, encryption and message authentication. The symmetric (secret) keys are used to encrypt outgoing data and decrypt incoming data. The keys are also used to create message authentication codes, which verify the integrity of the data.

Through these mechanisms, the record protocol ensures the authentication, integrity and confidentiality of the connection.

The exact steps of a TLS handshake vary based on the TLS version. It can take around 200 to 300 milliseconds, or as little as 100 milliseconds, to complete (of course, the exact duration depends on latency, round-trip time (RTT), server performance and other network considerations).

This illustration uses TLS 1.3, which is the fastest, most recent and more secure TLS version.

The client sends a ClientHello message with the supported TLS version (TLS 1.3), cipher suites, a random byte string (client_random) and an ephemeral key share—using the Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange method.

The server responds with a ServerHello message containing the selected cipher suite, another random byte string (server_random) and its own ephemeral key share. This step establishes the key exchange parameters.

Now, both parties can compute a shared secret using ECDHE. This shared secret is used to derive the handshake keys.

The server then sends its digital certificate, a CertificateVerify message (signed with its private key) and a Finished message (encrypted with the handshake key).

(Optional: If the server requires client authentication, it sends a CertificateRequest. The client then responds with its certificate and a CertificateVerify message.)

The client verifies that the server's certificate is issued by a trusted certificate authority, is valid and not revoked and that the domain matches. It also verifies the server’s CertificateVerify message using the server's public key from the certificate and the Finished message using the handshake key.

The client sends its own Finished message using a handshake key, and the handshake is confirmed complete.

At this point, both parties have authenticated each other and established a shared secret key. They can now exchange messages using symmetric encryption.

Key exchange methods help users securely exchange cryptographic keys. There are several key exchange methods used to implement TLS, including:

Diffie-Hellman is one of the most common key exchange methods. It’s an asymmetric key exchange protocol that allows two parties—with no prior knowledge of each other—to generate a shared secret key for secure communications over an insecure channel. Its security relies on the difficulty of solving the discrete logarithm problem, a complex mathematical problem that makes it computationally infeasible to decipher the shared secret.

There are several variations of the Diffie-Hellman key exchange, including:

• Diffie-Hellman ephemeral (DHE): In DHE, “ephemeral” means a temporary or single-use key is generated for each session. This provides forward secrecy, ensuring that the compromise of long-term keys does not compromise past sessions. DHE is commonly used in TLS 1.2, although TLS 1.2 supports both DH and DHE.
  
  
• Elliptic Curve Diffie-Hellman (ECDH): ECDH is similar to DH but uses elliptic curve cryptography—which provides greater security with smaller key sizes. ECDH computations are therefore faster and less resource intensive. However, non-ephemeral cipher suites are not recommended by the IETF due to their lack of forward secrecy.
  
  
• Elliptic Curve Diffie-Hellman Ephemeral (ECDHE): This is the ephemeral version of ECDH, where temporary keys are generated for each session, providing forward secrecy. It is the mandated key exchange method for TLS 1.3.

RSA is an asymmetric encryption algorithm that relies on the mathematical complexity of factoring large prime numbers to generate key pairs. It uses a public-private key pair for encryption and decryption, making it suitable for secure data transmission and digital signatures. RSA is not supported in TLS 1.3 for key exchange due to security concerns (that is, it does not provide forward secrecy). However, it can be used for authentication.

A PSK is a shared secret key that was previously shared between the two parties using a secure channel before the TLS session. Users can establish a PSK during one TLS handshake and then use it to establish a new connection in another handshake; this is called session resumption with a PSK. It is recommended to use PSKs with DHE or ECDHE to provide forward secrecy.

Since the initial release of TLS 1.0 in 1999 (which was an upgrade to SSL version 3.0), the IETF has released three subsequent TLS versions:

• TLS 1.1, specified in RFC 4346, April 2006: This version contained minor security and editorial improvements, as well as clarifications.
  
  
• TLS 1.2, specified in RFC 5246, August 2008: This version was an update to TLS 1.1 and notably improved flexibility for negotiation of cryptographic algorithms.
  
  
• TLS 1.3, specified in RFC 8446, August 2018: This latest update improves security, performance and privacy by reducing latency with a zero-round-trip time (0-RTT) and simplifying negotiation, among other changes.

It’s important to note that, while TLS 1.3 can be implemented with a backward-compatibility mode, it is not directly compatible with previous TLS versions.