mhils

mitmproxy would not really be helpful for what you describe, this sounds like she is confusing it with some other software/stalkerware.

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. :)

I don't think I'm aware of any. If possible I would recommend using a browser extension like uBlock Origin instead, being in the browser context makes adblocking more efficient. (I realize not every client is a browser, I simply don't have good recommendations for this then)

We can definitely intercept DTLS now, there are no specific contentviews (pretty-printers) for WebRTC yet. I don't know how much of a binary protocol WebRTC is that would make pretty-printing necessary. :)

The recommended way to install mitmproxy on Linux is to download new standalone binaries. They are self-contained and can just be dropped into /usr/local/bin. If you want some way to update automatically, use our Docker images, install via pipx (https://docs.mitmproxy.org/stable/overview-installation/#ins...), or (for Windows users) use the Microsoft Store.

> also is there a way to configure the IDE that pops up when I go to edit path?

You can set $MITMPROXY_EDITOR or more generally $EDITOR. :)

Hard to say without more details. Once you reach that limited connectivity state, do you see anything that stands out in the mitmproxy event log? Feel free to open a thread at https://github.com/mitmproxy/mitmproxy/discussions and I'm happy to help a bit more! Also it would be interesting to know if you observe the same thing with our new WireGuard mode. :)

I haven't played around with this myself yet, but basically:

  1. Configure your device to use mitmproxy.
  2. Visit our magic mitm.it domain on the device.
  3. Click on "Show Instructions" for Android.

Are you looking for mitmproxy-on-linux maintainers, or Linux kernel maintainers? You have found the former I suppose, but I'm the wrong person to ask for the latter. :)

If you can run mitmproxy on another device, then our new WireGuard mode does exactly fix that problem. At least as long as WireGuard is able to capture all traffic. :)

Transparent same-device interception is something where we still need to do some work on. I've started some work for Windows (https://github.com/mitmproxy/mitmproxy/pull/5543), but the top priority is HTTP/3 first. :)

mitmproxy dev here, happy to answer questions once I'm back home later! :)

Yes, the UDP parts are preparation for QUIC/HTTP/3! We will be there soon. :-)

Thank you! :) You are absolutely right on pre-commit hooks. My experience with FOSS projects is that it's quite hard to get contributors to follow your style guides and/or opt-in to pre-commit hooks. In this case it's much easier to have things auto-fixed than telling people to please install your specific pre-commit framework. It's different if you have a well-defined team with onboarding procedures.

FWIW, you can keep using pre-commit hooks and then have autofix.ci enforce them: https://autofix.ci/setup#pre-commit. For git purists, there's always the option to squash when merging. :)

Author here, happy to answer any questions! :)

Anecdata: Copilot has been net-negative for me when writing Python, but the Rust completions are fantastic.

Not yet, but you might be lucky soon. We have an RSS feed on mitmproxy.org and a Twitter account. :-)

AdTech increasingly uses CNAME cloaking-style tricks to evade DNS blocking. Some of those tricks are detectable, but DNS blocking will inevitably fail once ads are served from the first party domain. It's still rare, but simple CNAME cloaks specifically have seen an uptick in the last few years.

I wouldn't write it off - one possible trick here is to also MITM the DoH/DoQ server and disable ECH by removing the relevant records from the DNS response. We've just added DNS support to mitmproxy and this is a natural follow-up. :)

This approach is a natural escalation step as DNS-based blocking is getting increasingly difficult. But it's not without its drawbacks. For example, browsers tend to have by far the best TLS implementations. By MITMing yourself, you essentially trust the proxy's TLS implementation instead, which will receive much less scrutiny. There's a lot of precedent for TLS vulnerabilities introduced by middleboxes. If browser extensions are possible they should be preferred. But the author does have a point that this can't be taken for granted anymore!

FWIW, if your PyInstaller experience is from several years ago, I'd strongly recommend checking it out again. I used to dread its updates because they usually broke something, but everything has been super smooth in the last 1-2 years. :)

mitmproxy dev here, very awesome! :) This seems to be particularly useful to quickly generate clients for reverse-engineered APIs.

Technically possible, but I don't think that works with code signing (more accurately: every developer using it needs to re-sign).

I think there are other, more effective, mitigations in place against the threats you are describing. First, there's no automated way to install CAs on Android. Users must do this step manually (the articles you linked are about Windows). Second, if you have installed a user-added CA, you get a prominent and permanent notification – non-dismissable, reappears after reboot – that your network traffic may be monitored. All this stops the "secretly-added CA" threat.

Finally, the current implementation is not effective at protecting against country-level MITM. Attempts at country-level MITM have been thwarted by browser updates to blacklist the respective CA certs, the same can be done on Android.

I agree those are legitimate threats that need to be addressed, but there are better ways to do so, which don't come with the convenient side effect of killing privacy research.

Enforcing CT is good, but that doesn't excuse the treatment of user-added CAs. On all platforms but Android, user-added CAs are considered particularly trustworthy. For example, Chrome Desktop, Firefox, and IE did not enforce HPKP if they encountered a cert from a user-added CA. Why does Android do the opposite? I don't see the threat model they are addressing.

We (mitmproxy) have repeatedly tried to get an answer to this from the Android folks (e.g. here: https://github.com/mitmproxy/mitmproxy/issues/2054#issuecomm...). It very much feels like they just want to kill uncomfortable privacy research.

Thank you - that explanation makes sense, apology accepted. :)

We've been one of 666 repos, and I'm not too happy of having our repo used as advertising space. Some thoughts:

- I'm happy to receive fix-a-typo PRs from human users. In this case the other side demonstrated that they care by putting in a bit of manual effort, and a small PR often paves the way towards larger contributions. I also know that open source beginners get really excited about their first small contributions, and I'm honestly happy to support that.

- In contrast, the marginal effort for bot PRs is ~0. It's very easy to generate a small amount of work for a lot of people, and the nice side effect is that the bot's platform is advertised everywhere. As a maintainer, I have never given consent to this and I have no choice to opt out.

We are very happy users of some GitHub bots, but I feel it needs to be an active adoption decision by the maintainer. If you want to pitch me your service you may send me an unsolicited email, but don't use our public space to advertise your product without asking.

Edit: I don't want to be too harsh to OP here - at least they pointed out a small but valid issue in our case. I very much appreciate their apology at https://news.ycombinator.com/item?id=31210245

In our case OPs bot did not open a PR which could have been merged quickly, but filed an issue instead.

We've blocked the bot after their script malfunctioned and they opened a second issue with exactly the same text (https://github.com/mitmproxy/mitmproxy/issues/5286).

mitmproxy dev here! Happy to answer any questions. Answers may take a while as I'm on a remote mountain hut, but please shoot. :)

Could you explain what your use case is? What format would you prefer?

Shameless plug: We (mitmproxy) have a somewhat reasonable web UI (React/Typescript), but I think there's a lot more potential here. We're also looking for Google Summer of Code students at the moment, so if someone wants to spend a few months hacking on cool FOSS stuff while getting a nice stipend for it, please check out https://github.com/mitmproxy/mitmproxy/issues/5048 and reach out to me. I'd love to work with good front end folks on this! :)