What is the difference between SSL and TLS?

TLS is the successor to SSL. SSL (versions 2.0 and 3.0) is obsolete and insecure; 'SSL' persists as a colloquial term, but all current secure web connections use TLS, with TLS 1.3 being the modern version.

Does TLS protect me from a malicious website?

TLS only guarantees that you have a confidential, authenticated channel to the server named in the certificate — it confirms you are talking to that domain, not that the domain is trustworthy. A phishing site can serve a valid certificate for its own (look-alike) domain, so TLS does not vouch for the site's honesty.

TLS and Secure Channels

Transport Layer Security (TLS) is the protocol that secures most internet communication, combining authenticated key exchange and authenticated encryption to create a confidential, integrity-protected channel between two endpoints.

Definition

A secure channel protocol such as TLS establishes, between two parties, a session that guarantees confidentiality, integrity, and authentication of all data exchanged, by performing an authenticated key exchange followed by authenticated encryption of the traffic.

Scope

This topic covers secure-channel protocols, with TLS as the central example: the handshake that authenticates the server (and optionally the client) and establishes session keys, the record layer that provides authenticated encryption, forward secrecy and downgrade protection, and the lessons from historical attacks. It addresses how the cryptographic building blocks are assembled into a deployed protocol. It excludes the certificate infrastructure (PKI) and the individual primitives, which are treated in sibling topics.

Core questions

How does the TLS handshake authenticate the server and agree on session keys?
How does the record layer protect each message with authenticated encryption?
How is forward secrecy achieved, and why does it matter for recorded traffic?
How are downgrade and renegotiation attacks prevented?
What did historical attacks (BEAST, POODLE, Heartbleed) teach about protocol and implementation design?

Key concepts

TLS handshake
record layer
authenticated encryption (AEAD)
ephemeral key exchange (ECDHE)
forward secrecy
server and client authentication
downgrade and renegotiation attacks
session resumption
cipher suite negotiation

Key theories

Handshake plus record protocol: TLS separates an authenticated key-exchange handshake — which verifies identity via certificates and derives session keys — from a record layer that encrypts and authenticates application data with those keys, cleanly composing authentication, key agreement, and bulk protection.
Forward secrecy and downgrade protection: TLS 1.3 mandates ephemeral (elliptic-curve) Diffie-Hellman for forward secrecy and binds the handshake transcript into the key schedule so that an active attacker cannot force a downgrade to weaker parameters undetected.

Mechanisms

In TLS 1.3, the client sends its key-exchange shares and supported parameters; the server responds with its own ephemeral Diffie-Hellman share, certificate, and a signature over the handshake transcript, and both derive session keys via a key-derivation function (HKDF). The record layer then protects all data with an AEAD cipher (such as AES-GCM or ChaCha20-Poly1305). The transcript is authenticated to prevent tampering or downgrade, and the handshake completes in a single round trip, with optional zero-round-trip resumption.

Clinical relevance

TLS secures the overwhelming majority of internet traffic: HTTPS for the web, secure email transport, APIs, VPNs, and messaging all run over it. Its correctness directly determines whether passwords, payments, and personal data are protected from network attackers. The migration from flawed SSL/early TLS to TLS 1.3 — and the analysis that accompanied it — is a model for protocol evolution under real-world pressure.

Evidence & guidelines

TLS 1.3 is standardized in RFC 8446 and is recommended; SSL 3.0, TLS 1.0, and TLS 1.1 are deprecated (RFC 8996). NIST SP 800-52 gives configuration guidance. TLS 1.3 was developed with extensive formal analysis, removing legacy weaknesses (static RSA key exchange, CBC mode, renegotiation) that enabled earlier attacks such as BEAST, POODLE, and the implementation flaw Heartbleed.

History

Netscape created SSL in 1994-1995; SSL 3.0 was redesigned by the IETF as TLS 1.0 (1999) and refined through TLS 1.2 (2008). A decade of attacks — BEAST, CRIME, POODLE, the Heartbleed implementation bug, Logjam, and FREAK — exposed weaknesses in legacy modes and downgrade handling. TLS 1.3 (RFC 8446, 2018) was a major redesign with mandatory forward secrecy, a faster handshake, and formal security analysis.

Key figures

Eric Rescorla
Hugo Krawczyk
Kenny Paterson
Taher ElGamal

Seminal works

rfc8446
stallings2017
katz2020

Frequently asked questions

What is the difference between SSL and TLS?: TLS is the successor to SSL. SSL (versions 2.0 and 3.0) is obsolete and insecure; 'SSL' persists as a colloquial term, but all current secure web connections use TLS, with TLS 1.3 being the modern version.
Does TLS protect me from a malicious website?: TLS only guarantees that you have a confidential, authenticated channel to the server named in the certificate — it confirms you are talking to that domain, not that the domain is trustworthy. A phishing site can serve a valid certificate for its own (look-alike) domain, so TLS does not vouch for the site's honesty.