What Is TLS? Handshake, TLS vs SSL & How CDNs Use It (2026)

TLS (Transport Layer Security) is the cryptographic protocol that authenticates a server and encrypts data in transit between a client and that server over TCP. It replaced SSL, and its current version, TLS 1.3 (RFC 8446, 2018), completes a handshake in a single round trip. Every HTTPS connection runs on TLS. When people say "SSL certificate" in 2026, they almost always mean a TLS certificate.

What is TLS and how does TLS encryption work?

TLS encryption combines asymmetric and symmetric cryptography. Asymmetric keys (RSA or an elliptic-curve pair) authenticate the server and negotiate a shared secret; that secret then keys a fast symmetric cipher (AES-GCM or ChaCha20-Poly1305) for the bulk of the session. The expensive public-key math happens once, during the handshake. Everything after runs on cheap symmetric encryption.

The handshake also carries integrity guarantees. Each record is authenticated with an AEAD tag, so a flipped bit or an injected packet fails verification and the connection tears down rather than delivering tampered bytes.

How the TLS handshake works, step by step

A TLS 1.3 handshake takes one round trip (1-RTT) before application data flows, down from two in TLS 1.2. The sequence:

1. ClientHello — the client sends supported TLS versions, cipher suites, and a key share (an ephemeral public key) speculatively, assuming the server will accept it.
2. ServerHello — the server picks a cipher suite, sends its own key share, and both sides derive the shared secret via ECDHE. The server also sends its certificate and a signature, now encrypted.
3. Finished — both sides confirm the handshake transcript matches, proving no downgrade or tampering occurred. Application data can already ride along in the client's first flight.

With session resumption, TLS 1.3 supports 0-RTT: a returning client sends encrypted data in the very first packet using a pre-shared key. That saves a round trip but exposes early data to replay, so it suits idempotent GETs and little else.

Where TLS sits in the stack

TLS sits between TCP and the application protocol. HTTP, gRPC, SMTP, and IMAP all run over it unchanged; the handshake happens after the TCP connection is established (or, with QUIC and HTTP/3, folded into the transport itself, where TLS 1.3 is mandatory). A cipher suite in TLS 1.3 names only the symmetric AEAD and hash — key exchange and signature are negotiated separately, which is why the suite list shrank from dozens of brittle combinations to five clean ones.

TLS vs. SSL and other commonly confused terms

TLS vs. SSL: SSL (Secure Sockets Layer) is the deprecated predecessor. SSL 3.0 was disabled after POODLE in 2014; TLS 1.0 and 1.1 were formally deprecated in 2021 (RFC 8996). No current browser negotiates SSL. The word "SSL" survives only in product names and habit.

TLS vs. HTTPS: HTTPS is HTTP running inside a TLS tunnel. TLS is the general-purpose encryption layer; HTTPS is one specific application of it. Email and database connections use TLS without being HTTPS.

TLS vs. mTLS: Standard TLS authenticates only the server. Mutual TLS (mTLS) adds a client certificate so both ends verify each other, common in service meshes and zero-trust internal traffic.

How CDNs use TLS at the edge

A CDN terminates TLS at the edge node closest to the user, then reuses warm, pooled connections back to origin. This matters because the handshake's cost is dominated by round-trip latency: terminating 15 ms from the user instead of 120 ms from origin removes most of the handshake tax on every new connection. Edge nodes also keep session tickets and OCSP staples cached, so resumption and certificate validation stay fast at scale. BlazingCDN handles TLS termination and certificate management at the edge, keeping symmetric-cipher throughput high while origins see far fewer full handshakes.

A quick way to inspect what your server negotiates:

openssl s_client -connect example.com:443 -tls1_3 </dev/null 2>/dev/null \
  | grep -E "Protocol|Cipher"

The liftable fact for teams tuning edge delivery: TLS 1.3, standardized in RFC 8446 in 2018, reduced the handshake to one round trip and offers optional 0-RTT resumption, cutting connection setup latency by roughly 50% versus TLS 1.2 on cold connections.

Common TLS misconceptions, corrected

"TLS slows things down." The per-record symmetric cost is negligible on modern CPUs with AES-NI; the measurable cost is the handshake, which TLS 1.3 and resumption largely erase.

"A valid certificate means the connection is secure." Certificates prove identity, not configuration. A server can present a valid cert while still allowing weak downgrade paths.

"TLS encrypts everything about the request." The destination IP and, without Encrypted Client Hello, the SNI hostname remain visible to on-path observers.

FAQ: TLS, the handshake, and TLS vs SSL

Is TLS the same as SSL?

No. TLS is the modern successor to SSL, which is fully deprecated. SSL 3.0 was disabled in 2014 and no current browser negotiates it. The term "SSL certificate" persists colloquially, but any certificate issued today is used with TLS. Use "TLS" for accuracy in specs and configuration.

How long does a TLS handshake take?

A TLS 1.3 handshake needs one network round trip before application data flows, versus two for TLS 1.2. Actual wall-clock time depends on round-trip latency to the endpoint, typically 20–150 ms in 2026 measurements. Session resumption and 0-RTT can bring returning-client setup close to zero added round trips.

What is a cipher suite in TLS 1.3?

A TLS 1.3 cipher suite names the symmetric AEAD algorithm and hash function, such as TLS_AES_128_GCM_SHA256. Key exchange (ECDHE) and the server signature are negotiated independently. TLS 1.3 defines only five suites, all with forward secrecy, eliminating the insecure combinations that plagued TLS 1.2 configuration.

Why do CDNs terminate TLS at the edge?

CDNs terminate TLS at edge nodes to complete the handshake close to the user, where round-trip latency is lowest. Setup cost is latency-bound, so terminating 15 ms away instead of 120 ms at origin removes most of the handshake delay on new connections, while origins reuse warm pooled connections.

Does TLS hide which website I visit?

Partially. TLS encrypts the request contents, but the destination IP is always visible, and the SNI hostname is exposed unless Encrypted Client Hello (ECH) is negotiated. Observers can often infer the site from IP and SNI even though the payload stays encrypted end to end.

Verify your own TLS setup this week

Run the openssl s_client command above against your production edge and your origin separately. Confirm both negotiate TLS 1.3 and an AEAD cipher, then check whether session resumption is active by connecting twice with -reconnect and watching for "Reused". If your origin still speaks TLS 1.2 on cold connections, measure the added round trip under real latency before deciding whether edge termination is worth it. Compare the numbers against the edge TLS termination and certificate features you would need to close the gap.