SSL and TLS protocols encrypt and authenticate data between two devices, most visibly in HTTPS, and only two versions should still be running: TLS 1.2 and TLS 1.3. TLS replaced SSL in 1999. Every SSL version is now prohibited by the IETF, and TLS 1.0 and 1.1 were deprecated in March 2021 by RFC 8996. The name "SSL" survives out of habit, mostly in "SSL certificate". The table below lists each version with the RFC that defined it and the one that retired it.
SSL and TLS protocols by version
There are seven SSL and TLS versions. SSL 1.0, 2.0 and 3.0 came from Netscape; TLS 1.0, 1.1, 1.2 and 1.3 are IETF standards. SSL 2.0 and 3.0 are prohibited, TLS 1.0 and 1.1 are deprecated, TLS 1.2 is still allowed and TLS 1.3 is the current recommendation.
| Version | Year | Defined in | Status today | Why it was retired |
|---|---|---|---|---|
| SSL 1.0 | Never released | Netscape, internal | Never used publicly | Flaws found before release |
| SSL 2.0 | 1995 | Netscape | Prohibited by RFC 6176 (March 2011) | MD5-based MAC, unprotected handshake, truncation attacks |
| SSL 3.0 | 1996 | Netscape, later recorded as RFC 6101 (August 2011, Historic) | Prohibited by RFC 7568 (June 2015) | POODLE attack on CBC padding (2014), weak RC4 |
| TLS 1.0 | 1999 | RFC 2246 (January 1999) | Deprecated by RFC 8996 (March 2021) | Depends on SHA-1 and MD5, no AEAD cipher suites |
| TLS 1.1 | 2006 | RFC 4346 (April 2006) | Deprecated by RFC 8996 (March 2021) | Same weaknesses as TLS 1.0 |
| TLS 1.2 | 2008 | RFC 5246 (August 2008) | Allowed and widely used | Not retired |
| TLS 1.3 | 2018 | RFC 8446 (August 2018) | Recommended | Current version |
TLS 1.2 trips people up. RFC 8446 marks RFC 5246 as "obsoleted", which only means a newer document replaced its text. "Deprecated" in RFC 8996 is stronger: TLS 1.0 and 1.1 "MUST NOT be used". There is no TLS 2.0 and no SSL 1.3.
SSL vs TLS: what actually changed
SSL vs TLS is mostly a story of ownership and cleanup. TLS 1.0 was SSL 3.0 handed to the IETF with small changes; its version number on the wire is still 3.1. Each later TLS version removed weak algorithms, and TLS 1.3 cut the handshake to one round trip.
- Owner: SSL was a Netscape product; TLS is an open IETF standard.
- Algorithms: SSL leaned on MD5 and RC4. TLS 1.2 added AEAD ciphers such as AES-GCM, and TLS 1.3 accepts only AEAD.
- Handshake: SSL and TLS 1.2 need two round trips before data flows. TLS 1.3 needs one.
- Downgrade protection: a TLS 1.3 server forced to an older version puts a fixed marker in its random value, so the client notices the attack.
| SSL 3.0 | TLS 1.2 | TLS 1.3 | |
|---|---|---|---|
| Standard body | Netscape | IETF | IETF |
| Full handshake | 2 round trips | 2 round trips | 1 round trip |
| Forward secrecy | Optional | Optional (ECDHE suites) | Always |
| Ciphers | RC4, CBC | CBC and AEAD | AEAD only |
Why do people still say SSL?
The name stuck before TLS existed. Certificate sellers still market "SSL certificates", web servers keep directive names such as SSLProtocol, and mail apps show a security option called "SSL/TLS". The connection behind those labels runs TLS 1.2 or 1.3. Calling it SSL is harmless. Enabling the SSL protocol is not.
How the TLS handshake works
The TLS handshake is the short exchange at the start of every connection where client and server agree on a version and cipher, create shared keys and check the server's certificate. In TLS 1.3 it takes one round trip, and afterwards all data is encrypted with keys only the two endpoints hold.
A full TLS 1.3 handshake in RFC 8446 has five steps:
- The client sends ClientHello: supported versions, cipher suites, the server name and a key share (for example an X25519 public value).
- The server answers with ServerHello and its own key share. Both sides compute the same secret. The server's certificate, a CertificateVerify signature and a Finished message follow, already encrypted.
- The client checks the certificate chain, name and dates, then verifies the signature.
- The client sends its own Finished message.
- Application data, such as an HTTP request, flows.
The server's private key doesn't encrypt your data, despite what many tutorials say. It signs the handshake to prove ownership of the certificate. Session keys from the key exchange encrypt the data.
TLS 1.2 vs TLS 1.3 handshake
TLS 1.2 needs two round trips before the client can send a request; on a link with 150 ms of latency, that's about 300 ms. TLS 1.3 sends the key share in the first message and halves the wait. Its 0-RTT mode lets a returning client send data in the first message. RFC 8446 warns that 0-RTT data has no forward secrecy and can be replayed, so servers should accept it only for requests that are safe to repeat.
What the certificate does in the handshake
The certificate is an X.509 file that ties a public key to a domain name. A certificate authority (CA) signs it, and your browser trusts it because the CA chains to a root in its trust store. It proves the server controls the domain, not that the business behind it is honest. The same certificate works for TLS 1.2 and TLS 1.3, because certificates aren't tied to a protocol version.
What changed in TLS 1.3
TLS 1.3 removed most of the options that caused past attacks and encrypted more of the handshake. RFC 8446, section 1.2, lists the major changes. Every connection gets forward secrecy, and the certificate is hidden from anyone watching the network.
- Static RSA and static Diffie-Hellman key exchange are gone, so a stolen server key can't decrypt recorded sessions.
- Only AEAD ciphers remain, such as AES-GCM and ChaCha20-Poly1305. CBC mode and RC4 are out.
- Compression was removed.
- Handshake messages after ServerHello are encrypted, and a 0-RTT mode was added.
- Key derivation was rebuilt on HKDF, and elliptic curve algorithms are part of the base spec.
TLS 1.3 also sits inside newer transports. The QUIC protocol behind HTTP/3 builds the TLS 1.3 handshake into its own connection setup instead of running over TCP. Google's security blog also announced in September 2024 that Chrome 131 would use X25519MLKEM768, a hybrid key exchange that adds the post-quantum ML-KEM algorithm to a normal TLS 1.3 handshake.
Which SSL/TLS versions should you enable?
Enable TLS 1.3 and TLS 1.2, and turn off everything older. RFC 9325 (BCP 195) says implementations must support TLS 1.2 and should support TLS 1.3. RFC 8996, RFC 7568 and RFC 6176 retire the rest.
| Version | Setting | Basis |
|---|---|---|
| TLS 1.3 | Enable, prefer | RFC 8446, RFC 9325 |
| TLS 1.2 | Enable with AEAD cipher suites | RFC 9325 |
| TLS 1.0, TLS 1.1 | Disable | RFC 8996 |
| SSL 2.0, SSL 3.0 | Never enable | RFC 6176, RFC 7568 |
For website owners
Turn off TLS 1.0 and 1.1 on every layer that has its own setting, such as the web server and the CDN. Automate certificate renewal. Under CA/Browser Forum Ballot SC-081v3, passed on April 11, 2025, public TLS certificates issued from March 15, 2026 can last at most 200 days, then 100 days from March 15, 2027 and 47 days from March 15, 2029. Free, automated CAs exist, for example Let's Encrypt, a nonprofit. Add HSTS (RFC 6797) once HTTPS works everywhere: the header tells browsers to use only HTTPS for your domain for a set period.
For everyday users
Keep your browser and operating system updated. Chrome 84 (July 2020) and Firefox 78 (June 2020) turned off TLS 1.0 and 1.1 by default, following a joint plan by Mozilla, Google, Apple and Microsoft. A protocol error today almost always means the site runs old software. Re-enabling old versions in browser flags weakens every other connection.
TLS vs SSL in SMTP and email settings
In TLS vs SSL SMTP settings, "SSL/TLS" means implicit TLS, usually on port 465, and "STARTTLS" means the connection starts in plain text on port 587 and then upgrades. RFC 8314 (January 2018) says the two have no significant security difference when both sides require TLS, and it favors implicit TLS over time. Port 25 is for server-to-server relay. Our guide to port numbers explains what they identify.
How to check which TLS version a site uses
Your browser and the openssl command both show the negotiated TLS version in under a minute. The openssl test forces one version at a time, so you can see what a server still accepts.
- Chrome or Edge: press F12 to open DevTools and go to the Security panel (labeled "Privacy and security" in some recent versions). The Connection section shows a line such as "TLS 1.3".
- Firefox: click the icon left of the address bar, choose Connection secure, then More information. The Technical details box lists the cipher and the version, for example "TLS 1.3".
- Command line: run
openssl s_client -connect example.com:443 -tls1_3, then repeat with-tls1_2. A line such as "New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384" means the server accepted that version. A handshake failure means it didn't.
CheckIP doesn't have an SSL checker. You can check where a host's servers are located, useful when a CDN answers from several regions.
Common SSL/TLS errors and what they mean
Most browser SSL/TLS errors mean one of four things: the site only supports old versions, the certificate expired or your clock is wrong, the certificate doesn't match the domain, or the certificate comes from an untrusted issuer. Only the clock problem is yours to fix.
| Error | Meaning | Who fixes it |
|---|---|---|
| ERR_SSL_VERSION_OR_CIPHER_MISMATCH (Chrome), SSL_ERROR_UNSUPPORTED_VERSION (Firefox) | Server offers only old versions or ciphers | Site owner |
| NET::ERR_CERT_DATE_INVALID | Certificate expired, or your device clock is wrong | Site owner, or you (set the clock to automatic) |
| NET::ERR_CERT_COMMON_NAME_INVALID | Certificate issued for another domain | Site owner; don't log in until it's fixed |
| NET::ERR_CERT_AUTHORITY_INVALID | Untrusted issuer: self-signed, a Wi-Fi login page or interception | Don't enter passwords; open the Wi-Fi login page first |
The last row deserves care on public Wi-Fi. TLS stops most interception on HTTPS, and clicking past an untrusted certificate removes that protection, which is what a man-in-the-middle attack depends on.
Frequently asked questions
What does TLS mean?
TLS stands for Transport Layer Security. To define TLS in one sentence: it is the IETF protocol that encrypts data between two endpoints, checks it wasn't altered and authenticates the server with a certificate. HTTPS, secure email and DNS over TLS use it.
Is SSL deprecated?
Yes. SSL 2.0 has been prohibited since RFC 6176 in 2011, and SSL 3.0 since RFC 7568 in 2015. No modern browser negotiates either one. "SSL" survives only as a name for certificates and settings; the protocol underneath is TLS.
Is TLS 1.2 still safe?
Yes, when it's configured with AEAD cipher suites such as AES-GCM or ChaCha20-Poly1305 and ECDHE key exchange. Its problems come from weak setups with CBC suites or static RSA. TLS 1.3 removes those choices, so enable both and let clients pick 1.3.
Is there a difference between an SSL certificate and a TLS certificate?
No. Both names describe the same X.509 certificate. A certificate isn't tied to a protocol version, so the one on your server works for TLS 1.2 and TLS 1.3. Real differences are validation level (DV, OV, EV) and validity period.
Does HTTPS mean a website is safe?
No. HTTPS means the connection is encrypted and the server holds a certificate for the domain in the address bar. The Chromium team wrote in 2023 that nearly all phishing sites use HTTPS. Chrome 117 replaced the lock icon partly for that reason. Check the domain itself.
Does TLS hide my IP address?
No. TLS encrypts what you send, but the website still receives your public IP to send replies back, and your network can see which server you connect to. To keep sites from seeing your real address you need a VPN, proxy or Tor, covered in our guide on how to hide your IP address.
