HTTP vs HTTPS

HTTP is an application protocol. A client sends something like GET /login HTTP/1.1 plus headers, and the server answers with a status (200, 301, 404, 500), its own headers, and often HTML or JSON. Methods matter: GET should not change server state; POST/PUT/PATCH/DELETE often do. You will meet those words in logs long before you write a web app. The Host header is not decoration. One IPv4 can serve thousands of websites. The TCP connection lands on port 80 or 443 of that IP; Host: example.com tells the server which site you meant. Without Host (or its HTTP/2/3 equivalent), virtual hosting collapses. When you curl a URL, curl sets Host from the URL. When you curl an IP and forget Host, you may get a default vhost — a different app than the name implied.

A response is a story for defenders. 301/302 plus Location is a redirect — including the common http:// → https:// bounce. Set-Cookie without Secure can be stored after an HTTP response and later stolen on a cleartext hop. Server and X-Powered-By leak stack hints. None of that requires "hacking." curl -I on a host you are allowed to touch prints the metadata. The body is a separate download; HEAD/ -I is how you look at the envelope stamp without saving the novel.

Cleartext HTTP means the bytes of the request and response are the bytes on the wire (plus TCP/IP wrapping). On a shared network, a compromised router, or a malicious hotspot, those bytes are available to anyone capturing that path — which is why this course never captures café Wi-Fi or a roommate's session. The mechanism still matters on your own loopback lab: if you HTTP to a local python server and capture lo, you will see Cookie: and Authorization: as strings. That is the lesson, not a hunting license. Passwords in POST bodies, session cookies, tokens in query strings, "secret" reset links — all travel as text on port 80. Integrity is also gone: an on-path attacker can splice a script into the HTML. Confidentiality and integrity of the channel are both missing. Availability might still look fine. The user sees a page. The CIA triad is not a page-load indicator.

HTTPS is HTTP inside a TLS tunnel, conventionally TCP/443. TLS does three jobs you should keep separate. (1) Confidentiality: after the handshake, application bytes are ciphertext on the path. (2) Integrity: tampering is detectable. (3) Authentication of the server: the certificate binds a public key to names (SAN/CN) and is signed by a CA your client trusts. The client checks: is this cert unexpired, signed by a trusted CA, and does the name match the URL I typed? That last check is identity of the hostname, not honesty of the operator. Anyone who can prove control of evil-login.example can get a legit cert for evil-login.example. The padlock will glow. The page can still be a clone of a bank. HTTPS ≠ "website is safe from phishing." Certificate warnings (name mismatch, unknown CA, expired) mean the identity check failed. Clicking through is how an on-path attacker becomes "your bank" on a network you do not control. In a lab you own, a self-signed cert is a teaching tool — still not a reason to ignore warnings on the real web.

HSTS (HTTP Strict Transport Security) is a policy header: "for this name, browsers must use HTTPS for a stated time, and must not click through certain errors." It exists because the first hop to http://example.com is still a cleartext request — a chance to strip TLS or inject a redirect. Preload lists bake that policy into browsers for some names. HSTS is not magic antivirus. It hardens the upgrade from HTTP to HTTPS for a name the user already intends to visit. It does not stop the user from visiting a different, look-alike name that was always HTTPS.

example.com is the documentation domain reserved for this kind of lab. You are inspecting headers from your own client. You are not attacking the server, not fuzzing, not capturing a shared network. If HTTP redirects to HTTPS, that is data — write it down. If HSTS is present, write down max-age. If HTTP still returns 200 with a body path, that is also data.

# HTTPS first (TCP/443). -I asks for headers (HEAD-style).
curl -I https://example.com

# Cleartext HTTP (TCP/80). Note status and Location if it redirects.
curl -I http://example.com

# Show redirects instead of hiding them
curl -I -s -o /dev/null -w 'http  %{http_code}  redirect:%{redirect_url}
' http://example.com
curl -I -s -o /dev/null -w 'https %{http_code}  url:%{url_effective}
' https://example.com

# Optional: include response headers you care about in notes
mkdir -p "$HOME/cyberlium-lab"
{
  echo '=== HTTPS ==='
  curl -I https://example.com
  echo
  echo '=== HTTP ==='
  curl -I http://example.com
} > "$HOME/cyberlium-lab/http-https-notes.txt"
chmod 600 "$HOME/cyberlium-lab/http-https-notes.txt"

# NEVER: curl other people's private/internal apps without permission
# NEVER: capture café Wi-Fi HTTP to harvest cookies
# NEVER: ignore a real browser certificate warning to "just finish the login"

You can read an HTTP exchange as request/response plus Host, explain why port 80 leaks secrets on the path, and separate TLS (channel) from certificates (name binding) from phishing (human vs look-alike name). HSTS hardens the HTTP upgrade; it does not bless every padlock. Next — FTP, SSH, SMTP, IMAP — other application protocols, their ports, and which of them still send postcards.