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.
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?