TLS 1.2 vs TLS 1.3: What Actually Changed

Every time you load an HTTPS page, your browser and the server run a short negotiation before a single byte of the actual page moves. Part of that negotiation is picking a version of TLS, the protocol that turns plain HTTP into the padlocked kind. You never see the choice happen, but it decides how fast the connection sets up and how much of it an eavesdropper could ever learn.

For most of the last decade that version was TLS 1.2. Since 2018 there has been a successor, TLS 1.3, and it is now the default on a large share of the web. People describe the upgrade as "faster and more secure," which is true but unhelpfully vague. The improvements are concrete, and understanding them makes a lot of adjacent security topics click into place. Here is what actually changed between the two.

Two versions, and how a connection picks one#

TLS 1.2 was published as RFC 5246 in August 2008. It had a good run: it was solid enough to carry the web for ten years. TLS 1.3 followed a decade later as RFC 8446, published in August 2018 after years of drafts and real-world testing.

A connection settles on a version through the opening messages of the handshake. The client sends a ClientHello announcing the highest version it supports and a list of options; the server replies with the version it has chosen. Both sides prefer the newest version they have in common, so a modern browser talking to a modern server lands on TLS 1.3, while either side being older gracefully falls back to 1.2. That is why 1.3 could roll out across the internet without a flag day, and why both versions still coexist today.

Below those two live the genuinely old versions, TLS 1.0 and 1.1. Those were formally deprecated by RFC 8996 in March 2021, which states plainly that they MUST NOT be used. Modern browsers reject them outright. So in practice the live choice on today's web is exactly the one this article is about: 1.2 or 1.3.

The handshake got a round trip faster#

The most visible change is speed, and it comes from cutting a round trip out of the setup. In TLS 1.2, the handshake takes two full round trips between client and server before any application data can flow. The client says hello, the server responds with its certificate and parameters, the client replies with its key material, and only after that back-and-forth completes does the encrypted request go out. On a connection with 80 ms of latency, those extra trips are felt.

TLS 1.3 redesigned the handshake to complete in a single round trip. The client makes an educated guess about the key-exchange parameters and sends its key share in the very first message, so by the time the server has replied once, both sides have everything they need and the encrypted request can go out immediately. One round trip saved on every fresh connection adds up, especially on mobile networks where latency is high and connections are short-lived.

There is also an optional faster path called 0-RTT, or "early data." When a client has connected to a server recently, it can send application data along with its very first message, using keys derived from the earlier session, with no wait at all. The RFC is candid that this comes "at the cost of certain security properties": 0-RTT data can be replayed by an attacker who captures it, so it is only safe for requests that don't change state. It is a genuinely useful tool, but a sharp one, and most deployments limit it carefully.

Fewer choices, and that is the point#

TLS 1.2's flexibility was also its weakness. It supported a sprawling menu of cryptographic building blocks, and servers had to be configured carefully to avoid the weak ones. Left on defaults, a 1.2 server could negotiate the broken RC4 stream cipher, aging 3DES, or CBC-mode constructions that produced a long series of attacks with names like BEAST, Lucky Thirteen, and POODLE. The protocol wasn't broken so much as it gave you enough rope, and misconfiguration was the norm rather than the exception.

TLS 1.3 took the opposite approach and pruned the menu down to almost nothing. It defines just five cipher suites, and every one of them is an AEAD (Authenticated Encryption with Associated Data) algorithm that encrypts and authenticates in one vetted operation. The RFC puts it directly: the legacy algorithms have been removed and "those that remain are all Authenticated Encryption with Associated Data (AEAD) algorithms." The suites are built on AES-GCM, ChaCha20-Poly1305, and AES-CCM, with TLS_AES_128_GCM_SHA256 being the one every implementation must support.

Gone are RC4, 3DES, the CBC-mode suites, MD5 and SHA-1 in signatures, and the old DSA algorithm. There simply is no way to negotiate a weak symmetric cipher in TLS 1.3, because none is offered. A whole category of "you configured it wrong" vulnerabilities disappears not because administrators got more careful but because the dangerous options were deleted from the protocol.

Forward secrecy is no longer optional#

This is the security change that matters most, and it is easy to miss. In TLS 1.2, one common and perfectly valid configuration used the server's RSA key directly to establish the session secret. It worked, but it had a quiet flaw: anyone who recorded the encrypted traffic and later obtained the server's private key could decrypt all of that past traffic retroactively. One key compromise unlocked months of captured sessions.

Forward secrecy is the property that defeats this. When each session uses a fresh, ephemeral key that is thrown away afterward, stealing the server's long-term key gives an attacker nothing about past conversations. TLS 1.2 could do forward secrecy, but only if you chose an ephemeral suite; the non-forward-secret RSA option was still on the table.

TLS 1.3 removed the static RSA and static Diffie-Hellman key exchanges entirely. Every TLS 1.3 connection uses ephemeral (EC)DHE key exchange, which means forward secrecy is mandatory, not a checkbox. As the specification notes, all of the key-exchange mechanisms that remain now provide forward secrecy. A recorded TLS 1.3 session stays private even if the server's key leaks a year later, and there is no configuration that can weaken that.

More of the handshake is private#

The handshake itself leaked information in TLS 1.2. Because encryption only kicked in partway through, details like the server's certificate travelled in the clear, visible to anyone watching the network. A passive observer could see exactly which certificate, and therefore often which site, you were connecting to.

TLS 1.3 encrypts far more of the handshake. Once the first two messages establish keys, everything after the ServerHello is encrypted, including the server's Certificate message. The spec states it flatly: "All handshake messages after the ServerHello are now encrypted." A network observer still sees that a TLS connection is happening and to which IP, but the certificate and most of the negotiation details are now hidden. It is a real, if partial, privacy gain that TLS 1.2 never offered.

So should you care?#

If you run a server, the practical takeaway is short: enable TLS 1.3, keep 1.2 on for the shrinking set of older clients that still need it, and turn off everything below 1.2. That combination is the current mainstream baseline, and it gives you the faster handshake and mandatory forward secrecy for anyone modern while not breaking the stragglers.

If you're just someone who wants their connections to be safe, the good news is that you already benefit automatically. Your browser prefers TLS 1.3 on every site that supports it, with no setting to flip. The version is negotiated for you, silently, on every request. The details above are less a to-do list than an explanation of why the padlock means a bit more than it used to.

How to check which version a site uses#

Seeing the version for yourself makes all of this concrete. The definitive way is to open a real connection and watch what gets negotiated. From a terminal, the classic command is:

openssl s_client -connect example.com:443 -tls1_3

That attempts a TLS 1.3 handshake on port 443 and prints the negotiated protocol and cipher suite near the end of the output. Swap in -tls1_2 to confirm a server still accepts the older version, or drop the flag to see what it prefers on its own. A hosted service like SSL Labs' server test does the same handshake analysis in a browser and grades the result.

Our own SSL inspector answers a related but different question, and it's worth being precise about the boundary. It reads a domain's most recent certificate from the public Certificate Transparency logs and reports the issuing authority, expiry, hostname coverage, and HSTS state with a plain grade. Because it works from those logs rather than performing a raw TLS handshake, it deliberately does not report the negotiated protocol version or cipher suite; Cloudflare Workers can't open a raw TLS socket, so that field is honestly left blank. For the certificate side of your setup it's the fast check; for the exact 1.2-vs-1.3 handshake, reach for openssl s_client or a full handshake analyzer. Knowing which tool answers which question is half the work.

The version your connection lands on is one of the most consequential decisions on the web that nobody ever sees. TLS 1.3 didn't reinvent encryption; it removed the slow parts, deleted the dangerous options, and made the best-practice defaults the only defaults. That is why the advice collapsed from a page of cipher-suite tuning down to a single line: turn it on.