1) Having the TLS stack trust a "custom CA" provided by any number of debug tools (like mitmproxy or OWASP Zap) is relatively simple operation and can be done by anyone on any OS as long as you have admin/root. 2) There are a number of additional debug ways to decode the encryption from an application endpoint (e.g. https://wiki.wireshark.org/TLS and look at SSLKEYLOGFILE environment variable supported by most major TLS stacks and all major browser). Since MitmProxy2Swagger also supports HAR format ingest (e.g. https://github.com/alufers/mitmproxy2swagger#HAR ), this can easily be exported from any browser built-in debug tools (which also removes the encryption).

Modern TLS is great, but there are limitations on what it actually provides especially around the CA trust model. These mitm tools are not designed to take random traffic from the internet you intercepted, they require privileged endpoint access to enable specific debug features or configurations.

I think HAR export consumption lets you avoid the whole MITM part if we are talking about website API detection

This is only a problem if a client application has a server certificate pinned in source code. Otherwise, you can create a cert with a privacy CA and add it to a desktop OS trusted cert store.

Isn't that the point of mitmproxy? https://github.com/mitmproxy/mitmproxy

Option b could be more about breaking into some office that happens to contain those keys ;)

Wait, it works fine on production APIs, what it doesn't work on is "production clients". You're deliberately man-in-the-middling yourself.