srdusr
aboutsummaryrefslogtreecommitdiffstats
path: root/PLAN.md
diff options
context:
space:
mode:
Diffstat (limited to 'PLAN.md')
-rw-r--r--PLAN.md18
1 files changed, 16 insertions, 2 deletions
diff --git a/PLAN.md b/PLAN.md
index 16a8599..073c52e 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -190,7 +190,17 @@ 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-speaking proxy. A `socks5://[user:pass@]host:port` prefix
+routes through a SOCKS5 proxy instead (Tor, `ssh -D`, any other SOCKS5
+relay), via golang.org/x/net/proxy - already an indirect dependency
+through http2, so no new module. parseSOCKS5 is the single place that
+decides which kind of upstream a given UpstreamProxy string names;
+dialViaProxy (CONNECT/TLS path) and dialUpstreamPlain (plain-HTTP
+path) both check it first and fall through to the existing HTTP-proxy
+behavior otherwise. SOCKS5 is transport-level and protocol-agnostic -
+the tunnel it hands back behaves exactly like a direct connection to
+the target, so unlike HTTP-proxy chaining it needs no absolute-form
+request adjustment on the plain-HTTP path either. 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
@@ -210,7 +220,11 @@ 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.
+rather than hanging or crashing. SOCKS5 chaining verified the same
+way, live, against a real standalone SOCKS5 relay process (not an
+in-test mock): both a plain HTTP request and an HTTPS request through
+mitmux were confirmed - via the relay's own log, not just mitmux's
+success response - to have actually traversed it end to end.
This closes every item from the original "worth considering" list.