srdusr
aboutsummaryrefslogtreecommitdiffstats
path: root/internal/ipc
diff options
context:
space:
mode:
authorsrdusr <[email protected]>2026-05-16 11:49:00 +0200
committersrdusr <[email protected]>2026-05-16 11:49:00 +0200
commit1707cf827592bc3de7ea9c2805b7adea49b3cbc5 (patch)
treec61adf900307a76b557041c985b6a029393569c6 /internal/ipc
parentdd1621c0077e079e0693f16fe83f17d50338216e (diff)
downloadmitmux-1707cf827592bc3de7ea9c2805b7adea49b3cbc5.tar.gz
mitmux-1707cf827592bc3de7ea9c2805b7adea49b3cbc5.zip
Bound slow-loris connections and hung TLS handshakes
Neither the main proxy's http.Server nor the per-CONNECT-tunnel one had any timeouts - a client that opened a connection and either trickled request headers forever or, on the CONNECT/HTTPS path, completed the CONNECT handshake and then never sent a TLS ClientHello at all, held that connection and its goroutine open indefinitely. Confirmed live before the fix: partial headers with no terminator, and a completed CONNECT with no ClientHello, both held the connection open 10s+ with no sign of ever stopping. Low real-world risk at the 127.0.0.1 default, but multi-listener support means mitmuxd can now bind other interfaces, making this a real DoS-by-neglect surface rather than a purely theoretical one. clientHeaderTimeout (30s) is applied as ReadHeaderTimeout on both http.Server instances, and clientIdleTimeout (120s) as IdleTimeout on both - deliberately narrow, bounding only the pre-body header-parsing phase and idle time between keep-alive requests, not overall request duration, so a legitimately slow multi-minute upload/download still works exactly as before (verified: normal HTTP and HTTPS requests both still succeed after this change). The CONNECT-tunnel's TLS handshake specifically had no deadline at all before calling clientTLS.Handshake() - unlike the upstream leg, which already correctly calls conn.SetDeadline before its own round trip (see forward()). Now client.SetDeadline(...) is set with the same clientHeaderTimeout right before the handshake and cleared immediately after a successful one, so the request/response phase that follows doesn't inherit a stale handshake-only deadline. Verified live: a client sending a partial request line with no terminator was cut off at exactly 30.1s (previously indefinite); a client completing CONNECT and then never sending a ClientHello was cut off at exactly 30.1s (previously indefinite); normal HTTP and HTTPS requests through the proxy both still succeed afterward. go build/vet/gofmt/test/mod tidy all clean.
Diffstat (limited to 'internal/ipc')
0 files changed, 0 insertions, 0 deletions