What is TLS 1.3?

TLS 1.3 (Transport Layer Security version 1.3) is the latest major version of the TLS protocol, standardized by the IETF as RFC 8446 in August 2018 after four years of design and 28 working drafts. TLS encrypts HTTPS, SMTP STARTTLS, IMAPS, FTPS, OpenVPN, modern QUIC and many other application protocols on the internet. Compared to TLS 1.2 (RFC 5246, August 2008), TLS 1.3 is faster (one round trip handshake instead of two, with optional 0-RTT resumption), more secure (removes legacy ciphers like RC4, 3DES, CBC mode, RSA key exchange, removes static RSA, mandates forward secrecy via ephemeral Diffie Hellman), and simpler (the RFC is about 40 percent shorter). All modern browsers, operating systems and major web servers have supported TLS 1.3 since 2018 to 2020. According to Cloudflare data, more than 70 percent of HTTPS requests on the open internet now use TLS 1.3, with TLS 1.2 as the only remaining significant alternative. TLS 1.0 and 1.1 were deprecated by the IETF in RFC 8996 (March 2021) and are disabled in all current browsers (Chrome 84 July 2020, Firefox 78 June 2020, Safari 14 September 2020, Edge 84 July 2020). PCI DSS prohibits TLS below 1.2 since 2018, and the most recent PCI DSS v4.0 (effective 31 March 2024 and fully mandatory since 31 March 2025) recommends TLS 1.3 for cardholder data.

What changed compared to TLS 1.2?

How does the TLS 1.3 handshake work?

The TLS 1.3 handshake completes in a single round trip:

1. Client Hello: the client sends a list of supported cipher suites, key share for its preferred Diffie Hellman group (X25519 in 99 percent of cases) and SNI for the target hostname.
2. Server Hello: the server picks one cipher suite, returns its own key share and immediately switches to encrypted records. It then sends its certificate, certificate verify and Finished message, all already encrypted.
3. Client Finished: the client validates the certificate and key exchange and sends its Finished message.
4. Application data flows in the same trip if the client supports it.

0-RTT resumption (also called Early Data) lets a returning client send application data on the very first packet. This is fast but has replay attack implications, so it must only be used for idempotent requests like GET. POST, payment and login endpoints must reject 0-RTT.

Performance impact of TLS 1.3

• One full round trip saved per new HTTPS connection. On a 100 ms RTT connection that means 100 ms faster first byte.
• Faster cipher suites: AES-GCM and ChaCha20-Poly1305 are AEAD modes that run in a single pass without separate HMAC.
• X25519 elliptic curve Diffie Hellman is 5 to 10 times faster than the classic RSA key exchange in TLS 1.2.
• Together with HTTP/2 or HTTP/3 the effect compounds: TLS 1.3 + HTTP/3 over QUIC reduces first paint by 100 to 300 ms on mobile connections.

Security improvements

• No more weak ciphers: all CBC, RC4, 3DES, MD5, SHA-1, RSA key exchange and static DH are removed. TLS 1.3 can never accidentally negotiate a broken cipher.
• Mandatory forward secrecy: every session uses ephemeral keys. If a private key leaks years later, past traffic cannot be decrypted.
• Encrypted certificate: the server certificate is sent encrypted, hiding it from passive observers (DPI, government monitoring).
• No renegotiation: renegotiation attacks like CVE-2009-3555 are impossible.
• No compression: CRIME (2012) and BREACH style attacks against TLS compression cannot happen at the TLS layer.
• Downgrade protection: a downgrade indicator in the random field stops attackers from forcing a fallback to TLS 1.2.

How do I enable TLS 1.3?

nginx

Requires nginx 1.13.0 or newer compiled against OpenSSL 1.1.1 or newer (released September 2018). Most distros ship this since 2019.

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;

Note: in TLS 1.3, cipher selection is no longer controlled by ssl_ciphers. nginx will pick from the 5 mandatory TLS 1.3 suites automatically.

Apache

Requires Apache 2.4.37 or newer with OpenSSL 1.1.1 or newer.

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder off
SSLSessionTickets off
SSLUseStapling on

Cloudflare

TLS 1.3 is on by default for every Cloudflare zone since 2018. To verify or change: Cloudflare Dashboard, SSL/TLS, Edge Certificates, Minimum TLS Version. Set it to 1.2. Enable also: Opportunistic Encryption, Automatic HTTPS Rewrites, Always Use HTTPS.

Managed WordPress hosts

How do I test my TLS configuration?

• Qualys SSL Labs at ssllabs.com/ssltest: free, the de facto standard. Grades A+ to F, shows enabled versions, cipher suites, certificate chain, HSTS, vulnerability checks.
• Mozilla Observatory at observatory.mozilla.org: scores TLS plus other security headers.
• testssl.sh: open source command line tool that runs locally without uploading to a third party.
• openssl from the command line:

  openssl s_client -connect example.com:443 -tls1_3
  # Look for: Protocol  : TLSv1.3

• curl: curl --tlsv1.3 -v https://example.com/ 2>&1 | grep -i ssl.
• Chrome DevTools: Security tab on the page shows TLS version and cipher.

Common TLS 1.3 pitfalls

• 0-RTT replay: Early Data must be limited to idempotent requests. Disable it for login, checkout, account changes.
• Middleboxes that intercept TLS: some corporate proxies and antivirus products (Avast, Kaspersky historically) broke TLS 1.3 by failing to parse the new handshake. RFC 8446 added GREASE values and middlebox compatibility mode to mitigate.
• SNI is still cleartext: by default, the target hostname is visible to passive observers. Encrypted Client Hello (ECH, RFC 9460 draft) hides it. Cloudflare enabled ECH in production in September 2023, Firefox and Chrome support it behind a flag.
• Old client compatibility: Windows XP, IE 8 to 10, Android < 5 and Java < 8 cannot do TLS 1.3. If you need to serve these (less than 0.1 percent of the open web in 2025), keep TLS 1.2 enabled in parallel.
• Certificate chain: TLS 1.3 does not magically fix a missing intermediate certificate. Use fullchain.pem, not the leaf certificate alone.

What about TLS 1.4?

There is no plan for a TLS 1.4. Future improvements happen as extensions to TLS 1.3 (ECH, post quantum hybrid key exchange) without bumping the major version. The IETF post quantum migration via hybrid X25519MLKEM768 started shipping in Chrome 124 (April 2024) and is enabled by default in Cloudflare since March 2024.

How does InspectWP help with TLS?

InspectWP analyzes the TLS configuration of every scanned URL and reports the negotiated TLS version, certificate validity, key strength, supported cipher suites and HSTS configuration. Sites that still allow TLS 1.0 or 1.1 are flagged as critical. Sites without TLS 1.3 are flagged as a performance and security improvement opportunity.