TLS 1.2 vs TLS 1.3: What You Need to Know

What Is TLS?

Transport Layer Security (TLS) is the cryptographic protocol that powers HTTPS. Every time you visit a website with a padlock icon in the address bar, TLS is working behind the scenes to encrypt the connection between your browser and the server. It ensures that nobody can eavesdrop on or tamper with the data being exchanged.

TLS is the successor to SSL (Secure Sockets Layer), which was deprecated due to security vulnerabilities. Despite this, the term "SSL" persists in everyday usage — when someone talks about an "SSL certificate," they're really talking about a certificate used with the TLS protocol.

A Brief History: SSL to TLS 1.3

The evolution of secure web connections has been driven by the constant discovery of vulnerabilities and the need for better performance:

• SSL 2.0 (1995) — The first publicly released version. Quickly found to have serious security flaws.
• SSL 3.0 (1996) — A complete redesign that fixed SSL 2.0's issues, but was eventually compromised by the POODLE attack in 2014.
• TLS 1.0 (1999) — The first TLS version, a modest upgrade from SSL 3.0. Now considered insecure and deprecated by all major browsers.
• TLS 1.1 (2006) — Added protections against CBC attacks but is now deprecated alongside TLS 1.0.
• TLS 1.2 (2008) — A major improvement that introduced AEAD ciphers and SHA-256. Still widely used and considered secure when properly configured.
• TLS 1.3 (2018) — The current standard. Faster, simpler, and more secure by design. Removes legacy features that were sources of vulnerabilities.

Today, only TLS 1.2 and TLS 1.3 are considered acceptable. If your server still supports TLS 1.0 or 1.1, browsers will warn users or refuse to connect altogether. You can check your server's TLS support instantly with our SSL Checker.

Key Differences Between TLS 1.2 and TLS 1.3

Faster Handshake

The most immediately noticeable improvement in TLS 1.3 is handshake speed. TLS 1.2 requires two round trips between the browser and server before encrypted data can flow. TLS 1.3 reduces this to one round trip, cutting connection setup time roughly in half.

TLS 1.3 also supports 0-RTT (Zero Round Trip Time) resumption. When a client reconnects to a server it has visited before, it can start sending encrypted data immediately — with zero round trips for the handshake. This is particularly beneficial for mobile users on high-latency connections, where every millisecond counts.

Simplified Cipher Suites

TLS 1.2 supports a sprawling list of cipher suites — many of which are weak, outdated, or poorly configured in practice. This complexity creates opportunities for misconfiguration and downgrade attacks.

TLS 1.3 dramatically simplifies things by supporting only five cipher suites, all of which use AEAD (Authenticated Encryption with Associated Data) algorithms:

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_CCM_SHA256
• TLS_AES_128_CCM_8_SHA256

There's no way to accidentally enable a weak cipher in TLS 1.3 because weak ciphers simply don't exist in the specification.

Removed Legacy Features

TLS 1.3 removes several features from TLS 1.2 that were sources of vulnerabilities:

• RSA key exchange — Replaced by ephemeral Diffie-Hellman only, ensuring forward secrecy for every connection.
• CBC mode ciphers — Removed entirely, eliminating the class of padding oracle attacks (like BEAST and Lucky 13).
• RC4 and 3DES — Weak ciphers removed from the specification completely.
• Compression — Removed to prevent CRIME-style attacks.
• Renegotiation — Eliminated, closing off another historical attack vector.

Security Improvements in TLS 1.3

Beyond removing legacy features, TLS 1.3 introduces fundamental security improvements:

Forward secrecy is mandatory. In TLS 1.2, forward secrecy was optional — it depended on the cipher suite chosen. In TLS 1.3, every connection uses ephemeral key exchange, meaning that even if your server's private key is compromised in the future, past conversations remain encrypted and unreadable.

The handshake itself is encrypted. In TLS 1.2, most of the handshake happens in plaintext, exposing information like the server certificate. TLS 1.3 encrypts the handshake after the initial Client Hello, reducing the amount of metadata visible to network observers.

Downgrade protection is built in. TLS 1.3 includes mechanisms to detect and prevent attackers from forcing a connection to use an older, weaker protocol version.

Performance Benefits

The performance gains from TLS 1.3 are measurable and meaningful:

• Connection setup — One fewer round trip means connections are established faster. On a 100ms latency connection, this saves 100ms on every new connection.
• 0-RTT resumption — Returning visitors experience near-zero overhead for TLS, making HTTPS effectively free from a performance standpoint.
• Simpler processing — Fewer cipher options and a streamlined handshake mean less CPU work on both client and server.

If you're concerned about your site's performance, check your TLS configuration with SSL Checker and run a speed test with Site Speed Check to see the real-world impact.

How to Check Your TLS Version

The easiest way to find out which TLS versions your server supports is to use our SSL Checker tool. Enter your domain and we'll report exactly which protocol versions are enabled, along with the cipher suites in use and any configuration issues we detect.

You can also check from the command line using OpenSSL:

openssl s_client -connect yourdomain.com:443 -tls1_3

If the connection succeeds, your server supports TLS 1.3. Replace -tls1_3 with -tls1_2 to test TLS 1.2 support.

Should You Disable TLS 1.2?

Not yet. While TLS 1.3 is the preferred protocol, TLS 1.2 is still considered secure when properly configured, and a small percentage of clients don't yet support TLS 1.3. As of early 2026, roughly 3-5% of web traffic still uses TLS 1.2.

The recommended approach is to support both TLS 1.2 and TLS 1.3, while ensuring TLS 1.0 and 1.1 are disabled. This gives you the performance and security benefits of 1.3 for modern clients while maintaining compatibility for older ones. Your server will automatically negotiate the highest version both parties support.

If you're running a high-security application where you control the client software (like an internal API), disabling TLS 1.2 is reasonable. For public-facing websites, keep both versions enabled for now and monitor your traffic to see when TLS 1.2 usage drops low enough to safely remove it.

Enabling TLS 1.3 on Your Server

Most modern web servers support TLS 1.3 out of the box, but support depends on the underlying TLS library. nginx 1.13.0+, Apache 2.4.37+ with OpenSSL 1.1.1+, and Caddy (any version) all support 1.3. If your distribution still ships an older OpenSSL (1.0.x), TLS 1.3 won't be available regardless of how you configure the web server — that's the case on some long-term-support Linux releases. Update OpenSSL or upgrade the OS.

On nginx, ensure your ssl_protocols directive includes both 1.2 and 1.3:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;

Note: TLS 1.3 cipher suites are configured separately from TLS 1.2 ciphers and have their own (intentionally short) list. Most servers handle 1.3 ciphers automatically — you generally don't need to specify them.

On Apache:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off

For up-to-date, server-specific configurations, the Mozilla SSL Configuration Generator outputs ready-to-paste configs for nginx, Apache, HAProxy, AWS ELB, and other common platforms. The "intermediate" preset is the right baseline for almost every public site — it supports every browser released in the last decade while still being secure. After applying changes and reloading the server, verify with SSL Checker that both 1.2 and 1.3 are listed and the deprecated versions are gone.

Common Misconceptions About TLS 1.3

"TLS 1.3 breaks middlebox compatibility." True historically, mostly false now. During TLS 1.3's standardisation, some corporate firewalls and DPI appliances had trouble with the new handshake format. The IETF added a "middlebox compatibility mode" to TLS 1.3 specifically to handle this, and most middleboxes now work fine. If you're behind a corporate firewall that breaks TLS 1.3, the firewall is several years out of date.

"TLS 1.3 prevents you from inspecting your own traffic." Partly true. TLS 1.3 always uses ephemeral key exchange (ECDHE), which means there's no static key to share with a passive monitoring appliance. For internal traffic inspection, you need an active mTLS proxy or to terminate TLS at the inspection point. This is by design — passive decryption is exactly what forward secrecy is meant to prevent.

"You need a different certificate for TLS 1.3." False. Your existing certificate works for both 1.2 and 1.3. The only requirement is that the certificate uses a signature algorithm that 1.3 supports — every certificate issued in the last several years does.

"0-RTT is dangerous." Partially true and worth understanding. Data sent in 0-RTT is replayable — an attacker who captures the encrypted bytes can replay them to the server later. For idempotent requests (a GET to a public page) this is fine. For state-changing requests (POST to checkout), 0-RTT can cause duplicate submissions. Most servers and frameworks handle this correctly by only allowing 0-RTT on idempotent methods, but if you're enabling 0-RTT manually, verify what your server does with non-idempotent requests.

Migration Plan

If you're modernising an older server's TLS configuration, work in this order:

1. Confirm OpenSSL version. Run openssl version. If it's 1.1.1 or newer, you can support TLS 1.3.
2. Add TLS 1.3 to your protocols list. Don't remove 1.2 yet. Test with a real browser and our SSL Checker.
3. Disable TLS 1.0 and 1.1. Both have been deprecated since 2020 and are off in all major browsers. Removing them won't lose you legitimate traffic.
4. Audit cipher suites. Apply Mozilla's intermediate config. Re-run SSL Checker to confirm grade A or A+.
5. Monitor for a few weeks. Make sure no legitimate clients are failing. If you see unexpected handshake errors in logs, investigate before tightening further.
6. Optionally enable 0-RTT for low-risk static endpoints if you've measured the latency benefit and audited which routes can safely accept replayed requests.

The whole migration usually takes an afternoon. The performance and security wins are immediate, the configuration is well-understood, and the failure modes are easy to identify. If you've been putting it off, today's the day.