upstream:https failed

[ItsBean]

Problem Description

in two proxy mode, if I set upstream:http, it works. If I set upstream:https, the web will return bad gateway.

Steps to reproduce the behavior:

1. open mitmweb
2. set mode in option to upstream:https://xxx:xxx
3. visit any website, it returns bad gateway error or error_proxy_connection

System Information

Mitmproxy: 10.3.0 binary
Python: 3.12.3
OpenSSL: OpenSSL 3.2.1 30 Jan 2024
Platform: Linux-6.5.0-35-generic-x86_64-with-glibc2.35

[mhils]

Is your upstream proxy an regular HTTP proxy, or is it an HTTP proxy with TLS termination in front (i.e. a "Secure Web Proxy")?

[ItsBean]

the upstream proxy is an vpn.

[mhils]

I think everything is working as expected here. If upstream:http://... works but upstream:https://... doesn't, then your proxy server is a normal HTTP proxy and not a Secure Web Proxy.

[ItsBean]

The problem is that Charles works well with HTTPS upstream, and if you don't mind, I can provide you with the VPN link for testing.

[mhils]

You will still be able to access HTTPS sites through the HTTP proxy. upstream:http://... indicates that the proxy protocol between mitmproxy and upstream proxy is plain HTTP, but you can still have HTTPS inside of a CONNECT tunnel (which should happen all automatically).

[ItsBean]

the problem is that mitmproxy will send the decrypted https pkg to the vpn server.

[ItsBean]

If I decrypt a https pkg, then the pkg will be sent to the vpn through http connection, which means that the vpn server can also see the decrypted content.

[mhils]

I don't think I follow what you are saying.

[ItsBean]

Let me try using Charles as the second proxy, and mitmproxy as the first one, to see if Charles can see the decrypted content if the HTTPS is decrypted by mitmproxy.

[ItsBean]

Dear author:
I found that both charles and mitmproxy failed processing data from chat app, will there be any update in the future to support getting data from popular chat app like wechat, dingtalk ...