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 done: the IETF published it as RFC 8446 on August 10th. It's the first new version of the protocol behind nearly all web encryption since TLS 1.2 in 2008, and it's closer to a rebuild than a revision: faster handshakes, a thorough removal of legacy cryptography, and forward secrecy as a requirement rather than an option.

For once, a major security upgrade is also a performance upgrade, so the question isn't whether to adopt it but when your stack will let you. Here's what 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 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 needs one, because the client sends its key-exchange material in the very first message. On a 100ms connection, that saves 100ms on every new HTTPS connection. 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 in its first flight. It's a real latency win 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 this, and the guidance is clear: if you enable 0-RTT, accept early data only for idempotent requests. A GET for a stylesheet is fine; anything that moves money is not. Most server implementations leave it off by default, which is a reasonable place to start.

Safer: the legacy removal

The bigger change is what TLS 1.3 removes. Twenty years of accumulated options, many of them behind the named attacks of recent years (BEAST, POODLE, Lucky13 and others), are gone:

• Static RSA key exchange. Every TLS 1.3 handshake uses ephemeral (elliptic-curve) Diffie-Hellman, so forward secrecy is the default: 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, the family behind a decade of padding-oracle attacks. Only authenticated (AEAD) ciphers remain: AES-GCM and ChaCha20-Poly1305.
• RC4, SHA-1, MD5, DES, 3DES and export ciphers. The cipher-suite list shrinks from dozens of combinations, many of them risky, to a handful of sound ones.
• Compression and renegotiation, each the source of its own past vulnerabilities.

More of the handshake is also 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. Earlier TLS versions kept insecure options available and trusted operators to configure around them. TLS 1.3 concluded, reasonably given the evidence, that misconfiguration is the main failure mode, and removed the options.

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

Unusually, a lot of running code preceded this RFC:

• Browsers are largely ready. Chrome and Firefox have shipped draft versions of TLS 1.3 for months and are moving to the final version in upcoming releases. On the client side, the rollout should be uneventful.
• Servers depend on OpenSSL. For most of the web, TLS 1.3 arrives with OpenSSL 1.1.1, which is in pre-release now with the final release expected shortly. It's a long-term support 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 run their own TLS stacks and already offer 1.3, so if you're behind one you may get it with a checkbox or automatically.
• Middleboxes are the problem. The standard took 28 drafts largely because of inspection appliances, corporate proxies and security boxes built around TLS 1.2's wire format that break on anything new. Early drafts caused measurable connection failures through such devices. The final protocol works around them by making a 1.3 handshake look like a 1.2 session resumption to intermediaries. That works well, but if you operate behind inspection appliances, test before you switch, and expect vendors to need updates.

There's no need to panic: a well-configured TLS 1.2 deployment is still secure today. Adopt 1.3 deliberately and soon. The performance gain is real, and the smaller attack surface is where the ecosystem is heading.

How to check your own servers

First, check 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)

With 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 it for older clients:

ssl_protocols TLSv1.2 TLSv1.3;

While you're in that config block, do a broader TLS review: retire TLS 1.0 and 1.1 if you still serve them (the PCI Council's deadline for dropping early TLS passed at the end of June), confirm your certificate chain is complete, and check your renewal automation. A scanner like SSL Labs grades the whole configuration, including which protocol versions you negotiate, in one run.

Keep verifying what's actually served

RFC 8446 makes the strongest part of your security setup stronger and faster at the same time. But protocol version is only one property of a healthy TLS deployment, and the others degrade quietly: certificates expire, chains break, configurations drift with each upgrade. Chrome 68's "Not Secure" label made HTTPS effectively mandatory last month. TLS 1.3 makes it better. Monitoring keeps it working.

CompleteStatus continuously checks the TLS your servers actually serve: certificate expiry with early alerts, chain and configuration problems, and uptime checks that fail as soon as a handshake does. Create a free account.