TLS 1.3 vs 1.2: What Changed & Why It Matters

Why TLS 1.2 Needed to Be Replaced

TLS 1.2, published in 2008, was a significant improvement over TLS 1.0 and 1.1, but it inherited decades of legacy design decisions. By the time TLS 1.3 was finalised, researchers had demonstrated practical attacks against multiple aspects of TLS 1.2:

• BEAST (2011): Exploited CBC mode encryption in TLS 1.0, still partially relevant in 1.2 configs
• CRIME and BREACH (2012): Compression-based attacks leaking session data
• Lucky Thirteen (2013): Timing attack against CBC-mode cipher suites
• POODLE (2014): Downgrade attack forcing SSLv3; variants also affected TLS 1.2 with CBC ciphers
• FREAK and Logjam (2015): Downgrade attacks forcing weak 512-bit export-grade RSA/DH keys
• DROWN (2016): Servers supporting SSLv2 alongside TLS 1.2 could be attacked

Each of these attacks was possible because TLS 1.2 supported a sprawling list of cipher suites - some of which were fundamentally broken. The TLS working group decided that instead of patching, they would strip the protocol down to only what was cryptographically sound.

The Handshake: 2-RTT vs 1-RTT

The most immediately measurable improvement in TLS 1.3 is handshake speed. In TLS 1.2, establishing a new connection requires two round trips (2-RTT) before the first byte of application data can be sent:

1. RTT 1: Client Hello → Server Hello + Certificate + ServerHelloDone
2. RTT 2: Client KeyExchange + ChangeCipherSpec + Finished → Server ChangeCipherSpec + Finished
3. Application data exchange begins

TLS 1.3 reduces this to a single round trip:

1. RTT 1: Client Hello (with key share) → Server Hello + key share + Certificate + Finished
2. Application data exchange begins immediately

On a 50ms network, this saves 50ms per new TLS connection. For APIs making many short-lived connections, this compounds into significant latency savings. In high-frequency scenarios, TLS 1.3 handshakes run approximately 40% faster than TLS 1.2.

0-RTT Session Resumption

For returning clients, TLS 1.3 introduces 0-RTT (zero round trip time) resumption. The client can send application data in the very first message of a resumed connection, before the server responds. This is achieved using a pre-shared session ticket from a previous connection.

0-RTT comes with an important caveat: it is vulnerable to replay attacks. Because the server receives the data before it can confirm the client's identity, an attacker who intercepts a 0-RTT request can replay it. For this reason, 0-RTT should only be used for idempotent requests (GET, not POST with state changes).

Cipher Suites: From 37 to 5

TLS 1.2 supports 37 cipher suites (many more if you count deprecated variants). Picking the right combination was a constant source of misconfiguration. TLS 1.3 eliminates the problem by supporting exactly 5 cipher suites, all of which are AEAD (Authenticated Encryption with Associated Data):

• 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

All of these provide both confidentiality and integrity in a single operation, eliminating the class of attacks that exploited the separation between encryption and MAC in older CBC-mode cipher suites.

What TLS 1.3 Removed

The following were explicitly prohibited in TLS 1.3:

• RSA key exchange (no forward secrecy - if your server's private key is ever compromised, all past sessions recorded by an adversary can be decrypted)
• DHE with static parameters (vulnerable to Logjam if weak parameters are used)
• RC4 (stream cipher with known statistical biases)
• DES and 3DES (56-bit effective key size, broken by SWEET32)
• MD5 and SHA-1 for signatures (collision-vulnerable)
• CBC-mode cipher suites (vulnerable to padding oracle attacks)
• TLS compression (CRIME attack)
• Renegotiation (source of multiple vulnerabilities)
• Export-grade cryptography (40-bit and 56-bit keys)

Forward Secrecy Is Now Mandatory

In TLS 1.2, forward secrecy was optional. Many servers used RSA key exchange, where the same long-term private key was used to protect every session. If that key was later compromised (by breach, legal compulsion, or cryptanalysis), all past sessions encrypted with it could be decrypted.

In TLS 1.3, forward secrecy is mandatory. Every connection uses ephemeral keys generated fresh for that session. Even if your server's certificate private key is compromised next year, all sessions established today remain secure.

Forward secrecy is especially important in the context of mass surveillance. Adversaries may be recording encrypted TLS 1.2 traffic today, expecting to decrypt it later when computational power improves or a key is stolen. TLS 1.3 closes this risk for every new connection.

How to Enable TLS 1.3 on Your Server

Nginx

server {
    listen 443 ssl;
    ssl_certificate     /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    # Enable TLS 1.2 and 1.3 (disable 1.0 and 1.1)
    ssl_protocols TLSv1.2 TLSv1.3;

    # TLS 1.2 cipher suites (TLS 1.3 ciphers are configured separately by OpenSSL)
    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;

    # Session resumption
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;  # Disable for forward secrecy

    # HSTS (6 months)
    add_header Strict-Transport-Security "max-age=15768000" always;
}

Apache

<VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile    /etc/ssl/certs/example.com.crt
    SSLCertificateKeyFile /etc/ssl/private/example.com.key

    # Enable TLS 1.2 and 1.3
    SSLProtocol -all +TLSv1.2 +TLSv1.3

    # TLS 1.2 cipher suites
    SSLCipherSuite 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
    SSLHonorCipherOrder off

    # TLS 1.3 ciphers (Apache 2.4.36+)
    SSLOpenSSLConfCmd Curves X25519:prime256v1:secp384r1
</VirtualHost>

Verifying TLS 1.3 Support

# Test TLS 1.3 handshake from command line
openssl s_client -connect example.com:443 -tls1_3

# Check which protocol was negotiated
curl -vI https://example.com 2>&1 | grep "SSL connection"
# Should show: SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384

# Using nmap for TLS version detection
nmap --script ssl-enum-ciphers -p 443 example.com

Browser and Client Support

As of 2026, TLS 1.3 is supported by virtually all modern clients:

• Chrome 70+ (2018) - full TLS 1.3 support
• Firefox 63+ (2018) - full TLS 1.3 support
• Safari 12.1+ (2019) - full TLS 1.3 support
• Edge 79+ (2020, Chromium-based) - full TLS 1.3 support
• curl 7.52+ with OpenSSL 1.1.1+
• Python 3.7+ with OpenSSL 1.1.1+

The only clients that cannot use TLS 1.3 are legacy systems: Windows XP, IE 11 on older Windows, and very old Android devices. If you support these, you should keep TLS 1.2 enabled alongside TLS 1.3 - never disable 1.2 completely unless you have confirmed your user base does not need it.

Frequently Asked Questions

Should I disable TLS 1.2 entirely?

Not yet for most public-facing services. TLS 1.2 with strong cipher suites (ECDHE + AES GCM) is still considered secure. Disabling it would break compatibility with a small but real segment of older clients. The recommended approach is to support both TLS 1.2 and 1.3, let clients negotiate the best version, and monitor your access logs to see what percentage of traffic uses TLS 1.2. If it drops to near zero, you can consider disabling it.

Does TLS 1.3 improve performance measurably?

Yes. The 1-RTT handshake saves one round trip on every new connection, and 0-RTT can eliminate the handshake entirely for returning clients. On a typical HTTPS API with 80ms latency, switching from TLS 1.2 to TLS 1.3 reduces connection setup time by roughly 80ms per new session. For mobile users on high-latency networks, this is meaningful. Google's measurements showed a 10% improvement in connection time after enabling TLS 1.3 across their infrastructure.

Is 0-RTT safe to enable?

0-RTT is safe for GET requests and other idempotent operations. It should not be enabled for endpoints that mutate state (POST, DELETE, financial transactions) because 0-RTT data can be replayed. If you enable 0-RTT at the server level, you must add application-level replay protection (anti-replay tokens or idempotency keys) for any sensitive endpoint. Cloudflare, for example, enables 0-RTT by default but documents the replay risk clearly.

What is the difference between TLS 1.3 and HTTPS?

HTTPS is HTTP transported over TLS. TLS is the encryption layer; HTTPS is the application protocol. When you enable TLS 1.3 on your server, you are upgrading the encryption used by HTTPS connections. The browser still uses HTTP semantics (GET, POST, status codes, headers) - TLS 1.3 is invisible to the application layer.

How does TLS 1.3 affect PCI DSS compliance?

PCI DSS 3.2 (and later 4.0) requires disabling TLS 1.0 and TLS 1.1, and recommends TLS 1.2 or higher. TLS 1.3 is fully compliant and preferred. If you are pursuing PCI DSS compliance, enabling TLS 1.3 alongside TLS 1.2 is the recommended configuration. TLS 1.3's mandatory forward secrecy and removal of weak ciphers align directly with PCI DSS security requirements.

The Bottom Line

TLS 1.3 is strictly better than TLS 1.2 in every dimension: faster handshake, mandatory forward secrecy, removed weak cipher suites, and a simpler protocol that is harder to misconfigure. Enabling it on your server takes one line of configuration on Nginx or Apache, and major CDNs like Cloudflare enable it automatically. There is no reason to run a public web service in 2026 without TLS 1.3 support.

Check whether your server supports TLS 1.3, inspect your certificate, and verify your cipher suite configuration: Use our SSL Checker tool here →