If you have ever clicked a padlock icon in your browser and wondered what it actually means, this post is for you. That little symbol tells you the connection between your browser and the website you are visiting is encrypted — and the protocol doing that encryption is called TLS. Most people call it SSL out of habit, even though SSL itself was retired years ago. The two names have become so intertwined that even security professionals use them interchangeably. So let's untangle that, and explain what TLS actually is, how it got here, and what version you should be using today.

For the full history of how SSL became TLS and what happened along the way, see our SSL/TLS Timeline. For a deeper look at what happens during an actual TLS connection, see our posts on the TLS Handshake and Cipher Suites.

---

Transport Layer Security (TLS) is a successor of Secure Sockets Layer (SSL) and it's a cryptographic protocol used for establishing an encrypted link between a Server and a Client over a public network.

They use X.509 certificates and hence asymmetric cryptography to authenticate the certificate holder to its clients, and to negotiate a symmetric session key. This session key is used to encrypt the data communication between client and server. This allows message confidentiality and authenticity.

TLS secures virtually all encrypted communication on the modern internet, including:

• Web browsing (HTTPS)
• Email (SMTP, IMAP, POP3 over TLS)
• Voice over IP (VoIP) and video calling
• Instant messaging and chat applications
• API communication between services and apps
• IoT device communication
• VPN protocols (including WireGuard and OpenVPN in TLS mode)
• Database connections
• Code repositories and DevOps pipelines (Git over HTTPS, CI/CD)

Because of the use of X.509 certificates, CAs and PKI infrastructure are necessary to verify the certificates and for the establishment of chain-of trust.

For a detailed look at how that chain works, see our post on the CA Certificate Chain, and for the organisations that operate that infrastructure today, see our 2026 Certificate Authority Landscape guide.

TLS is an Internet Engineering Task Force (IETF) standards track protocol, first defined in 1999 and updated in RFC 5246 (August 2008), RFC 6176 (March 2011) and RFC 8446 (August 2018). It is based on the earlier SSL specifications (1994, 1995, 1996) developed by Netscape Communications.

---

History and present development

• SSL 1.0, 2.0 and 3.0

  Netscape developed the original SSL protocols. Version 1.0 was never publicly released because of serious security flaws in the protocol; version 2.0, released in February 1995, contained a number of security flaws which ultimately led to the design of SSL version 3. SSL version 3.0, released in 1996, represented a complete redesign of the protocol.

  Newer versions of SSL/TLS are based on SSL 3.0. The 1996 draft of SSL 3.0 was published by IETF as a historical document in RFC 6101 . Dr. Taher Elgamal, chief scientist at Netscape Communications from 1995 to 1998, is recognised as the "father of SSL".

  As of 2014 the 3.0 version of SSL is considered insecure as it is vulnerable to the POODLE attack that affects all block ciphers in SSL; and RC4, the only non-block cipher supported by SSL 3.0, is also feasibly broken as used in SSL 3.0.

  SSL 2.0 is deprecated in RFC 6176.
  SSL 3.0 is deprecated in RFC 7568.

• PCT

  A brief historical footnote: In the mid-1990s, Microsoft developed a competing protocol called Private Communications Technology (PCT 1.0), designed to address flaws in SSL 2.0 and pressure Netscape into handing SSL to an open standards body. PCT was eventually superseded by SSL 3.0 and TLS, and has been effectively dead since Internet Explorer 5. It is mentioned here purely for historical completeness.

• TLS 1.0

  TLS 1.0 was defined in RFC 2246 in January 1999 — the first version of the protocol to carry the TLS name rather than SSL. It was almost identical to SSL 3.0, with minor differences. For years it was the internet's workhorse. But time was not kind to it — TLS 1.0 is now fully deprecated (RFC 8996, 2021) and disabled by default in all major browsers and operating systems.

• TLS 1.1

  TLS 1.1 was defined in RFC 4346 in April 2006. Its main contribution was adding an explicit Initialization Vector (IV) to protect against CBC attacks. Like TLS 1.0, it has since been deprecated in RFC 8996 (March 2021) and is no longer supported by Chrome, Firefox, Safari, or Edge.

  Significant differences in this version include:

  1. Added protection against cipher-block chaining (CBC) attacks.
     1. The implicit initialisation vector (IV) was replaced with an explicit IV.
     2. Change in handling of padding errors.
  2. Support for IANA registration of parameters.
• TLS 1.2

  TLS 1.2 was defined in RFC 5246 in August 2008. It is based on the earlier TLS 1.1 specification. Many major changes were made in TLS 1.2.

  All TLS versions were further refined in RFC 6176 in March 2011 removing their backward compatibility with SSL such that TLS sessions will never negotiate the use of Secure Sockets Layer (SSL) version 2.0.

• TLS 1.3 — The Current Standard

  TLS 1.3 was finalised in August 2018 as RFC 8446 and is now the version you should be running. It was not a minor update — it was a ground-up rethink of the protocol, cutting away a decade's worth of accumulated complexity and insecure legacy features.

  The biggest improvements over TLS 1.2 are:

  • Faster handshake — TLS 1.3 completes in one round trip instead of two, meaning encrypted connections are established faster. It even supports zero round-trip (0-RTT) resumption for returning visitors.
  • Forward secrecy by default — Static RSA key exchange (which allowed past sessions to be decrypted if the private key was ever compromised) is gone. All key exchanges in TLS 1.3 use ephemeral keys, meaning past sessions stay private even if a key is stolen later.
  • Removed weak algorithms — MD5, SHA-1, RC4, DES, 3DES, export-grade ciphers, and CBC mode ciphers are all removed. Only strong, modern authenticated encryption (AEAD) ciphers are permitted.
  • Encrypted handshake — Much more of the handshake itself is now encrypted, reducing the amount of metadata an observer can collect about the connection.

  As of June 2026, TLS 1.3 is supported by all major browsers and accounts for over 70% of web traffic. If your server is not offering TLS 1.3, it is time to update your configuration.

  ---

  What Should You Disable Today?

  If you manage a server, here is the short version of where things stand:

  • SSL 2.0 and SSL 3.0 — Disabled everywhere. Deprecated in RFC 6176 and RFC 7568 respectively. POODLE killed SSL 3.0 in 2014.
  • TLS 1.0 and TLS 1.1 — Both deprecated in RFC 8996 (March 2021). Disabled by default in Chrome, Firefox, Safari and Edge since 2020–2021. You should not be running these.
  • TLS 1.2 — Still widely used and acceptable, but TLS 1.3 should be your preferred version. Certificate lifetime changes (200 days max as of March 2026, dropping to 47 days by 2029) make automation increasingly important regardless of version.
  • TLS 1.3 — This is what you should be running. Enable it on your servers and make sure TLS 1.2 is your fallback, not 1.0 or 1.1.

  ---

  TLS has come a long way from Netscape's first draft in 1994. What started as a proprietary protocol for securing credit card transactions has become the invisible foundation of the entire encrypted web. The lesson of its history is that cryptography does not age well — algorithms that seemed unbreakable in 1995 were broken within a decade. TLS 1.3 is the best version of this protocol we have ever had, but it will not be the last. Stay current, automate your renewals, and keep an eye on what comes next.

  This post was originally written in September 2015 and has been substantially updated in June 2026 to reflect current protocol versions, deprecations, and best practices.