Terminal-based intercepting HTTP proxy. https://srdusr.com/git/mitmux/atom?h=main 2026-08-25T13:58:00+00:00 2026-08-25T13:58:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-08-25T13:58:00+00:00 urn:sha1:9e94bcbc939afd38b45f9ef42e1b1666fafd8d45 Writing PLUGINS.md as an authoritative external spec surfaced a real, pre-existing bug: store.Summary/Entry/EntryTag/WSMessage, rules.Rule, scope.Rule, and clientcert.Cert had no JSON struct tags at all, so Go's default marshaling serialized them PascalCase ("ID", "StartedAt") while the rest of the protocol (EntryDetail's own fields, every Request/Response wrapper field) uses snake_case. Confirmed live against a real daemon before touching anything: a raw socket "list" request came back with "ID"/"StartedAt"/"StatusCode", exactly the mismatch suspected. Nothing outside this repo's own Go code consumes this wire format yet, so this was a free, purely additive fix rather than something to work around - every affected struct now tags snake_case consistently. plugins/authcheck is the first real plugin: an Autorize-style authorization checker. For every proxied request carrying an Authorization or Cookie header, resends it with that header stripped and compares status classes - a resend that still succeeds where the original did too is a likely missing-function-level-access-control bug, tagged authcheck:bypass with structured detail. Deliberately speaks the wire protocol directly (its own local request/response/ summary/entryDetail structs mirroring the real ones field-for-field, not imported from internal/ipc) rather than taking the shortcut a Go plugin could - proof the documented protocol is actually sufficient on its own, since that's all a non-Go plugin author has to work with. Verified live end to end: a real daemon, a real Python origin with one endpoint that looks like it enforces auth but doesn't (vulnerable by design) and one that actually does (the control case) - the broken endpoint was correctly tagged, the secure one correctly left alone, no false positive, confirmed both via the stored tag data directly and visually in the TUI (tmux, real keystrokes): the Tags column badge, T's tag list, and the tag detail view's JSON-colorized data (ANSI-verified, not eyeballed) all showing the plugin's actual findings. 2026-08-04T07:35:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-08-04T07:35:00+00:00 urn:sha1:dde73a349a68f942a5bd89b27ac980d7973148e0 The prerequisite for the plugin ecosystem: any external process - any language - that can reach the control socket can now tag a history entry with a short string marker and an opaque JSON data blob, stored in a new entry_tags table rather than requiring the plugin stay connected for a later live round-trip. A plugin does its analysis once; the data it attaches is what a human reviewing the entry later actually sees. internal/ipc: new "tag_entry" request (id, tag_plugin, tag, tag_data) and EntryDetail.Tags (the full record for one entry, populated by "get"). internal/store: entry_tags table, EntryTag struct, AddEntryTag/ ListEntryTags, a comma-joined Tags aggregate added to List/Search via a correlated subquery (cheap enough per row that showing a tag badge in the history list needs no N+1 query), and a new tag: search filter alongside the existing status:/source:/flagged:. TUI: a Tags column in the history table (sortable via o/O, the eighth sort column), T from detail view opens a tag list (mirroring the WebSocket-messages view's table-then-detail-viewport pattern), enter on one shows its data - JSON-colorized via the existing jsoncolor.go if it parses as JSON, sanitized plain text otherwise. Also fixed a pre-existing gap while touching this: the WebSocket-messages view never got mouse wheel support when it shipped; wired both it and the new tags view up together. PLUGINS.md documents the wire protocol for non-Go plugin authors - connection model (subscribe vs request/response), the handful of request types a plugin actually needs, and the trust boundary (the socket has no auth beyond OS file permissions, same as the TUI's own access). PLAN.md records the architecture decision (external process over an embedded scripting language - mirrors the daemon/TUI split already in place, no interpreter to sandbox, any language) and groups ~20 researched Burp extensions/Pro features into what Phase 1 already covers (Autorize, Param Miner, Backslash Powered Scanner, Retire.js - all just subscribe+repeat+tag, no new capability needed), what needs a second protocol addition (JWT Editor, SAML Raider - live RPC to a specific connected plugin for interactive actions like re-signing), and what deserves its own separate project rather than a plugin (active vulnerability scanning, Collaborator/OAST, a crawler). Verified live end to end against a real daemon: a throwaway program simulating a real plugin tagged a captured entry with structured JWT data over the actual wire protocol; confirmed the tag badge, tag: search filter, and full tag record all round-tripped correctly through List/Search/Get. Confirmed in the TUI itself (tmux, real keystrokes): the Tags column renders, T opens the tag list, entering it shows the JSON data with real ANSI-verified syntax highlighting (not just eyeballed), and tag: search filtering works from the history list. 2026-06-30T12:52:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-06-30T12:52:00+00:00 urn:sha1:384573a2dc5e3b8e2a7bdfe2ce949f2c52ba2c52 The last "known limitation": a ws://wss:// connection stops being one-shot request/response the instant its 101 Switching Protocols lands, and forward()'s normal write-response-then-record flow has no way to represent that. Scoped to HTTP/1.1 client legs (HTTP/2 can't be hijacked for raw post-response access the way HTTP/1.1 can, and browsers open a dedicated HTTP/1.1 connection for WebSocket regardless of the surrounding page's protocol, so this isn't a real-world gap). internal/proxy/websocket.go decodes each RFC 6455 frame's opcode and payload for capture while relaying the exact same raw bytes it read unmodified - this is capture, not tampering, matching the rest of the codebase's raw-bytes-as-source-of-truth stance. One row per frame, not per reassembled message (fragmentation is rare in real-world WebSocket traffic; not worth buffering an unbounded number of pending fragments to handle it). forward() branches on a matching 101 into handleWebSocketUpgrade, which hijacks the client connection, relays the handshake response raw, records the upgrade request/response to history normally, then relays frames bidirectionally into a new ws_messages table - reachable from the TUI's detail view via `w`. Found and fixed two real bugs by actually driving a WebSocket connection through a running daemon, not by reading the code: stripHopByHop was deleting Connection/Upgrade from every outgoing request (correct for an ordinary request per RFC 7230, catastrophic for one asking to upgrade - every WebSocket attempt silently became a 426); and the relay tore the whole connection down the instant either side saw a close frame, before the peer's own close-frame reply could be relayed back, producing an abrupt EOF instead of a clean close. Verified live end to end on both paths a real client uses: ws:// (plain HTTP forward-proxying) against a Python websockets echo server, and wss:// (CONNECT-tunneled, TLS-intercepted) against the same server behind TLS - text, binary, and extended-length frames, plus a full close handshake with both directions' close frames present, confirmed via the actual bytes captured in ws_messages. 2026-06-24T12:40:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-06-24T12:40:00+00:00 urn:sha1:e01afcbf0de00af52fe90959ba77288679e3303d Extends -upstream-proxy to accept a socks5://[user:pass@]host:port prefix, using golang.org/x/net/proxy (already an indirect dependency via http2, so no new module) rather than hand-rolling the client side of RFC 1928/1929. 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 CONNECT behavior otherwise. SOCKS5 needs no absolute-form request adjustment on the plain-HTTP path the way HTTP-proxy chaining does, since it tunnels straight to the target rather than expecting a proxy-aware request. Tested against a real, minimal SOCKS5 server built for the test suite (exercises dialSOCKS5's actual wire behavior, not a mock of the client library), plus live against a real standalone SOCKS5 relay process: both a plain HTTP and an HTTPS request through mitmux were confirmed, via the relay's own log, to have actually traversed it. 2026-06-16T20:57:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-06-16T20:57:00+00:00 urn:sha1:23c8ab359c2108654d57176e233d2c099b398f31 Adds internal/clientcert: a cert/key pair matched to hosts by the same substring-or-regex pattern model as scope.Rule, so mitmux can present a client certificate on an upstream TLS handshake that requires one - the previous behavior was a hard handshake failure with no way to authenticate. Wired into both places mitmux dials an https:// upstream over its own TLS client connection: proxy.go's handleConnect (live proxied traffic) and repeat.go's dialForRepeat (Repeater/Intruder resends), both through a new Server.clientCertFor(host) helper. Stored in a new client_certs table, mirroring the existing scope_rules persistence pattern. The TUI (`t` from history) is add-only like scope, for the same reason: delete and re-add covers changing anything, and it's a rarely-touched, low-cardinality list. The add form takes cert/key file paths and reads them once at save time - PEM content, not the path, is what's stored and later presented, so a cert keeps working even if the original file moves afterward. Verified live against a real mutual-TLS-requiring origin server: without a matching cert the handshake correctly fails; with one configured, the origin receives it and the request succeeds; toggling it off reproduces the failure, confirming the enable/disable path works end to end. 2026-06-10T22:37:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-06-10T22:37:00+00:00 urn:sha1:6114567258bcad0517a0d881168711aaacdba5d5 Generalizes Intrude beyond Sniper to all four of Burp's attack modes (proxy.AttackMode). Sniper and Battering ram only ever need one shared payload set; Pitchfork and Cluster bomb are inherently per-position, so they take one payload set per §marked§ position instead. Request-set generation (intrudeValues) is pure and side-effect free, so the total request count is validated against the existing 1000 cap before anything is dispatched - Cluster bomb's product is checked incrementally, one payload set at a time, so a pathological product bails out before ever trying to enumerate it. This also makes the combinatorics unit-testable without a live target. IntrudeResultMsg now reports Values (one substitution per marked position, in order) instead of a single Position/Payload pair, since three of the four modes touch multiple positions per request. TUI: `a` cycles the attack mode. Pitchfork/Cluster bomb reuse the existing single Payloads pane rather than a new multi-widget editor - sets are separated by a `---` delimiter line, in position order. Verified live against a real daemon: all four modes produce the expected substitution values and request counts, and pitchfork correctly rejects a payload-set count that doesn't match the template's marked positions. 2026-06-09T13:46:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-06-09T13:46:00+00:00 urn:sha1:a2362fc08c31b23fb971279f8b160555123ad2f6 Extends match-and-replace rules to request/response bodies, not just headers. A body rule materializes the body into memory (bounded by the same maxCaptureBytes cap as history capture) instead of streaming it straight through - the opposite of the normal path, so it's only paid when a body rule is actually configured. A body over the cap passes through byte-exact and unmodified rather than being partially rewritten. Response Content-Length is recomputed explicitly when a rule changes body length: unlike http.Request.Write, http.ResponseWriter doesn't derive it from resp.ContentLength on its own, so a stale header would otherwise corrupt response framing for the client. The history audit trail still shows the original, pre-rule bytes on both legs; only the wire traffic reflects the rewrite. Verified live against a real daemon: origin receives the rewritten request body, client receives the rewritten response body with correct Content-Length, and history keeps the unmodified bytes. Adds a Part selector (header/body) to the Rules add/edit form and table in the TUI. 2026-06-05T21:30:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-06-05T21:30:00+00:00 urn:sha1:f3558f18ecabba983aba001468b06394471e6d8b Browser/mobile setup previously meant "find ca.pem on disk and import it manually" - awkward on a phone or tablet especially, which has no convenient way to get a file onto the device at all short of emailing it to yourself or similar. Any client already configured to proxy through mitmux can now just visit http://mitmux.cert/ and get the cert directly, with Content-Type: application/x-x509-ca-cert triggering iOS/Android's native "install this certificate" prompt. Same idea as mitmproxy's own http://mitm.it/, arrived at independently rather than reusing their domain - mitmux.cert isn't a registered TLD, so it can never collide with a real site someone meant to visit. Deliberately HTTP-only: fetching it over HTTPS would require the client to already trust mitmux's CA to MITM that very connection, the exact chicken-and-egg problem this exists to solve, so it's not attempted on the CONNECT/TLS path at all. internal/proxy/proxy.go: isCertDownloadHost matches the hostname case-insensitively regardless of port; handleHTTP checks it before ever dialing upstream and answers directly via serveCACert, using the CA's own CertPEM bytes already held in memory. Short-circuits before record() is ever reached, so the download itself never pollutes history. Verified live: fetched http://mitmux.cert/ through a real running proxy and confirmed the downloaded bytes are byte-identical to the actual ca.pem on disk (diff, not just "the request succeeded"); confirmed a request with an explicit port and a path still matches; confirmed normal proxying to an unrelated host is completely unaffected; confirmed via direct SQLite query that the cert-download requests never appear in history while a normal request in the same session does. Also documented (no code needed): any standard proxy-switcher extension (FoxyProxy, etc.) or a phone/tablet's own Wi-Fi proxy setting already works with mitmux exactly like it would with Burp/ZAP/Caido, since it's a normal forward proxy speaking the standard protocol. This was true before but never actually spelled out in the README for the phone/ tablet case specifically, which is a real, common daily workflow. go build/vet/gofmt/test/mod tidy all clean. 2026-05-25T21:13:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-05-25T21:13:00+00:00 urn:sha1:dc059db6db67abad249fa153593a89a45fa37486 Neither binary had a -version flag - a basic expectation for any CLI tool, and useful for anyone reporting a bug ("which build is this"). internal/version holds Version/Commit/Date, set via -ldflags "-X mitmux/internal/version.X=..." at build time and defaulting to "dev" for a plain `go build` with no ldflags, so -version is never blank or misleading about whether a given binary is a tagged release or a local build. Both mitmux and mitmuxd gained a -version flag that prints it and exits. Makefile: `make build` (both binaries for the current platform, version info from `git describe`), `make test` (the same build/vet/gofmt/test checks expected before every commit here), `make install` (a thin wrapper over `go install`, respecting GOBIN/GOPATH as usual - not reimplementing Go's own path resolution), `make release` (cross-compiles both binaries for linux/darwin/windows/freebsd, amd64+arm64 where it makes sense, into dist/). Every target is CGO_ENABLED=0: modernc.org/sqlite is pure Go, so no C toolchain is needed anywhere, cross-compiling included - this was already true before this commit, just not verified or made easy to use. Verified live, every target actually run rather than just written: `make build` produces working binaries with version info correctly picked up from git (confirmed against a real -version invocation, both the "dev" default and an ldflags-injected release-style version string); `make test` runs clean; `make release` was run for real and produced 6 platform/arch binaries, each confirmed with `file` to be a genuinely correctly-formatted executable for its target (Mach-O for both macOS architectures, PE32+ for Windows, ELF for both Linux architectures and FreeBSD) - not just "the command exited zero." `make install`'s correctness rests on `go install` itself, Go's own well-tested mechanism; deliberately not run for real here since it writes into the real GOPATH/bin outside this repo, unprompted. README gained an honest Platforms section: Linux is what's actually been run and verified throughout this project's development; macOS, Windows, and FreeBSD cross-compile cleanly and pass go vet, and the code has nothing Linux-specific in it (CA/history storage already used Go's own cross-platform os.UserConfigDir, not a hardcoded XDG path - also fixed the README's install-directory example, which had been Linux-only text), but they haven't run on real hardware, so they're documented as "should work, not yet verified" rather than a claim this session can't actually back up. Also flagged a concrete, real gotcha: macOS's shorter Unix domain socket path limit combined with the deeper ~/Library/Application Support default control-socket location could matter for a long username, with the existing -socket flag as the workaround. go build/vet/gofmt/test/mod tidy all clean. 2026-05-24T07:50:00+00:00 srdusr 99972264+srdusr@users.noreply.github.com 2026-05-24T07:50:00+00:00 urn:sha1:0d1ce88962fe31ce1d204634e6ea10998a02827a Closes the interop loop HAR export opened - traffic can now move both directions between mitmux and any other HAR-producing tool (browser DevTools, Burp, Postman), not just out. cmd/mitmux/har.go: rawRequestFromHAR/rawResponseFromHAR reconstruct HTTP/1.1 wire bytes from HAR's structured fields - the mirror image of harEntryFromDetail on the export side. Deliberately tolerant of a HAR file that didn't come from mitmux at all: lowercase header names, "HTTP/2" in httpVersion, missing optional fields like postData, a redirectURL nobody filled in. Content-Encoding and Transfer-Encoding headers are stripped from the reconstructed response before writing it - HAR's content.text is already decoded per spec, so re-emitting those headers would describe framing the body no longer has and break any client that tried to decode it again - and a Content-Length is computed if the HAR didn't carry a consistent one. importEntriesFromHAR converts a whole document, skipping (not failing on) any entry that fails to convert, same reasoning as export's own skip-and-continue for a malformed capture. Imported entries are always request_exact=false/response_exact=false: reconstructed from structured HAR fields, the same situation an HTTP/2 capture is already in, never claiming to be the literal bytes that were actually on the wire for the original request. internal/ipc: ImportEntry (the slim shape the client sends - the daemon just stores what it's given, all HAR parsing happens client-side) and an "import" request type; Client.Import returns how many entries were actually inserted, a per-entry store failure is skipped rather than aborting the batch. Server-side, imported entries are tagged source="import" so source:import finds them in search, same as source:repeater/source:intruder already work. TUI: 'I' from the history list prompts for a HAR path (same modal pattern as export, in reverse - reading instead of writing), then reloads the list and status once the import completes. Verified live: exported real captured traffic to HAR, cleared history entirely, imported the same file back and got both entries with correct content (byte-different after the round trip - headers get reordered/reformatted - but semantically identical, correctly labeled "reconstructed" rather than falsely "exact"); hand-built a HAR mimicking a real Chrome DevTools export (lowercase headers, HTTP/2, a base64- encoded binary PNG body, several optional fields omitted) and confirmed it imports cleanly with the binary body decoded correctly (PNG magic bytes verified byte-for-byte); confirmed a missing file and invalid JSON both fail with a clear error and no crash, history left untouched. go build/vet/gofmt/test/mod tidy all clean.