TLS 1.2 vs TLS 1.3: Key Differences & Why You Should Upgrade

TLS 1.3, released in RFC 8446 (August 2018), is the most significant overhaul of the TLS protocol in years. It removes legacy weaknesses that plagued TLS 1.2 and significantly improves connection performance. If your servers still rely exclusively on TLS 1.2, here is everything you need to know about making the transition.

Handshake Speed: 1-RTT vs 2-RTT

One of TLS 1.3's most significant improvements is its reduced handshake latency. In TLS 1.2, establishing an encrypted connection requires two round trips (2-RTT) between client and server before any application data can be sent. TLS 1.3 reduces this to one round trip (1-RTT).

TLS 1.3 also introduces 0-RTT resumption for reconnecting clients. When a client reconnects to a server it has recently visited, it can send application data in its very first message — zero additional round trips. This dramatically improves performance for mobile users and APIs with high request frequencies.

Removed Weak Cipher Suites

TLS 1.2 supported many cipher suites that are now considered weak or broken. TLS 1.3 removes all of them and supports only five cipher suites, all of which provide forward secrecy:

• 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

Removed cipher suites include RC4, DES, 3DES, and MD5-based MACs — all of which have known exploits. TLS 1.3 also removes RSA key exchange, which was vulnerable to DROWN and FREAK attacks and did not provide forward secrecy.

Perfect Forward Secrecy by Default

In TLS 1.2, forward secrecy was optional. Many servers were misconfigured to use static RSA key exchange, meaning that if an attacker captured encrypted traffic and later obtained the server's private key, they could decrypt all historical sessions. TLS 1.3 makes forward secrecy mandatory — every session uses ephemeral Diffie-Hellman key exchange, so each session key is unique and cannot be retroactively decrypted.

Encrypted Certificate in Handshake

In TLS 1.2, the server's certificate is sent in plain text during the handshake. This means a passive observer on the network can see which certificate — and therefore which domain — you are connecting to. TLS 1.3 encrypts the server certificate as part of the handshake, improving privacy by preventing passive analysis of which websites a user visits.

Should You Still Support TLS 1.2?

As of 2026, TLS 1.3 adoption among browsers is above 90%. However, older devices, embedded systems, and some corporate proxy setups still negotiate TLS 1.2. A best practice is to:

• Enable TLS 1.3 as the preferred version
• Keep TLS 1.2 as a fallback with strong cipher suites only
• Disable TLS 1.0 and TLS 1.1 completely
• Monitor your server's negotiated TLS versions in access logs

How to Enable TLS 1.3 on Popular Servers

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

SSLProtocol -all +TLSv1.2 +TLSv1.3

// Node.js 12+ supports TLS 1.3 automatically via OpenSSL 1.1.1+
const https = require('https');
const server = https.createServer({
  minVersion: 'TLSv1.2',
  maxVersion: 'TLSv1.3',
  // ... cert and key
});