← Week 3: mTLS and TLS Extensions

Day 20: TLS 1.3 vs 1.2 — What Changed and Why

Phase 1 · June 2, 2026

← Week 3: mTLS and TLS Extensions

Agenda (2–3 hours)

  • Read (60 min): RFC 8446 Appendix C (backward compat), Appendix D (security analysis), RFC 5246 §7.4 overview (skim for comparison)
  • Study (45 min): Each removed feature and the attack that motivated its removal
  • Practice (30 min): Connect with TLS 1.2, compare output
  • Challenge (45 min): Feature removal rationale table
← Week 3: mTLS and TLS Extensions

What TLS 1.3 Eliminated

Removed Feature Attack / Reason
RSA key transport No forward secrecy; ROBOT attack
Static DH / ECDH No forward secrecy
CBC mode ciphers BEAST, LUCKY13, POODLE
RC4 stream cipher RC4 biases, practical decryption
MD5, SHA-1 in signatures Collision attacks
PKCS#1 v1.5 RSA Bleichenbacher / ROBOT
Compression CRIME attack
Renegotiation Triple Handshake, CVE-2009-3555
Export cipher suites FREAK, Logjam
Extended Master Secret Triple Handshake (patched in 1.2 via RFC 7627)
← Week 3: mTLS and TLS Extensions

RSA Key Transport vs ECDHE (The Biggest Change)

TLS 1.2 with RSA key exchange:

Client → Server: encrypt(server_pub_key, pre_master_secret)

If the server's private key is ever compromised → all past sessions can be decrypted.
This makes passive recording + later key theft catastrophically effective.

TLS 1.3 with ECDHE:

Client + Server: ephemeral ECDH key pair per session → shared secret → discarded

Compromise of server's long-term signing key → cannot decrypt past sessions.
Ephemeral keys are gone. This is forward secrecy / perfect forward secrecy.

← Week 3: mTLS and TLS Extensions

CBC Mode Elimination

CBC mode with MAC-then-encrypt leads to padding oracle attacks:

  • BEAST (2011): exploits CBC IV predictability in TLS 1.0
  • LUCKY13 (2013): timing side-channel in MAC-then-encrypt
  • POODLE (2014): forces SSL 3.0 downgrade, padding oracle

TLS 1.3 uses only AEAD (authenticated encryption). The authentication tag is checked
before any decryption output is used → no padding oracle possible.

← Week 3: mTLS and TLS Extensions

1-RTT vs 2-RTT Handshake

TLS 1.2 (2-RTT full handshake):

→ ClientHello
← ServerHello + Certificate + ServerHelloDone
→ ClientKeyExchange + ChangeCipherSpec + Finished
← ChangeCipherSpec + Finished
→ [application data]

TLS 1.3 (1-RTT):

→ ClientHello (includes key_share)
← ServerHello + [EncryptedExtensions + Certificate + Finished]
→ [Finished]
→ [application data simultaneously]

The key_share in ClientHello allows server to derive traffic keys immediately.

← Week 3: mTLS and TLS Extensions

Practice Exercise

# Connect with TLS 1.2 and compare cipher suite to TLS 1.3
openssl s_client -connect google.com:443 -tls1_2 2>&1 | \
  grep -E "Cipher|Protocol"

openssl s_client -connect google.com:443 -tls1_3 2>&1 | \
  grep -E "Cipher|Protocol"

# Check if a server supports TLS 1.2 at all
openssl s_client -connect example.com:443 -no_tls1_3 2>&1 | \
  grep -E "Cipher|Protocol|alert"
← Week 3: mTLS and TLS Extensions

Challenge Assignment

Create a reference table: for each of the 8 major TLS 1.3 removals listed on slide 2:

  1. Name of the removed feature
  2. Attack name(s) that targeted it
  3. Year the attack was published
  4. Why the attack worked (one sentence — the fundamental flaw)
  5. What TLS 1.3 uses instead

This table is something you could use in a future design review to justify
why a service should not support TLS 1.2 fallback.

← Week 3: mTLS and TLS Extensions

Resources

  • RFC 8446 Appendix C: backward compatibility notes
  • RFC 8446 Appendix D: security analysis
  • RFC 5246 §7.4: TLS 1.2 handshake (for comparison)
  • "Lucky13: Breaking the TLS and DTLS Record Protocols" — Al Fardan & Paterson (2013)