TLS 1.2 vs TLS 1.3
TLS 1.3 (RFC 8446, 2018) is a ground-up redesign of TLS that removed every feature that had caused vulnerabilities over TLS 1.2's 10-year lifespan: static RSA key exchange, RC4, 3DES, CBC mode cipher suites, MD5/SHA-1 signatures, compression, and renegotiation. What remained is a minimal, fast, and formally verified protocol. The cipher suite architecture changed fundamentally. TLS 1.2 cipher suites encoded four choices in one identifier: key exchange algorithm (RSA, ECDHE, DHE), authentication algorithm (RSA, ECDSA, DSS), bulk cipher (AES, 3DES, RC4, NULL), and MAC (SHA-1, SHA-256, MD5). This combinatorial model yielded a large IANA registry, most of which should never be used. TLS 1.3 separates these concerns: the 5 cipher suites specify only the AEAD algorithm and hash function. Key exchange is negotiated separately via the supported_groups extension. Authentication uses the signature_algorithms extension. The result is a smaller, auditable set with no weak combinations possible.
TLS 1.3 (RFC 8446) is strictly better than TLS 1.2 in every meaningful dimension: 1 RTT handshake vs 2 RTT, mandatory forward secrecy via ephemeral key exchange, 5 cipher suites (all AEAD) vs a combinatorial set in TLS 1.2 that includes RC4, 3DES, NULL, and export-grade entries, encrypted certificates, and no renegotiation. The only reason to retain TLS 1.2 is legacy client compatibility.
| Feature | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Handshake round trips | 2 RTT – data starts on 4th message | 1 RTT – data starts on 2nd message |
| 0-RTT resumption | Not available | Available via PSK – carries replay risk for non-GET |
| Forward secrecy | Optional – static RSA key exchange still allowed | Mandatory – only ephemeral ECDHE/DHE allowed |
| Cipher suites | Combinatorial – key exchange × authentication × bulk cipher × MAC. Includes legacy entries: RC4, 3DES, NULL cipher, export-grade, MD5/SHA-1 MACs. Most modern configurations restrict to ECDHE + AEAD suites, but the full list in the registry is large. | 5 only – all AEAD (AES-128-GCM-SHA256, AES-256-GCM-SHA384, ChaCha20-Poly1305-SHA256, AES-128-CCM-SHA256, AES-128-CCM-8-SHA256). Key exchange and authentication are negotiated separately as signature algorithms, not embedded in the cipher suite. |
| Certificate visibility | Certificate sent in cleartext – visible to passives | Certificate encrypted after ServerHello |
| Handshake encryption | Partial – server certificate and key exchange plaintext | Full – all messages after ServerHello encrypted |
| Downgrade protection | Vulnerable – POODLE, DROWN, BEAST possible | Sentinel values in ServerHello random field |
| Renegotiation | Supported (CVE-2009-3555 history) | Removed – KeyUpdate replaces renegotiation |
| Compression | Supported (CRIME attack exploited this) | Removed entirely |
| Session resumption | Session IDs + session tickets (plaintext ticket) | PSK-based – tickets encrypted and bound to identity |
| RFC | RFC 5246 | RFC 8446 |
When to use TLS 1.2
TLS 1.2 is necessary only for: legacy clients from before 2018 (old Android, old Java runtimes), enterprise environments with TLS inspection appliances that don't support TLS 1.3 yet, or FIPS 140-2 environments where TLS 1.3 certification is pending. For everything else, TLS 1.3 is the answer.
When to use TLS 1.3
TLS 1.3 is the correct choice for all new deployments. Modern browsers (Chrome 70+, Firefox 63+, Safari 12.1+) negotiate TLS 1.3 automatically when the server supports it. The 1 RTT handshake benefit is most visible on high-latency connections. Forward secrecy is critical for any system where long-term key compromise is a risk.
Common Mistakes
- Supporting TLS 1.0 and 1.1 for 'compatibility' – both are deprecated by RFC 8996 (2021) and removed from all major browsers. There is no legitimate reason to support them.
- Configuring a long TLS 1.2 cipher suite list without removing weak entries (RC4, 3DES, NULL, EXPORT, MD5-based) – the defaults in many older server configs include broken ciphers.
- Using 0-RTT for POST/PUT/DELETE requests – 0-RTT data can be replayed by a network attacker. Safe only for idempotent GET requests.
- Assuming TLS 1.3 is slower because of 'more security' – TLS 1.3 is faster due to fewer round trips. The 1 RTT handshake improves connection setup by one full round trip.
- Not updating cipher string configurations after enabling TLS 1.3 – TLS 1.3 cipher suites are configured independently from TLS 1.2 cipher suites. In OpenSSL, use ssl_conf_command Ciphersuites for TLS 1.3 and SSLCipherSuite (Apache) or ssl_ciphers (nginx) for TLS 1.2. The TLS 1.3 cipher suite list defaults to all 5 suites in most libraries, which is correct – do not restrict it unless you have a specific FIPS requirement.
FAQ
Does TLS 1.3 break TLS inspection (middleboxes)?
Yes, intentionally. TLS 1.3's mandatory forward secrecy means there is no static private key to give to a TLS inspection appliance. This is a security feature. Enterprises that require inspection must use TLS 1.3-capable proxies that re-terminate the connection.
Is TLS 1.2 with ECDHE + AES-GCM as secure as TLS 1.3?
Almost, but not quite. TLS 1.2 with ECDHE and AEAD ciphers achieves forward secrecy and authenticated encryption. But TLS 1.3 still wins: 1 RTT handshake, encrypted certificates, no renegotiation surface, and provably secure handshake design with formal verification.
When will TLS 1.2 be deprecated?
RFC 8996 (2021) already formally deprecates TLS 1.0 and 1.1. TLS 1.2 remains valid but NIST SP 800-52 Rev 2 recommends TLS 1.3 for all new systems. PCI-DSS 4.0 requires TLS 1.2 minimum and recommends 1.3.