What Is SSL/TLS? How That Little Padlock Actually Works

SSL/TLS (Secure Sockets Layer / Transport Layer Security) is the encryption protocol that secures communication between your web browser and a website’s server. When you see that padlock icon next to a URL and the address starts with https://, TLS is doing the work behind the scenes. It encrypts data in transit so that nobody between you and the server, not your ISP, not the coffee shop Wi-Fi operator, not some random hacker, can read or modify what’s being transmitted. Every password you type, every credit card number you enter, and every search query you make on HTTPS sites is protected by this protocol.

SSL Is Dead. Long Live TLS.

Quick clarification that will save you confusion: SSL and TLS are not the same thing, despite everyone using the names interchangeably.

SSL was created by Netscape in the mid-1990s. It went through versions 1.0 (never released, too broken), 2.0 (released in 1995, also broken), and 3.0 (1996, less broken but still eventually compromised by the POODLE attack in 2014).

TLS is the successor to SSL. TLS 1.0 was released in 1999 as essentially SSL 3.1. Then came TLS 1.1 (2006), TLS 1.2 (2008), and TLS 1.3 (2018).

As of 2026, TLS 1.2 and TLS 1.3 are the only versions you should be using. Everything older has known vulnerabilities and has been deprecated by every major browser. But people still call it “SSL” because thirty years of habit is hard to break, and “SSL certificate” is easier to say than “TLS certificate.” The certificates themselves work the same way regardless.

The TLS Handshake: What Happens When You Click a Link

Every time you visit an HTTPS website, your browser and the server perform an elaborate greeting ritual called the TLS handshake. This happens before any actual page content loads, and it’s finished in milliseconds. Here’s what goes down:

TLS 1.2 Handshake (Simplified)

1. Client Hello: Your browser says “Hey, I want to connect securely. I support these cipher suites and TLS versions.”
2. Server Hello: The server responds with “Cool, let’s use this specific cipher suite. And here’s my SSL certificate.”
3. Certificate Verification: Your browser checks the certificate. Is it issued by a trusted Certificate Authority? Is it expired? Does the domain name match? Is it revoked?
4. Key Exchange: Both sides use asymmetric encryption (usually RSA or ECDHE) to securely exchange a symmetric session key.
5. Finished: Both sides confirm they have matching session keys.
6. Encrypted Communication Begins: All subsequent data is encrypted with the symmetric session key (AES-128 or AES-256).

This took 2 round trips between client and server. Doesn’t sound like much, but on a 200ms latency connection, that’s 400ms just for the handshake.

TLS 1.3 Handshake (Better)

TLS 1.3 slimmed this down to 1 round trip. It removed support for outdated cipher suites, simplified the negotiation process, and added 0-RTT resumption for repeat connections (meaning you can skip the handshake entirely if you’ve connected to this server recently).

The result is measurably faster page loads, especially on high-latency connections like mobile networks. TLS 1.3 also eliminated several categories of attacks that were possible with earlier versions by removing weak algorithms entirely rather than making them optional.

SSL Certificates: The Trust System

An SSL certificate is basically a digital ID card that proves “yes, this server really is who it claims to be.” It contains:

• The domain name(s) the certificate covers
• The organization that owns it (in some cases)
• The Certificate Authority (CA) that issued it
• The server’s public key
• The certificate’s validity period
• A digital signature from the CA verifying everything above

How Certificate Trust Works

Your browser (and your operating system) comes pre-loaded with a list of trusted Certificate Authorities. These are companies and organizations that have been vetted and approved to issue certificates. There are about 150 root CAs trusted by major browsers.

When a website presents its certificate, your browser traces the chain of trust:

Website Certificate (whatismyip.wiki)
  ↓ signed by
Intermediate CA Certificate (Let's Encrypt R3)
  ↓ signed by
Root CA Certificate (ISRG Root X1)
  ↓ pre-installed in
Your Browser's Trust Store ✓

If the chain is complete and the root CA is trusted, the padlock appears. If anything in the chain is broken, expired, or untrusted, you get the scary “Your connection is not private” warning.

Certificate Types

Here’s an honest take: the difference between DV, OV, and EV in terms of actual encryption is zero. They all use the same encryption algorithms and provide the same level of data protection. The difference is only in the verification process. EV certificates used to show the company name in a green address bar, but Chrome and Firefox removed that in 2019 because research showed users didn’t actually notice or understand it.

Let’s Encrypt has issued over 3 billion certificates since its launch in 2016 and is now responsible for roughly half of all HTTPS certificates on the web. The fact that strong encryption became free and automated is probably the single biggest improvement to internet security this century.

What TLS Actually Encrypts

TLS encrypts the data layer of your connection. Specifically:

Encrypted (can’t be read by third parties):

• The URL path and query parameters (/search?q=my+embarrassing+question)
• HTTP headers (cookies, authentication tokens)
• Request and response bodies (form data, page content)
• HTTP method (GET, POST, etc.)

NOT encrypted (still visible to observers):

• The destination IP address (obviously, packets need to reach the server)
• The domain name in the SNI (Server Name Indication) field during the handshake
• Connection timing and data volume patterns
• DNS queries (unless you’re also using DNS over HTTPS)

That SNI leak is worth mentioning. When your browser initiates a TLS connection to a server that hosts multiple websites, it sends the domain name in plain text during the handshake so the server knows which certificate to present. This means someone watching your traffic can see which domains you’re connecting to even though they can’t read the content. Encrypted Client Hello (ECH) is a newer extension designed to fix this, but adoption is still in early stages.

HTTPS Everywhere: How We Got Here

Back in the early 2010s, only websites that handled sensitive data (banks, email, online stores) used HTTPS. Most of the web was plain HTTP. Google started pushing the change by:

1. Making HTTPS a ranking signal in search results (2014)
2. Marking HTTP pages as “Not Secure” in Chrome (2017, gradually increasing severity)
3. Let’s Encrypt launching free certificates (2015)

The result was dramatic. In 2015, about 30% of web traffic was HTTPS. By 2026, it’s over 95%. The web is now overwhelmingly encrypted, which is genuinely great for privacy and security.

But HTTPS doesn’t mean “this site is trustworthy.” It only means the connection is encrypted. A phishing site can have a perfectly valid HTTPS certificate (often a free one from Let’s Encrypt). The padlock tells you that your connection to totally-not-a-scam.com is secure. It says nothing about whether totally-not-a-scam.com is legitimate.

Performance Benefits of TLS 1.3

TLS 1.3 isn’t just more secure, it’s actually faster:

• 1-RTT handshake (vs 2-RTT in TLS 1.2). Cuts connection setup time roughly in half.
• 0-RTT resumption for repeat visits. Your browser can send encrypted data immediately without waiting for the handshake to complete. The tradeoff is a small replay attack window, but for idempotent requests (like loading a homepage), the speed benefit is worth it.
• Fewer cipher suites means less negotiation overhead. TLS 1.3 only supports 5 cipher suites compared to the dozens in TLS 1.2.
• Forward secrecy is mandatory. Every TLS 1.3 connection uses ephemeral keys, meaning a compromised server key can’t decrypt past traffic. This was optional in TLS 1.2.

The performance improvement is especially noticeable on mobile networks with high latency. Google reported that switching YouTube to TLS 1.3 reduced connection errors by 50% on some networks.

Common TLS Mistakes

If you’re running a website, avoid these:

Mixed content: Loading some resources over HTTP on an HTTPS page. Browsers will block or warn about this, and it compromises the security of the entire page.

Expired certificates: Let’s Encrypt certificates are valid for 90 days. Use automated renewal (certbot handles this). Nothing looks worse than a security warning on your homepage.

Missing HSTS header: HSTS (HTTP Strict Transport Security) tells browsers to always use HTTPS for your domain, preventing downgrade attacks. Without it, an attacker on your network can strip the HTTPS and serve HTTP instead. Add Strict-Transport-Security: max-age=31536000; includeSubDomains to your response headers.

Weak cipher suites: If your server still supports TLS 1.0, TLS 1.1, or weak ciphers like RC4 and 3DES, disable them. They have known vulnerabilities.

Missing certificate chain: If you don’t include intermediate certificates in your server configuration, some clients (especially older Android devices) won’t be able to verify your certificate.

Test It Yourself

Frequently Asked Questions