How Does TLS Work?

Sam Erickson
Updated 21 hours ago
0

Key Takeaways

The TLS handshake authenticates the server and establishes keys for protecting subsequent communication.
Modern TLS derives traffic keys from shared secrets; TLS 1.3 does not send a session key encrypted with the certificate’s public key.
Certificate validation requires both a trusted certificate chain and a match for the requested hostname.
TLS protects data between its endpoints. It does not make a website trustworthy or eliminate application vulnerabilities.

TLS, or Transport Layer Security, protects communication by authenticating the server, establishing cryptographic keys, and using those keys to encrypt data and detect tampering. The handshake lays the groundwork for the protected conversation that follows.

For web developers, this is the security behind HTTPS. If you’re wondering why certificates are still called “SSL certificates,” see SSL vs TLS; the protocol to understand here is TLS.

The TLS Handshake Explained

We’ll follow a full, certificate-authenticated TLS 1.3 handshake using ephemeral elliptic-curve Diffie–Hellman, or ECDHE. “Ephemeral” means the key-agreement keys are temporary rather than the server’s long-term certificate keys. Session resumption and 0-RTT early data are outside this basic walkthrough.

The TLS 1.3 specification separates three jobs: negotiating connection parameters, establishing shared secrets, and authenticating the handshake. Here’s the simplified message flow:

Browser                                         Server
   |                                               |
   | ClientHello: versions, suites, key share ----> |
   | <---- ServerHello: version, suite, key share   |
   |                                               |
   |       Both derive handshake encryption keys   |
   |                                               |
   | <---- {EncryptedExtensions}                   |
   | <---- {Certificate, CertificateVerify}        |
   | <---- {Finished}                              |
   |                                               |
   | Validate certificate, signature, and Finished |
   | {Finished} ---------------------------------> |
   |                                               |
   | <==== Encrypted application data ============> |

{...} = encrypted handshake messages
Optional messages and alternative flows are omitted.

For actual message bytes rather than a conceptual diagram, RFC 8448 provides example TLS 1.3 handshake traces.

1. The client sends ClientHello

The browser advertises supported TLS versions, cipher suites, signature algorithms, and key-agreement groups. For our ECDHE example, it also sends an ephemeral public key share while keeping the corresponding private key secret.

The server’s ServerHello identifies the selected version and cipher suite and supplies its public key share. These choices must fit the client’s offers and the server’s security policy; the server isn’t choosing an objectively “optimal” protocol.

In TLS 1.3, a cipher suite specifies authenticated encryption and a hash used in key derivation and handshake authentication. Key agreement and signature algorithms are negotiated separately.

3. Both sides derive handshake keys

Each endpoint combines its private ECDHE key with the other endpoint’s public share to calculate the same shared secret independently. The shared secret itself never travels across the network.

TLS derives handshake keys from that secret and the handshake context. Messages after ServerHello are encrypted, starting with EncryptedExtensions, which carries additional negotiated parameters.

4. The server presents its certificate and proves possession of its key

The server sends a Certificate message containing its certificate chain, followed by CertificateVerify. CertificateVerify signs handshake data using the private key corresponding to the server certificate, proving possession of that key and binding the authentication to this handshake.

The browser validates the chain, checks the requested hostname and applicable certificate constraints, and verifies the signature. Receiving a certificate alone is not proof: certificates contain public information that an attacker could copy.

5. The browser verifies the server’s Finished message

Finished contains a message authentication code: a cryptographic check calculated with a derived secret over the handshake transcript. The transcript is the ordered record of handshake messages exchanged so far.

Verifying Finished confirms that the peer derived the expected secrets and that the handshake messages covered by the check weren’t altered. A failed verification terminates the connection.

6. The client sends Finished and protected HTTP traffic begins

The browser sends its own encrypted Finished message, which the server verifies. Application traffic uses separately derived keys, with different keys for each direction.

Authenticated encryption protects the confidentiality and integrity of the HTTP messages, including headers and bodies. That means a network observer cannot simply read or silently rewrite the protected requests and responses.

TLS Certificates and Certificate Authorities

A certificate chain connects the server’s key to a trusted issuer

A certificate binds a public key to names and other attributes through an issuer’s digital signature. Servers commonly send a leaf certificate—the website’s certificate—plus intermediate CA certificates that help the client build a path to a trusted root.

The root is trusted because of the client’s configured trust store, not because the server supplied it. Let’s Encrypt’s chain-of-trust documentation illustrates how leaf, intermediate, and root certificates fit together.

Server certificate --> Intermediate CA --> Trusted root
        |
        +-- Separate check: does it cover the requested hostname?

Trusting a CA signature is not enough

The browser combines certificate-path validation with application-specific identity checks. Important checks include:

Certificate signatures and a path to an accepted trust anchor.
Validity dates and applicable CA, key-usage, and certificate constraints.
A match between the requested hostname and an appropriate Subject Alternative Name in the leaf certificate.

Hostname verification is separate from trusting the issuer: a valid certificate for one hostname does not authenticate another hostname. Clients also apply revocation and trust policies; they don’t all perform identical online revocation checks.

Certificate Authorities are not infallible

Validation depends on certificate type. A domain-validated certificate establishes domain control, not the legal identity of the organization operating the website. Other profiles can validate additional organizational details.

A CA can misissue a certificate, and a compromised trusted CA can enable impersonation. A valid certificate also says nothing about whether a site’s content or business is benign. The trust model depends on both sound issuance and correct client validation.

How TLS Key Exchange Provides Forward Secrecy

Forward secrecy means that stealing the server’s long-term certificate private key later does not, by itself, reveal previously recorded sessions. With ephemeral key agreement, those sessions depend on temporary secrets that must be erased when no longer needed.

This is why the distinction between signing and key agreement matters. The certificate key authenticates the handshake; it is not the ECDHE private key. RFC 9325 explains forward secrecy and secure TLS deployment, including the limits of certificate revocation.

TLS 1.2 vs. TLS 1.3 Handshakes

TLS 1.3 is the clearest modern example, but TLS 1.2 remains in use. They don’t share one universal handshake sequence.

Aspect	TLS 1.2	TLS 1.3
Key establishment	Historically supported static RSA transport as well as ephemeral key agreement.	Removes static RSA key transport; supports ephemeral key agreement and pre-shared-key modes.
Cipher suites	Combine more choices, including key exchange and authentication.	Specify authenticated encryption and a hash; key exchange and signatures are separate.
Handshake privacy	The server certificate is normally sent before encryption begins.	Handshake messages after ServerHello are encrypted.

The old explanation that “the client encrypts a session key with the server’s public key” describes static RSA key transport, not TLS 1.3. Even historically, RSA transported a premaster secret from which keys were derived—not the final traffic key. RFC 10015 now prohibits RSA key transport in TLS 1.2; an RSA certificate can still be used for signatures.

Server Authentication Is Not User Authentication

Ordinary browser HTTPS authenticates the server without requiring a client certificate. Mutual TLS, or mTLS, additionally authenticates the client using a client certificate and proof of its private key.

Both connections can provide encryption and integrity. Neither automatically defines your application’s authorization rules: identifying a client does not decide which records it may access. For application-level identity flows, see how OAuth 2.0 works.

Where SNI and ALPN Fit

Server Name Indication (SNI) tells the server which hostname the client wants, helping it select a certificate when multiple sites share an address. It does not replace hostname verification.
Application-Layer Protocol Negotiation (ALPN) negotiates the application protocol, such as HTTP/2, rather than the TLS version. In TLS 1.3, the server’s selection is carried in EncryptedExtensions.

What TLS Does Not Protect

Correctly implemented TLS with valid certificate checking protects against passive eavesdropping and network impersonation under its trust assumptions. Disabling validation, accepting an attacker’s certificate, or compromising an endpoint can defeat those protections.

TLS does not encrypt data after the receiving endpoint decrypts it, and it does not fix application vulnerabilities such as broken authorization. Treat transport security and application security as separate responsibilities.

Also identify where TLS ends. If a reverse proxy terminates TLS, it can read the decrypted traffic, and its connection to your application is a separate security decision. Cloudflare’s edge and origin connection documentation illustrates this distinction; our proxy server explanation covers the underlying architecture.

Production Checklist

Use the OWASP TLS checklist when turning the handshake model into deployment decisions:

Prefer TLS 1.3. If compatibility requires TLS 1.2, use ECDHE with authenticated encryption; disable SSL and TLS 1.0/1.1.
Keep certificate and hostname verification enabled, including on backend connections.
Serve the needed intermediate certificates, automate renewal, and monitor expiration.
Document every TLS termination point and protect each subsequent network hop appropriately.

FAQ

What happens during a TLS 1.3 handshake?

The client and server negotiate parameters, establish shared secrets, and authenticate the server through its certificate and handshake signature. Finished messages confirm the handshake and derived secrets before the basic flow proceeds to protected application traffic.

Does TLS encrypt a session key with the server’s public key?

Not in TLS 1.3. In an ECDHE handshake, both endpoints derive secrets independently from ephemeral key shares, while the certificate’s public key verifies the server’s signature. Static RSA key transport belongs to older handshake designs.

How does a browser validate a TLS certificate?

It checks a certificate path to a trusted issuer, validity dates, applicable constraints, and whether the certificate covers the requested hostname. Revocation and additional trust checks depend on client policy; a valid certificate does not establish that a website is benign.

What is the difference between TLS 1.2 and TLS 1.3?

TLS 1.3 separates cipher selection from key exchange and signatures, encrypts handshake messages after ServerHello, and removes static RSA key transport. TLS 1.2 uses a different handshake and needs careful configuration to retain forward secrecy.

Does HTTPS authenticate the client as well as the server?

Ordinary browser HTTPS generally authenticates only the server at the TLS layer. Mutual TLS additionally authenticates the client using a client certificate and proof of its private key; application authorization remains a separate responsibility.