Closed veita closed 6 years ago
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- .
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.
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.
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. :)
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
, andssl_insecure
, as well as aconfig.yaml
. But none of them seem to be documented in a way such that it could be used with the docker image.