HTTP vs HTTPS

If you are new here: HTTP is the language browsers and APIs use (GET, POST, headers, bodies). HTTPS is the same language, but the bytes are wrapped in TLS so observers on the network cannot read or tamper with them. The URL http:// is plaintext; https:// is encrypted.

The Problem

You ship a login form. On your laptop everything looks fine — the browser shows a little “Not secure” chip, but the page loads. Then a teammate opens DevTools on café Wi‑Fi and copies the password straight off the wire. Nothing was “hacked” in the database; the transport was simply readable.

HTTP carries bytes in the clear. HTTPS is HTTP inside TLS — same verbs, same headers, but ciphertext on the untrusted path.

In plain terms: HTTPS wraps your HTTP in encryption + identity checks so coffee-shop Wi‑Fi is not a live transcript of passwords and tokens.

Analogy: HTTP is a postcard; HTTPS is a locked envelope with a stamp that proves who sent it (certificate).

What actually crosses the wire (HTTP): Anyone on the path can see something shaped like:

POST /login HTTP/1.1
Host: shop.example.com
Content-Type: application/x-www-form-urlencoded
 
username=alex&password=SuperSecret123

With HTTPS, that same application data is inside TLS records — packet captures show length and timing, not the password.

When the path is hostile

Anyone who can observe traffic between the user and your origin — a rogue AP, a tapped switch, malware on the LAN — sees the same request your server would have parsed. Forward secrecy and encryption are not paranoia; they are the minimum bar for credentials and tokens.

Practical takeaway: Treat any token, cookie, or API key like a password. If it travels over HTTP, assume it is compromised.

Client hello

The upgrade begins with a ClientHello: supported TLS versions, cipher suites, and random material. No application data yet — just negotiation so both sides speak a common dialect.

Browsers and curl initiate this automatically when you use https://.

Server certificate

The server answers with its certificate chain so the client can prove the hostname matches before trusting the tunnel. If verification fails, the browser stops — it does not quietly continue.

Inspecting a live chain (read-only):

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

You should see the subject matching the site, an issuer (intermediate CA), and notBefore / notAfter dates.

Shared keys

Modern handshakes use ephemeral key agreement (often ECDHE) so each session gets fresh keys. Bulk encryption uses fast symmetric ciphers; public-key math bootstraps the session, not every packet.

Inside the tunnel

After the handshake, TLS records wrap your HTTP. Same GET and JSON — different bytes on the wire. Middleboxes still see packet sizes and timing, but not your secrets.

See TLS + HTTP with curl:

curl -v https://api.example.com/v1/health 2>&1 | head -40

Look for * TLSv1.3, * Server certificate:, then > GET /v1/health — the HTTP request happens after the tunnel exists.

Gibberish for observers

An on-path observer still forwards packets, but without session keys the payload stays opaque. That is the practical difference users and auditors care about.

Trust anchors

Browsers ship root CAs; intermediate certificates bridge your domain leaf to a trusted root. Renewal, revocation (OCSP / stapling), and short-lived certs are operational work — but they replace “anyone can read the password.”

The trade-offs

TLS adds handshake latency (often 1–2 RTTs on first connect; TLS 1.3 and session resumption help) and CPU on the server — usually negligible compared to business logic. Misconfigured or expired certs break sites loudly — which is preferable to silent interception.

Why this matters for you

If you own an origin on the internet, HTTPS everywhere is table stakes — not only for secrecy but for integrity (proxies cannot silently patch responses). Start with managed certificates from your cloud or CDN, automate renewal, and treat HTTP-only URLs as a bug.