Understanding TLS 1.3
I've been digging into TLS recently, specifically what changed between 1.2 and 1.3, and why those changes matter. This post is a summary of what I learned.
TLS establishes shared cryptographic keys between client and server, authenticates the server via certificates, and uses those keys to encrypt and integrity-protect application data. Everything depends on the handshake, the negotiation that happens before any application data moves.
Despite the name "Transport Layer Security," TLS doesn't actually operate at the transport layer. It sits above TCP (layer 4), around layers 5-6 of the OSI model - handling session management and encryption. It acts as a secure bridge between the transport layer below and application protocols like HTTP above.
TLS 1.2 requires two round trips before data flows. The client sends a hello, the server responds with certificate and key exchange parameters, the client completes its side, the server confirms, then data moves. TLS 1.3 collapses this to one round trip by having the client include key exchange material in its first message. At scale, millions of connections, mobile users on high-latency networks, removing a full round trip adds up.
The most important concept I came across was forward secrecy. Perfect Forward Secrecy (PFS) means that if an attacker steals the server's private key tomorrow, they cannot retroactively decrypt traffic they captured today. Each session uses ephemeral keys that are discarded after use. In TLS 1.2, forward secrecy was optional, RSA key exchange was widely supported, which meant recorded traffic could be decrypted later if the key was compromised. TLS 1.3 removed RSA key exchange entirely. Ephemeral Diffie-Hellman is the only option now. Forward secrecy is no longer a configuration choice; it's built into the protocol.
TLS 1.2 cipher suites bundled multiple algorithms (key exchange, authentication, encryption, MAC) into single identifiers, creating many combinations, some unsafe. TLS 1.3 removed weak options entirely. Fewer choices, but all secure by default. The same thinking applies to handshake encryption, TLS 1.2 transmitted metadata in cleartext, while TLS 1.3 encrypts more of the handshake earlier. SNI remains exposed in most deployments, but passive observers learn less overall.
TLS 1.3 also removed renegotiation complexity, compression-related attack vectors, and outdated cipher constructions. The reasoning: if a feature has repeatedly caused vulnerabilities, remove it.
One addition worth noting is 0-RTT. During session resumption, the client can send application data immediately, before the handshake completes. The tradeoff: 0-RTT data is replayable. An attacker who captures it can retransmit it. This makes it suitable for idempotent operations (fetching static resources) but unsafe for anything with side effects (payments, state changes).
Summary
| TLS 1.2 | TLS 1.3 | |
|---|---|---|
| Round trips | 2 (client waits for server params before completing) | 1 (client sends key material upfront) |
| Forward secrecy | Optional (RSA key exchange still supported) | Mandatory (ephemeral Diffie-Hellman only) |
| Cipher suites | Many combinations, some unsafe | Reduced to 5 secure options |
| Handshake encryption | Certificate and negotiation visible to observers | Encrypted after ServerHello |
| 0-RTT | Not available | Optional (replayable, so idempotent requests only |
The key takeaway for me: the biggest source of TLS vulnerabilities has been configuration, not the protocol itself. TLS 1.3 addresses this by removing unsafe options. The secure path is now the only path.
Practically, this means preferring TLS 1.3 where possible. If running TLS 1.2 for compatibility, prioritise forward-secrecy suites and disable RSA key exchange. If using 0-RTT, document the decision and limit it to idempotent operations.
Resources
If you want to know what I've read, take a look at these resources:
RFC 8446 – full specification
tls13.ulfheim.net – visual handshake walkthrough