Preferences

Probably not, but mitmproxy is not a reverse proxy for any production purpose. It’s for running on your local machine and doing testing of either low-level protocol or web security stuff.

> mitmproxy is not a reverse proxy for any production purpose

At a startup I was working on a few years ago, I set up mitmproxy in dev and eventually if memory serves right I also sometimes enabled it in prod to debug things.

That being said, we did not have a lot of users. We had in fact very very few users at the time.

I’ve been patiently waiting for someone to write a howto that uses mitmproxy to transparently obtain acme certificates for any web servers that are behind it.

I’d totally pay a cloud provider to just do this and forward requests to my port 80 or 443 with self signed certificates.

Https+acme is already open to this attack vector, so why inconvenience myself by pretending it is not?

In our setup, TLS was already being terminated by Nginx or Caddy (I don’t remember which, but it was one of those two) sitting in front of another web server on the same host.

So inserting mitmproxy into the setup was just a case of putting it between the Nginx or Caddy that did TLS termination, and the web server that served the backend API. So to mitmproxy it was all plain HTTP traffic passing through it, locally on the same machine.

I bound the mitmweb web UI to the VPN interface so that us devs could connect to the dev server with VPN and then have access to the mitmweb web UI to inspect requests and responses.

This item has no comments currently.