TLS: Transport Layer Security

What TLS is

TLS (Transport Layer Security) runs on top of TCP and gives an application confidentiality, integrity, and server authentication for everything it sends — it's the protocol behind HTTPS, and most other secure application traffic besides. It's the standardized successor to Netscape's SSL: SSL 2.0 and 3.0 and TLS 1.0 and 1.1 are now all considered broken or obsolete and should not be enabled. The current standard is TLS 1.3, defined in RFC 8446 (2018), which this lesson focuses on — it's a significant redesign over TLS 1.2, not just a version bump, removing an entire category of legacy weak cipher suites and cutting the handshake down to a single round trip.

The TLS handshake

Before any application data moves, the client and server run a handshake to agree on a protocol version, a cipher suite, and a set of session keys, and to let the client authenticate the server. TLS 1.3's headline change is that this now takes one round trip (1-RTT): the client sends a ClientHello that already guesses which key-exchange group the server will pick and includes its own key share, so if the server accepts that guess, it can reply with everything needed — its own key share, certificate, and a proof of identity — in a single flight back. TLS 1.2 needed two full round trips to get to the same point, because the client had to wait to learn the server's chosen parameters before it could send its own key material.

Key exchange and cipher suites

TLS 1.3 only supports (EC)DHE key exchange — the Diffie-Hellman exchange from the previous lesson, run with ephemeral (freshly generated, thrown away after one session) key pairs on elliptic curves. This is a deliberate removal: TLS 1.2 also allowed static RSA key exchange, where the client encrypted a premaster secret directly with the server's long-term public key — a design with no perfect forward secrecy, since recording the traffic and later stealing that one long-term private key would decrypt every past session it was ever used for. Because every (EC)DHE exchange generates a brand-new ephemeral key pair, compromising the server's long-term certificate key later does not expose any past session's traffic.

Certificates and server authentication

Key exchange alone proves the two sides share a secret — it says nothing about who is on the other end, which is exactly the gap a man-in-the-middle attack exploits. TLS closes it with a certificate: the server sends an X.509 certificate binding its public key to a hostname, signed by a certificate authority the client already trusts (the PKI lesson covers exactly how that trust chain is built and verified), and then proves it actually holds the matching private key by signing the handshake transcript itself. The client also sends the hostname it's trying to reach in cleartext, in an extension called SNI (Server Name Indication) — necessary because many unrelated sites can share one IP address, so the server needs to know which certificate to present before the handshake can even complete.

Interactive TLS handshake

Step through a complete TLS 1.3 handshake in one round trip: the client's guessed key share, the server's response bundling its own key share, certificate, and proof of identity, and the final exchange that unlocks encrypted application data.

TLS record protocol and data protection

Once the handshake derives session keys, the record protocol takes over: every subsequent record is encrypted and integrity-protected together using an AEAD (Authenticated Encryption with Associated Data) cipher such as AES-128-GCM or ChaCha20-Poly1305 — a single operation that provides both confidentiality and the same tamper-detection an HMAC would, without needing a separate MAC computation. This is the layer that actually carries the HTTP request and response once the handshake is done; everything before this point exists purely to get two strangers to this shared, authenticated key.

Inspect TLS evidence

openssl s_client -connect host:443 -tls1_3 forces a TLS 1.3 connection and prints the negotiated cipher suite and the full certificate chain — useful for confirming a server actually supports 1.3 rather than silently falling back. Adding -servername host sends SNI explicitly, which matters when testing a server that hosts multiple sites on one IP.

Guided TLS handshake practice

Work through why removing static RSA key exchange specifically improves confidentiality over time, not just at the moment of the handshake. Suppose an attacker records a full year of a server's encrypted traffic without being able to decrypt any of it in real time. A year later, the attacker compromises the server and steals its long-term private key. Under TLS 1.2's static RSA key exchange, that one stolen key would let the attacker decrypt every recorded session from that entire year, because each session's premaster secret was encrypted directly with that same long-term public key. Under TLS 1.3's mandatory (EC)DHE, every session generated its own ephemeral key pair that was discarded immediately after use — the stolen long-term key only proves the server's identity during future handshakes and cannot reconstruct any past session's keys.

Troubleshoot TLS

1. Confirm which TLS version was actually negotiated (openssl s_client or a packet capture) rather than assuming — a client falling back to an older version it still supports can hide a server misconfiguration.
2. Check for a cipher suite mismatch: if the client and server share no common cipher suite for the negotiated version, the handshake fails immediately with no application-layer error.
3. Walk the certificate chain from leaf to root and confirm every intermediate is present — exactly the same most-common cause of "untrusted certificate" errors covered in the fundamentals lesson, but now specific to this one connection.
4. Confirm the hostname the client requested (via SNI) matches a name on the certificate the server presented — a mismatch here, not a broken handshake, is the single most common cause of browser certificate warnings.
5. Check for significant clock skew between client and server; certificate validity windows depend on both having roughly correct time.
6. Rule out a middlebox performing TLS interception (common in some corporate networks), which replaces the real server's certificate with one the client was never told to trust.

Knowledge check and summary

Pro deep dive