TL;DR: TLS is the layer underneath HTTPS. Every time a browser loads a URL that starts with https://, TLS does two jobs first: it confirms the server is actually who it claims to be, and it negotiates a fresh secret key that only the browser and server know. Everything after that — HTML, JSON, cookies, uploads — travels encrypted under that key. The whole exchange takes one or two round trips and finishes in 50-300ms.

What is it?

When you type https://yourdomain.com into a browser, the URL scheme is the only visible hint that something cryptographic is about to happen. Before any HTML moves over the wire, the browser and server run a separate protocol called TLS (Transport Layer Security) that wraps the connection in two guarantees:

  1. Identity check. The server proves “I really am yourdomain.com” by presenting a digital certificate signed by a trusted Certificate Authority. The browser already trusts a small set of root CAs shipped with the OS, so it can walk the signature chain and decide whether to believe the server.
  2. Key agreement. The browser and server jointly compute a fresh secret key — known only to the two of them, never sent over the wire in the clear, and thrown away when the session ends. Every byte that follows is encrypted and authenticated under that key.

That’s the whole job. HTTP itself doesn’t change. The browser still sends GET / and the server still answers with HTML. TLS just sits underneath, handling identity and confidentiality so HTTP doesn’t have to.

This article stays at the conceptual layer. Which version of TLS your server actually negotiates (1.2 vs 1.3), which cipher suites it prefers, and whether it offers forward secrecy are all separate questions WQI grades individually. Pointers to those at the bottom.

Why does it matter?

Without TLS, anything you send over the network travels as plaintext that anyone on the path can read. “On the path” is a longer list than people assume: your home router, your ISP, every transit provider between you and the destination, the coffee-shop Wi-Fi you joined last week, the corporate proxy at your office. TLS shuts all of that down.

What TLS protects against:

  • Passive eavesdropping. Someone capturing your traffic gets encrypted bytes they can’t decrypt. This is the headline win.
  • Active man-in-the-middle. Someone trying to impersonate the server fails the identity check, because they can’t produce a valid certificate for your domain that chains to a trusted root.
  • Tampering. The encryption layer is also authenticated, so flipping bits in transit corrupts the message in a way the receiver detects and rejects.

What TLS does not protect against:

  • A compromised server. If an attacker owns the box your site runs on, they see plaintext on the inside of the TLS terminator. TLS protects the wire, not the endpoints.
  • Malicious code on the page. A bad script tag, a compromised ad network, a supply-chain attack on an npm dependency — all of these run inside the browser’s already-trusted session. TLS doesn’t know the script is hostile.
  • Phishing. A site at yourdomain-login.com can have a perfectly valid TLS cert. The padlock means “the connection to this server is private,” not “this server is the one you wanted.”

TLS is necessary and not sufficient. It closes the network-level attack surface so you can focus on the rest.

Real-world analogy

Picture showing your driver’s license to a bouncer at a private event, then agreeing on a code word for the rest of the night.

The license is the certificate. It carries your name, was issued by an authority the bouncer recognizes (the DMV, standing in for the Certificate Authority), has an expiration date, and is hard to forge. The bouncer doesn’t have to call you to verify it — they just check that the issuing authority is one they trust, that the license hasn’t expired, and that the photo matches the face in front of them.

Once the bouncer is satisfied you’re really you, the two of you agree on a code word. From that moment on, anyone who wants to prove they’re part of your group has to use the code word. Someone eavesdropping at the door hears the negotiation but doesn’t end up knowing the code word, because the way you agreed on it was designed so an observer can’t reconstruct it. And critically, you pick a fresh code word every night. If someone steals last week’s list, it’s worthless.

That’s TLS. The license is the cert (the identity check). The code word is the session key (key agreement). The fact that an eavesdropper can’t reconstruct it from what they hear is the Diffie-Hellman key exchange. The fact that you pick a new one every session is forward secrecy.

The handshake, step by step

Here’s what actually flies over the wire when a browser opens a TLS connection. This is TLS 1.3, the modern version. Older versions took an extra round trip but the shape is the same.

1. ClientHello. The browser opens a TCP connection to the server on port 443 and sends a single message: “I’d like to start a TLS 1.3 session. Here are the cipher suites I support, here’s a random number I just generated, and here’s my half of a fresh key exchange.” That last part is the clever bit — the browser already includes a Diffie-Hellman public value, betting on what the server will choose so they can save a round trip.

2. ServerHello + Certificate + Finished. The server replies in one shot. It picks a cipher suite, sends its own random number and its own Diffie-Hellman public value, attaches its certificate chain, and signs a hash of the conversation so far with the cert’s private key. The browser now has everything it needs.

3. Key derivation. Both sides combine their Diffie-Hellman halves into a shared secret, mix in both random numbers, and run the result through a key-derivation function. They both arrive at the same session keys without ever transmitting them. An observer who captured every byte on the wire has the two public halves but can’t compute the shared secret — that’s what makes Diffie-Hellman work.

4. Verify. The browser walks the certificate chain (cert → intermediate → root), confirms the root is one it pre-trusts, checks the cert is for the domain it asked for, checks expiry, checks the signature on the conversation transcript. If anything fails, the browser tears down the connection and shows a warning.

5. Encrypted application data. The browser sends its first HTTP request encrypted under the new session keys. The server answers, also encrypted. Done. The whole handshake is one round trip on TLS 1.3 (and the application data ships with the second trip), versus two round trips on TLS 1.2.

Wall-clock cost depends almost entirely on network latency. On a nearby server you’ll see 50-100ms; on a transcontinental hop, 150-300ms. A slow handshake doesn’t usually mean weak crypto. It usually means an extra round trip somewhere — a missing intermediate cert forcing the client to fetch one, an OCSP lookup that didn’t get stapled, or just plain distance.

A note on naming: SSL vs TLS

The protocol started life at Netscape in 1995 as Secure Sockets Layer. SSL 2.0 shipped that year, SSL 3.0 in 1996. Both are now broken and disabled everywhere.

When the IETF took over the standard in 1999, they renamed it Transport Layer Security. TLS 1.0 in 1999 was barely changed from SSL 3.0; the rename was largely political (SSL was Netscape’s name, TLS belonged to the standards body). TLS 1.1 followed in 2006, 1.2 in 2008, and 1.3 in 2018.

So technically, nothing has been called “SSL” since the late 1990s. The protocol your site speaks today is TLS 1.2 or 1.3. Common usage hasn’t caught up though — people still say “SSL certificate,” CAs still sell “SSL certs,” and Nginx config still uses directives like ssl_protocols. Treat “SSL” in 2026 as a synonym for TLS unless someone is specifically talking about the ancient versions.

WQI grades several specific aspects of how your TLS deployment works. The big three:

Each of those has its own article with scoring details, the exact server-side fix, and verification steps. Start there if you want to grade your own deployment.

Further reading