The terms "SSL" and "TLS" are often used interchangeably in everyday conversation — people say "SSL certificate" and "SSL configuration" even when they mean TLS. In technical reality, SSL is entirely obsolete and has been replaced by TLS. Understanding the distinction matters for configuring secure servers, interpreting security audit findings, and making sense of error messages.
SSL: The Origin
SSL (Secure Sockets Layer) was developed by Netscape Communications in the early 1990s to secure HTTP connections for e-commerce. The protocol went through three versions:
- SSL 1.0 — never publicly released due to serious security flaws discovered during internal review.
- SSL 2.0 — released in 1995, but contained critical vulnerabilities including susceptibility to man-in-the-middle attacks. Deprecated in 2011 (RFC 6176).
- SSL 3.0 — released in 1996, a significant improvement but still fundamentally flawed. The POODLE attack in 2014 exploited SSL 3.0's padding scheme to decrypt HTTPS sessions. Deprecated in 2015 (RFC 7568).
TLS: The Successor
TLS (Transport Layer Security) was introduced in 1999 as RFC 2246 — essentially a cleaned-up and improved version of SSL 3.0. The IETF deliberately renamed the protocol to signal a clean break from Netscape's original implementation. Four versions of TLS have been published:
- TLS 1.0 (1999) — minor improvements over SSL 3.0 but shares structural weaknesses. Deprecated in 2021 (RFC 8996). Payment Card Industry (PCI DSS) compliance forbids TLS 1.0.
- TLS 1.1 (2006) — added protection against specific CBC attacks. Also deprecated in 2021. No longer accepted by major browsers.
- TLS 1.2 (2008) — a substantial redesign with support for authenticated encryption, stronger cipher suites, and SHA-256 signatures. Still widely used and considered secure when configured correctly.
- TLS 1.3 (2018) — a comprehensive overhaul. Removed all legacy cipher suites, reduced handshake round trips, mandated forward secrecy, and improved performance. The recommended standard for all new deployments.
| Version | Year | Status | Notes |
|---|---|---|---|
| SSL 2.0 | 1995 | Deprecated 2011 | Critical vulnerabilities, must be disabled |
| SSL 3.0 | 1996 | Deprecated 2015 | POODLE attack, must be disabled |
| TLS 1.0 | 1999 | Deprecated 2021 | Forbidden by PCI DSS, browsers dropped support |
| TLS 1.1 | 2006 | Deprecated 2021 | Browsers dropped support in 2020–2021 |
| TLS 1.2 | 2008 | Current | Secure with proper cipher configuration |
| TLS 1.3 | 2018 | Current (recommended) | Fastest, most secure, forward secrecy mandatory |
Why "SSL" Is Still Used Colloquially
Despite SSL being obsolete, the term "SSL certificate" is deeply entrenched in the industry. The reasons are partly historical inertia and partly because the certificates themselves have not changed — the same X.509 certificates work with both TLS 1.2 and TLS 1.3. The certificate format is independent of the protocol version. When someone says "SSL certificate," they almost always mean a TLS certificate used over HTTPS. The terminology is informal and widely understood, though technically imprecise.
TLS 1.3 Improvements Over TLS 1.2
TLS 1.3 represents the most significant update to the protocol since its introduction. Key improvements include:
- Faster handshake — TLS 1.3 requires only one round trip (1-RTT) to complete the handshake, compared to two in TLS 1.2. For connections where latency matters, this is a meaningful performance improvement.
- 0-RTT resumption — for reconnecting clients, TLS 1.3 supports zero round-trip resumption, allowing data to be sent immediately on reconnect. This comes with replay attack considerations and should be used carefully.
- Forward secrecy mandatory — TLS 1.3 removes all cipher suites that do not provide forward secrecy. RSA key exchange (which does not provide forward secrecy) is no longer supported.
- Removed legacy cipher suites — TLS 1.3 eliminated RC4, DES, 3DES, AES-CBC, MD5, SHA-1, and all export-grade cipher suites, removing decades of cryptographic baggage.
- Encrypted handshake — in TLS 1.3, more of the handshake is encrypted, protecting certificate information from passive observers.
How to Check the TLS Version Your Server Supports
You can test which TLS versions your server accepts using OpenSSL or the ShowDNS SSL Checker:
# Test if TLS 1.3 is supported
openssl s_client -connect example.com:443 -tls1_3 -servername example.com </dev/null 2>&1 | grep -E "Protocol|Cipher"
# Test if TLS 1.2 is supported
openssl s_client -connect example.com:443 -tls1_2 -servername example.com </dev/null 2>&1 | grep -E "Protocol|Cipher"
# Test if deprecated TLS 1.0 is (wrongly) still supported
openssl s_client -connect example.com:443 -tls1 -servername example.com </dev/null 2>&1 | grep -E "Protocol|handshake failure"
# Show the negotiated protocol version
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep "Protocol"Configuring TLS Versions in Nginx
A correctly configured Nginx server should support only TLS 1.2 and TLS 1.3, with all deprecated versions explicitly disabled:
# /etc/nginx/sites-available/example.com
server {
listen 443 ssl;
server_name example.com www.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# Only TLS 1.2 and TLS 1.3 — disable all deprecated versions
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;
}Why Keeping Deprecated Protocols Enabled Is Dangerous
Servers that continue to support TLS 1.0 or TLS 1.1 are vulnerable to downgrade attacks — where an attacker in a privileged network position forces the browser and server to negotiate the weakest mutually supported protocol. If the server supports TLS 1.0, an attacker can attempt to exploit known TLS 1.0 vulnerabilities (such as BEAST) even though the client would prefer TLS 1.3.
Additionally, PCI DSS 3.2 prohibits TLS 1.0 for any system that handles cardholder data. NIST SP 800-52 guidance recommends TLS 1.2 or higher. Leaving old versions enabled can create compliance failures as well as security exposures.
Frequently Asked Questions
Should I use SSL or TLS?
Always TLS — specifically TLS 1.2 or TLS 1.3. SSL (all versions) and TLS 1.0/1.1 are deprecated and insecure. Your server configuration should explicitly list only TLSv1.2 TLSv1.3 in the protocols directive.
Do I need a different certificate for TLS 1.3?
No. The same X.509 certificate works with TLS 1.2 and TLS 1.3. Upgrading to TLS 1.3 is a server configuration change — you update the ssl_protocols directive in Nginx or the SSLProtocol directive in Apache. No certificate replacement is required.
How can I tell which TLS version a browser negotiated?
In Chrome, open Developer Tools (F12), go to the Security tab, and click on the connection. It shows the protocol version and cipher suite that were negotiated. In Firefox, click the padlock in the address bar, then "Connection secure" and "More information."
What is POODLE and why does it affect SSL 3.0?
POODLE (Padding Oracle On Downgraded Legacy Encryption) is an attack discovered in 2014 that exploits a design flaw in SSL 3.0's CBC padding scheme. An attacker who can act as a man-in-the-middle can force a connection to downgrade to SSL 3.0 and then decrypt parts of the encrypted communication. This is why SSL 3.0 was deprecated and must be disabled.
Is TLS 1.3 supported by all browsers?
Yes. TLS 1.3 is supported by all modern browsers: Chrome (since version 70, 2018), Firefox (since version 63, 2018), Safari (since version 12.1, 2019), and Edge (since 2018). Enabling TLS 1.3 on your server does not break compatibility with any current browser.