TLS 1.3 Explained: What Website Owners Need to Know

TLS is the protocol that puts the S in HTTPS, and TLS 1.3 is its current version. For most website owners, TLS 1.3 explained in one sentence is this: it makes HTTPS connections faster to set up and removes the weak options that made older versions risky. This guide covers what changed from TLS 1.2, what the faster handshake and 0-RTT really mean, why TLS 1.0 and 1.1 should be switched off, and how to check and configure your server, host or Cloudflare account.

Key takeaways

The safe target for almost every business site is TLS 1.2 and TLS 1.3 enabled, with TLS 1.0, 1.1 and all SSL versions disabled.
A full TLS 1.3 handshake takes one round trip instead of two, which helps time to first byte on new connections.
Your certificate does not set your TLS version, which is configured in your server, hosting or CDN settings.
Leave 0-RTT off on a self-managed server unless your application rejects unsafe early data requests, as it carries a replay risk.

TLS, SSL and certificates: a quick refresher

People still say "SSL", but SSL was retired years ago. Every HTTPS connection today uses TLS. Two separate things are involved:

The certificate proves your site's identity. It has an issuer and an expiry date, and it's what browsers warn about when it's wrong.
The protocol version (TLS 1.2 or 1.3) decides how the browser and server agree on keys and encrypt traffic.

Your certificate doesn't determine your TLS version. The same certificate works with TLS 1.2 and TLS 1.3. The version is set by your server software, your hosting company or your CDN. If certificates themselves are your concern, see our guide on how to check an SSL certificate.

What changed in TLS 1.3 compared with TLS 1.2

TLS 1.3 is defined in RFC 8446, published by the IETF in 2018. The main differences:

Area	TLS 1.2	TLS 1.3
Full handshake	Two round trips	One round trip
Resumed connections	One round trip	One, or zero with 0-RTT
Key exchange	Static RSA allowed (no forward secrecy)	Forward secrecy always (ephemeral Diffie-Hellman)
Ciphers	Many, including CBC and RC4-era options	Only authenticated encryption (AEAD)
Cipher suites	Dozens of combinations	Five defined
Handshake privacy	Certificate sent in the clear	Handshake encrypted after the first message
Compression, renegotiation	Supported	Removed
Post-quantum key exchange	Not available	Supported via hybrid groups

Forward secrecy by default

In TLS 1.2, a server could use static RSA key exchange. If someone recorded encrypted traffic and later stole the server's private key, they could decrypt the lot. TLS 1.3 removes static RSA, so every session uses fresh keys. A stolen key can't unlock past traffic.

Fewer, stronger ciphers

TLS 1.2's long menu of cipher suites is why older configurations were so easy to get wrong. TLS 1.3 keeps only modern AEAD ciphers such as AES-GCM and ChaCha20-Poly1305. There's very little left to misconfigure, which is good news for small businesses without a security team.

Encrypted handshake

More of the handshake is encrypted, including the server's certificate. That reduces what network observers can see, although the site name is still usually visible through the Server Name Indication (SNI) field.

Ready for post-quantum cryptography

The UK's National Cyber Security Centre (NCSC) says in its current TLS guidance that only TLS 1.3 provides protection against quantum attacks when configured correctly, and advises anyone still on TLS 1.2 to plan a migration to TLS 1.3 so they can adopt post-quantum cryptography. It lists hybrid key agreement mechanisms such as X25519MLKEM768 and recommends hybrid schemes as an interim measure. You don't need to configure these by hand on a typical site; modern browsers, CDNs and up-to-date server libraries negotiate them automatically over TLS 1.3.

The faster handshake, in plain terms

Before any page content flows, the browser and server must agree on keys. In TLS 1.2 a new connection needs two round trips for this. TLS 1.3 needs one, because the browser sends its key share in the very first message, guessing which group the server will accept.

What does that save? One round trip is the time for a message to reach your server and come back. For a visitor in the same city as your server it's small. For a visitor on a congested mobile network, or one far from your server, it can be noticeable. It helps time to first byte on new connections, but it won't fix a slow server or a heavy page. Our guide to reducing TTFB covers the bigger wins.

0-RTT: faster, but with a replay risk

TLS 1.3 also offers 0-RTT (zero round-trip time resumption, also called early data). A returning visitor can send their first request together with the handshake, so there's no wait at all.

RFC 8446 is explicit about the cost. 0-RTT data:

is not forward secret, because it's encrypted only with keys from the earlier session;
has no guarantee of non-replay between connections, so an attacker who captures the early data can send it again.

A replayed GET for your home page is harmless. A replayed "submit order", "transfer funds" or "change password" request isn't. That's why careful implementations restrict 0-RTT to safe, read-only requests.

0-RTT on Cloudflare

Cloudflare's 0-RTT Connection Resumption is available on every plan, including Free, and is off by default. It's under Speed > Settings > Protocol Optimization. Cloudflare only accepts GET, HEAD and OPTIONS requests as 0-RTT, adds an Early-Data: 1 header so your origin can identify them, and applies it only between visitors and Cloudflare.

0-RTT on Nginx

Nginx has an ssl_early_data directive. Its documentation warns that early data requests are subject to replay attacks and tells you to pass $ssl_early_data to your application so it can protect itself:

ssl_early_data on;
proxy_set_header Early-Data $ssl_early_data;

Recommendation: leave 0-RTT off on a self-managed server unless your application checks the Early-Data header and rejects unsafe requests (typically with a 425 Too Early response). On Cloudflare, it's a reasonable speed tweak for content sites, but test checkout and login flows afterwards.

Disable TLS 1.0 and TLS 1.1

TLS 1.0 and 1.1 are two decades old and rely on outdated cryptography. The IETF formally deprecated both in RFC 8996 (March 2021), which states that "TLS 1.0 MUST NOT be used". The NCSC's guidance says to disable TLS 1.1 and TLS 1.0, and all versions of SSL.

Practical reasons to act:

Current browsers no longer connect using them, so real visitors aren't using them.
PCI DSS requires TLS 1.2 or above for card payments, a point Cloudflare's own documentation repeats.
Leaving them on adds risk with no benefit, and security scans and cyber insurance questionnaires flag them.

The safe target for almost every business site is TLS 1.2 and TLS 1.3 enabled, everything older disabled. TLS 1.2 is still considered strong when configured with modern ciphers, and keeping it avoids locking out older devices and some business software.

How to check which TLS versions your server supports

In the browser

In Chrome or Edge, open DevTools (F12), go to the Security panel and reload. It shows the protocol (for example "TLS 1.3"), the key exchange and the cipher for the current connection. In Firefox, click the padlock, then Connection secure > More information.

From the command line

# Does the server accept TLS 1.3?
openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null 2>/dev/null | grep -E "Protocol|Cipher"

# Is TLS 1.1 still accepted? (It should fail.)
openssl s_client -connect example.com:443 -servername example.com -tls1_1 </dev/null

# Same checks with curl
curl -sI --tlsv1.3 https://example.com/ -o /dev/null -w "%{http_code}\n"
curl -sI --tlsv1.1 --tls-max 1.1 https://example.com/ -o /dev/null -w "%{http_code}\n"

Note that newer OpenSSL builds may refuse TLS 1.0 and 1.1 on the client side regardless of the server, so a failure on those tests only proves something if your client still supports them. Online scanners such as Qualys SSL Labs test every protocol version from the outside.

Check your certificate too

Our SSL checker opens a verified TLS connection to your site and reports whether the certificate is trusted and in date, who issued it and how many days are left. It focuses on the certificate rather than listing protocol versions, so pair it with the checks above. With certificate lifetimes shrinking (see our post on SSL certificate lifetime changes), expiry is the more common cause of outages.

How to enable TLS 1.3 and disable old versions

Cloudflare

Under SSL/TLS > Edge Certificates:

Turn TLS 1.3 on.
Set Minimum TLS Version to TLS 1.2. Cloudflare's default minimum is TLS 1.0, so this is worth changing.

These settings cover visitor-to-Cloudflare connections. Your origin server still needs a sensible configuration, especially if you use Full (strict). Our Cloudflare free plan settings guide covers the rest.

Nginx

Current nginx versions default to ssl_protocols TLSv1.2 TLSv1.3;, but older configs and distributions often list TLS 1.0 and 1.1 explicitly. Set it in the http or server block:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

TLS 1.3 needs OpenSSL 1.1.1 or later. Test with sudo nginx -t and reload.

Apache

Apache's default is SSLProtocol all -SSLv3, which still includes TLS 1.0 and 1.1. Change it in your SSL virtual host or ssl.conf:

SSLProtocol -all +TLSv1.2 +TLSv1.3

Like Nginx, TLS 1.3 needs Apache built against OpenSSL 1.1.1 or later. SSLProtocol can't be set in .htaccess.

Shared hosting, cPanel and site builders

cPanel/WHM: server administrators set protocols in WHM for Apache and other services. On shared hosting you can't change this yourself; ask your host whether TLS 1.0 and 1.1 are disabled and TLS 1.3 is enabled.
Shopify, Wix, Squarespace: TLS is managed by the platform; there's nothing to configure.
Microsoft 365 and Google Workspace: both manage TLS for their own services. Your concern is your website and any on-premises systems.

If your host can't offer TLS 1.3 in 2026, that's a sign the platform is out of date. Our guide to choosing web hosting lists what to ask.

Will disabling TLS 1.0 and 1.1 break anything?

For public websites, rarely. The usual exceptions are old point-of-sale terminals, legacy payment or stock systems, ancient Android devices and embedded hardware that call your site or API. If you have integrations like these, check your server logs (many log formats can record $ssl_protocol in Nginx or %{SSL_PROTOCOL}x in Apache) for a week before switching, and contact the owners of any clients still on old versions.

When you're done, run a free website audit to check HTTPS, redirects, security headers and certificate expiry together.

Frequently asked questions

Is TLS 1.3 faster than TLS 1.2?

Yes, for new connections. A full TLS 1.3 handshake takes one round trip instead of two, which shortens the time before the first byte arrives. The difference is most noticeable on mobile networks and for visitors far from your server.

Should I disable TLS 1.2 and only allow TLS 1.3?

Not for most business sites yet. TLS 1.2 is still considered secure when configured with modern ciphers, and keeping it avoids locking out older devices and business software. Enable both, and disable TLS 1.0 and 1.1.

Is 0-RTT safe to enable?

It's safe for read-only requests but carries a replay risk for anything that changes data. Cloudflare limits 0-RTT to GET, HEAD and OPTIONS requests; on your own server, only enable it if your application checks for early data.

How do I know if my website supports TLS 1.3?

Open the site in Chrome, press F12 and check the Security panel, which shows the protocol in use. From a terminal, openssl s_client with the -tls1_3 flag confirms whether the server accepts it.

Does TLS 1.3 need a different SSL certificate?

No. The same certificate works with TLS 1.2 and TLS 1.3. The protocol version is set in your server, hosting or CDN configuration, not in the certificate.

How to Get a Free SSL Certificate: Let's Encrypt or Cloudflare: How to get a free SSL certificate in minutes with Let's Encrypt, cPanel AutoSSL or Cloudflare, and how to make sure it renews automatically every time.
Post-Quantum Encryption for Websites: What Small Businesses Need: Post-quantum encryption for websites: harvest now, decrypt later, hybrid X25519MLKEM768 key exchange, NCSC timelines and the steps a small business needs.