About this project
Description from the program archive
The problem to solve is the implementation of a truly transparent mode on mitmproxy both in OSx and Linux (Issue #1261 unsolved since 2016).
I plan to adapt existing Rust API `start_os_proxy()` and `stop_os_proxy()`, that currently works only on Windows (trough packet_sources/windows.rs), to MacOS and Linux creating new crates `osx.rs` and `linux.rs` that will use properly osx-specific APIs.
In addition, I will also adapt the existing `--mode osproxy[:pid or executable name] `command-line option to allow users to specify a PID or executable name for the process to be intercepted by mitmproxy.
There are two possible approaches that can be taken:
1. The first is to use packet filter (pf) for macOS, initially trying to swallow all traffic coming from the same machine that is launching packet filter itself. The second step in this approach will be to use some gimmick to figure out which packets are actually coming from mitmproxy and filter them out to avoid loops, a possible solution for this could be to use nettop, launching it as a command directly from rust, the solution is not definitive and possible alternatives should be explored to understand the privilege issue as well. 2. A second approach is to use NEAppProxyProvider: an Apple proprietary framework that extends the functionality of the iOS and MacOS network stack. With NEAPP we can implement custom rules for filtering, routing, and modifying network traffic based on a variety of criteria, such as the app, the network protocol, the destination address, or the user identity. As it is a proprietary framework, we need to develop in Swift or objective-C and then transmit the information to the main mitmproxy stack.
How other proxies or VPN actually work: - WireGuard: wireguard has a apple version written in Swift, the adopted approach is the second one, it uses Apple Network Interfaces [ source ] - Squid: the same problem is currently unsolved - TinyProxy: it uses POSIX and no https transparent proxy