diff options
| author | srdusr <[email protected]> | 2026-04-02 20:55:00 +0200 |
|---|---|---|
| committer | srdusr <[email protected]> | 2026-04-02 20:55:00 +0200 |
| commit | f77a9570e973dda7247c653754e62d5a9a895658 (patch) | |
| tree | 00bd28c9f76e3ed6ea5bc1e0663acf2716e98128 /PLAN.md | |
| parent | b11e60dcccc836bf67b3720930600f7112f624dc (diff) | |
| download | mitmux-f77a9570e973dda7247c653754e62d5a9a895658.tar.gz mitmux-f77a9570e973dda7247c653754e62d5a9a895658.zip | |
Per-OS CA install instructions (mitmuxd -install-ca)
Trusting the CA was previously "import ca.pem into whatever's making
the requests" with no further help. -install-ca generates the CA if
needed and prints copy-pasteable, OS-specific steps, then exits without
starting the proxy.
Deliberately instructions-only, never auto-executing anything: Linux
trust-store tooling varies enough across distros (trust vs
update-ca-trust vs update-ca-certificates) that guessing wrong and
running the wrong command unattended is worse than asking, and
installing a root CA is a system-wide trust change affecting every TLS
connection on the machine, not just mitmux's own traffic - running the
printed command themselves keeps the user in control of that.
internal/ca/install.go: InstallInstructions(goos, caPath) dispatches by
OS. Linux detects trust (p11-kit - Arch, also on Fedora) /
update-ca-trust (RHEL/Fedora/CentOS) / update-ca-certificates
(Debian/Ubuntu/Gentoo) via PATH lookup and prints whichever is actually
present, plus separate certutil/NSS instructions for Firefox/Chrome's
own certificate store (which doesn't always follow the system trust
store on Linux). macOS (security add-trusted-cert) and Windows
(certutil -addstore / Import-Certificate) are implemented from each
platform's standard documented tooling but not verified live - no
macOS/Windows machine was available to test against, unlike Linux.
commandExists is a package var (not a direct exec.LookPath call) so
tests can fake which tools are "present" and exercise every detection
branch deterministically, independent of what's actually installed on
whatever machine runs `go test`.
Verified live: built mitmuxd, ran -install-ca against a throwaway CA
dir on this (Arch Linux) machine - correctly detected `trust` and
`certutil` on PATH and printed accurate commands, confirmed the CA
files were actually generated, confirmed no proxy/daemon process was
left running (exits immediately after printing), and confirmed running
it a second time reuses the existing CA (identical file hash) rather
than regenerating.
go build/vet/gofmt/test/mod tidy all clean.
Diffstat (limited to 'PLAN.md')
| -rw-r--r-- | PLAN.md | 25 |
1 files changed, 23 insertions, 2 deletions
@@ -146,8 +146,29 @@ configured once before `ctrl+r` starts an attack and apply for that run only - matching Burp, which doesn't retroactively re-grep already-fired requests if you change the options mid-attack. -Still open from "worth considering": CA install UX per OS, multiple -proxy listeners and upstream proxy chaining. Neither is started yet. +Shipped since: CA install UX per OS (`mitmuxd -install-ca`) - generates +the CA if needed, prints copy-pasteable install steps for the detected +platform, and exits without starting the proxy. Deliberately +instructions-only, never auto-executing: trust-store tooling varies +enough across Linux distros that guessing wrong and running the wrong +command unattended is worse than asking, and installing a root CA is a +system-wide trust change that affects every TLS connection on the +machine, not just mitmux's own traffic - the user running the printed +command themselves keeps them in control of that. On Linux, detects +`trust` (p11-kit - Arch, and Fedora also ships it)/`update-ca-trust` +(RHEL/Fedora/CentOS)/`update-ca-certificates` (Debian/Ubuntu/Gentoo) +via PATH lookup and picks whichever is actually present, plus separate +`certutil` (NSS) instructions for Firefox/Chrome's own certificate +store, which doesn't always follow the system trust store on Linux. +macOS (`security add-trusted-cert`) and Windows (`certutil -addstore` / +`Import-Certificate`) instructions are implemented but, unlike the +Linux path, not verified live - no macOS/Windows machine was available +to test against; only the command text itself (sourced from each +platform's standard, documented tooling) is confirmed correct by +inspection. + +Still open from "worth considering": multiple proxy listeners and +upstream proxy chaining. Not started yet. Skipped deliberately (from the research, matches this tool's stated scope): active/passive vulnerability scanning, plugin marketplace, |