Error 502 when connecting to a site with self-signed certificates

[veita]

When connecting to a site with a self-signed certificate mitmproxy issues a 502 Bad Gateway error. The connection cannot be established.

A web search suggested parameters and configuration options like --verify-upstream-cert, --insecure, and ssl_insecure, as well as a config.yaml. But none of them seem to be documented in a way such that it could be used with the docker image.

[mhils]

Which docker image are you using? If you are using "latest" (soon-to-be 3.0), --set ssl_insecure is the correct way. That's not really documented yet as 3.0 is not out. If you are using <3.0, --insecure should work.

On Tue, 26 Dec 2017, 01:05 Alexander Veit, notifications@github.com wrote:

When connecting to a site with a self-signed certificate mitmproxy issues a 502 Bad Gateway error. The connection cannot be established.

A web search suggested parameters and configuration options like --verify-upstream-cert, --insecure, and ssl_insecure, as well as a config.yaml. But none of them seem to be documented in a way such that it could be used with the docker image.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mitmproxy/docker-releases/issues/21, or mute the thread https://github.com/notifications/unsubscribe-auth/AA-NPtVrbLxASR5q3TRqppEEhF2_uZb7ks5tEDhFgaJpZM4RMa1- .

[veita]

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.

[mhils]

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.

[veita]

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. :)