Transport Layer Security (TLS) and its predecessor, the Secure Sockets Layer (SSL), are cryptographic protocols designed to secure communications over computer networks. They rely on X.509 certificates to authenticate the parties involved: identity verification is performed using asymmetric (public-key) cryptography, and once identities are established the peers agree on a shared symmetric session key. That session key is then used to encrypt the bulk data exchanged during the session, providing confidentiality and enabling message integrity through mechanisms such as message authentication codes. Variants of these protocols are widely used in many applications, including web browsing, network scanning tools, email, Internet fax, instant messaging, and Voice over IP. In these contexts, protecting the confidentiality of transmitted data is often the primary requirement; consequently, session keys used for short-lived connections must not be derivable from long-term secret keys.
Because TLS and SSL use X.509 certificates, they depend on certificate authorities (CAs) and a public key infrastructure (PKI) to create, sign, and manage certificates and the relationship between a certificate and its owner. This CA-based trust model provides a scalable way to authenticate identities across the global Internet, but it also introduces potential weaknesses: disclosures from global surveillance and security investigations in 2013 revealed that weaknesses in certificate management and CA practices could be exploited to facilitate man-in-the-middle attacks, bringing attention to the need for stronger CA governance and additional protections in the ecosystem.
Within networking stacks, SSL and TLS operate to encrypt data for application-layer connections. In terms of the OSI model, TLS/SSL is typically initiated at the session layer (layer 5) and provides services that are used at the presentation layer (layer 6) to protect application data. The handshake phase uses asymmetric cryptography to authenticate endpoints and negotiate session parameters; the goal of this handshake is to establish a shared session key and select cryptographic algorithms and modes for the connection. Once the handshake completes, the presentation layer uses symmetric encryption and the negotiated session key to encrypt and decrypt the remainder of the communication, ensuring privacy and integrity for the transported data.
TLS is standardized through the Internet Engineering Task Force (IETF) as an open protocol. The TLS family was first defined in 1999 and has been updated through several RFCs over time. Earlier SSL specifications—originating in 1994, 1995, and 1996—were developed by Netscape Communications, and the IETF later adapted and standardized the protocol family. TLS has seen a number of revisions and updates to address security improvements and evolving cryptographic practices: TLS 1.0 was released as RFC 2246, TLS 1.1 as RFC 4346, TLS 1.2 as RFC 5246, and TLS 1.3 as RFC 8446. Additional RFCs and updates have refined recommended cipher suites and deprecated insecure features as vulnerabilities were discovered and cryptographic understanding advanced.
The Secure Sockets Layer protocol itself was developed by Netscape in 1994 to provide secure data transmission over the Internet. SSL 2.0 appeared in 1995, and the SSL 3.0 specification followed in 1996, later documented as RFC 6101. When the IETF moved to formalize and evolve the protocol, it based its initial TLS work on SSL 3.0, resulting in the publication of TLS 1.0 in January 1999. Subsequent versions—TLS 1.1, TLS 1.2, and TLS 1.3—introduced improvements in both protocol design and cryptographic choices to better resist attacks and to offer stronger privacy guarantees.
Although TLS has continued to evolve and TLS 1.3 represents the most recent major revision with significant performance and security enhancements, SSL 3.0 remains a notable part of the protocol’s history. Historically, many web browsers and servers supported SSL 3.0 during the transition period to TLS, though over time insecure protocol versions have been deprecated and removed from modern, secure configurations in favor of newer TLS releases and safer cipher suites.
When you see a padlock icon in a web browser’s address bar, it indicates that the connection to that website is encrypted using SSL/TLS. Most browsers allow users to click that icon to view details about the site’s certificate, such as the issuing certificate authority, the site’s public key, the certificate’s validity period, the hash algorithm used, and the protocol version negotiated for the connection. These details help users and administrators verify that a secure, authenticated channel has been established and can assist in diagnosing configuration or trust issues.