TLS 1.2 vs TLS 1.3

TLS 1.3 (RFC 8446, published 2018) is the current version. It is faster, simpler, and removes legacy cryptographic options that made TLS 1.2 vulnerable to certain attacks.

Quick Comparison

Feature	TLS 1.2	TLS 1.3
Handshake round trips	2 RTT	1 RTT
0-RTT resumption	No	Yes (with replay protection caveats)
Cipher suites	~37 supported, many weak	5 supported, all AEAD
Key exchange	RSA, DHE, ECDHE	ECDHE and DHE only
RSA key exchange	Allowed	Removed
CBC mode ciphers	Allowed	Removed
Forward secrecy	Optional (only with DHE/ECDHE)	Mandatory (always ephemeral keys)
Downgrade protection	Limited	Built-in sentinel values in ServerHello random
Browser support	Universal	All modern browsers (Chrome 70+, Firefox 63+, Safari 12.1+, Edge 79+)

Performance

TLS 1.2 requires two round trips to complete a handshake before application data can flow. The client sends ClientHello, the server responds with its certificate and key exchange parameters, the client sends its key exchange values, and then both sides confirm. This adds latency, especially on high-latency connections like mobile networks or intercontinental links.

TLS 1.3 reduces this to a single round trip. The client sends its key share in the first message (ClientHello), and the server can respond with its key share, certificate, and finished message all at once. The client can begin sending encrypted application data after just one round trip.

For repeat connections, TLS 1.3 supports 0-RTT resumption. The client can send encrypted application data in the very first packet using a pre-shared key from a previous session. This is particularly valuable for latency-sensitive applications. However, 0-RTT data is vulnerable to replay attacks, so it should only be used for idempotent requests (like GET).

Security Improvements

TLS 1.3 removes several cryptographic mechanisms that had been sources of vulnerabilities in TLS 1.2:

• RSA key exchange removed. RSA key exchange does not provide forward secrecy. If the server's private key is later compromised, all past sessions can be decrypted. TLS 1.3 requires ephemeral key exchange (ECDHE or DHE), so every session has unique keys.
• CBC mode ciphers removed. CBC ciphers in TLS 1.2 were vulnerable to padding oracle attacks (BEAST, LUCKY13, POODLE variants). TLS 1.3 only allows AEAD ciphers (AES-GCM, ChaCha20-Poly1305), which authenticate and encrypt in a single operation.
• Weak algorithms removed. RC4, 3DES, MD5, and SHA-1 are all gone. The reduced cipher suite list makes misconfiguration much harder.
• Encrypted handshake. In TLS 1.3, the server certificate is encrypted, so passive observers cannot see which site the client is connecting to from the certificate alone. In TLS 1.2, the certificate is sent in plaintext.

Should You Disable TLS 1.2?

Not yet for most sites. While TLS 1.3 is clearly superior, some clients still require TLS 1.2. Older Android devices (pre-Android 10), certain enterprise proxy appliances, IoT devices with outdated TLS stacks, and some legacy payment terminals may not support TLS 1.3.

The practical approach is to support both TLS 1.2 and TLS 1.3, but configure TLS 1.2 with only strong cipher suites (ECDHE key exchange, AES-GCM or ChaCha20-Poly1305). Monitor your server logs to understand what percentage of connections use each version. When TLS 1.2 traffic drops below a threshold you are comfortable with, you can disable it.

One thing is clear: TLS 1.0 and TLS 1.1 should never be enabled. They were formally deprecated in RFC 8996 (2021) and all major browsers have removed support for them.

How to Check

Use the TLS Inspector to see which version your server negotiates, what cipher suites it offers, and whether the certificate chain is valid. Enter any domain and you will get the full handshake details.