TLS 1.3 vs 1.2: What Really Changed

TLS 1.3 is a surprisingly simple protocol at its core, yet its speed improvements come from a ruthless elimination of complexity that existed purely for backward compatibility.

Let’s see it in action. Imagine a client (your browser) and a server (a website).

Client Hello

Client Hello
  Protocol Version: TLS 1.3
  Cipher Suites:
    TLS_AES_256_GCM_SHA384
    TLS_CHACHA20_POLY1305_SHA256
    TLS_AES_128_GCM_SHA256
  Extensions:
    Supported Groups: secp256r1, x25519
    Signature Algorithms: ecdsa_secp256r1_sha256, rsa_pss_sha256
    Key Share: x25519 (public key)

This is the client saying, "Hey server, I want to talk TLS 1.3. Here are the ciphers I support, the groups I can use for key exchange, and the signature types I can verify. Oh, and here’s my part of the key for our secure channel."

Server Hello

Server Hello
  Protocol Version: TLS 1.3
  Cipher Suite: TLS_AES_256_GCM_SHA384
  Extension: Key Share: x25519 (public key)

The server responds, "Okay, TLS 1.3 it is. We’ll use TLS_AES_256_GCM_SHA384. And here’s my public key for our key exchange."

Encrypted Extensions & Certificate

The server then sends its certificate and any other necessary configuration, all encrypted. This is a huge change from TLS 1.2, where this information was sent in the clear.

Finished

Both sides then send a Finished message, which is a hash of all the handshake messages exchanged so far. If these hashes match, the handshake is complete.

The Big Picture: What Problem Does TLS 1.3 Solve?

TLS 1.2, while robust, was burdened by decades of legacy features. It was like a Swiss Army knife with so many tools that it became clunky and inefficient. Many of these features were for backward compatibility with older, less secure versions of SSL/TLS or for negotiation of algorithms that are now well-understood and standardized. TLS 1.3 strips away all that cruft.

How It Works Internally: The "0-RTT" and "1-RTT" Handshake

The most significant change is the handshake. TLS 1.2 often took two round trips (2-RTT) between the client and server to establish a secure connection. TLS 1.3 reduces this to just one round trip (1-RTT) for most connections.

• TLS 1.2 (2-RTT):

  1. Client Hello
  2. Server Hello, Certificate, Server Key Exchange, Server Hello Done
  3. Client Key Exchange, Change Cipher Spec, Finished
  4. Application Data

• TLS 1.3 (1-RTT):

  1. Client Hello (includes client’s key share)
  2. Server Hello (includes server’s key share), Encrypted Extensions (including certificate and server’s cipher choice), Finished
  3. Application Data

The client now sends its public key share as part of the initial Client Hello. The server uses this to compute the shared secret before it even sends its own Server Hello. This eliminates an entire round trip.

Furthermore, TLS 1.3 removes a long list of cipher suites that were either insecure or redundant. It forces the use of authenticated encryption with associated data (AEAD) ciphers like AES-GCM or ChaCha20-Poly1305, which combine encryption and integrity checking in a single, efficient step. Negotiating separate encryption and MAC (Message Authentication Code) algorithms, as in TLS 1.2, is gone.

The Levers You Control

For most users, TLS 1.3 is enabled by default in modern browsers and servers. If you’re managing a server, you’ll typically configure your web server (like Nginx or Apache) to prioritize TLS 1.3.

For Nginx, it might look something like this in your nginx.conf or site-specific configuration:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_early_data on; # For 0-RTT

The ssl_protocols directive explicitly lists the allowed protocols. ssl_early_data on; enables 0-RTT. The ssl_ciphers directive, while still present, is less critical for TLS 1.3 because the protocol itself mandates AEAD ciphers and strong key exchange mechanisms. The server chooses from the client’s offered list, and TLS 1.3’s allowed ciphers are much more restricted and secure.

The "0-RTT" Advantage

TLS 1.3 also introduces an optional "0-RTT" mode. If a client has connected to a server before, it can send application data in its very first Client Hello. This is possible because the client can derive session keys from previously stored pre-shared keys or session tickets. This is incredibly fast, but it comes with security caveats: replay attacks are a concern if not handled carefully on the server side.

The Finished message in TLS 1.3 is fundamentally different and more secure than in TLS 1.2. It’s derived from the handshake transcript and the negotiated secret, making it resistant to certain downgrade attacks that plagued earlier versions. The handshake messages themselves are also encrypted earlier in the process.

The next thing you’ll likely encounter is understanding the implications and security trade-offs of 0-RTT connections.