The short answer
TLS 1.3 does two things to its predecessor: it cuts the handshake from two round trips to one, and it deletes every cryptographic option that ever went wrong, from RSA key exchange to CBC ciphers. Run 1.3 preferred with 1.2 as the compatibility floor; refuse everything older.
One round trip instead of two
A TLS 1.2 handshake is a four-flight conversation: the client offers its capabilities, the server picks and sends its certificate, the client sends key material and confirms, the server confirms back. Two full round trips before the first byte of your actual page moves. At 30 ms of latency that is fine; at 150 ms on a phone, the handshake alone costs nearly a third of a second.
TLS 1.3, standardized as RFC 8446 in 2018, collapses that. The client guesses the key exchange group (it guesses right essentially always, since everyone uses x25519) and ships its key share inside the very first message. The server answers with everything at once: its key share, the certificate, the finish line. One round trip, done. Resumed connections can go further with 0-RTT, sending data in flight zero, replay caveats included.
TLS 1.2: 2 round trips
data starts here
TLS 1.3: 1 round trip
data starts here
(0-RTT possible on resumption)
The great deletion
The speed got the headlines, but the security story is the list of things TLS 1.3 removed. Static RSA key exchange: gone, so a stolen server key no longer decrypts past recorded traffic, making forward secrecy mandatory rather than optional. CBC-mode ciphers and their padding oracle attacks (BEAST, Lucky13, POODLE’s cousins): gone. RC4: gone. SHA-1 in signatures, compression (CRIME), renegotiation (the source of a whole attack family): gone, gone, gone.
What survives is a short list of five AEAD cipher suites, AES-GCM and ChaCha20-Poly1305 variants, every one of them respectable. This is the deeper design shift: TLS 1.2 was a menu where a sloppy administrator could still order something poisonous in 2026; TLS 1.3 took the poison off the menu. An entire genre of configuration error, the weak-cipher-suite audit finding, simply does not exist on a 1.3-only endpoint.
The protocol also encrypts most of its own handshake, certificate included. Passive observers on the path learn far less about who you are connecting to, which is good for privacy and famously inconvenient for inspection middleboxes; that tension delayed enterprise rollouts for years and explains most of the “TLS 1.3 broke our appliance” tickets of the early 2020s.
What to actually run
The 2026 baseline is unambiguous: TLS 1.3 enabled and preferred, TLS 1.2 retained as the floor with a modern suite list (ECDHE key exchange, AES-GCM or ChaCha20), and TLS 1.0/1.1 disabled outright. Those last two were formally deprecated by RFC 8996 in 2021, and every current browser dropped them back in 2020. Holding 1.2 as the floor costs you nothing in security when configured well and keeps the long tail of older clients, embedded devices and corporate proxies working.
Adoption data says you will rarely need even that floor: Qualys SSL Pulse has tracked TLS 1.3 support climbing past the three-quarters mark across popular sites, and client-side support has been universal in browsers since 2019. The stragglers are almost always B2B integrations and ancient Java runtimes, which is an inventory problem, not a protocol one.
On the server side the change is usually a few lines. Nginx:
ssl_protocols TLSv1.2 TLSv1.3; and a sane cipher string for the
1.2 fallback (1.3 suites are not configurable, by design). Apache, HAProxy
and the CDN dashboards all have the same two knobs. While you are in there,
add HSTS so returning browsers never even attempt plaintext; our
HTTP headers checker grades that part of the
config in one click.
Verifying the result
Trust, then verify from outside. Point our
SSL checker at your host: it reports the negotiated
protocol and cipher next to the certificate countdown, which catches the
classic case of a load balancer fronting your beautifully configured backend
with its own 2019-era settings. For the full matrix, openssl from any shell
answers version-by-version: openssl s_client -connect host:443
-tls1_1 should fail, -tls1_3 should succeed.
One last habit worth keeping: re-test after every infrastructure change. TLS termination has a way of moving (new CDN, new ingress controller, new appliance) and every move resets your protocol configuration to whatever that layer’s defaults are. The defaults are better than they used to be. They are still not your config.
What’s already arriving: post-quantum key exchange
The next chapter is being deployed on top of TLS 1.3 rather than as a TLS 1.4. The concern is “harvest now, decrypt later”: traffic recorded today could be decrypted decades from now by a quantum computer breaking the elliptic-curve key exchange. The countermeasure is hybrid key exchange, pairing x25519 with ML-KEM (the NIST-standardized Kyber), so a session stays safe unless both problems fall. Chrome ships it on by default, Cloudflare reports a large share of its TLS 1.3 traffic already negotiating post-quantum keys, and OpenSSL 3.5 brought support to the server mainstream.
Two practical notes if you operate servers. First, hybrids ride on TLS 1.3’s key share mechanism, so a 1.2-only endpoint is excluded from the upgrade path entirely; that is quietly becoming the strongest argument for finishing your 1.3 rollout. Second, the bigger ClientHello (Kyber keys are chunky) has flushed out middleboxes and load balancers that assumed a hello fits in one packet, a bug class worth testing for before your users find it. The protocol keeps evolving; the operational lesson stays the same: keep the floor modern, and the future arrives as a config change instead of a migration.
Frequently asked questions
Is TLS 1.2 insecure in 2026?
No. TLS 1.2 with modern cipher suites (AES-GCM or ChaCha20, ECDHE key exchange) remains solid and universally accepted by compliance frameworks. The insecurity stories belong to TLS 1.0/1.1, which RFC 8996 formally deprecated, and to TLS 1.2 configured with legacy options like CBC suites and RSA key exchange. Configuration, not version, is usually the problem.
Does TLS 1.3 make my site measurably faster?
On new connections, yes: one round trip saved on every handshake. The gain scales with latency, so a user 100 ms away saves 100 ms on first connect, and mobile networks benefit most. On resumed connections both versions are quick, and TLS 1.3 adds 0-RTT resumption for another saving if you accept its replay caveats.
What is 0-RTT and should I enable it?
Zero round trip resumption lets a returning client send application data with its very first packet. The catch: that early data can be replayed by an attacker, so it is only safe for idempotent requests like GETs. Enable it on content sites with the proxy configured to restrict early data to safe methods; skip it for APIs that mutate state.
Why can my old monitoring appliance not inspect TLS 1.3 traffic?
TLS 1.3 encrypts the certificate exchange and removed static RSA key exchange, which passive middleboxes relied on to decrypt traffic with a copied private key. Inspection now requires being an active proxy that terminates the session. That broke a generation of enterprise appliances and delayed many TLS 1.3 rollouts; the protocol chose privacy on purpose.
How do I check which TLS version my server negotiates?
Our SSL checker reports the negotiated protocol and cipher for any host. From a terminal, openssl s_client -connect host:443 -tls1_3 (then -tls1_2 and -tls1_1) shows exactly which versions the server accepts. Aim for 1.3 preferred, 1.2 accepted, everything older refused.