Every time you see the padlock in your browser, two computers perform a secret handshake. They agree on a secret key — without ever sending that key across the internet. And your browser checks that the server really is who it claims to be.

This post explains exactly how that works: HTTPS, the TLS handshake, keys, and certificates. In simple steps.

The Problem: Plain HTTP Is Readable

HTTP sends everything as plain text. Your password, your messages, your card number — all of it.

That text travels across many routers, wifi access points, and networks you do not control. Anyone in the middle can read it. Worse, they can change it.

HTTPS fixes three things at once:

  • Privacy — no one in the middle can read your data.
  • Identity — you know the server is the real one, not a fake.
  • Integrity — no one can change the data without you noticing.

The “S” in HTTPS is a security layer called TLS (Transport Layer Security).

Two Kinds of Encryption

To protect data, we use encryption. There are two kinds, and HTTPS uses both.

Symmetric encryption uses one shared key. The same key locks (encrypts) and unlocks (decrypts) the data. It is very fast. But there is a problem: both sides need the same key. You cannot just send the key over the internet, because anyone watching would copy it.

Asymmetric encryption uses a pair of keys: a public key and a private key. Data locked with the public key can only be opened with the matching private key. The public key can be shared with anyone. The private key stays secret. This is powerful, but it is slow.

So HTTPS combines them. It uses slower asymmetric methods — a key exchange and digital signatures — to set up the connection safely. Then it switches to fast symmetric encryption for the real conversation.

The Key Exchange: A Shared Secret Without Sending It

Here is the clever part. How do two strangers agree on a secret key, in public, without ever sending it?

Think about mixing paint.

  1. Both sides start with the same public color. Everyone can see it.
  2. Each side privately picks a secret color and mixes it in. Then they send the mixture.
  3. An eavesdropper sees both mixtures. But you cannot “un-mix” paint to find the secret colors.
  4. Each side mixes in its own secret color one more time. Both sides end up with the exact same final color.

That final color is the shared secret. Both sides turn it into the same session keys. In real life it is math, not paint. This idea is called a key exchange (for example, Diffie-Hellman). The result is the same: both ends compute the same key, and a watcher cannot reproduce it.

Certificates: Proving Identity

There is still one danger. What if the server is an impostor?

This is where certificates help. When you connect, the server sends your browser a certificate. Think of it as a digital ID card. It says “I am yourbank.com” and it is signed by a Certificate Authority (CA) — a trusted company your browser already knows.

Your browser checks two things: that the certificate chains up to a trusted authority it already knows, and that the name on the certificate matches the site you are visiting. If both pass, the connection continues. If a fake server cannot show a valid certificate, your browser blocks it and shows a warning:

Your connection is not private

This is what stops a “man in the middle” from pretending to be your bank.

The TLS Handshake, Step by Step

Now put it all together. The handshake happens before any real data is sent.

  1. Client Hello — your browser says hello and sends its part of the key exchange.
  2. Server Hello — the server says hello back, sends its part of the key exchange, and sends its certificate.
  3. Verify and derive — your browser checks the certificate. Both sides use the key exchange to compute the same secret key.

In modern TLS (TLS 1.3), this usually takes a single round trip. By the end:

  • Both sides share a secret key that never crossed the network.
  • Your browser is sure who it is talking to.

After the Handshake

From this point on, the connection switches to fast symmetric encryption using the shared key.

Every request and response is now:

  • Sealed — unreadable to anyone in the middle.
  • Tamper-evident — any change is detected.

The padlock icon means all of this succeeded: identity checked, key agreed, channel encrypted. If any step had failed, you would see a warning instead.

See It Yourself

You can inspect a real TLS connection from your terminal.

View the certificate a server presents:

# Shows the certificate chain and connection details
openssl s_client -connect example.com:443 -servername example.com

Or use curl to see the handshake and certificate info:

# -v prints the TLS handshake; grep keeps the security lines
curl -v https://example.com 2>&1 | grep -iE "SSL|TLS|subject|issuer"

Look for the TLS version, the certificate subject (the domain), and the issuer (the Certificate Authority that signed it).

What You Learned

  • Plain HTTP is readable by anyone on the network path.
  • HTTPS uses asymmetric encryption to set up, then fast symmetric encryption.
  • A key exchange lets both sides agree on a secret key without sending it.
  • Certificates and Certificate Authorities prove the server’s identity.
  • The TLS handshake ties it together — in a single round trip.

Follow @kemal_codes on X and kemalcodes on GitHub. This is part of “Under the Hood” — how everyday tech really works.