diff options
| author | srdusr <[email protected]> | 2026-05-16 11:49:00 +0200 |
|---|---|---|
| committer | srdusr <[email protected]> | 2026-05-16 11:49:00 +0200 |
| commit | 1707cf827592bc3de7ea9c2805b7adea49b3cbc5 (patch) | |
| tree | c61adf900307a76b557041c985b6a029393569c6 /internal/store | |
| parent | dd1621c0077e079e0693f16fe83f17d50338216e (diff) | |
| download | mitmux-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/store')
0 files changed, 0 insertions, 0 deletions