Error 502 when connecting to a site with self-signed certificates about docker-releases HOT 4 CLOSED

from docker-releases.

I'm using the latest image (id 52c914698058). I've tried

docker run --rm -it \
  -v /home/mitmproxy/.mitmproxy:/home/mitmproxy/.mitmproxy \
  -p 8888:8080 \
  mitmproxy/mitmproxy --set ssl_insecure

and

docker run --rm -it \
  -v /home/mitmproxy/.mitmproxy:/home/mitmproxy/.mitmproxy \
  -p 8888:8080 \
  mitmproxy/mitmproxy --insecure

but only get error /usr/local/bin/docker-entrypoint.sh: exec: line 13: --set: not found and /usr/local/bin/docker-entrypoint.sh: exec: line 13: --insecure: not found respectively.

BTW, what is the rationale behind verifying upstream certificates by default? For all use cases I could imagine not verifying by default would be the better choice. Especially for software testing and debugging in corporate networks where you normally have self-signed certificates, the current behaviour makes using the tool more difficult than it probably should be.

from docker-releases.

You want ... mitmproxy/mitmproxy mitmproxy --set ssl_insecure - the --set part overrides the default mitmproxy command. If youj think it'd be useful, I'd be happy to merge a PR that prepends "mitmproxy" if the command starts with a dash for cases like this.

BTW, what is the rationale behind verifying upstream certificates by default?

The rationale is that we want to be secure-by-default. It is a reasonable assumption that TLS certificates are verified, so we do not want anyone to have a bad surprise even if that is a bit annoying in many cases.

from docker-releases.

I had not tried this variant. ... mitmproxy --insecure works with the image mentioned above. Thanks for this!

If youj think it'd be useful, I'd be happy to merge a PR that prepends "mitmproxy" if the command starts with a dash for cases like this.

Ok, I will try.

But the real problem is the undocumented parameter required to successfully use the image with self-signed certificates (which is probably the most common case in software development). In my opinion this should be fixed in the README.md along with a hint to ... mitmproxy --help for further documentation .

The rationale is that we want to be secure-by-default.

I agree that security by default is an important principle in use cases where security is required.

But it's kind of funny for a tool whose sole purpose is to eavesdrop on encrypted communication. :)

from docker-releases.