What is TLS 1.3? Everything That Changed

TLS 1.3 is the current version of the Transport Layer Security protocol, published as RFC 8446 in August 2018. It’s a fundamental redesign — not an incremental update — that makes HTTPS faster, simpler, and more secure than any previous version.

As of 2026, 62% of websites support TLS 1.3, and all major browsers have supported it since 2018.

What changed from TLS 1.2

The design philosophy: remove everything that can be misconfigured. TLS 1.2 has 37 cipher suites — some secure, some broken. TLS 1.3 has 5, all safe.

The 5 TLS 1.3 cipher suites

TLS_AES_256_GCM_SHA384        ← Strongest, most common
TLS_AES_128_GCM_SHA256        ← Widely used, slightly faster
TLS_CHACHA20_POLY1305_SHA256  ← Best for ARM/mobile (no AES-NI)
TLS_AES_128_CCM_SHA256        ← IoT/embedded
TLS_AES_128_CCM_8_SHA256      ← IoT/embedded (short tag)

You can’t misconfigure these — they’re all AEAD ciphers with strong keys. There’s no “accidentally enable a weak cipher” risk like in TLS 1.2.

1-RTT handshake: why it’s faster

TLS 1.2 handshake (2 round trips):

Client → Server:  ClientHello (supported ciphers)
Server → Client:  ServerHello, Certificate, KeyExchange
Client → Server:  KeyExchange, ChangeCipherSpec, Finished
Server → Client:  ChangeCipherSpec, Finished
                  [4 messages before encrypted data flows]

TLS 1.3 handshake (1 round trip):

Client → Server:  ClientHello + KeyShare
Server → Client:  ServerHello + KeyShare + Certificate + Finished
Client → Server:  Finished
                  [encrypted data can flow after 1 round trip]

The client sends its key share parameters in the first message — no need to wait for the server to specify algorithms first. This cuts the handshake from 2 round trips to 1.

0-RTT resumption

For returning visitors (who’ve connected before), TLS 1.3 supports 0-RTT — encrypted application data sent with the very first message:

Client → Server:  ClientHello + KeyShare + EarlyData (encrypted request)
Server → Client:  ServerHello + response

The request is sent before the handshake completes. Trade-off: 0-RTT data is vulnerable to replay attacks, so it should only be used for idempotent requests (GET, not POST).

Mandatory forward secrecy

In TLS 1.2, you could use RSA key exchange — the server’s long-term RSA key directly decrypts the pre-master secret. If someone records the traffic and later steals the server’s private key, they can decrypt all past conversations.

TLS 1.3 removes RSA key exchange entirely. All key exchange uses ephemeral Diffie-Hellman (ECDHE) — a unique key pair is generated for every connection. Stealing the server’s private key doesn’t help decrypt past sessions. More on forward secrecy →

Encrypted certificate

In TLS 1.2, the server’s certificate (including the domain name) is sent in plaintext during the handshake. A passive observer can see which site you’re connecting to.

In TLS 1.3, the certificate is sent after the handshake keys are derived — it’s encrypted. The SNI (Server Name Indication) is still visible in TLS 1.3, but Encrypted Client Hello (ECH) will encrypt that too in the future.

How to enable TLS 1.3

Check if it’s already enabled

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_3 2>/dev/null | grep "Protocol"
# Expected: TLSv1.3

Nginx (1.13+ with OpenSSL 1.1.1+)

ssl_protocols TLSv1.2 TLSv1.3;

TLS 1.3 is enabled by default in modern Nginx — you just need to not disable it.

Apache (2.4.37+ with OpenSSL 1.1.1+)

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

This enables TLS 1.2 and 1.3.

Check your OpenSSL version

openssl version
# Needs: OpenSSL 1.1.1+ for TLS 1.3 support

If your OpenSSL is older, upgrade it or upgrade your OS.

Should I force TLS 1.3 only?

Not yet. About 38% of sites don’t support TLS 1.3, and some clients (corporate proxies, Java 8, older embedded systems) only support TLS 1.2. Dropping TLS 1.2 today would lock out some users.

Recommended config: Support both TLS 1.2 and 1.3. This gives you TLS 1.3 speed for modern clients while maintaining compatibility. This is what Google, Cloudflare, and most major sites do.

Frequently asked questions

Do I need a new certificate for TLS 1.3?

No. The same certificate works with TLS 1.2 and 1.3. Certificates are protocol-agnostic — they contain a public key and CA signature, regardless of which TLS version uses them.

Does TLS 1.3 affect performance?

Yes, positively. The 1-RTT handshake saves 50-100ms on first connection. 0-RTT resumption eliminates handshake latency entirely for returning visitors. Combined with HTTP/2 (which requires HTTPS), TLS 1.3 sites are measurably faster.

Is TLS 1.2 still safe?

Yes, with AEAD cipher suites (AES-GCM, ChaCha20-Poly1305) and ECDHE key exchange. Avoid CBC ciphers in TLS 1.2 — they’ve been vulnerable to attacks (BEAST, Lucky13). TLS 1.3 is better, but TLS 1.2 with modern ciphers remains secure.

What about TLS 1.4?

There’s no TLS 1.4 planned. The IETF considers TLS 1.3 the target for the foreseeable future. The next major change will be incorporating post-quantum key exchange (ML-KEM) as a hybrid with existing ECDHE — this will happen within TLS 1.3, not as a new version.