Why can an intercepting proxy read plain HTTP traffic effortlessly, but needs an extra trick to read HTTPS?
Plain HTTP travels in cleartext, so a proxy in the path just reads it; HTTPS is encrypted, so the proxy must terminate the TLS itself — which only works if the client already trusts the proxy's certificate.
* Cleartext HTTP is read directly; HTTPS makes the proxy a TLS endpoint on both sides — only possible if the client trusts its certificate. *
All the browser's traffic is routed through the proxy, so the only difference is encryption:
| Plain HTTP | HTTPS (TLS) | |
|---|---|---|
| On the wire | cleartext | encrypted |
| Proxy can read/modify? | yes, directly | not without terminating TLS |
| What the proxy must do | just relay and observe | be a TLS endpoint on both sides — decrypt from the client, re-encrypt to the server |
| Catch | none | the client must trust the proxy's certificate, or it warns |
For HTTPS the proxy runs two separate TLS connections — one to the browser, one to the real server — and bridges them in the clear in the middle. The browser only accepts the proxy's side if the certificate it presents chains to a CA the browser trusts, which is why interception setups install the proxy's own root CA.
Tip: Interception is a trust story, not a crypto-breaking story — the proxy never breaks TLS, it gets the client to trust it.
Go deeper:
TLS termination proxy (Wikipedia) — a proxy that decrypts and re-encrypts TLS, the mechanism HTTPS interception relies on.