Making your own web debugging proxy
twiinsen.com
twiinsen.com
I'm an nginx person, so learning a new python code base to hack on features I want is way harder than having something simple I can add on to, as needed.
It's two ways to do the same thing, but I like my way, and mine uses software that is production ready as a proxy :)
* libmproxy is not recommended for external projects. Instead you should use "inline scripts" (embedding functionality in mitmproxy). This is a pain point for me since I wanted to work on the captured streams in an external program that already existed and I shouldn't need to run mitmdump to do that work. The dumped streams are not in a standard format either, they're serialized python objects and dumps from different mitmproxy versions sometimes break the format.
* Performance. Having more than a couple of concurrent requests at the time tends to eat CPU. Running the requests of one browser through it is fine. Running multiple browser instances (e.g., using the new headless library in chromium for automated testing) through it, continuously performing requests is not a good idea. Memory footprint is also quite high, but is not a limiting factor for me.
I would like it if the dump format was a standard format and if libmproxy was a stable API.
A friend of mine was creating a product based on mitmproxy for a client and was running in to performance projects. He asked me for advice and I pointed him to just how little work it was to do exactly what he wanted with openresty, instead of mitmproxy.
If you want everything, mitmproxy might be for you. If you want fast, minimal, hackable, and not a pile of python then openresty and my approach might be for you.
> libmproxy is not recommended for external projects.
This is true (for the reasons outlined in [1]), but your use case is the reason why we also offer the libmproxy API. That being said, you'll see improvments here in the next release (and hopefully a lot of stability afterwards).
> The dumped streams are not in a standard format either
We would love to use JSON, but JSON does not really work with streaming. We use tnetstrings (not serialized python objects) instead, and we do schema migrations for the last 5 releases now. We have an example on how to read dumpfiles in Python in the repo [2]. :)
> Performance
Thanks for bringing that up. Scaling beyond a few concurrent users is not a design goal for mitmproxy currently - otherwise we probably should start rewriting it in Rust/Go. If you need anything large-scale, the submission here is vastly superior. :)
[1] http://docs.mitmproxy.org/en/stable/scripting/mitmproxy.html [2] https://github.com/mitmproxy/mitmproxy/blob/master/examples/...
Many intercepting proxies like The Fiddler with FiddlerScript and the Burp Suite through Burp Extender can be extended to have any feature you want by writing your own code or leveraging someone else's. Personally the only time I've found myself thinking I might need nginx for a debugging proxy is when I need scale. I'd rather use something that's close enough, write stuff where I need to, then focus on doing really cool things with them like finding vulnerabilities for fun and profit.
so, i did a tutorial search for myself, and if anyone may benefit here's a text one with screenshots: https://www.pentestgeek.com/web-applications/burp-suite-tuto...
and some official video tutorials: https://portswigger.net/burp/tutorials/
LogLevel dumpio:trace7
DumpIOInput On
DumpIOOutput On
and all your traffic is in the log files.I occasionally need to debug traffic. Not often, but occasionally.
For me, the ~$5 on Cellist (http://cellist.patr0n.us/index.html) was a no-brainer.
Note: Created certs has a 60 mins of cache (nginx) to improve performance. You don't want to download each certificate for all static files in a single request.
Don't ever do that.