---
title: TLS 1.2 vs 1.3: what changed (and why it matters)
description: TLS 1.3 made HTTPS both faster and more secure than 1.2 — by doing less, not more. Here's what changed in the handshake, why it matters, and what to make sure your servers support.
canonical: https://watchfor.io/blog/tls-1-2-vs-1-3
---

# TLS 1.2 vs 1.3: what changed (and why it matters)

2025-12-22 · WatchFor Team · Security · security, networking, ssl

TLS 1.3 made HTTPS both faster and more secure than 1.2 — by doing less, not more. Here's what changed in the handshake, why it matters, and what to make sure your servers support.

Every `https://` connection is secured by **TLS** — and the version your servers speak quietly affects both speed and security. TLS 1.3, finalised in 2018, is now the standard, and it's a rare upgrade that makes things *faster* and *safer* at the same time. Here's what changed from 1.2.

## A quick recap of TLS

TLS is the protocol that encrypts web traffic (the "S" in HTTPS). Before any data flows, the client and server perform a [handshake](/blog/how-https-works) — agreeing on a version and cipher, exchanging keys, and verifying the server's [certificate](/blog/ssl-certificate-expiry). The version they use shapes how fast and secure that handshake is.

## What TLS 1.3 changed

TLS 1.3 improved security largely by **removing things** — dropping old, weak options that had caused vulnerabilities for years.

| Area | TLS 1.2 | TLS 1.3 |
| --- | --- | --- |
| **Handshake round trips** | Two (slower to set up) | One (faster) |
| **Resumed connections** | Round trip needed | "0-RTT" — near-instant |
| **Old/weak ciphers** | Still allowed | Removed entirely |
| **Default security** | Depends on config | Secure by default |

### Faster handshakes

TLS 1.2 needed **two round trips** to set up a secure connection; TLS 1.3 cut that to **one**. On a high-[latency](/blog/what-is-latency) connection (mobile, distant servers), that saved round trip is real, noticeable speed — it lowers your [TTFB](/blog/ttfb-explained) for first connections.

### More secure by design

TLS 1.2's flexibility was also its weakness: it supported old ciphers and options that, misconfigured, opened holes (many famous TLS attacks targeted these). TLS 1.3 **removed the legacy cruft** — fewer options means fewer ways to get it wrong. It's secure by default rather than secure-if-configured-carefully.

> **The neat part:** TLS 1.3 is faster *because* it's simpler, and more secure *because* it's simpler. Stripping out the old, weak options improved both at once.

## What about TLS 1.0 and 1.1?

Those older versions are **deprecated and unsafe** — modern browsers reject them. If a server only offers TLS 1.0/1.1, up-to-date clients refuse to connect (a cause of [handshake failures](/blog/ssl-handshake-failed)). They should be disabled everywhere.

## What you should do

You don't implement TLS yourself, but you should make sure your servers and CDN are configured well:

1. **Support TLS 1.2 and 1.3.** 1.3 for speed and security, 1.2 for any older clients that need it.
2. **Disable TLS 1.0 and 1.1.** They're insecure and trigger failures with modern clients.
3. **Keep certificates valid.** TLS version means nothing if your [certificate has expired](/blog/ssl-certificate-expiry) — that breaks the handshake regardless.
4. **Send the full chain.** A common [handshake failure](/blog/ssl-handshake-failed) is a missing intermediate certificate.

## A monitoring angle

Your TLS setup can drift — a renewal changes the chain, a config update disables a needed version. Monitoring the TLS connection (that the handshake completes, the chain is valid, and the certificate isn't near [expiry](/blog/ssl-certificate-expiry)) catches these before they become a total HTTPS outage.

## The bottom line

| | In one line |
| --- | --- |
| **TLS 1.3** | One-round-trip handshake — faster than 1.2's two. |
| **Security** | More secure by removing old, weak options. |
| **TLS 1.0/1.1** | Deprecated and unsafe — disable them. |
| **You** | Support 1.2 + 1.3, valid certs, full chain. |

TLS 1.3 is a quiet win: enable it (almost always a toggle at your server or CDN) and your HTTPS gets both faster and safer, with fewer ways to misconfigure. Just keep your certificates and chain healthy underneath it.

Related: [How HTTPS works](/blog/how-https-works), [SSL certificate expiry](/blog/ssl-certificate-expiry); check any site's TLS with the free [SSL checker](/ssl-checker).

---

Canonical page: https://watchfor.io/blog/tls-1-2-vs-1-3 · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt