HTTP interception & proxies

An interception proxy sits between client and server and makes application traffic observable and, when configured, mutable. That power is useful for controlled fault injection and replay but introduces certificate, privacy and state-change risks.

Client → proxy trust/certificate → capture/filter → inspect → optional rule/replay → server
             ↘ always know whether traffic is only observed or actively changed

The interception-proxy workflow and local certificates

For HTTPS inspection, an interception proxy typically terminates TLS locally and establishes a second TLS connection to the server, which requires the client to trust the proxy's local certificate authority.

Practical use: Use a dedicated test profile/device, install trust only where authorized, capture the minimum traffic needed, then remove test certificates after the investigation.

Caveat: Installing a proxy CA changes the device trust model. Never normalize leaving it installed on personal or production devices.

Fiddler Everywhere: capturing, filtering and inspecting traffic

Current Fiddler Everywhere is the maintained cross-platform Telerik proxy product. Its capture modes and filters help narrow HTTP(S) traffic to the process, host or sessions relevant to the investigation.

Practical use: Name the capture mode and filters in defect evidence so another engineer can recreate the view. Start narrow when the machine handles sensitive or noisy traffic.

Caveat: Capturing everything increases privacy exposure and makes diagnosis harder. Broad capture should be deliberate.

Fiddler rules, request modification and replay

Proxy rules and replay/composer workflows let a tester change requests or responses and resend traffic. This is useful for negative testing, dependency simulation and hypothesis testing.

Practical use: Label the session as modified, keep the original capture, and use non-production targets for state-changing replays unless explicit authorization says otherwise.

Caveat: Replaying a GET may still have side effects in a badly designed system; method semantics do not guarantee implementation safety.

Charles and mitmproxy as alternative proxy workflows

Charles provides a GUI proxy workflow widely used for desktop/mobile debugging; mitmproxy offers interactive and scriptable proxying. The core concepts—routing, trust, filtering, inspection and modification—transfer between them.

Practical use: Choose based on platform, team workflow and need for scripting. Document device proxy address, certificate setup and cleanup so mobile captures are reproducible.

Caveat: A tool comparison should not become three parallel courses. Learn one deeply enough to understand the model, then map alternatives.

Certificate pinning limits and privacy/security boundaries

Certificate pinning or custom trust logic can prevent ordinary MITM-style inspection even when the proxy CA is installed. That is an application security property, not an error to bypass casually.

Practical use: If inspection is legitimately required, use an authorized test build, documented debug configuration or application-provided diagnostics instead of weakening production controls.

Caveat: Captured traffic may contain authentication tokens, personal data and business secrets. Apply least-capture and redaction rules.

Summary

• This chapter covers 5 required concepts while keeping tool/formula details tied to a practical decision.
• Definitions, scope, assumptions and caveats matter more than a number or a tool name by itself.
• Claims that depend on a standard or product are grounded in the source registry below.