1st Principles
Menu

Security · 34 min read

HTTPS and TLS

How HTTP rides inside an authenticated, encrypted transport: certificates, handshakes, and what the lock icon actually promises.

Why this exists

HTTP alone sends cleartext requests on a path full of observers. Cookies, passwords, and personal pages would be trivial to intercept or modify.

TLS provides a secure channel: confidentiality, integrity, and server authentication (and optionally client authentication). HTTPS is HTTP over that channel.

Understanding TLS stops magical thinking about the lock icon and clarifies where trust anchors, certificates, and name checks fit.

Axioms & primitives

  1. 01HTTPS is HTTP over TLS, not a wholly different application language.
  2. 02TLS authenticates the server to the client using certificates anchored in trust stores (typical web case).
  3. 03Handshakes negotiate keys; records protect application bytes afterward.
  4. 04Certificate validation must check signatures, validity period, revocation strategy, and name match.
  5. 05TLS does not by itself prove the site is honest, only that you reached the owner of a validated name key.
  6. 06Downgrade and stripping attacks target the leap from http:// to https:// and weak negotiation.

Learning objectives

After this lesson you should be able to:

  • Explain what the browser lock icon does and does not guarantee.
  • Trace a simplified TLS 1.3 handshake at the level of roles (client, server, certificate, keys).
  • Diagnose a name mismatch versus an untrusted CA versus an expired certificate from an error description.
  • Locate where HTTP headers become invisible to on-path observers under TLS.
  • Describe why HSTS and HTTPS redirects exist.

Progressive depth

Read the layers in order for a full explanation. Or open the layer you need.

01

Intuition

You type a URL. Before your browser sends HTTP, it wants a private pipe to the real server for that name. TLS is how it builds that pipe: check the server's certificate, agree on keys, then encrypt what follows.

The lock icon means the channel checks succeeded for that name under your trust settings. It is not a moral judgment about the business behind the site.

If someone on the path tries to alter bytes, integrity checks fail. If they only eavesdrop, they should see ciphertext.

02

Formal shape

TLS runs over a reliable stream (classically TCP). TLS 1.3 reduces round trips and removes old ciphers. The handshake authenticates the server (typically) and derives traffic keys. Application data is then carried in AEAD-protected records.

X.509 certificates bind a public key to names (SANs). Clients validate a chain to a trusted root, check time validity, follow revocation strategy (OCSP/CRL/CRLite-style mechanisms vary), and match the name to the URL host.

SNI tells the server which certificate to present when many sites share an IP. Encrypted Client Hello aims to reduce that metadata leak.

HSTS instructs browsers to use HTTPS only for a site after first visit (or via preload lists), mitigating SSL stripping.

TLS channel setup

Click a stage to see the pipe this page builds before HTTP rides inside: check the server, agree on keys, then protect records.

Loading diagram...

Select a stage to read the boundary detail.

03

Worked examples

Happy path: DNS to IP, TCP connect, TLS handshake with valid cert for example.com, HTTP GET inside TLS, 200 OK.

Name mismatch: certificate is for other.example; browser errors. Encryption to the wrong name is not success.

Corporate TLS inspection: a middlebox terminates TLS with an enterprise root installed on managed devices. The lock may still show, but privacy assumptions change.

Mixed content: HTTPS page loading an HTTP script is blocked or degraded because active content on a clear channel undermines the page's trust.

04

Edge cases

Certificate transparency and automation (ACME/Let's Encrypt) changed issuance scale; mis-issuance detection matters.

Session resumption and 0-RTT (TLS 1.3) trade latency for replay considerations on early data.

HTTP/3 uses QUIC, which embeds TLS 1.3-like handshake properties over UDP. The security goals rhyme; the packet framing differs.

Pinning public keys is delicate and can brick clients if mis-rotated. Prefer CT and solid CA practices unless you know the operational cost.

Mental models

  • Armored truck for letters

    HTTP letters go inside an armored TLS truck. The postal network still sees where the truck drives.

  • ID check at the door

    The certificate is an ID badge. The browser checks whether a trusted issuer signed it for the name you typed.

  • Ephemeral conversation keys

    After ID check, both sides mint fresh session keys so bulk data is fast and past sessions are harder to decrypt later (forward secrecy).

Common misconceptions

  • Myth

    HTTPS means the website is safe to trust with money and secrets.

    Reality

    TLS secures the channel to whoever controls the certificate for that name. Phishing sites use HTTPS too.

  • Myth

    TLS encrypts DNS automatically.

    Reality

    Classic DNS is separate. DoT/DoH encrypt DNS to a resolver; TLS to a site does not hide the fact you contacted that site's IP (and often SNI).

  • Myth

    A self-signed certificate is 'just as encrypted.'

    Reality

    Encryption may occur, but without a trust anchor the client cannot tell a stranger from the intended server. Authenticity fails.

  • Myth

    Once TLS is done, HTTP headers are still visible to coffee-shop Wi-Fi.

    Reality

    On a proper TLS connection, HTTP is inside the encrypted records. Observers see IPs, ports, approximate sizes, and often SNI/ECH dynamics.

Exercises

Work these without looking up answers first. Check yourself against the intent notes.

  1. Exercise 01

    A cafe attacker presents a self-signed certificate for your bank. What should a correctly configured browser do, and which TLS goal failed for the attacker?

    What good looks like

    Browser warns/blocks; authenticity/trust anchor check failed. Confidentiality to attacker is irrelevant.

  2. Exercise 02

    List three things still visible to a network observer during a normal HTTPS visit, and three that should not be.

    What good looks like

    Visible: IPs, SNI (often), sizes/timing. Hidden: HTTP paths, cookies, HTML body, passwords.

  3. Exercise 03

    Why does redirecting HTTP to HTTPS on first visit not fully solve SSL stripping for that first visit?

    What good looks like

    First cleartext request can be stripped/modified; HSTS preload or never offering HTTP helps.

Sources & further reading

External references. Prefer primary documents and clear explainers.

Go deeper on your own

These picks go past the foundation in this lesson. Use them when you want a primary spec, official docs, or a longer walkthrough.