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.