TLS 1.2 vs TLS 1.3: what changed and what to configure

TLS 1.2 vs TLS 1.3 is no longer a choice between two equals. TLS 1.2 (RFC 5246, 2008) is secure when restricted to ECDHE key exchange and AEAD cipher suites; TLS 1.3 (RFC 8446 in 2018, revised as RFC 9846 in July 2026) makes that the only option, encrypts more of the handshake and is the only version that offers post-quantum hybrid key exchange and Encrypted Client Hello.

At a glance

The handshake

TLS 1.2 negotiates first and exchanges keys second: the client lists cipher suites, the server picks one and sends its certificate and key-exchange parameters, the client sends its key share, and both finish. Two round trips pass before application data flows, and the certificate travels in the clear. With static RSA suites the client encrypts the premaster secret to the server's certificate key, so anyone who later obtains that key can decrypt every recorded session.

TLS 1.3 guesses: the client sends key shares for its preferred groups in the first message, the server replies with its share and immediately encrypted extensions, certificate, CertificateVerify and Finished, and the client can send data after one round trip. Resumed sessions can even carry 0-RTT early data, at the cost of replay protection for that data.

The script below, run with OpenSSL 3.6.5 against a public server on 20 October 2026, shows the practical outcome of the same client forcing each version.

#!/bin/sh
host=${1:-cloudflare.com}
for version in -tls1_2 -tls1_3; do
  echo "== $version"
  echo | openssl s_client -connect "$host:443" -servername "$host" "$version" -brief 2>&1 \
    | grep -E "Protocol version|Ciphersuite|Peer Temp Key|Negotiated TLS1.3 group"
done

== -tls1_2
Protocol version: TLSv1.2
Ciphersuite: ECDHE-ECDSA-CHACHA20-POLY1305
Peer Temp Key: X25519, 253 bits
== -tls1_3
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Negotiated TLS1.3 group: X25519MLKEM768

The TLS 1.2 connection is safe here because the server allows only ECDHE with AEAD, but it is limited to classical X25519; the TLS 1.3 connection negotiates the post-quantum hybrid.

What TLS 1.3 removed, and why

Almost every famous TLS attack of the 2010s exploited a TLS 1.2-era feature that TLS 1.3 deleted:

• CBC mode with MAC-then-encrypt (BEAST, Lucky Thirteen, POODLE): only AEAD ciphers remain.
• RC4 (statistical biases) and 3DES (SWEET32): removed.
• RSA key transport (Bleichenbacher padding oracles, ROBOT; no forward secrecy): removed.
• Export-grade and arbitrary finite-field groups (FREAK, Logjam): only named groups remain.
• Renegotiation and compression (triple handshake, CRIME): removed.
• Signatures over partial transcripts (the TLS 1.2 ServerKeyExchange signs only parameters): CertificateVerify signs the whole transcript.
• SHA-1 and MD5 in signatures: removed.

RFC 9846 also tightens requirements for TLS 1.2 implementations, and RFC 9325 lists the safe TLS 1.2 subset: ECDHE or DHE with AEAD, extended master secret (RFC 7627) and secure renegotiation.

Features only TLS 1.3 offers

• Hybrid post-quantum key exchange (X25519MLKEM768, RFC 10024), negotiated by default in major browsers since late 2024 and in OpenSSL since 3.5.
• Encrypted Client Hello (RFC 9849), which hides the server name from the network when used with DNS HTTPS records.
• Certificate compression (RFC 8879) and delegated credentials (RFC 9345).
• QUIC, which embeds the TLS 1.3 handshake and is the transport for HTTP/3.

Compliance and policy

• US federal systems: NIST SP 800-52 Rev. 2 requires government TLS servers to support TLS 1.3 by 1 January 2024 and allows TLS 1.2 with approved suites.
• Payment card environments: PCI DSS has prohibited SSL and early TLS (1.0) since 30 June 2018; TLS 1.2 and 1.3 are both acceptable.
• IETF: RFC 8996 deprecated TLS 1.0 and 1.1 in 2021; browsers removed them in 2020.
• Post-quantum plans: NIST IR 8547 (draft) and CNSA 2.0 assume hybrid or post-quantum key establishment, which is only available in TLS 1.3.

When to choose which

• Public websites and APIs: TLS 1.3 preferred, TLS 1.2 with the safe subset as fallback.
• Internal services, service meshes, mTLS: TLS 1.3 only.
• Legacy clients (old Android, embedded devices, older Java and Windows versions): TLS 1.2 with ECDHE and AEAD; plan their retirement.
• Middleboxes that inspect traffic: expect them to need updates for TLS 1.3, ECH and large post-quantum ClientHellos rather than holding servers back.
• Anything needing post-quantum confidentiality: TLS 1.3 with a hybrid group.

Migration notes

1. Upgrade the TLS library: OpenSSL 1.1.1 or later for TLS 1.3, 3.5 or later for default post-quantum groups; current BoringSSL, Go, Java 11 or later, Windows Server 2022 or later.
2. Enable TLS 1.3 alongside 1.2, then trim 1.2 to ECDHE and AEAD suites; in nginx, ssl_protocols TLSv1.2 TLSv1.3; with a short ssl_ciphers list, since TLS 1.3 suites are configured separately.
3. Check certificates and keys: RSA certificates work with TLS 1.3 because handshake signatures use PSS with the same keys; ECDSA certificates work unchanged.
4. Decide on 0-RTT: leave it off unless the application can safely handle replays of early requests.
5. Measure the remaining TLS 1.2 traffic and set a date to disable it where it falls to zero. The TLS configuration generator produces settings for common servers, and the bulk domain checker reports which versions your hosts accept.

References

• RFC 9846, TLS 1.3 (§1.3 differences from TLS 1.2, §1.4 updates affecting TLS 1.2)
• RFC 5246, TLS 1.2
• RFC 9325, recommendations for secure use of TLS and DTLS
• RFC 8996, deprecating TLS 1.0 and TLS 1.1
• RFC 10024, hybrid ML-KEM key agreement for TLS 1.3
• RFC 9849, TLS Encrypted Client Hello
• NIST SP 800-52 Rev. 2
• PCI SSC: migrating from SSL and early TLS