diff options
| author | srdusr <[email protected]> | 2026-06-05 23:30:00 +0200 |
|---|---|---|
| committer | srdusr <[email protected]> | 2026-06-05 23:30:00 +0200 |
| commit | f3558f18ecabba983aba001468b06394471e6d8b (patch) | |
| tree | 49bc1c3843945e4d98a85e9129f34b4739a081b9 /cmd | |
| parent | ec42c6652eec8030b3710a804d02ff954d253720 (diff) | |
| download | mitmux-f3558f18ecabba983aba001468b06394471e6d8b.tar.gz mitmux-f3558f18ecabba983aba001468b06394471e6d8b.zip | |
Serve the CA certificate for browsers/mobile at http://mitmux.cert/
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.
Diffstat (limited to 'cmd')
0 files changed, 0 insertions, 0 deletions