TLS 1.3 Is Final — What RFC 8446 Changes and What to Do About It

After roughly four years of work and 28 drafts, TLS 1.3 is officially done: the IETF published it as RFC 8446 on August 10th. It's the first new version of the protocol securing essentially all web encryption since TLS 1.2 in 2008 — and it's not an incremental polish. TLS 1.3 is closer to a rebuild: faster handshakes, a ruthless purge of legacy cryptography, and forward secrecy as a requirement rather than an option.

For once, a major security upgrade is also a performance upgrade — which means the question isn't whether to adopt it, but when your stack will let you. Here's what actually changed, where deployment stands this month, and how to check what your own servers are doing.

Faster: the handshake loses a round trip

The most user-visible improvement is speed. A TLS 1.2 handshake needs two round trips between client and server before any application data flows; TLS 1.3 collapses that to one, by having the client send its key-exchange material optimistically in the very first message. On a 100ms connection, that's 100ms shaved off every fresh HTTPS connection — before your server has done anything at all. Mobile and high-latency users benefit most.

For repeat visitors there's 0-RTT resumption: a client that has connected before can send application data with its very first packet. It's a genuine free lunch for latency with one well-documented catch — 0-RTT data can be replayed by an attacker who captures it, because it's sent before the handshake completes. The RFC is explicit about the risk, and the operational guidance is clear: if you enable 0-RTT, ensure early data is only accepted for idempotent requests (a GET for a stylesheet, fine; anything that transfers money, absolutely not). Most server implementations leave it off by default — a reasonable place to start.

Safer: the great legacy purge

The more consequential change is what TLS 1.3 removes. Twenty years of accumulated protocol baggage — much of it implicated in the named attacks of recent years (BEAST, POODLE, Lucky13, and the rest of the menagerie) — is simply gone:

• Static RSA key exchange — gone. Every TLS 1.3 handshake uses ephemeral (Elliptic-curve) Diffie-Hellman, which means forward secrecy by default: even if someone steals your server's private key later, previously recorded traffic stays unreadable. Under 1.2 this was a configuration choice; now it's the only mode.
• CBC-mode ciphers — gone. The entire family behind a decade of padding-oracle attacks. Only modern authenticated (AEAD) ciphers remain: AES-GCM and ChaCha20-Poly1305.
• RC4, SHA-1, MD5, DES, 3DES, EXPORT ciphers — gone. The cipher-suite list collapses from dozens of combinations (many of them footguns) to a handful, all of them sound.
• Compression and renegotiation — gone, each the root of its own past vulnerability class.
• More of the handshake is encrypted, including the server certificate — a modest privacy gain over 1.2, where certificates crossed the wire in the clear.

The design philosophy is the real story: previous TLS versions kept insecure options available and trusted operators to configure around them. TLS 1.3 concluded — correctly, on the evidence — that misconfiguration is the dominant failure mode, and deleted the options instead.

Deployment reality: closer than you'd think, messier than you'd hope

The unusual thing about this RFC is how much running code preceded it:

• Browsers are largely ready. Chrome and Firefox have been shipping draft versions of TLS 1.3 for months and are moving to the final RFC version in upcoming releases. Client-side, the rollout is nearly a non-event.
• Servers are gated on OpenSSL. For most of the web, TLS 1.3 arrives when OpenSSL 1.1.1 does — the release with final RFC 8446 support is due imminently (it's in pre-release now), and it's an LTS release designed as a drop-in replacement for 1.1.0. From there it flows into distributions, then into nginx and Apache builds linked against it. Some CDNs and large providers, running their own TLS stacks, already offer 1.3 today — if you're behind one, you may get it with a checkbox or without lifting a finger.
• Middleboxes are the headache. The reason the standard took 28 drafts isn't cryptography — it's the internet's accumulated sediment of inspection appliances, corporate proxies and "security" boxes that ossified around TLS 1.2's wire format and choke on anything new. Early drafts caused measurable connection failures through such devices; the final protocol responds with camouflage, deliberately making a 1.3 handshake look like a 1.2 session resumption to intermediaries. It works remarkably well, but if you operate behind inspection appliances, test before you flip the switch — and expect vendors to need updates.

There's no urgency panic here: TLS 1.2, well-configured, remains perfectly secure today. The right posture is "adopt deliberately, soon" — the performance win is real, and the shrunken attack surface is the direction the whole ecosystem is moving.

How to check your own servers

First, know what you're running. TLS 1.3 support requires OpenSSL 1.1.1:

openssl version
# OpenSSL 1.1.1  (anything 1.1.0 or older: no TLS 1.3)

Once you have a 1.1.1 build, ask a server to negotiate 1.3 explicitly:

openssl s_client -connect example.com:443 -tls1_3 </dev/null 2>/dev/null \
  | grep -E 'Protocol|Cipher'
#     Protocol  : TLSv1.3
#     Cipher    : TLS_AES_256_GCM_SHA384

Enabling it in nginx (built against OpenSSL 1.1.1) is one token in the config — keep 1.2 alongside for the long tail of older clients:

ssl_protocols TLSv1.2 TLSv1.3;

And while you're in that config block: this is the perfect moment for a broader TLS hygiene pass — retire TLS 1.0/1.1 if you still serve them (the PCI Council's deadline for 1.0 passed in June), confirm your certificate chain is complete, and check your renewal automation. An online scanner like SSL Labs will grade the whole picture, including which protocol versions you negotiate, in one run.

The protocol got better — keep verifying what's actually served

RFC 8446 makes the strongest link in your security chain stronger and faster at the same time — a rare combination. But protocol version is only one property of a healthy TLS deployment, and every property degrades silently: certificates expire, chains break, configurations drift with each upgrade. The Chrome 68 "Not Secure" milestone last month made HTTPS mandatory in practice; TLS 1.3 makes it better; monitoring is what makes it stay working.

CompleteStatus continuously checks the TLS your servers actually serve — certificate expiry with early alerts, chain and configuration problems, and uptime checks that fail the moment a handshake does. Create a free account and get a watchful eye on your handshakes — whichever TLS version they negotiate this year.