What Is a Man-in-the-Middle Proxy? – Definition and How It Works

Learn how an intercepting proxy terminates TLS to inspect HTTPS, its legitimate uses, and the limits it runs into.

A man-in-the-middle proxy — usually called an intercepting proxy — terminates a TLS connection, inspects the plaintext, and opens its own connection to the destination. It sees inside HTTPS that would otherwise be opaque.

1. How Interception Works

1. The client connects to the proxy, requesting a destination.
2. The proxy presents a certificate it generated for that hostname.
3. The client validates it against its trust store — which succeeds only because the proxy's root certificate was added to that store.
4. The proxy connects to the real destination itself.
5. Requests and responses pass through the proxy in plaintext.

Step 3 is the entire mechanism. Interception requires deliberately trusting the proxy's root; without that, validation fails as it should.

2. Legitimate Uses

API discovery. Watching an application's own requests is the fastest way to learn a private API's endpoints, parameters, and authentication — far faster than reading obfuscated client code.

Debugging your own clients. Seeing exactly what your code sent, including headers a library added.

Corporate inspection, where an organisation inspects traffic on devices it owns and has disclosed it.

Security testing of applications you are authorised to test.

Response mocking, injecting a modified response to test client behaviour.

3. Common Tools

mitmproxy's scriptability is what makes it useful beyond inspection — a small script can rewrite requests, record structured logs, or replay traffic.

4. What Defeats It

Certificate pinning. An application checking against an embedded key rejects the proxy's certificate, failing with a generic network error. This is standard in banking and messaging apps.

Non-HTTP protocols. An HTTP proxy does not inspect arbitrary TCP or UDP, and a QUIC connection over UDP bypasses an HTTP-only proxy entirely.

A trust store you cannot modify. Some platforms restrict adding roots, and modern Android distinguishes user-added from system roots, with apps able to reject the former.

Client-side encryption. A payload encrypted inside the request body is still opaque after TLS is stripped.

5. Using It for API Discovery

The workflow that produces the most value:

1. Configure the device or browser to use the proxy and trust its root.
2. Exercise the application normally, performing the operation you care about.
3. Filter the captured traffic to the API host.
4. Identify the request that returns the data of interest.
5. Note the full request: method, path, query, headers, body, and the authentication mechanism.
6. Reproduce it outside the application and confirm it works.

Step 6 is the one that matters. A captured request frequently depends on a signature, a nonce, or a device-bound token that must be understood before the request is reproducible — and discovering that early saves rebuilding around a false assumption.

6. Ethical and Legal Boundaries

Intercepting traffic is intercepting communications. The line is consent and ownership:

• Your own device and your own traffic — fine.
• A device you own, with disclosure to its users — the corporate case, subject to local law.
• An application you are authorised to test — fine within that authorisation.
• Someone else's traffic without consent — unlawful in most jurisdictions, regardless of technical ease.

An intercepting proxy also holds every credential passing through it in plaintext, so its logs are credential material and must be treated as such: never committed, never shared, deleted when the work is done.

7. Operational Notes

• Remove the root certificate when finished. A trusted root left installed is a standing vulnerability on that device.
• Never run an intercepting proxy you do not control. The operator sees everything.
• Filter noisy hosts — telemetry and analytics traffic drowns the requests you want.
• Save flows for later analysis rather than working live; the interesting request is often identified in review.
• Expect HTTP/2 and QUIC differences. Interception normally forces HTTP/1.1 or HTTP/2, which can itself change behaviour.

8. Summary

An intercepting proxy terminates TLS and inspects HTTPS plaintext, which works only because its root certificate was deliberately added to the client's trust store — and it is the fastest route to understanding an application's private API.

Certificate pinning, unmodifiable trust stores, QUIC, and payload-level encryption all defeat it; its logs contain plaintext credentials and must be handled as secrets; and its root certificate should be removed as soon as the work is finished.

Potential Related Glossary

• Browser Fingerprints
• Residential Proxies
• Parsing
• Headless Browser