How HTTPS Works — The Lock Icon Explained

Your TCP connection to 142.250.80.46 is open.

Congratulations — you’re now connected to Google’s server. Every byte you send will arrive reliably, in order. TCP guaranteed it.

There’s just one problem: anyone between you and that server can read every byte.

Your ISP. The coffee shop router. A corporate proxy. A government’s network. Every router your packets pass through. HTTP sends everything as plain text — your login credentials, your search queries, your private messages — all of it is visible.

This is what TLS fixes.

🔓 HTTP vs HTTPS🤝 The Handshake📜 Certificates

HTTP sends everything as plain text. Anyone between your browser and the server can read it. HTTPS wraps everything in TLS encryption.

NETWORK PATH

🔓 View as HTTP🔒 View as HTTPS

Choose a mode above to see what travels across the wire

---

What TLS actually does

TLS (Transport Layer Security) does two things:

Encryption. It scrambles your data so that only the intended recipient can read it. Anyone who intercepts the packets sees random bytes — the encrypted ciphertext — and can’t reconstruct the original data without the key.

Authentication. It proves you’re actually talking to who you think you are. Without this, you could set up a perfect encrypted tunnel to an attacker’s server, thinking it was your bank. Certificates solve this.

HTTPS is just HTTP running inside a TLS tunnel. The H remains the same. The S stands for the security layer underneath.

The TLS 1.3 handshake

Before encrypted data can flow, the two sides need to agree on encryption parameters and exchange keys. This is the TLS handshake.

TLS 1.3 (the current version) does it in one round trip — a significant improvement over TLS 1.2 which required two. Here’s what happens:

Step 1: ClientHello

Your browser sends a list of what it supports:

ClientHello:
  Supported cipher suites:
    - TLS_AES_256_GCM_SHA384
    - TLS_CHACHA20_POLY1305_SHA256
  Key share: (browser's public Diffie-Hellman key)
  TLS versions: 1.3, 1.2

The “key share” is the browser’s half of a Diffie-Hellman key exchange. We’ll come back to what that means.

Step 2: ServerHello + Certificate + Finished

The server responds with three things at once:

ServerHello:
  Chosen cipher: TLS_AES_256_GCM_SHA384
  Key share: (server's public Diffie-Hellman key)

Certificate:
  Issued to: google.com
  Issued by: DigiCert Inc
  Valid: 2024-01-15 to 2024-04-09
  Public key: (server's long-term public key)
  Signature: (DigiCert's cryptographic signature)

CertificateVerify:
  Signature over handshake: (proves server has the private key)

Finished:
  (first message encrypted with derived keys)

At this point, both sides have each other’s Diffie-Hellman key shares. They can each independently compute the same session key — without ever transmitting the key itself. This is the magic of Diffie-Hellman.

Step 3: Client Finished

Your browser verifies the certificate, derives the session keys, and confirms:

Finished: (encrypted confirmation)

And that’s it. The handshake is complete. One round trip total.

Every subsequent packet is encrypted with the session key. The session key is temporary — generated fresh for each connection, discarded when the session ends. Even if someone recorded all your traffic and later stole the server’s private key, they couldn’t decrypt it. This property is called Perfect Forward Secrecy.

Certificates: proving identity

Encryption without identity verification is dangerous. You could have a perfect encrypted channel to an attacker’s server that’s impersonating your bank.

Certificates solve this. A certificate is a signed document that says:

“The server at this IP address controls the private key paired with this public key, and that server is genuinely operating the domain google.com.”

The signing is done by a Certificate Authority (CA) — a company like DigiCert, Let’s Encrypt, or Comodo. Your OS and browser ship with a list of ~150 trusted CAs. When a certificate is signed by one of them, you trust it.

What a certificate proves:

• The server has the private key corresponding to the certificate’s public key (proven by CertificateVerify)
• A trusted CA verified the domain ownership before signing (typically by proving control over DNS or HTTP)
• The certificate hasn’t expired
• The certificate hasn’t been revoked

What a certificate doesn’t prove:

• That the company is legitimate or not a scam
• Anything about the content of the site

A phishing site can have a valid HTTPS certificate. The padlock means “the connection is encrypted and you’re talking to whoever registered this domain.” It doesn’t mean “this site is safe.”

What the padlock actually means

The padlock in your browser’s address bar means:

1. Your connection to this domain is encrypted
2. The server proved it controls the private key matching the certificate
3. The certificate was signed by a CA your OS trusts
4. The certificate is valid and not expired

It does not mean the site is safe, trustworthy, or not malicious.

When you see “Not Secure” instead, it means either:

• The page uses HTTP instead of HTTPS (no encryption at all)
• The HTTPS certificate is invalid, expired, or for the wrong domain
• The page has mixed content (HTTPS page loading HTTP resources)

TLS 1.2 vs 1.3

If you’re working on infrastructure, you’ll encounter both:

	TLS 1.2	TLS 1.3
Handshake round trips	2	1
Cipher suite negotiation	Client lists all; server picks	Streamlined, fewer options
Forward secrecy	Optional	Mandatory
0-RTT resumption	No	Yes (allows session resumption with 0 round trips, but has replay attack considerations)
Adoption	~30% of traffic	~70%+ of traffic

Use TLS 1.3 wherever you control the server. It’s faster and more secure.

---

The takeaway

TLS transforms a naked TCP pipe into a secure, authenticated tunnel. The encryption protects your data from anyone in the middle. The certificate proves you’re talking to the right server.

The handshake is fast — one round trip in TLS 1.3. But it still costs time, which is why browsers aggressively reuse TLS sessions and why reducing the number of distinct origins on a page (fewer hostnames = fewer TLS handshakes) is a real performance optimization.

Next up: The tunnel is secure. Time to actually ask for something. How HTTP Works →