TLS 1.2 stands alone: what it means for your website

If your website still relies exclusively on TLS 1.2, you are not in immediate danger, but you are not in the strongest position either. In March 2021, the IETF published RFC 8996, formally deprecating TLS 1.0 and TLS 1.1. TLS 1.3, published in 2018 as RFC 8446, is now the reference standard for secure web communications. TLS 1.2 remains functional and secure with proper configuration, but its role shrinks every day. Here is what this means for your website and what steps you should take.

A brief history of TLS

The encryption protocol protecting the web has evolved significantly over three decades:

• SSL 2.0 (1995) -- The first public version of Netscape's protocol. It contains fundamental design flaws and must never be used.
• SSL 3.0 (1996) -- Improved on SSL 2.0's design but was compromised by the POODLE attack in 2014. Officially deprecated.
• TLS 1.0 (1999) -- The direct successor to SSL 3.0 under the IETF umbrella. Vulnerable to the BEAST attack and others. Deprecated in 2021 (RFC 8996).
• TLS 1.1 (2006) -- Fixed some TLS 1.0 issues but introduced no substantial cryptographic improvements. No known catastrophic flaws, but it lacks modern features. Deprecated in 2021 (RFC 8996).
• TLS 1.2 (2008) -- Introduced support for SHA-256, AEAD cipher suites, and greater flexibility. It remains the most widely deployed version on the Internet and is secure when properly configured.
• TLS 1.3 (2018) -- Faster handshake (1-RTT vs 2-RTT), removed unsafe features, and makes Perfect Forward Secrecy mandatory. It is the current standard.

Why TLS 1.3 is better

TLS 1.3 is not an incremental update; it is a deep rewrite of the protocol with concrete improvements:

Removal of obsolete cryptography. TLS 1.3 completely eliminated RC4, DES, 3DES, MD5, SHA-1 as a handshake signature algorithm, and static RSA key exchange. These algorithms had been considered weak for years, but TLS 1.2 still allowed them for backward compatibility.

Mandatory Perfect Forward Secrecy. In TLS 1.2, PFS is optional. A server can negotiate a static RSA key exchange, meaning that if the server's private key is compromised in the future, all past recorded traffic becomes exposed. TLS 1.3 only allows ECDHE, ensuring every session generates unique ephemeral keys.

Faster handshake. TLS 1.2 requires two round trips (2-RTT) to complete the handshake. TLS 1.3 reduces this to one (1-RTT) and supports 0-RTT resumption for repeat connections. On mobile networks with high latency, this produces a measurable difference in page load times.

Simplicity. TLS 1.2 supports dozens of cipher suites, many of them insecure. TLS 1.3 reduces the list to just five, all based on AEAD (Authenticated Encryption with Associated Data). Fewer options means fewer opportunities for misconfiguration.

Encrypted handshake. In TLS 1.2, the server certificate is transmitted in cleartext during the handshake. In TLS 1.3, the certificate is encrypted, improving user privacy by making it harder for a network observer to identify which server a client is connecting to.

The TLS 1.2 problem

TLS 1.2 is not broken. Millions of websites use it daily without incident. But it has real limitations:

It allows weak cipher suites if misconfigured. A poorly configured TLS 1.2 server can negotiate CBC modes (vulnerable to padding oracle attacks) or use SHA-1 for signatures. The security of TLS 1.2 depends entirely on the administrator selecting the right cipher suites.

It does not enforce PFS. As mentioned, static RSA key exchange remains a valid option in TLS 1.2. If your server allows it, your traffic does not have forward secrecy.

Slower handshake. The additional round trip in TLS 1.2 particularly affects mobile users on high-latency networks. On a 3G connection with 300 ms RTT, the TLS 1.2 handshake takes an extra 600 ms compared to 300 ms for TLS 1.3.

Regulatory pressure. PCI DSS 4.0 already recommends TLS 1.3, and future revisions are likely to require it. Compliance frameworks such as SOC 2 and ISO 27001 audits increasingly evaluate TLS version as part of their controls.

Browsers are moving forward. Chrome, Firefox, Safari, and Edge have already removed TLS 1.0 and 1.1 support. TLS 1.2 is the next version in the deprecation queue, though no official date has been set.

What to do today

Enabling TLS 1.3 is a matter of minutes, not weeks. Here are the concrete steps:

1. Enable TLS 1.3 on your server

Nginx:

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;
ssl_prefer_server_ciphers off;

Apache:

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off

2. Disable TLS 1.0 and 1.1 completely

If you have not done so already, this should be your first step. Both versions are officially deprecated and there is no valid reason to keep them enabled in production.

3. Review your cipher suite order

Always prioritize ECDHE with AES-GCM. Remove any cipher suite that uses CBC, RC4, 3DES, or static RSA key exchange.

4. Enable HSTS with a long max-age

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

HSTS (HTTP Strict Transport Security) instructs browsers to connect only over HTTPS. A max-age of two years (63,072,000 seconds) is the current recommendation. Including preload allows you to register your domain in browsers' preload lists, ensuring HTTPS-only access even on the first visit.

5. Monitor Certificate Transparency logs

Certificate Transparency (CT) is a system of public logs where certificate authorities record every issued certificate. Monitoring these logs allows you to detect fraudulent certificates issued for your domain before they can be used in attacks.

6. Test your configuration

Tools like Qualys SSL Labs allow you to verify your TLS configuration in detail. UareSafe automates these checks as part of its continuous security evaluation, running them on every certified site at regular intervals.

Beyond versions: what else matters

TLS version is only one piece of the puzzle. Other critical factors include:

• Certificate validity. Expired certificates or broken trust chains break the secure connection entirely.
• Certificate Transparency. A certificate not logged in CT records can be a red flag indicating unauthorized issuance.
• OCSP Stapling. Allows the server to provide the revocation response directly, eliminating the need for the browser to query the CA separately (improving both performance and privacy).
• Key size. RSA 2048 bits is the minimum acceptable today. ECDSA with P-256 offers equivalent security with better performance and smaller certificate sizes.

What UareSafe evaluates

UareSafe automatically verifies five TLS-related controls on every certified website:

1. TLS version -- Confirms the server supports TLS 1.2 or higher and that obsolete versions are disabled.
2. Valid certificate -- Checks the full trust chain, expiration date, and domain name match.
3. HSTS enforcement -- Evaluates the presence of the HSTS header, the max-age value, and subdomain inclusion.
4. Cipher suite quality -- Analyzes the cipher suites accepted by the server and penalizes those using weak algorithms.
5. Certificate Transparency compliance -- Verifies that the domain's certificates are registered in public CT logs.

These controls are part of the Technical Security dimension, which accounts for 30% of the overall UareSafe certification score.

Conclusion

TLS 1.2 works today, but the window is closing. Regulatory frameworks are advancing, browsers are pushing forward, and the security and performance improvements of TLS 1.3 are too significant to ignore. Enabling TLS 1.3 is a five-minute server configuration change that improves both security and performance for your website. There is no reason to wait.