Part 7 — TLS and HTTPS

Everything so far — hashes, AEAD, key exchange, signatures, certificates — comes together here. TLS is the protocol that secures the web, and understanding it end to end is a core skill for a security engineer.

Chapter 27 — What HTTPS actually guarantees (and what it doesn't)

In one sentence

HTTPS is HTTP carried inside a TLS tunnel that provides confidentiality, integrity, and server authentication between your browser and one endpoint — and nothing beyond that.

The problem: plain HTTP on a shared network

   You type http://bank.example and hit enter. Between you and the server:

     your laptop -> home router -> ISP -> transit networks -> hosting -> server

   On plain HTTP, ANY hop can:
     * READ everything      -- passwords, cookies, page contents
     * MODIFY everything    -- inject ads, malware, change bank details
     * IMPERSONATE the site -- you have no way to tell
     * REPLAY requests

Coffee-shop Wi-Fi, a compromised router, a malicious ISP, a nation-state tap on a backbone cable — all are "a hop". HTTP assumes the network is trustworthy. It never was.

What TLS adds

   CONFIDENTIALITY   an eavesdropper sees only which SERVER you connected to
                     (IP, and the hostname via SNI/DNS) and rough traffic
                     SIZE and TIMING. Not the URL path, not headers, not body.

   INTEGRITY         any modification in transit is detected and the
                     connection is torn down (AEAD tag failure, Ch 15).

   SERVER            you are cryptographically sure you're talking to the
   AUTHENTICATION    holder of the private key for a certificate that a
                     trusted CA issued for THIS hostname (Ch 29).

   FORWARD SECRECY   (TLS 1.3, always) recording today + stealing the key
                     later does not decrypt past sessions (Ch 18).

What TLS does NOT give you

This list matters as much as the previous one:

   [ ] It does not make the SERVER trustworthy. HTTPS to a phishing site is
       still a phishing site -- with a valid padlock. "Secure" != "safe".

   [ ] It does not hide WHICH site you visit. The destination IP is visible;
       the hostname leaks via the DNS lookup and via the TLS SNI field
       (unless Encrypted Client Hello / ECH is in use -- still rolling out).

   [ ] It does not protect data BEFORE or AFTER the tunnel. The server
       decrypts everything. Logs, backups, a breached database, a rogue
       admin, a subpoena -- all outside TLS's scope. (End-to-end encryption
       is a different, stronger property.)

   [ ] It does not authenticate the CLIENT by default. The server rarely
       knows who you are from TLS alone (mTLS is opt-in -- Ch 31).

   [ ] It does not stop application bugs. SQL injection, XSS, broken authz
       all travel happily inside a perfect TLS tunnel (Part 10).

   [ ] It does not defend against a MALICIOUS or MIS-ISSUED certificate,
       except that Certificate Transparency makes mis-issuance detectable
       after the fact (Ch 30).

   [ ] It does not hide traffic ANALYSIS. Packet sizes and timing can reveal
       which page you loaded, what video you're streaming, or what you typed.

"The padlock means it's safe" — the enduring myth

   The padlock means: the connection to THIS server is encrypted and the
   server proved control of a certificate for THIS domain name.

   The padlock does NOT mean: the site is legitimate, honest, competent,
   or not run by criminals.

   Today the MAJORITY of phishing sites use HTTPS (free certs from ACME
   CAs). Browsers removed the word "Secure" from the address bar precisely
   because users read it as "trustworthy".

The relationship to HTTP

   HTTPS = HTTP  +  TLS  +  (default port 443 instead of 80)

     Application:  HTTP/1.1, HTTP/2, or HTTP/3
     Security:     TLS 1.2 or 1.3   (TLS 1.3 for HTTP/2 in practice;
                                     HTTP/3 uses QUIC, which embeds TLS 1.3)
     Transport:    TCP (h1, h2)  or  UDP+QUIC (h3)

TLS is a generic secure-channel protocol. It also wraps SMTP, IMAP, LDAP, gRPC, MQTT, syslog, and more. HTTPS is just its most visible user.

Practice (20 min)

mkdir -p ~/sec-lab/scratch && cd ~/sec-lab/scratch

# 1. See plain HTTP in the clear (a deliberately-plaintext test host)
curl -v http://neverssl.com 2>&1 | head -20
# every header and byte here is visible to every hop

# 2. See what an eavesdropper learns from an HTTPS connection: the SNI
#    (hostname in the ClientHello) is currently NOT encrypted
sudo tcpdump -i any -n -A 'tcp port 443' -c 40 2>/dev/null | grep -a -i -E 'example|wikipedia' &
curl -s https://en.wikipedia.org/wiki/Transport_Layer_Security -o /dev/null
sleep 1; sudo pkill tcpdump 2>/dev/null
# you'll spot the hostname in the ClientHello, but nothing else

# 3. The padlock proves domain control, not honesty:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Think it through: you're on hostile Wi-Fi and load https://news.example. List exactly what the network operator can and cannot learn. (Answer in Appendix F.)

Common confusions

"HTTPS means the website is safe." It means the channel is secure. The site can still be malicious.
"HTTPS hides the URL." It hides the path and query from the network; the hostname still leaks (DNS + SNI). Bookmarked, logged, and Referer-leaked URLs are unprotected.
"My data is encrypted end to end because I use HTTPS." TLS terminates at the server (often at a load balancer before the server). The server sees plaintext. E2E encryption (Signal, etc.) is a stronger, separate design.
"TLS stops hackers." It stops network attackers. Application vulnerabilities are untouched.

Check yourself

Name the three core guarantees TLS provides.
List three things TLS explicitly does not protect.
What can a network eavesdropper still learn about your HTTPS traffic?
Why did browsers stop showing the word "Secure"?
Where does the TLS tunnel end, and why does that matter for your data?

(Answers: Appendix F.)