Why do HTTP credentials show up in plaintext in Wireshark, but HTTPS credentials don't — even when the attacker is fully in-path?
HTTP traffic is unencrypted on the wire — anyone with packet capture sees usernames and passwords. HTTPS encrypts at the TLS layer, so the attacker sees only ciphertext, even when MitM-positioned.
HTTP example (a deliberately vulnerable web app):
POST /login HTTP/1.1
Host: dvwc.introl.ls.eee.intern
Content-Type: application/x-www-form-urlencoded
username=admin&password=hunter2 ← visible in plain text!
A simple Wireshark filter http.request.method == "POST" reveals all credentials.
HTTPS example (real mycampus.hslu.ch):
TLS Application Data
Encrypted: 4a 7e 02 bf 8c 91 ... (random bytes)
Same login, but inside the TLS encryption. The attacker sees:
- That a connection happened (metadata)
- The destination IP and port
- The size and timing of packets
- Not the contents
Why the attacker can't decrypt:
The session keys were derived using:
- Server's private key (which the attacker doesn't have)
- Both sides' random values
- Diffie-Hellman exchange
Without the server's private key (or some way to break the cryptography), the encrypted bytes are indistinguishable from random.
What HTTPS doesn't protect:
| What's still leaked | Why |
|---|---|
| Domain (via SNI) | Sent in plaintext during TLS handshake |
| IP address & port | Routing requires these in cleartext |
| Timing & size patterns | Can fingerprint specific actions ("user just logged in") |
| DNS lookups (if not DoH) | Plaintext DNS reveals what sites you visit |
The MitM next move — SSL Stripping:
If the victim accidentally types http://bank.com (or follows an HTTP link), the attacker can:
- Connect to
https://bank.comthemselves - Serve the response over HTTP to the victim
- Read everything the victim types
Defense — HSTS:
Strict-Transport-Security header tells browsers "always use HTTPS for this domain, never HTTP." After first visit, the browser refuses to even try HTTP → SSL stripping fails. HSTS preload list bakes this protection in for top sites from the first visit.
Tip: When testing security, always check whether HTTP fallback exists. A site that "works on HTTPS but also responds on HTTP without redirect" is an SSL-strip target.
Go deeper:
New Tricks for Defeating SSL in Practice — Moxie Marlinspike (Black Hat, 2009) — the original talk that introduced SSL stripping and the sslstriptool. (slides PDF)
HTTP Strict Transport Security (Wikipedia) — how HSTS (RFC 6797) and the preload list shut down the downgrade attack above.