Terminal-based intercepting HTTP proxy. https://srdusr.com/git/mitmux/atom?h=main 2026-06-05T21:30:00+00:00 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.