← Blog · May 7, 2026 · tls, security
TLS 1.2 vs TLS 1.3: What Actually Changed
TLS 1.3 (RFC 8446) was published in 2018 after four years of design and 28 drafts. It's not a polish of 1.2 — it's a substantial rewrite that drops a lot of baggage. Here's what's different and why each change matters in production.
The handshake: 2-RTT to 1-RTT
TLS 1.2's handshake takes two round trips before any application data flows. ClientHello → ServerHello + cert + ServerHelloDone → ClientKeyExchange + ChangeCipherSpec + Finished → ServerChangeCipherSpec + Finished. ThenHTTP can start.
TLS 1.3 collapses this to 1-RTT. The client guesses the key-exchange group in the first message and sends its key share immediately. The server picks a group, sends its key share, the certificate, and Finished. Client confirms, sends HTTP. One RTT instead of two — measurable as 20–100ms of saved latency on every fresh connection.
With 0-RTT (resumption with early data), TLS 1.3 can send application data in the very first packet. That cuts latency to zero — but 0-RTT is replay-vulnerable and should only be used for idempotent GET requests.
Cipher suites: cut from 300+ to 5
TLS 1.2 had hundreds of cipher suite combinations likeECDHE-RSA-AES256-GCM-SHA384. Each one bundled four choices: key exchange, authentication, cipher, MAC. Many were obsolete by the time they were standardized.
TLS 1.3 ships with exactly five suites:
TLS_AES_256_GCM_SHA384TLS_AES_128_GCM_SHA256TLS_CHACHA20_POLY1305_SHA256TLS_AES_128_CCM_SHA256TLS_AES_128_CCM_8_SHA256
Key exchange and authentication are negotiated separately and only one cipher family (AEAD) is allowed. The cipher suite reference shows which are recommended.
RSA key exchange: removed
In TLS 1.2 you could do RSA key exchange: the client encrypts a pre-master secret with the server's RSA public key. That's simple but has no forward secrecy — if the server's private key is ever compromised, every past recorded session can be decrypted.
TLS 1.3 forces (EC)DHE-only key exchange. Every session uses an ephemeral key pair generated for that session and thrown away after. Forward secrecy is no longer optional, no longer a checkbox — it's baked into the protocol.
Static RSA, RC4, 3DES, MD5, SHA-1, CBC mode: all gone
Every algorithm with known weaknesses or operational complexity got cut:
- RC4 — biased keystream, decryptable
- 3DES — Sweet32 birthday attack at 64-bit block size
- MD5, SHA-1 — collision attacks
- CBC mode — padding oracle attacks (Lucky 13, BEAST)
- Compression — CRIME attack
- Renegotiation — Triple Handshake attacks
TLS 1.3 only ships AEAD ciphers (AES-GCM, ChaCha20-Poly1305, AES-CCM). These encrypt and authenticate in one operation; no separate MAC step, no padding oracle surface area.
What stays the same
Certificates work the same — your X.509 cert from Let's Encrypt or any CA works for both 1.2 and 1.3. Server Name Indication (SNI) works the same. ALPN for HTTP/2 and HTTP/3 negotiation works the same. The PKI is unchanged.
Should you turn off TLS 1.2?
For public web traffic, no. TLS 1.3 adoption is over 95% in modern browsers, but you'll still see TLS 1.2 from older email clients, embedded devices, and long-tail HTTP clients. Cutting 1.2 will break things in the long tail without meaningfully improving security — 1.2 with modern AEAD suites and forward secrecy is still strong.
The right config in 2026:
- Support TLS 1.2 and 1.3
- Disable TLS 1.0, TLS 1.1, SSL 3.0, SSL 2.0
- Restrict TLS 1.2 to forward-secret AEAD suites only (the ones starting with ECDHE- and ending in -GCM or -POLY1305)
- Use Mozilla's "Intermediate" config as a starting point
Test what you actually offer with SSL Labs or openssl s_client -connect host:443 -tls1_2 -cipher ALL.