How TLS works

When a browser shows a padlock next to an address, the connection is protected by Transport Layer Security (TLS). TLS is the “S” in HTTPS, and it also secures email transfer, encrypted DNS and many other protocols. It runs on top of a reliable transport such as TCP and below the application, which hands it plain data and gets plain data back, while everything on the wire in between is protected.

TLS promises three things:

• Confidentiality. Nobody on the path can read the data.
• Integrity. Nobody can change, remove, reorder or insert data without being detected.
• Authentication. The client knows it is talking to the server it meant to reach, not to an impostor. (The server can also authenticate the client, but on the web it usually does not.)

This article describes TLS 1.3, the current version. It was defined in RFC 8446 in 2018, and RFC 9846 replaced that document in July 2026 with a revision that keeps the same protocol, clears up unclear passages and tightens some requirements. The article explains how TLS 1.3 delivers on these promises in a single round trip.

From SSL to TLS 1.3

TLS began as the Secure Sockets Layer (SSL), developed at Netscape in the mid-1990s. The IETF took over the design and renamed it; TLS 1.0 was published as RFC 2246 in 1999. Every version since has fixed weaknesses found in the one before, and old versions have been formally retired as attacks against them became practical.

TLS 1.3 was a deep redesign rather than an update. It removed every algorithm and feature that had caused trouble, encrypted far more of the handshake, and cut the handshake from two round trips to one. TLS 1.2 remains in wide use alongside it, because many older systems cannot speak 1.3.

The building blocks

TLS combines four kinds of cryptography, each with one job. Key exchange and signatures are explained in depth in how public-key cryptography works.

• Symmetric encryption protects the data itself. Both sides use the same secret key, and the algorithms are fast enough to encrypt everything a connection carries. TLS 1.3 uses only authenticated encryption (AEAD) algorithms, such as AES-GCM and ChaCha20-Poly1305 (RFC 8439), which encrypt the data and at the same time attach a tag that reveals any change to it.
• Key exchange lets two parties that have never met agree on a shared secret over a public channel. TLS 1.3 uses Diffie-Hellman key exchange, usually over elliptic curves such as X25519 (RFC 7748) or P-256. Each side picks a random private value and sends only a public value derived from it. Combining its own private value with the other side’s public value, each side computes the same shared secret, while an observer who sees only the public values cannot. Hybrid mechanisms such as X25519MLKEM768 (RFC 10024) combine this with a post-quantum algorithm, ML-KEM.
• Digital signatures prove who someone is. The server signs data with a private key that only it holds, and anyone can check the signature with the matching public key, found in the server’s certificate. TLS 1.3 uses RSA, ECDSA and EdDSA signatures.
• Hash functions turn data of any length into a short fingerprint. TLS 1.3 uses SHA-256 or SHA-384, both to fingerprint the handshake and, through a construction called HKDF (RFC 5869), to derive all its keys from the shared secret.

Inside TLS, two layers use these tools. The handshake protocol negotiates the parameters, authenticates the server and establishes the keys. The record protocol then uses those keys to protect the data in both directions.

The TLS 1.3 handshake

A full TLS 1.3 handshake needs a single round trip before the client can send application data. Messages in braces are already encrypted.

1. ClientHello. The client opens with a message that already contains everything the server needs to complete the key exchange:

• a fresh random value;
• the TLS versions it supports, in the supported_versions extension;
• the cipher suites, key exchange groups and signature algorithms it supports;
• one or more key shares: public Diffie-Hellman values for the groups it expects the server to choose, such as X25519;
• the server name it wants to reach, in the Server Name Indication (SNI, RFC 6066) extension, so that one server can host many sites;
• the application protocols it can speak, such as HTTP/2 or HTTP/1.1, in the ALPN extension (RFC 7301).

Sending a key share in the first message is the decisive change from TLS 1.2, where the client sent its part of the key exchange only in its second flight.

2. ServerHello. The server chooses a version, a cipher suite and one of the client’s key shares, and answers with its own key share. Both sides can now compute the Diffie-Hellman shared secret and derive handshake keys from it. Everything that follows is encrypted.

3. The server’s encrypted messages. In the same flight, the server sends:

• EncryptedExtensions: the remaining negotiated settings, such as the chosen application protocol;
• Certificate: its certificate chain, which binds its public key to its name;
• CertificateVerify: a signature, made with the certificate’s private key, over a hash of the whole handshake so far. It proves that the server holds the private key, and that it saw the same handshake as the client;
• Finished: a message authentication code over the whole handshake, computed with a key derived from the handshake secret.

4. The client’s Finished. The client checks the certificate chain, the signature and the Finished message. If all are valid, it sends its own Finished, and both sides switch to application keys. The client can send its request immediately after its Finished, one round trip after it started.

If the client guessed wrong and sent no key share for a group the server accepts, the server answers with a HelloRetryRequest naming the group it wants, and the client starts again with a suitable key share. This costs an extra round trip, which is why clients send a share for the group servers most commonly prefer.

Cipher suites

In TLS 1.3, a cipher suite names only two things: the AEAD algorithm for the records and the hash function for the key derivation. The key exchange and the signature algorithm are negotiated separately. The specification defines five suites:

Protection against downgrades

An attacker in the middle might try to change the client’s offer, for example by removing TLS 1.3 from it, so that both sides fall back to an older version with known weaknesses. Within TLS 1.3, the whole handshake, including the client’s offer, is covered by the server’s signature and by both Finished messages, so any change is detected. To stop a fallback to an older version, a TLS 1.3 server that negotiates TLS 1.2 or below writes a fixed marker, the ASCII letters DOWNGRD followed by one more byte, into the last eight bytes of its random value. A TLS 1.3 client that sees the marker aborts the connection.

From one secret to many keys

TLS 1.3 never uses the Diffie-Hellman result as a key directly. A key schedule turns it into a family of independent secrets with HKDF, which has two steps: Extract concentrates the randomness of its inputs into one strong secret, and Expand derives as many separate keys from that secret as needed, each labeled with its purpose.

Two details make the schedule robust:

• Every key is bound to the handshake. The derivations mix in a hash of all handshake messages so far, the transcript hash. If an attacker changed any message, the two sides would derive different keys, and the connection would fail.
• Every direction and phase has its own key. Client and server use different keys, and the handshake keys are never used for application data. Long-lived connections can even replace their application keys at any time with a KeyUpdate message, so that each key protects only a limited amount of data.

Forward secrecy

The Diffie-Hellman values are ephemeral: both sides create new ones for every connection and discard them afterwards. Older TLS versions also allowed RSA key transport, in which the client encrypted the secret with the server’s long-term public key. Anyone who recorded such a connection and later stole that private key, even years later, could decrypt it. With ephemeral keys, the private key of the certificate is only used to sign; it cannot decrypt anything. This property is called forward secrecy, and TLS 1.3 requires it for every full handshake.

Certificates: who is on the other end

Encryption is worthless if the client is talking to the wrong server. The server proves its identity with a certificate: a document in the X.509 format (RFC 5280) that binds a public key to one or more names, such as www.example.com, and that is signed by a certificate authority (CA).

Operating systems and browsers ship with a trust store: a list of root CA certificates they trust. Usually, a root CA does not sign server certificates itself: it signs certificates for intermediate CAs, which issue the certificates of servers. To validate a server’s certificate, the client checks that:

1. every signature in the chain is valid, up to a root in its trust store;
2. every certificate is within its validity period;
3. the name the client wanted to reach appears in the certificate’s subject alternative name field (RFC 9525); the older common name field is no longer used for this;
4. the certificate is allowed to be used for a TLS server and has not been revoked.

The certificate alone proves nothing, since it is public and anyone can copy it. The proof is the CertificateVerify signature: only the holder of the matching private key can sign the handshake.

Two developments have made this system far more reliable:

• Certificate Transparency (RFC 6962, with a version 2.0 in RFC 9162): certificate authorities record the certificates they issue in public, append-only logs, which anyone can monitor, and browsers can refuse certificates that were not logged. A certificate issued by mistake or by a compromised CA becomes visible to the domain owner.
• Automation. The ACME protocol (RFC 8555) lets a server prove to a certificate authority that it controls a domain, and obtain and renew its certificate without human help, which makes short certificate lifetimes practical.

The record protocol

After the handshake, all data travels in records. Each record carries at most 2¹⁴ bytes (16 KiB) of data, encrypted and authenticated with the current traffic key.

• Every record has a unique nonce. The nonce combines a fixed value from the key schedule with a 64-bit record sequence number that both sides count but never send. A record that is replayed, removed or moved fails authentication, because the receiver decrypts it with the wrong number.
• The content type is hidden. On the wire, every encrypted record looks like application data; its real type (data, handshake message or alert) is inside the encryption. Records can also be padded, so that their size reveals less about their contents.
• Alerts report errors and closure. A side that is done sends a close_notify alert, so that the other side can tell a complete transfer from a connection cut off by an attacker.

Resumption and 0-RTT

After a handshake, the server can send the client a session ticket. When the client connects again, it presents the ticket and a value derived from the earlier connection, a pre-shared key (PSK), and both sides skip the certificate exchange. Tickets may be valid for at most seven days. Clients normally combine the PSK with a new Diffie-Hellman exchange, which keeps forward secrecy for the new connection.

Resumption also allows 0-RTT (“zero round trip”) data: the client sends a request together with its very first message, encrypted with a key derived from the PSK. The server can answer at once, saving a full round trip. The price is security. Early data does not have forward secrecy with respect to the PSK, and an attacker can record it and replay it to the server. 0-RTT is therefore only safe for requests that may be repeated without harm, such as fetching a page. HTTP defines a status code for servers that refuse early data, 425 Too Early (RFC 8470).

The chart counts the transport handshake too. TCP needs a round trip of its own before TLS can start, which is one reason why QUIC, the transport under HTTP/3, merges the two handshakes into one.

What TLS 1.3 removed

What TLS does not hide

TLS protects the contents of a connection, not the fact that it exists. An observer on the path can still see:

• the IP addresses and ports of both ends;
• the server name in the SNI extension, which the client sends unencrypted. The Encrypted Client Hello (ECH) extension, standardized in RFC 9849 in 2026, encrypts the ClientHello, including the server name, with a key the server publishes in its DNS HTTPS record (RFC 9848);
• the timing and sizes of the records, from which much can sometimes be inferred.

TLS also protects only the path between the two ends. Data is readable again on the server, and a connection is only as trustworthy as the certificate checks the client performs.

Key points

• TLS provides confidentiality, integrity and authentication for a connection. TLS 1.3 (RFC 8446, revised as RFC 9846) is the current version; SSL and TLS 1.0 and 1.1 are retired.
• The TLS 1.3 handshake takes one round trip: the client sends its key share at once, and everything after ServerHello is encrypted.
• Ephemeral Diffie-Hellman provides forward secrecy. HKDF derives separate keys for each direction and phase, all bound to the handshake transcript.
• Certificates, chained to a trusted root and checked against the server name, prove who the server is; the CertificateVerify signature proves that it holds the private key.
• Resumption skips the certificate exchange, and 0-RTT saves a round trip at the cost of possible replays.