How does an intercepting HTTPS proxy (a TLS man-in-the-middle) abuse the chain-of-trust model to read encrypted traffic?
It installs its own root CA into the client's trust store; then it can mint a valid-looking certificate for any site on the fly, so the browser trusts the proxy instead of the real server.
* Add the proxy's root to the trust store and every forged leaf certificate validates — so the proxy can decrypt without any warning. *
Normally TLS stops a MITM: the attacker can't produce a certificate for www.bank.com that chains to a CA your browser trusts. An intercepting proxy (e.g. the kind used in web-app security testing) sidesteps this by becoming a trusted CA on that machine:
- The proxy generates its own root CA certificate.
- That root is installed into the client's trust anchor list (manually, or by an admin/MDM).
- For every site the client visits, the proxy dynamically generates and signs a leaf certificate for that hostname with its own CA.
- Because the client now trusts the proxy's root, the chain validates — no warning — and the proxy decrypts, inspects, and re-encrypts the traffic.
Why it works: TLS trust is only as strong as your trust-anchor list. Add a new trusted root, and you've authorised it to vouch for anyone.
Tip: This is legitimate and essential for testing your own apps — but it's also why installing unknown root certificates is extremely dangerous: it hands someone the power to impersonate every website to you.
Go deeper:
How mitmproxy works (mitmproxy docs) — a concrete walkthrough of generating certificates on the fly to intercept TLS.
Transport Layer Security (Wikipedia) — how TLS authenticates the server via certificates, exactly what interception subverts.