TLS protocol

What TLS promises

Client authentication with certificates is possible too, but most public websites authenticate only the server. The application handles user login separately.

Two kinds of cryptography work together

Asymmetric cryptography uses a public and private key pair. It is useful for signatures and agreeing secrets without already sharing one, but is comparatively expensive. Symmetric cryptography uses the same secret key at both ends and protects bulk data efficiently.

TLS combines them. An ephemeral Diffie–Hellman exchange lets both sides independently derive the same temporary secret without sending that secret across the network. The server signs the handshake with its private key, proving the exchange belongs to the certificate holder. Derived symmetric keys then protect the application data.

Modern ephemeral key exchange provides forward secrecy: stealing the server’s long-term private key later should not decrypt old captured sessions, because their temporary secrets have gone.

Certificates and the chain of trust

A certificate is a signed document binding a public key to identities—most importantly DNS names in its Subject Alternative Name field. It includes validity times, an issuer and constraints. It does not contain the server’s private key.

1. The server sends its certificate chain. Usually this contains the leaf certificate and one or more intermediate CA certificates.
2. The client builds a chain. Each certificate’s signature is checked up to a root certificate already trusted by the operating system or browser.
3. The client checks the name. The requested host must match a permitted name in the leaf certificate.
4. It checks time and purpose. The certificate must be currently valid and authorised for server authentication.
5. The server proves possession. A valid signature over the handshake shows it owns the private key corresponding to the leaf certificate.

A certificate authority verifies control of a name before issuing a certificate. The chain is a delegated trust system: root keys are kept highly protected and sign intermediates; intermediates perform day-to-day issuance.

A TLS 1.3 handshake, step by step

With a new connection, useful application data can normally begin after one network round trip.

1. ClientHello. The client offers TLS versions, cipher suites, a fresh random value, one or more ephemeral key shares, the requested server name (SNI), and application protocols such as HTTP/2 via ALPN.
2. ServerHello. The server selects compatible parameters and sends its ephemeral key share. Both sides can now calculate handshake keys.
3. Encrypted server authentication. The server sends encrypted extensions, its certificate chain, a CertificateVerify signature and Finished proof. The client validates them.
4. Client Finished. The client proves it saw the same handshake. Application data can now flow under fresh traffic keys.

Every Finished message authenticates a transcript hash of the handshake, binding the negotiation together so an attacker cannot silently change the chosen parameters.

How application data is protected

TLS breaks data into records. TLS 1.3 uses authenticated encryption with associated data (AEAD), such as AES-GCM or ChaCha20-Poly1305. Each protected record gets confidentiality and an authentication tag. The receiver rejects it if verification fails.

Client-to-server and server-to-client traffic use different keys and nonces. Sequence information prevents a captured valid record from simply being replayed within the connection. TLS also periodically allows new traffic keys to be derived with KeyUpdate.

TLS protects bytes between its two endpoints. At a reverse proxy, CDN or corporate inspection gateway, one TLS connection may end and another begin. Data is plaintext inside each endpoint while being processed.

Versions, cipher suites and negotiation

TLS 1.3 deliberately removed obsolete choices and redesigned the handshake. TLS 1.2 can still be securely configured, but older SSL and early TLS versions should not be used.

The peers choose from compatible offers; a downgrade defence binds the chosen version into the handshake. In TLS 1.3, key exchange and signature choices are no longer bundled into the cipher-suite name.

Session resumption and 0-RTT

After a successful connection, a server can issue a resumption ticket. On a later connection the client proves knowledge of the ticket’s secret, avoiding full certificate authentication work and reducing delay. Fresh ephemeral exchange can still preserve forward secrecy.

TLS 1.3 can allow 0-RTT early data to be sent with the first client flight. It is faster, but it can be replayed by an attacker even though it remains encrypted. Applications must restrict early data to replay-safe actions. A GET may be suitable if it truly has no side effects; a payment or state-changing request is not.

What TLS does not hide—and how it fails

Observers still see metadata such as IP addresses, connection times, duration and approximate traffic volume. Standard TLS has historically exposed the requested name in SNI; Encrypted ClientHello can protect that name when the client, DNS setup and server all support it. The server endpoint still sees application data.

TLS cannot protect a compromised endpoint, stop a user submitting secrets to a convincing malicious domain, fix vulnerable application code, or guarantee availability. It secures a channel; the systems and decisions at either end still matter.