What's the difference between SSL and TLS?

Historically the same thing. SSL was Netscape's name; TLS is the IETF-standardized successor starting in 1999. Modern colloquial usage often calls everything 'SSL' even though TLS has been the actual protocol for 25+ years. All current secure web connections use TLS 1.2 or TLS 1.3.

Why is TLS 1.3 faster?

It cuts the handshake from two round trips to one (1-RTT) by sending the client's DH public key in the first message and bundling the server's response with all the other handshake state. Session resumption can even start sending application data with the first message (0-RTT). On a 100ms-latency link, that's a perceived 200ms improvement on first connection.

Is TLS 1.2 still safe in 2026?

Yes, when properly configured: AES-GCM or ChaCha20-Poly1305 cipher, ECDHE key exchange for forward secrecy, no CBC-mode ciphers, no RC4, no SSL 3.0 fallback. TLS 1.3 removes the configuration risk entirely by deleting the bad options.

What is Encrypted Client Hello?

An extension that encrypts the Server Name Indication (SNI) field in the TLS handshake. Without ECH, your network can see every domain you visit even when the rest of the connection is encrypted. ECH (and the earlier ESNI) hides that last piece of metadata, completing the privacy story TLS started in 1994.

Not yet by default, but rolling out. The standard X25519 elliptic-curve Diffie-Hellman is theoretically breakable by a large enough quantum computer. The hybrid X25519MLKEM768 mode (Chrome default since late 2024, growing browser support) combines classical and post-quantum algorithms so traffic stays safe even against future quantum attackers.

TLS Explained: The Protocol Behind Every Padlock Icon

Transport Layer Security is the cryptographic foundation of HTTPS, modern email, VPNs, messaging apps, and most internet traffic in 2026. It started as Netscape's SSL in 1994 and has been quietly upgraded eight times since. This is the technical explainer — how the handshake works, what TLS 1.3 changed, the attacks that shaped it, and where it goes next.

SSL → TLS: the chronological story

Netscape Communications built the first SSL implementation in 1994 to secure online shopping in the brand-new Netscape Navigator browser. SSL 1.0 was never publicly released because it had critical flaws. SSL 2.0 shipped in February 1995, was promptly broken, and SSL 3.0 followed in 1996 as a near-total rewrite.

In 1999 the IETF took over the protocol and renamed it Transport Layer Security to mark the transition from a Netscape product to an open standard. The version history since:

TLS 1.0 (January 1999, RFC 2246) — essentially SSL 3.1.
TLS 1.1 (April 2006, RFC 4346) — protected against CBC attacks via explicit initialization vectors.
TLS 1.2 (August 2008, RFC 5246) — added AEAD ciphers, SHA-256, configurable signature algorithms. Dominated for a decade.
TLS 1.3 (August 2018, RFC 8446) — major redesign. Removed legacy cruft, mandated forward secrecy, slashed handshake latency.

SSL 3.0 was formally deprecated in June 2015 (RFC 7568) after POODLE. TLS 1.0 and 1.1 were deprecated in March 2021 (RFC 8996). In 2026, modern servers should refuse anything below TLS 1.2 and prefer TLS 1.3.

How the handshake actually works

Every TLS connection starts with a handshake that does three things: agree on a cipher suite, prove the server's identity, and derive shared keys for the rest of the session.

TLS 1.2 handshake (the classic flow)

ClientHello: client sends supported TLS versions, cipher suites, and a random number.
ServerHello: server picks one cipher suite, sends its random number.
Certificate: server sends its X.509 certificate chain so the client can verify identity.
ServerKeyExchange: server sends its Diffie-Hellman public key (for ephemeral key exchange).
ClientKeyExchange: client sends its DH public key. Both sides now derive the same shared secret.
Finished: both sides confirm the handshake by sending a MAC over the entire transcript.

That's two full round trips before the first application byte can flow. On a 100ms-latency link, every new HTTPS connection eats 200ms before any actual content moves.

TLS 1.3 handshake (the modern flow)

TLS 1.3 collapses the handshake to one round trip in the common case:

ClientHello: includes the client's DH public key for every cipher group the client supports.
ServerHello + everything else: server picks a group, sends its DH public key, certificate, and Finished, all in one flight.
Client validates and replies with its own Finished.

One round trip, two flights. With session resumption (0-RTT), the client can even start sending data with its first message — at the cost of some forward-secrecy properties for that initial data.

What TLS 1.3 removed

TLS 1.3's other big move was deletion. Out went:

Static RSA key exchange (broke forward secrecy).
CBC mode ciphers (vulnerable to BEAST and Lucky Thirteen).
RC4 stream cipher (long-since broken).
MD5 and SHA-1 hashes for signatures.
Renegotiation (replaced by post-handshake auth).
Compression (CRIME class of attacks).
Custom Diffie-Hellman parameters (Logjam fix).

The cipher suite list went from ~300 in TLS 1.2 down to 5 in TLS 1.3. Less rope to hang yourself with.

The attack history that shaped TLS

BEAST (2011) — chosen-plaintext attack on CBC mode in TLS 1.0. Fixed in 1.1+ via explicit IVs.
CRIME (2012) — used TLS compression to recover session cookies. Fixed by disabling compression.
BREACH (2013) — HTTP-level compression equivalent of CRIME. Mitigated by disabling HTTP compression on sensitive responses.
Heartbleed (April 2014) — OpenSSL bug, not a TLS spec issue. Leaked server memory including private keys. Mass certificate-rotation event across the web.
POODLE (October 2014) — exploited SSL 3.0 fallback. Killed SSL 3.0 in browsers within weeks.
Logjam (2015) — showed that small Diffie-Hellman groups (especially the 1024-bit Group 2 widely used in IPsec/IKE) were within reach of nation-state attackers. Forced industry-wide migration to larger groups and elliptic-curve DH.
Lucky Thirteen (2013) — timing attack on CBC mode. Library-level fix in OpenSSL and others.

Each attack tightened the protocol. By TLS 1.3 most of these classes are impossible by design.

Certificate authorities and the trust problem

TLS authentication relies on Certificate Authorities (CAs) that browsers trust by default. Top three by market share since 2019: IdenTrust, DigiCert, and Sectigo. Let's Encrypt — the free, automated CA launched in 2016 — drove the biggest adoption push in HTTPS history.

The structural weakness: any trusted CA can issue a certificate for any domain. A compromised or coerced CA can mint a valid certificate for your bank. Certificate Transparency (CT) logs — public append-only records of every certificate ever issued — were introduced to detect this. Browsers now require certificates to appear in CT logs before they'll accept them.

The CA/Browser Forum approved reducing maximum certificate validity to 47 days by 2029, tightening the window during which a compromised CA can do damage.

Encrypted Client Hello (ECH)

One thing classical TLS leaks: the Server Name Indication (SNI) field in the ClientHello, which tells the server which hostname you're connecting to so it can present the right certificate. SNI is plaintext, so network observers learn every domain you visit even though the rest of the connection is encrypted.

Encrypted Client Hello (ECH) — an evolution of the earlier ESNI proposal — encrypts the SNI using a public key the destination publishes via DNS. Cloudflare and Apple have shipped ECH support; Firefox and Chrome rolled it out behind flags through 2024 and are moving toward default-on. For users on hostile networks, ECH is the next privacy upgrade after universal HTTPS.

DTLS — TLS for UDP

DTLS (Datagram TLS) is the TLS variant that works over UDP. It powers WebRTC (browser video/voice), QUIC's underlying security, and several VPN protocols. DTLS 1.3 (RFC 9147, 2022) matches TLS 1.3's handshake and cipher modernizations.

Post-quantum TLS

Diffie-Hellman key exchange — the basis of TLS forward secrecy — is breakable by a sufficiently large quantum computer. The fix is hybrid key exchange combining a classical algorithm (X25519) with a post-quantum candidate (typically ML-KEM-768, formerly known as Kyber).

Chrome enabled the X25519MLKEM768 hybrid by default in late 2024. Cloudflare, Apple iCloud, and several VPN providers shipped it through 2025. The wider rollout protects today's traffic against the "harvest now, decrypt later" attack — an adversary recording encrypted traffic today, waiting for quantum computers, then decrypting historically.

How to verify the TLS your browser is actually using

Click the padlock in your browser's address bar. Modern browsers show the protocol version, cipher suite, and certificate details. If you see TLS 1.0 or 1.1, the site is using deprecated configurations. If you see TLS 1.3 with AES-256-GCM or ChaCha20-Poly1305, you're on modern crypto.

The companion technology HTTPS — covered in our HTTPS explainer — is what wraps the web in TLS. The two terms are often used interchangeably colloquially, but TLS is the underlying cryptographic protocol; HTTPS is just HTTP-over-TLS.

Frequently asked questions

What's the difference between SSL and TLS?: Historically the same thing. SSL was Netscape's name; TLS is the IETF-standardized successor starting in 1999. Modern colloquial usage often calls everything 'SSL' even though TLS has been the actual protocol for 25+ years. All current secure web connections use TLS 1.2 or TLS 1.3.
Why is TLS 1.3 faster?: It cuts the handshake from two round trips to one (1-RTT) by sending the client's DH public key in the first message and bundling the server's response with all the other handshake state. Session resumption can even start sending application data with the first message (0-RTT). On a 100ms-latency link, that's a perceived 200ms improvement on first connection.
Is TLS 1.2 still safe in 2026?: Yes, when properly configured: AES-GCM or ChaCha20-Poly1305 cipher, ECDHE key exchange for forward secrecy, no CBC-mode ciphers, no RC4, no SSL 3.0 fallback. TLS 1.3 removes the configuration risk entirely by deleting the bad options.
What is Encrypted Client Hello?: An extension that encrypts the Server Name Indication (SNI) field in the TLS handshake. Without ECH, your network can see every domain you visit even when the rest of the connection is encrypted. ECH (and the earlier ESNI) hides that last piece of metadata, completing the privacy story TLS started in 1994.
Is TLS quantum-safe?: Not yet by default, but rolling out. The standard X25519 elliptic-curve Diffie-Hellman is theoretically breakable by a large enough quantum computer. The hybrid X25519MLKEM768 mode (Chrome default since late 2024, growing browser support) combines classical and post-quantum algorithms so traffic stays safe even against future quantum attackers.