TLS 1.3: What Changed and Why You Should Care

TLS 1.2 served the internet well for a decade, but it was designed with legacy compatibility requirements that created attack surfaces. TLS 1.3, finalised in RFC 8446 in August 2018, started from a clean slate. It removed decades of optional features that had become vulnerabilities and redesigned the handshake to be both faster and cryptographically stronger.

The Handshake Is Faster

TLS 1.2 requires two round trips to complete the handshake before data can be sent. TLS 1.3 completes in one round trip — the client sends key share information in its first message, and the server can respond with its key share and already begin sending application data in its first response. This 1-RTT handshake reduces connection setup latency by one full round trip.

For 0-RTT resumption — reconnecting to a server you've connected to before — TLS 1.3 allows the client to send application data in its very first message using a session ticket from the previous connection. Data starts flowing before the handshake completes. There are replay attack caveats with 0-RTT that make it unsuitable for non-idempotent operations, but for GET requests it's a meaningful latency improvement.

What Got Removed

TLS 1.3 removed all cipher suites considered weak: RC4, DES, 3DES, MD5, SHA-1, and export-grade ciphers. These had been mandatory to support in TLS 1.2 for backward compatibility — and they'd been exploited in attacks like POODLE, BEAST, and FREAK. In TLS 1.3, there are only five cipher suites, all of them strong. No negotiation of weak options is possible.

RSA key exchange was removed. In RSA key exchange (used in TLS 1.2), the pre-master secret is encrypted with the server's RSA public key. If an attacker records encrypted traffic today and later obtains the server's private key, they can decrypt all historical sessions. TLS 1.3 requires ephemeral Diffie-Hellman key exchange, which provides perfect forward secrecy — each session uses a fresh key that isn't stored.

Adoption and Compatibility

As of early 2026, TLS 1.3 handles roughly 70% of HTTPS connections globally. Major browsers enabled it by default in 2019. Most web servers (nginx, Apache, IIS) support it with configuration. Some older middleware and inspection appliances broke with TLS 1.3 because they relied on being able to decrypt traffic for inspection — the stronger encryption made that impossible without proper proxying.

Honestly — the breakage of middle-box SSL inspection was a feature, not a bug. Corporate proxies that intercepted TLS traffic for surveillance were relying on weak key exchange modes. TLS 1.3 closed that loophole, which is why some enterprises were slow to adopt it.

Checking Which TLS Version a Site Uses

In Chrome: click the lock icon in the address bar, then 'Connection is secure', then 'Certificate is valid'. That shows the TLS version in use. For more detail, open DevTools (F12), go to the Security tab, and you'll see the protocol version and cipher suite for the current connection. If a site shows TLS 1.2, it's not necessarily broken — but it's worth noting, especially for sites handling sensitive data.

From the command line, OpenSSL is the most flexible tool: 'openssl s_client -connect example.com:443' outputs the full TLS handshake including protocol version, cipher suite, and certificate chain. The 'Protocol : TLSv1.3' line confirms TLS 1.3 is in use. SSL Labs' free server test at ssllabs.com/ssltest provides a comprehensive analysis of a server's TLS configuration — A+ rating, supported protocols, cipher suite ordering, forward secrecy status, and more. Running a domain through it takes about a minute and gives a complete picture of where the configuration stands.