Networking and Protocols

TLS

Cryptographic protocol that secures client server traffic against eavesdropping and tampering.

Where you will see it: Shows up in packet captures, network diagrams, firewall rules, and system or network logs.

What it is

TLS (Transport Layer Security) is the standard way to secure traffic between two endpoints on the Internet. It provides confidentiality (encryption), integrity (tamper detection), and endpoint authentication, most commonly authenticating the server to the client.

Key points
  • Handshake negotiates versions, ciphers, and keys, then the record layer protects data.
  • Server authentication relies on certificate chains and hostname verification.
  • TLS 1.3 reduces handshake round trips and removes many legacy features.

How it works in broad strokes

  1. The client connects to the server and sends a ClientHello with supported protocol versions, cipher suites, and random values.
  2. The server replies with ServerHello, chooses parameters, and provides key exchange material. In TLS 1.3, this establishes handshake keys quickly.
  3. The server sends its certificate chain and proves possession of the private key, and the client verifies the chain and the hostname.
  4. Both sides derive shared secrets and switch to encrypted records for the rest of the session.
  5. Application data is split into records that are encrypted and integrity protected.
  6. Features like session resumption allow later connections to skip parts of the handshake for speed.
  7. When the connection ends, keys are discarded. Good implementations also rotate keys and enforce modern versions.

Concrete example

When you visit a banking site, your browser performs a TLS handshake, verifies that the certificate matches the bank's domain, and then encrypts all HTTP traffic so WiFi attackers cannot read your credentials or alter the page.

Why it matters

Without TLS, anyone on the path can read or modify traffic. TLS exists so that applications can safely use the public Internet and still have private, trustworthy communication.

Security angle

  • TLS security depends on correct certificate validation and trusted root stores.
  • Modern guidance is to prefer TLS 1.3 and strong cipher suites and to disable legacy renegotiation and older versions.
  • Operationally, manage certificates like credentials: track expiry, automate renewal, and monitor for misissuance.

Common pitfalls

  • Skipping hostname verification. A valid certificate for the wrong name is not safe.
  • Allowing outdated protocols or weak ciphers for compatibility.
  • Forgetting that TLS does not secure the endpoint itself. Compromised clients can still leak secrets.
  • TLS terminating proxies can break end to end assumptions and change what network monitoring can see.
  • Misunderstanding certificate errors as optional. They are usually your only warning of interception.

DEEP DIVE

▾

What TLS provides and where it sits

TLS sits above a transport like TCP and below application protocols like HTTP. The transport delivers bytes. TLS turns those bytes into a protected channel with confidentiality, integrity, and optional client authentication. It does this by agreeing on keys and algorithms, then wrapping application data into encrypted records.

TLS is not just encryption. Integrity is equally important. Each record is authenticated, so a passive attacker cannot alter traffic without detection. This is why HTTPS protects you from tampering even on hostile WiFi, not only from eavesdropping.

Because TLS is layered, you can often reason about issues by separating layers. If TCP is unstable you see retransmissions and resets. If TLS is failing you see handshake alerts, certificate errors, or mismatched protocol expectations even when TCP connectivity exists.

TLS 1.3 handshake in real life

A typical TLS 1.3 connection starts with a ClientHello. The client offers supported protocol versions, cipher suites, and key shares for ephemeral Diffie Hellman. It may also include SNI to tell the server which hostname it wants, and ALPN to negotiate application protocols like HTTP/2.

The server replies with ServerHello selecting parameters and providing its own key share. From that point, both sides can derive handshake keys and encrypt much of the remaining handshake. The server sends its certificate and proof of possession, then both sides exchange Finished messages that confirm they saw the same transcript and derived the same keys.

After Finished, application data records flow, protected by AEAD ciphers. TLS 1.3 is designed to reach this point with one round trip in the common case, which is why modern HTTPS feels faster than older TLS versions on high latency networks.

Certificates, identity, and why validation matters

The certificate is how the client knows it is talking to the right server, not an impostor. The server presents a certificate chain that links back to a trusted root in the client trust store. The client validates the chain signatures, checks expiration, and verifies that the certificate matches the hostname it intended to reach.

If validation fails, you get the familiar browser warnings. A common failure is a hostname mismatch, which can happen if SNI is missing or if a load balancer serves the wrong certificate. Another is an incomplete chain where an intermediate certificate was not served correctly.

In enterprise environments, TLS interception adds another twist. A proxy can terminate TLS and present a different certificate signed by an internal CA. That works only if the client trusts that CA. If not, it looks like an attack, which is accurate from the client viewpoint.

After the handshake: records, resumption, and key updates

Once established, TLS sends data as a sequence of records. Each record has its own authentication tag, and sequence numbers prevent replay and reordering tricks. If you capture traffic, you will still see packet sizes and timing, but the content is opaque.

To reduce latency on repeat visits, servers can enable resumption. The client can present a session ticket and resume with fewer round trips. TLS 1.3 also defines 0 RTT data, but that feature can allow replay of early data, so it is typically restricted to idempotent requests.

TLS also supports key updates during a long connection. Periodically refreshing keys reduces the amount of data protected under any single key and limits damage if a key were somehow compromised. In practice, most sessions are short enough that you rarely notice this, but the mechanism is part of what makes TLS robust at scale.