Some mobile apps (e.g. YouTube) stop working when using mitmproxy – how to allow encrypted pass-through like Charles?

[pinkal26022005]

Hello mitmproxy team,

I’m using mitmproxy to capture network traffic for testing purposes.
I noticed that some mobile apps (for example YouTube and other Google apps) stop working when mitmproxy is enabled.

In Charles Proxy, these apps still work because the traffic is forwarded encrypted (no SSL decryption), so the app is not blocked even though APIs are not visible.

I understand this is related to SSL pinning and QUIC/HTTP3, and that decrypting this traffic is not possible.
My question is:

What is the recommended way in mitmproxy to automatically allow encrypted pass-through (tunnel mode) for such apps/domains, without breaking the app, similar to Charles’ behavior?

Any best practices, flags, or examples would be very helpful.

Thank you!

[Prinzhorn]

See https://docs.mitmproxy.org/stable/concepts/options/#ignore_hosts

Ignore host and forward all traffic without processing it. In transparent mode, it is recommended to use an IP address (range), not the hostname. In regular mode, only SSL traffic is ignored and the hostname should be used. The supplied value is interpreted as a regular expression and matched on the ip or the hostname.

[yoshimo]

Wouldn't it make sense to have this automatically trigger for hosts that can't be decrypted instead of a manually curated list?

[Prinzhorn]

Not sure what heuristic Charles has implemented, how do you decide that? Wouldn't that always require at least a single failed attempt to then switch to ignoring that host? You can likely do that with an addon.

You can intercept stuff like YouTube, look into Frida to remove certificate pinning.

[Prinzhorn]

From Charles FAQ

Charles 3.4 changes the default behaviour of SSL in Charles to opt-in rather than opt-out. You must now opt-in each site you wish to enable for SSL proxying.

So that's how, they don't 😃

[yoshimo]

@Prinzhorn it is independent from charles , mitmproxy could check for failed handshakes and skip intercepting the domain:ip combination for the rest of the current session and fallback to pure forwarding of the encrypted packages.
So less maintenance needed and still useful.

[Prinzhorn]

If something like this were to be implemented, it would not be the default behavior. And this sounds like too much magic to me. We want errors to be loud, visible and explicit. It would be confusing to get an error first and then not see it again in the current session.

What exactly is your use case, that you want that behavior? You can also check out wireguard mode and then only select the apps you need to inspect in the wireguard app.

[pinkal26022005]

@Prinzhorn Thanks for your feedback. I appreciate it.

[pinkal26022005]

@Prinzhorn I’m facing another issue. I’ve connected 5–10 devices to the server, and on some devices the internet stops working after a while. When I disable the proxy, the internet works fine again.

[Prinzhorn]

I’m facing another issue. I’ve connected 5–10 devices to the server, and on some devices the internet stops working after a while. When I disable the proxy, the internet works fine again.

If you believe this is a bug, then open a new issue with steps to reproduce. But since you didn't mention any exception or error messages, I doubt you can track this down. But you can still open a discussion and provide as much info as you can.

[pinkal26022005]

I’m facing another issue. I’ve connected 5–10 devices to the server, and on some devices the internet stops working after a while. When I disable the proxy, the internet works fine again.

If you believe this is a bug, then open a new issue with steps to reproduce. But since you didn't mention any exception or error messages, I doubt you can track this down. But you can still open a discussion and provide as much info as you can.

Sure, thanks