TLS 1.2 vs TLS 1.3: what changed and why it matters

TLS 1.3 is faster and safer than TLS 1.2: new connections need one round trip instead of two, forward secrecy is built in, and the legacy options behind a decade of attacks are gone. TLS 1.2 is still acceptable when carefully configured, but in July 2026 the IETF froze it, ruling out post-quantum key exchange, and banned its RSA and finite-field Diffie-Hellman key exchanges. Build for TLS 1.3 and keep TLS 1.2 only for clients that need it.

The short version

TLS 1.3's specification was reissued in July 2026 as RFC 9846, which obsoletes RFC 8446 and also sets some new requirements for TLS 1.2 implementations. The protocol on the wire is the same TLS 1.3.

Handshake: two round trips to one

A round trip is a message out and a reply back. On a phone, each one costs tens to hundreds of milliseconds, so the count matters more than the maths.

A full TLS 1.2 handshake goes like this:

1. The client says hello and lists the cipher suites it supports.
   
   
2. The server picks one and sends its certificate and, for ECDHE, its key-exchange value.
   
   
3. The client sends its own key-exchange value and a "finished" message.
   
   
4. The server replies with its "finished" message. Only now can the client send its request.
   
   

That is two round trips before any application data, because the client can't contribute its half of the key exchange until it knows which method the server chose. Browsers softened this with False Start, described in RFC 7918, which lets a client send its request slightly early in some conditions and cuts the wait to one round trip.

TLS 1.3 builds the saving into the protocol for every client. The client guesses which key-exchange group the server will accept and sends its key share in the very first message. The server answers with its own share, its encrypted certificate, a signature and its "finished" message in one flight, and the client's request follows immediately. If the guess was wrong, the server asks again with a HelloRetryRequest, which costs one extra round trip; that is why clients typically send shares for the two groups most likely to be accepted. Our guide to how SSL/TLS works walks through each message.

What TLS 1.3 removed

Most TLS attacks of the 2010s went after options that TLS 1.3 simply deleted:

• RSA key exchange. Sending the session secret encrypted to the server's RSA key gave no forward secrecy and invited a long line of padding-oracle attacks.
  
  
• Static and custom Diffie-Hellman groups. Weak or widely shared primes made attacks such as Logjam possible. TLS 1.3 allows only named groups; see our guide to Diffie-Hellman.
  
  
• CBC-mode and RC4 ciphers. Weaknesses in how TLS used CBC mode led to attacks such as BEAST and Lucky Thirteen; RC4's biases led to its outright ban. Every TLS 1.3 cipher is authenticated encryption.
  
  
• Compression, which enabled the CRIME attack.
  
  
• Renegotiation, the source of an earlier authentication flaw. TLS 1.3 forbids it.
  
  
• Old signature options such as DSA, and the fragile version negotiation of earlier versions, replaced by a version list plus a downgrade-protection signal hidden in the server's random value.
  
  

The result is a much shorter list of choices, covered in our guide to cipher suites. Fewer choices mean fewer ways to misconfigure a server.

0-RTT and its replay risk

When a client reconnects to a server it has used recently, TLS 1.3 can resume the session with a pre-shared key and even send the first request inside the first message. This "early data" or 0-RTT mode removes the handshake delay entirely. The specification is blunt about the cost: early data isn't guaranteed forward secrecy, and there is no protection against it being replayed on another connection. An attacker who captures the first flight can send it to the server again.

So early data is safe only for requests that do no harm if repeated. RFC 8470 gives HTTP servers a way to refuse the rest with a 425 (Too Early) status, and nginx keeps early data off unless you enable it; when enabled, it can pass your application a flag marking requests that arrived as early data.

If you aren't sure, leave early data off. Android's own TLS stack doesn't support 0-RTT at all, so most native app traffic gains nothing from it anyway.

Performance on mobile networks

Here is a worked example with illustrative round-trip times: 50 milliseconds for a good 4G or 5G connection, and 250 milliseconds for a weak signal in a hostel room or a crowded coaching-centre Wi-Fi. The table counts the round trips before a new connection's first response can start arriving, ignoring DNS lookups and server processing time.

On a poor connection, moving from TLS 1.2 to TLS 1.3 saves a quarter of a second on every new connection, and HTTP/3, which builds TLS 1.3 into its transport, saves another. That matters most in bursts. When a mock test opens at 10:00 and thousands of students connect at once, each fresh handshake costs the student time and your servers CPU. Three habits help beyond upgrading the protocol:

• Reuse connections. HTTP/2 and HTTP/3 carry many requests over one connection, so the handshake is paid once.
  
  
• Allow session resumption, so returning clients skip the certificate signature and verification.
  
  
• Prefer an ECDSA certificate where your clients support it; its handshake signature is usually cheaper for the server than RSA's.
  
  

Our guide to handling 100,000 concurrent users covers the rest of the exam-day picture.

Should you still support TLS 1.2?

For public websites served over HTTPS and public APIs, usually yes, for now. Some older phones, libraries, corporate proxies and partner systems still can't do TLS 1.3. Android turned TLS 1.3 on by default for all connections from Android 10, so anything older depends on the app's own networking library. Mozilla's server configuration guidance reflects this: its "intermediate" profile allows TLS 1.2 and 1.3, while its "modern" profile is TLS 1.3 only and lists Android 10, Chrome 70, Firefox 63 and Safari 12.1 as the oldest clients it supports.

If you keep TLS 1.2, configure it the way the 2026 standards now demand:

1. Allow only ECDHE key exchange with AEAD ciphers. RFC 10015, published in July 2026, says clients must not offer and servers must not select RSA or finite-field DHE key exchange in TLS 1.2.
   
   
2. Keep the extended master secret extension on, which fixes a known weakness in how TLS 1.2 derives keys; modern libraries enable it by default.
   
   
3. Rotate session-ticket keys, because a long-lived ticket key undermines forward secrecy for resumed TLS 1.2 sessions.
   
   
4. Measure before you cut. Log the negotiated protocol (in nginx, the $ssl_protocol variable) and check what share of real handshakes still use TLS 1.2.
   
   
5. Go TLS 1.3-only where you control both ends, such as APIs used only by your own recent apps, admin panels and service-to-service traffic.
   
   

The deciding factor for the future is the freeze. RFC 9851 states that the IETF will not add new features to TLS 1.2, and that post-quantum cryptography will never be specified for it. Anything you want protected against future quantum computers has to move to TLS 1.3; see our guide to post-quantum cryptography.

Key takeaways

• TLS 1.3 connects in one round trip instead of two and encrypts most of the handshake.
  
  
• It removed RSA key exchange, custom Diffie-Hellman groups, CBC and RC4 ciphers, compression and renegotiation.
  
  
• 0-RTT early data is fast but replayable; use it only for requests that are harmless to repeat.
  
  
• TLS 1.2 is still acceptable with ECDHE and AEAD suites only, but it is frozen and will never get post-quantum key exchange.
  
  
• Serve both where old clients need it, measure their share, and move to TLS 1.3-only wherever you control both ends.
  
  

Frequently asked questions

Is TLS 1.2 still secure?

Yes, when it is configured well: ECDHE key exchange, AEAD ciphers such as AES-GCM or ChaCha20-Poly1305, and the extended master secret extension. Its weak options are the problem, which is why RFC 10015 now forbids RSA and finite-field DHE key exchange in TLS 1.2. It is also frozen and lacks post-quantum protection, so treat it as a compatibility fallback rather than a target.

Is TLS 1.2 deprecated?

Not as a whole protocol. TLS 1.0 and 1.1 were formally deprecated in 2021, while TLS 1.2 remains in use and widely supported. In July 2026, the IETF put TLS 1.2 into feature freeze with RFC 9851, allowing only urgent security fixes, and deprecated its RSA and finite-field Diffie-Hellman key exchanges with RFC 10015. New deployments should prefer TLS 1.3.

Is TLS 1.2 quantum safe?

No. TLS 1.2 key exchange relies on elliptic-curve Diffie-Hellman, which a large quantum computer could break, exposing any traffic recorded today. The IETF has said post-quantum cryptography will not be specified for TLS 1.2. Hybrid post-quantum key exchange, such as X25519MLKEM768, exists only for TLS 1.3, and current browsers already use it. The symmetric ciphers inside TLS 1.2 are not the weak point.