TLS (Transport Layer Security) is the protocol behind the padlock in your browser. It encrypts traffic between a visitor and your server and proves the server is who it claims to be. Two versions matter today: TLS 1.2, defined in 2008, and TLS 1.3, published in 2018 as RFC 8446. Comparing TLS 1.3 vs 1.2 is not just a version bump; 1.3 was redesigned to be simpler, faster and harder to misconfigure.
A quick refresher: what the handshake does
Before any web page is sent, the browser and server perform a handshake. In it they agree on which algorithms to use, the server presents its certificate, and both sides derive shared encryption keys that nobody watching the network can calculate. Only then does real data flow. Everything in the TLS 1.3 vs 1.2 comparison comes back to how this handshake is done.
TLS 1.3 vs 1.2: the main differences
1. A faster handshake
A full TLS 1.2 handshake needs two round trips between client and server before application data can be sent. TLS 1.3 needs one. The client guesses which key-exchange method the server will accept and sends its key share in the very first message, so the server can respond with everything needed to finish.
A round trip is the time for a message to reach the server and a reply to come back. For a visitor on the other side of the world or on a mobile network, saving one can noticeably shorten the time to first byte on a new connection.
TLS 1.3 also offers 0-RTT resumption (sometimes called "early data"): a returning client can send a request alongside its first message. The trade-off is that early data can be replayed by an attacker, so it should only be enabled for safe, idempotent requests such as plain GETs, and many servers leave it off by default.
2. Weak and legacy options were removed
TLS 1.2 allows a long menu of cipher suites, and many configurations still offer outdated ones. TLS 1.3 removed whole categories of risky features:
- Static RSA key exchange (no forward secrecy).
- CBC-mode ciphers, which were behind several attacks over the years.
- RC4, 3DES, MD5 and SHA-1 based constructions.
- TLS-level compression and renegotiation.
TLS 1.3 defines just five cipher suites, all using authenticated encryption (AEAD). In practice you will see TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256.
3. Forward secrecy is mandatory
Forward secrecy means each session uses temporary keys that are thrown away afterwards. If your server's private key is stolen next year, an attacker who recorded today's traffic still cannot decrypt it. TLS 1.2 supports forward secrecy only when ECDHE or DHE cipher suites are chosen. In TLS 1.3, every key exchange is ephemeral, so you get it automatically.
4. More of the handshake is encrypted
In TLS 1.2, the server's certificate travels in plain text, so anyone on the network path can see it. In TLS 1.3, everything after the initial hello messages is encrypted, including the certificate. The hostname in the first message (SNI) is still visible unless Encrypted Client Hello is used, which is a separate, newer extension.
Summary table
| Feature | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Full handshake | 2 round trips | 1 round trip |
| Resumption with early data | No | Yes (0-RTT, optional) |
| Forward secrecy | Only with ECDHE/DHE suites | Always |
| Cipher suites | Many, some weak | Five, all AEAD |
| Certificate visible on the wire | Yes | No (encrypted) |
| Configuration risk | Higher | Lower |
Is TLS 1.2 still safe?
Yes, when configured well. TLS 1.2 with ECDHE key exchange and AES-GCM or ChaCha20-Poly1305 ciphers remains secure and is still needed for some older clients and enterprise systems. The risk lies in weak cipher suites left enabled for compatibility. TLS 1.0 and 1.1, by contrast, were formally deprecated in RFC 8996 and are no longer supported by current major browsers. They should be disabled. Newer developments such as post-quantum hybrid key exchange are being deployed for TLS 1.3, which is another reason to make sure it is switched on.
How to enable TLS 1.3 and disable old versions
TLS 1.3 needs a reasonably modern TLS library (OpenSSL 1.1.1 or later). Most current Linux distributions meet this.
Nginx:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;Apache (mod_ssl):
SSLProtocol -all +TLSv1.2 +TLSv1.3Reload the service after editing. On Windows Server, TLS 1.3 support depends on the Windows version; Windows Server 2022 and later support it, while older releases do not. Load balancers and CDNs usually have a security-policy setting where you select the minimum TLS version. If you run several servers, set these values in shared configuration templates so they stay consistent, a routine part of good server management.
How to test which versions your server accepts
With OpenSSL you can force a specific version:
openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null
openssl s_client -connect example.com:443 -servername example.com -tls1_1 </dev/nullThe first should complete and show Protocol : TLSv1.3 (wording varies slightly between OpenSSL versions). The second should fail if TLS 1.1 is correctly disabled. You can also use curl -v --tlsv1.3 https://example.com. For the certificate side of the connection, including expiry and chain, run the site through our SSL checker.
Key takeaways
- TLS 1.3 halves the handshake round trips and removes weak legacy cryptography.
- Forward secrecy and encrypted certificates come built in with TLS 1.3.
- Run TLS 1.2 and 1.3 together; disable TLS 1.0 and 1.1.
- Keep TLS 1.2 limited to modern ECDHE and AEAD cipher suites.