diff options
Diffstat (limited to 'PLAN.md')
| -rw-r--r-- | PLAN.md | 40 |
1 files changed, 38 insertions, 2 deletions
@@ -167,8 +167,44 @@ to test against; only the command text itself (sourced from each platform's standard, documented tooling) is confirmed correct by inspection. -Still open from "worth considering": multiple proxy listeners and -upstream proxy chaining. Not started yet. +Shipped since: multiple proxy listeners and upstream proxy chaining - +the last two items from the original "worth considering" list. + +Multiple listeners: `-listen` takes a comma-separated address list +(`-listen "127.0.0.1:8080,127.0.0.1:8081"`); all bound addresses share +the same handler, history store, CA and rules - one logical proxy +reachable on more than one address/port, not several independent +proxies in one process. Every address is bound up front before any of +them start serving, so a bad address fails startup immediately instead +of leaving the daemon partially listening. + +Upstream proxy chaining: `-upstream-proxy host:port` (optional +`http://` prefix, stripped) routes every outbound connection through +another HTTP CONNECT proxy instead of dialing origins directly - +chaining mitmux into Burp, a corporate proxy, or any other +CONNECT-speaking proxy. SOCKS5 upstreams aren't implemented. For the +CONNECT/HTTPS path, chaining is transparent below the tunnel: once the +CONNECT handshake to the upstream proxy succeeds, TLS and the +request/response on top of it are identical to a direct connection, so +no other code needed to change. The plain-HTTP path is different: an +absolute-form request line ("GET http://host/path HTTP/1.1") has to be +sent to the upstream proxy instead of origin-form, so `roundTripH1` +gained a `proxyForm` parameter and `forward()` selects it based on +whether the request is plain HTTP and an upstream proxy is configured. + +Chaining into another intercepting/MITM proxy (including another +mitmuxd instance) will fail TLS verification unless that proxy's own CA +is separately trusted - expected, not a mitmux-specific gap: the +upstream MITM terminates and re-signs the connection with its own CA, +which mitmux's outbound TLS client (verifying against the system root +store) has no reason to trust. Confirmed live: chaining through a +genuine passthrough CONNECT proxy (tunnels raw bytes, no MITM) works +correctly for both plain HTTP and HTTPS; chaining through a second +mitmuxd instance correctly fails with a clear +"certificate signed by unknown authority" error recorded in history, +rather than hanging or crashing. + +This closes every item from the original "worth considering" list. Skipped deliberately (from the research, matches this tool's stated scope): active/passive vulnerability scanning, plugin marketplace, |