What is TLS 1.3? Everything You Need to Know

TLS 1.3 was published as RFC 8446 in August 2018, almost a decade after TLS 1.2. The gap is significant. TLS 1.2 arrived in 2008 and was designed to be backwards compatible, preserving negotiation pathways for dozens of cipher suites, key exchange mechanisms, and extensions that existed at the time. The result was a protocol with enormous configuration surface and numerous optional features, each of which became a potential attack vector over the following decade.

TLS 1.3 took the opposite approach. Rather than adding to TLS 1.2, the working group spent years removing from it. RSA key exchange is gone. Static Diffie-Hellman is gone. CBC mode cipher suites are gone. RC4, DES, 3DES, SHA-1, MD5 are gone. Compression is gone. Renegotiation is gone. The export cipher suites that enabled FREAK and Logjam are gone. By removing all of it, TLS 1.3 eliminated not just known vulnerabilities but entire categories of future vulnerability that come from having weak options available at all.

What remains is a protocol that is simultaneously faster and more secure than its predecessor, not because of what was added, but because of how much was taken out. This guide covers how TLS 1.3 works, why specific design decisions were made, where 0-RTT mode introduces tradeoffs that are worth understanding, and how to enable TLS 1.3 on your server.

Where TLS 1.3 Sits in the Protocol History

SSL and TLS have a long version history. SSL 2.0 and SSL 3.0 are broken and disabled everywhere. TLS 1.0 and TLS 1.1 were deprecated by the CA/B Forum and removed from all major browsers in 2020. TLS 1.2 remains widely supported and is still acceptable with careful configuration. TLS 1.3 is the current standard.

The TLS 1.3 Handshake: One Round Trip Instead of Two

The most visible performance improvement in TLS 1.3 is the handshake. TLS 1.2 required two full round trips between client and server before any application data could be exchanged. TLS 1.3 requires one. That difference matters most on high-latency connections: mobile networks, intercontinental connections, and satellite links where a single round trip can take 150 milliseconds or more.

TLS 1.2 handshake (two round trips)

In TLS 1.2, the client sends a ClientHello listing its supported cipher suites, TLS versions, and extensions. The server responds with a ServerHello choosing the negotiated parameters, followed by its certificate, a ServerKeyExchange if needed, and a ServerHelloDone. The client then verifies the certificate, generates key material, sends a ClientKeyExchange, ChangeCipherSpec, and Finished. The server responds with its own ChangeCipherSpec and Finished. Only after this full exchange can the first HTTP request be sent.

The two round trips add latency on every new connection. Each round trip on a transcontinental connection costs 80 to 150 milliseconds. Two round trips means 160 to 300 milliseconds of overhead before a byte of content moves.

TLS 1.3 handshake (one round trip)

TLS 1.3 combines the key exchange into the ClientHello itself. The client no longer waits for the server to announce its preferred key exchange method before generating key material. Instead, the client sends key shares for the groups it is likely the server supports alongside the ClientHello. The server receives the ClientHello, selects a key share, and responds with its ServerHello, key share, encrypted extensions, certificate, CertificateVerify, and Finished all in one flight.

The client can verify the server’s identity and derive the session keys from the server’s first response, then immediately send the first HTTP request as the Finished message is acknowledged. The full exchange takes one round trip.

The reason TLS 1.3 can send key material speculatively in the ClientHello is that the set of supported key exchange groups was rationalized. TLS 1.2 supported so many options that the client could not reasonably guess which one the server would choose. TLS 1.3 reduced the supported groups to a small set of modern elliptic curves and finite field groups, making correct prediction likely. This is another case where removing options enabled a better design.

What TLS 1.3 Removed and Why Each Removal Mattered

Each feature removed from TLS 1.3 had a documented history of being exploited or creating risk. This is not a checklist of deletions. These removals each addressed specific attack classes.

RSA key exchange removed

In TLS 1.2 and earlier, RSA key exchange allowed the client to encrypt a random pre-master secret using the server’s RSA public key. The server decrypted it with its private key. The problem: if the server’s private key is ever compromised, an attacker who recorded historical TLS sessions can decrypt all of them retroactively. The private key is the single point of failure for the confidentiality of every past session.

TLS 1.3 removes RSA key exchange entirely. All key exchanges use ephemeral Diffie-Hellman variants: ECDHE over standard elliptic curves (P-256, P-384, X25519, X448) or DHE over finite fields. Ephemeral means a new key pair is generated for every session. The session encryption keys are derived from an exchange that cannot be reconstructed even by someone who later obtains the server’s long-term private key. This property is called forward secrecy and it is mandatory in TLS 1.3, not optional.

CBC mode cipher suites removed

TLS 1.2 supported both CBC (Cipher Block Chaining) mode and GCM (Galois Counter Mode) cipher suites. CBC mode has a long history of padding oracle attacks: BEAST (2011), Lucky 13 (2013), POODLE (2014), and variations of each. These attacks exploited the way TLS 1.2 handled MAC-then-encrypt with CBC padding to leak information about plaintext content.

TLS 1.3 supports only AEAD (Authenticated Encryption with Associated Data) cipher suites. AEAD combines encryption and authentication in a single operation, eliminating the MAC-then-encrypt separation that enabled padding oracle attacks. The supported AEAD modes in TLS 1.3 are AES-128-GCM, AES-256-GCM, and ChaCha20-Poly1305.

Renegotiation removed

TLS 1.2 supported renegotiation, allowing either party to initiate a new handshake within an established session. This feature enabled legitimate uses (triggering client certificate authentication mid-session) but also enabled attacks like the renegotiation injection attack (CVE-2009-3555). The fix was adding renegotiation information extension, but the underlying complexity remained.

TLS 1.3 removes renegotiation entirely. Certificate-based client authentication can be requested post-handshake through a different mechanism that does not carry the same risks. Removing renegotiation removed the entire attack class.

Compression removed

TLS compression (which compressed HTTP content before encryption) enabled the CRIME attack (2012) and its variants. Compression creates observable differences in ciphertext length based on plaintext content, which allowed attackers to recover session cookies by injecting known content and observing size changes. TLS 1.3 removes compression support entirely.

What TLS 1.3 Supports: The Reduced Cipher Suite List

TLS 1.2 had over 300 standardized cipher suites, many of them weak. TLS 1.3 has five. This is not a limitation but a feature: fewer options means less negotiation overhead, no possibility of downgrade to a weak suite, and less configuration surface for mistakes.

In TLS 1.3, the cipher suite name no longer includes the key exchange algorithm because all key exchanges use ephemeral Diffie-Hellman variants and the specific group is negotiated separately through the supported_groups extension. This separation is itself a design improvement: key exchange and symmetric encryption can be updated independently.

Zero Round Trip Time (0-RTT) Resumption: Performance With a Tradeoff

For repeat visitors, TLS 1.3 offers a mode that eliminates handshake latency entirely. When a client has previously connected to a server and holds a session ticket (a piece of encrypted state from the previous session), it can send application data in the very first message of the new connection. The server validates the session ticket, derives session keys, and processes the application data without any round trips. From the user’s perspective, the connection is instant.

The tradeoff is real and worth stating clearly: 0-RTT data is not protected against replay attacks.

In a normal TLS 1.3 handshake, the server sends a random value (server random) that the client must include in its Finished message, binding the session to this specific exchange. This prevents an attacker from recording a client’s Finished message and replaying it later. With 0-RTT, the data is sent before any server random is received, so there is no binding. An attacker who captures the 0-RTT data can replay it to the server.

For a GET request fetching a static page, replay is harmless. The same request fetched twice produces two identical responses and nothing changes on the server. For a POST request that transfers money, updates account data, or submits a form, a replayed request could execute the action twice.

Do not enable 0-RTT for endpoints that process non-idempotent requests: payment processing, account modification, form submissions, or any action with side effects. The replay risk is real and the performance benefit is not worth the exposure on these endpoints. Safe uses of 0-RTT include read-only API endpoints, static asset requests, and connections where the application layer has independent replay detection.

Encrypted Server Certificate: A Privacy Improvement

In TLS 1.2, the server’s certificate was sent in plaintext during the handshake. Anyone monitoring network traffic could read the certificate, learn the domain name of every HTTPS site visited, and potentially fingerprint the organization behind the certificate. This was a privacy gap even when the connection content was encrypted.

TLS 1.3 encrypts the server certificate as part of the EncryptedExtensions message, which is sent after the key exchange is complete and session keys are derived. An observer watching TLS 1.3 traffic still sees the SNI (Server Name Indication) field in the ClientHello, which contains the destination hostname in plaintext. However, the certificate itself (including the organization name and other identity fields) is encrypted.

Encrypted Client Hello (ECH) extends this further by encrypting the SNI as well, hiding the destination hostname from network observers entirely. ECH requires DNS-level configuration to provide the client with the encryption key needed to encrypt the ClientHello. Support for ECH in production is still rolling out as of 2026 but is available in Chrome, Firefox, and Cloudflare’s network.

TLS 1.3 Adoption and Compatibility in 2026

TLS 1.3 support is effectively universal among modern browsers, operating systems, and server software. Chrome, Firefox, Safari, and Edge all enable TLS 1.3 by default. OpenSSL 1.1.1 (released 2018) and later support TLS 1.3. Nginx 1.13.0 and Apache 2.4.37 with OpenSSL 1.1.1 both support TLS 1.3. AWS, Cloudflare, Fastly, and all major CDNs support TLS 1.3 on their edge infrastructure.

Compatibility concerns are minimal for public-facing websites. The relevant question is whether old client software in enterprise environments (specific versions of Java, .NET Framework, older OpenSSL builds on Linux distributions with long support cycles) needs to connect to your server over TLS. For consumer-facing websites, TLS 1.3 can be enabled as the preferred version with TLS 1.2 as a fallback with no user impact.

Enabling TLS 1.3 on Your Web Server

TLS 1.3 negotiation is automatic when both client and server support it. No special cipher suite configuration is required for TLS 1.3 because the cipher suites are fixed. The main configuration task is ensuring TLS 1.3 is listed in the accepted protocols alongside TLS 1.2.

Nginx

Apache

In Apache 2.4.37 and later with OpenSSL 1.1.1, adding TLSv1.3 to the SSLProtocol directive enables it. The full directive should read: SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1, which enables TLS 1.2 and 1.3 while disabling all deprecated versions. The SSLCipherSuite directive applies only to TLS 1.2; TLS 1.3 cipher suites are managed through SSLCipherSuite TLSv1.3 if customization is needed.

Verifying TLS 1.3 is active

After deploying the configuration, test using the SSL Labs server test at ssllabs.com/ssltest. The Protocol Support section shows which TLS versions the server accepts. A server with TLS 1.3 enabled shows TLS 1.3 in the Protocol Support section with a checkmark. Alternatively, OpenSSL can test directly: run openssl s_client -tls1_3 -connect yourdomain.com:443 from any machine with OpenSSL 1.1.1 or later. A successful connection showing Protocol: TLSv1.3 in the output confirms TLS 1.3 is operational.

TLS 1.3 vs TLS 1.2: Key Differences at a Glance

Frequently Asked Questions

What is TLS 1.3?

TLS 1.3 is the current version of the Transport Layer Security protocol, published as RFC 8446 in August 2018. It is the cryptographic protocol that secures HTTPS connections. TLS 1.3 improves on TLS 1.2 in two primary ways: it is faster, completing the connection handshake in one round trip instead of two, and it is more secure, by removing all deprecated and weak cryptographic options that created attack surface in TLS 1.2. All modern browsers, operating systems, and web servers support TLS 1.3.

What is the difference between TLS 1.2 and TLS 1.3?

The most significant differences are: TLS 1.3 requires only one round trip to complete the handshake (TLS 1.2 needs two), TLS 1.3 mandates forward secrecy for all connections (TLS 1.2 makes it optional), TLS 1.3 has only five cipher suites (TLS 1.2 has over 200), TLS 1.3 encrypts the server certificate during the handshake (TLS 1.2 sends it in plaintext), and TLS 1.3 removes all CBC mode ciphers, RSA key exchange, renegotiation, and compression that enabled various attacks against TLS 1.2.

Does enabling TLS 1.3 break compatibility with old clients?

Rarely, for public-facing websites. All browsers released since 2018 support TLS 1.3. Servers configured with ssl_protocols TLSv1.2 TLSv1.3 continue to accept TLS 1.2 connections from clients that do not yet support TLS 1.3, so old clients are not broken. The risk area is specific enterprise software: Java 8 before update 261, .NET Framework 4.6 and earlier, and specific versions of OpenSSL on old Linux distributions do not support TLS 1.3 and fall back to TLS 1.2 automatically as long as TLS 1.2 is still enabled on the server.

Should I disable TLS 1.2 and use only TLS 1.3?

Not for most public servers in 2026. While TLS 1.3 is preferable and all modern clients support it, some enterprise software, embedded devices, and legacy systems use TLS 1.2. Disabling TLS 1.2 breaks connections from these clients. The recommended configuration is ssl_protocols TLSv1.2 TLSv1.3, with TLS 1.3 used automatically by any client that supports it and TLS 1.2 available as a fallback. Disable TLS 1.0 and TLS 1.1, which are deprecated and removed from major browsers, but keep TLS 1.2 active alongside TLS 1.3.

What is 0-RTT in TLS 1.3 and is it safe to enable?

0-RTT (zero round-trip time) resumption allows returning clients that hold a session ticket to send application data in the very first message of a new connection, before the handshake completes. This eliminates connection setup latency for repeat visitors. The security tradeoff is that 0-RTT data is not protected against replay attacks: an attacker who captures 0-RTT data can send it to the server again, potentially causing the server to process the same request twice. 0-RTT is safe for read-only requests and safe to enable when the application layer has independent replay protection. It should not be used for payment processing, account modification, or any non-idempotent operation.

Does TLS 1.3 affect the SSL certificate I need?

No. The SSL certificate type (DV, OV, EV), the key algorithm (RSA or ECC), and the CA that issued it are independent of the TLS version. An existing RSA 2048-bit certificate works with TLS 1.3. Switching to TLS 1.3 does not require replacing the certificate. The certificate is presented during the TLS handshake regardless of version. The only certificate-related consideration is that TLS 1.3 removes SHA-1 signature support, so certificates signed with SHA-1 cannot be used with TLS 1.3 connections. All certificates issued since 2016 use SHA-256 or better and are unaffected.