WireGuard mode does not help with interception, it helps with getting traffic into mitmproxy. Put differently, it's a user-friendly alternative to
1. configuring an explicit HTTP proxy in your system settings, or
2. fiddling with iptables on your router and/or your mitmproxy device.
The downside of 1) is that it does not work for UDP-based traffic such as DNS and can often be easily bypassed by applications. The downside of 2) is that it's generally fiddly and does not work very well for users with consumer routers (no iptables). In all cases you still need to install a trusted mitmproxy CA for TLS interception, that part does not change with WireGuard mode. :)
Sorry, I'm not following. With e.g. HTTPS traffic all I have to do is make sure that the browser sends all its traffic through 127.0.0.1:8080 and trusts mitmproxy's certificate. In that case, mitmproxy will show me the plaintext traffic.
Now, let's say I've set up WireGuard with three peers, i.e. each of these peer's public key appears in my WireGuard config along with an IP address. Now I start sending traffic to one of these IP addresses which WG would normally encrypt and then route directly to the peer in question. How can mitmproxy's WG mode help me here with "getting [the encrypted] traffic into mitmproxy", as you say, and reading the plaintext?
Suppose you have an Android device for which you want to see all traffic. You could configure an HTTP proxy in your system settings, but this does not capture any UDP-based protocols. Additionally, apps may choose to ignore the proxy settings and it's hard to tell if they do. To overcome these shortcomings, we now have WireGuard mode: Mitmproxy spawns a WireGuard server on startup (instead of an HTTP proxy listener). Now you don't set a proxy on your device, but you configure your device to use WireGuard with a config that sends all traffic to mitmproxy. mitmproxy then transparently intercepts all requests that are coming through that WireGuard tunnel (the device still needs to trust the mitmproxy CA). Put differently, instead of using an explicit proxy configuration or something like iptables to route packets to mitmproxy, you use a VPN (WireGuard). The benefits are:
- You can intercept/modify UDP, in particular DNS.
- You avoid the "apps ignore proxy settings" problem.
- On Android specifically, the WireGuard app allows you to only proxy specific apps (not possible with a global proxy config)
Thank you, it now makes a lot of sense. My apologies, I thought this was about reading WireGuard traffic, not about using WireGuard to replace the usual HTTP proxy.
Comments
WireGuard mode does not help with interception, it helps with getting traffic into mitmproxy. Put differently, it's a user-friendly alternative to
The downside of 1) is that it does not work for UDP-based traffic such as DNS and can often be easily bypassed by applications. The downside of 2) is that it's generally fiddly and does not work very well for users with consumer routers (no iptables). In all cases you still need to install a trusted mitmproxy CA for TLS interception, that part does not change with WireGuard mode. :)Sorry, I'm not following. With e.g. HTTPS traffic all I have to do is make sure that the browser sends all its traffic through 127.0.0.1:8080 and trusts mitmproxy's certificate. In that case, mitmproxy will show me the plaintext traffic.
Now, let's say I've set up WireGuard with three peers, i.e. each of these peer's public key appears in my WireGuard config along with an IP address. Now I start sending traffic to one of these IP addresses which WG would normally encrypt and then route directly to the peer in question. How can mitmproxy's WG mode help me here with "getting [the encrypted] traffic into mitmproxy", as you say, and reading the plaintext?
Suppose you have an Android device for which you want to see all traffic. You could configure an HTTP proxy in your system settings, but this does not capture any UDP-based protocols. Additionally, apps may choose to ignore the proxy settings and it's hard to tell if they do. To overcome these shortcomings, we now have WireGuard mode: Mitmproxy spawns a WireGuard server on startup (instead of an HTTP proxy listener). Now you don't set a proxy on your device, but you configure your device to use WireGuard with a config that sends all traffic to mitmproxy. mitmproxy then transparently intercepts all requests that are coming through that WireGuard tunnel (the device still needs to trust the mitmproxy CA). Put differently, instead of using an explicit proxy configuration or something like iptables to route packets to mitmproxy, you use a VPN (WireGuard). The benefits are:
Does that make more sense now? We also have a bit more documentation at https://docs.mitmproxy.org/stable/concepts-modes/#wireguard-....Thank you, it now makes a lot of sense. My apologies, I thought this was about reading WireGuard traffic, not about using WireGuard to replace the usual HTTP proxy.