What is the difference between TLS 1.2 and TLS 1.3?

TLS 1.3 reduces the handshake from two round trips to one, cuts supported cipher suites from 37+ to exactly 5 (all AEAD), makes forward secrecy mandatory, and encrypts the server certificate during the handshake. TLS 1.2 supports weaker cipher options like RSA key exchange and CBC mode that have been exploited in BEAST, POODLE, and FREAK attacks.

Is TLS 1.3 faster than TLS 1.2?

Yes. TLS 1.3 completes a new connection in one round trip instead of two. At 100 ms network latency, that saves 100 ms per connection. For returning clients, 0-RTT session resumption can eliminate handshake overhead entirely, though it carries replay-attack caveats for non-idempotent requests.

Should I upgrade from TLS 1.2 to TLS 1.3?

Yes, and most modern servers support TLS 1.3 already. NIST SP 800-52 Rev 2 requires federal agencies to support TLS 1.2 minimum, but TLS 1.3 is now the preferred standard. All major browsers dropped TLS 1.0 and 1.1 between 2020 and 2021. Enable TLS 1.3 on your server and keep TLS 1.2 as a fallback until legacy clients are phased out.

Does TLS 1.3 support RSA?

TLS 1.3 removed RSA key exchange entirely. RSA certificates can still be used for authentication (the server proves its identity), but the key agreement that generates session keys must use ECDHE. This means every TLS 1.3 session has forward secrecy — past sessions cannot be decrypted even if the server's RSA private key is later compromised.

What is forward secrecy in TLS?

Forward secrecy means that each session uses a unique ephemeral key pair for key exchange. If an attacker records encrypted traffic today and later steals the server's private key, they still cannot decrypt those recordings. TLS 1.3 makes forward secrecy mandatory by requiring ECDHE for all key agreements.

Is TLS 1.2 still secure?

TLS 1.2 is still acceptable when configured correctly — specifically with AEAD cipher suites and ECDHE key exchange only. The problem is that TLS 1.2 allows weak options by default, and misconfigured servers leave those options enabled. NSA and CISA jointly recommended disabling TLS 1.0 and 1.1 in 2021, and TLS 1.2 remains conditionally acceptable with proper hardening.

TLS 1.3 vs TLS 1.2: What Actually Changed

Introduction

Every HTTPS connection starts with a handshake. In TLS 1.2, that handshake takes two full round trips before your first byte of application data moves. At 100 ms of network latency — typical for transatlantic connections — that is 200 ms of overhead before the page begins loading.

TLS 1.3 vs TLS 1.2 is not just a version number change. The newer protocol redesigns the handshake from scratch, compresses it to one round trip, and removes every cipher suite behind the decade’s worst HTTPS attacks: BEAST, POODLE, FREAK, Logjam, CRIME, and SWEET32.

That cleanup matters because TLS 1.2 does not just permit strong cipher suites — it also permits weak ones. A misconfigured server running TLS 1.2 might still accept RSA key exchange (no forward secrecy), CBC mode (vulnerable to padding oracle attacks), or MD5 in its PRF. Attackers negotiate down to the weakest option you allow. TLS 1.3 removes that surface entirely: all five supported cipher suites are AEAD-only, all use ECDHE for key exchange, and forward secrecy is no longer optional. To understand the cipher suites TLS 1.3 introduced, read our guide on AES-256-GCM authenticated encryption.

TLS 1.3 became an IETF standard in RFC 8446 in August 2018. Today, Google, Cloudflare, and AWS all default to it. Cloudflare Radar shows TLS 1.3 accounting for 60–70% of new TLS connections in 2024. If your servers are not yet offering it, you are running behind the industry.

What Is TLS 1.3?

TLS (Transport Layer Security) is the protocol that encrypts data between a client — your browser, your mobile app, your API client — and a server. The padlock icon in your browser means TLS is active. Every HTTPS connection, every encrypted API call, every secure WebSocket runs on TLS.

TLS 1.3, defined in RFC 8446 (2018), is the current version of the protocol. It replaces TLS 1.2 (RFC 5246, 2008) with three major changes: a faster handshake, a radically reduced cipher suite list, and mandatory forward secrecy.

Where TLS 1.2 was designed to be backward-compatible with older algorithms, TLS 1.3 starts fresh. It drops RSA key exchange, CBC mode, export ciphers, session renegotiation, and compression — every mechanism that gave attackers something to exploit over the past decade.

How TLS 1.3 Works

The TLS 1.2 Handshake (2-RTT)

A TLS 1.2 connection for a new client requires two full round trips:

The client sends a ClientHello listing supported cipher suites, TLS versions, and a random nonce.
The server responds with a ServerHello (chosen cipher suite), its certificate, a key exchange message, and a done signal — all unencrypted.
The client sends its key exchange material (RSA-encrypted premaster secret or Diffie-Hellman public value) and signals a cipher change.
The server confirms, and encrypted data exchange begins.

Two round trips. At 100 ms latency, 200 ms of delay before the first byte of your application data.

The TLS 1.3 Handshake (1-RTT)

TLS 1.3 collapses this to one round trip by front-loading key material:

The client sends a ClientHello that already includes its ECDHE public key (key_share extension), making a guess at which curve the server will prefer.
The server replies with its own key share, derives the session keys immediately, and sends its certificate and a Finished message — all of this is already encrypted in TLS 1.3. The server can begin sending application data right away.
The client sends its Finished message.

Encrypted data begins after step 2, not step 4. For returning clients, 0-RTT session resumption allows the client to send application data with the very first message, achieving effectively zero handshake overhead. (0-RTT carries a replay-attack risk and should not be used for POST requests or other non-idempotent operations.)

This video explains Diffie-Hellman key exchange, the mechanism TLS 1.3 uses in every handshake to achieve forward secrecy. TLS 1.3 requires ECDHE — an elliptic-curve variant — for all connections.

TLS 1.3 vs TLS 1.2

Notice the round-trip difference on the left and the cipher suite count on the right — TLS 1.3 removes every legacy option, leaving only five AEAD suites.

Feature	TLS 1.2	TLS 1.3
Handshake round trips	2-RTT	1-RTT (0-RTT for resumption)
Cipher suites	37+ (including weak options)	5 (all AEAD + ECDHE only)
Forward secrecy	Optional	Mandatory (ECDHE only)
RSA key exchange	Supported	Removed
CBC mode	Supported	Removed
ServerHello encrypted	No	Yes
Session renegotiation	Allowed	Removed
Published	2008 (RFC 5246)	2018 (RFC 8446)

The most important row is cipher suites. TLS 1.2 shipped with backward-compatible support for export-grade ciphers, 64-bit block ciphers, and NULL encryption. Each of those options became an attack surface. TLS 1.3 ships with only five cipher suites, all using AEAD (Authenticated Encryption with Associated Data) — meaning every cipher both encrypts and authenticates in a single step, eliminating an entire class of padding oracle and bit-flipping attacks.

Real-World Use Cases

HTTPS web servers: When a browser connects to your server offering both TLS 1.2 and TLS 1.3, the browser negotiates TLS 1.3. Cloudflare measured a 30% improvement in connection setup speed after enabling TLS 1.3. Facebook reduced handshake latency by 35% in a 2017 deployment study. Enabling TLS 1.3 in nginx or Apache requires adding it to the ssl_protocols directive — no application code changes.

API and mobile clients: Mobile apps connecting to REST APIs benefit from TLS 1.3’s reduced round trips, particularly on high-latency mobile networks. The 0-RTT session resumption feature means a user re-opening an app after a few minutes reconnects with zero handshake overhead, directly reducing perceived latency.

Compliance evidence: NIST SP 800-52 Rev 2 (2019) requires federal agencies to support TLS 1.2 and deprecate TLS 1.0/1.1. NSA and CISA’s 2021 joint advisory explicitly recommends moving to TLS 1.3 where possible. SOC 2 auditors will ask for SSL Labs reports; a server running TLS 1.3 with strong cipher suites earns an A+ rating, while servers still supporting TLS 1.0 fail.

Common Mistakes to Avoid

Disabling TLS 1.2 before clients are ready. TLS 1.3 adoption among client libraries is high but not universal. Some enterprise software, older Android versions, and legacy Java applications do not support TLS 1.3. Keep TLS 1.2 enabled as a fallback with strong cipher suites only (ECDHE + AEAD). Disable TLS 1.0 and 1.1 immediately — those have no defensive justification.

Leaving weak TLS 1.2 cipher suites enabled. If you run TLS 1.2 alongside TLS 1.3, audit your TLS 1.2 cipher suite list. Remove anything with RSA key exchange, CBC mode, MD5, or SHA-1. The OWASP TLS Cipher String Cheat Sheet provides tested, copy-paste configurations for nginx, Apache, and HAProxy.

Assuming 0-RTT is always safe. Zero-RTT session resumption is a performance win, but early data can be replayed by an attacker who captures the initial ClientHello. Never enable 0-RTT for POST, DELETE, or any endpoint with side effects. Use it only for idempotent GET requests.

Not testing with SSL Labs. The free Qualys SSL Labs server test (ssllabs.com/ssltest) reports your protocol versions, cipher suites, and certificate chain. Run it on every public endpoint. A result below A-rating means there are TLS configuration issues to fix, regardless of TLS version.

Getting Started

Check which TLS versions your servers currently offer by running an SSL Labs test on any public endpoint. The report shows exactly which protocol versions are enabled and which cipher suites are advertised. If your server shows TLS 1.0 or 1.1 as supported, disabling those is the first priority — no legitimate client needs them.

To enable TLS 1.3, update your web server’s TLS protocol configuration to include TLSv1.3. Most modern distributions of nginx (1.13+), Apache (2.4.36+), and HAProxy (1.8+) support TLS 1.3 out of the box. Your application code does not change — the protocol negotiation is handled by the TLS library.

After enabling TLS 1.3, verify your cipher suite list for TLS 1.2 fallback sessions. The OWASP Cipher String B recommendation removes all weak options while maintaining broad compatibility. Re-run the SSL Labs test after every configuration change to confirm the rating.

For internal services that communicate server-to-server, enforce TLS 1.3 only once you have confirmed all clients support it. Use certificate pinning or mutual TLS (mTLS) for internal APIs to add an additional layer of authentication beyond the certificate chain.

To understand the cipher suites TLS 1.3 introduced as mandatory, read about the cipher behind TLS 1.3 — ChaCha20-Poly1305. For the fundamentals of how hashing and encryption work together inside TLS, see hashing vs encryption.