I'd highly recommend https://httptoolkit.tech/ for that explorative GUI phase. I found it recently and the rule configuration, UI and interception setup is significantly better than Charles/Fiddler/Proxyman.

It’s such a bummer that a tool like this has a subscription model pricing. I don’t know what it’s like in other companies, but where I work getting a recurring subscription approved is a hassle compared to a one-time thing. I’ve been looking for something like this for work but a recurring cost is almost an instant dealbreaker.

Hi! I'm the dev behind HTTP Toolkit.

There is a subscription for Pro features, but most users don't need it - you can do most things common use cases need (all interception & inspection, manual traffic rewriting, almost everything that doesn't need advanced configuration) with just the free version. It's also 100% open-source, even the paid bits.

That said, imo subscriptions provide lots of benefits as a model for both sides. Basically by aligning how much value users get with how much they pay - cheap for quick use, expensive for extensive heavy use, strong incentive to fix bugs & support existing users instead of chasing the next shiny launch.

I hear your point about approvals anyway. If subscriptions are impossible, I can do one-off indefinite licenses - send me an email at [email protected]

Thank you for clarifying. I initially misread the pricing page and thought the free could only be used for personal and not commercial use. That really helps with adoption. If I can get multiple people to try it and if they like it, it’s an easier conversation with the people who approve expensed if I’m not the only one vouching for a piece of software.

I get what you mean about aligning incentives. I do want to support devs in a way that these types of projects are sustainable, but the way other products shut off access to your stuff once you stop paying make subscription models an unnecessary risk. Having a free tier like yours really helps.

While I don't currently need such a tool at work, I just want to chime in to agree with the approval point. It's significantly less hassle to get an expensive one time purchase approved than a €5 recurring payment. I very much appreciate your openness in that regard and I'll keep it in mind for the future :-)

Can confirm that the only way I could buy a subscription tool would be with my own money, they stress of buying it at work would be insane. Every monthly credit card charge would require someone to code it against the requisition, have that approved, then file in the records management system. Just purchasing software once is painful. We haven't even got to the part about installing it. You can imagine their happiness about mitmproxy.

Generally I try to buy the tool and three years of support upfront. Otherwise I'm at risk of it being deleted because we can't have software if it doesn't have a support contract 'in case there are bugs'. These rules are written by cretins in 'IT' and accountants.

Anyway, put the bit about flexible licencing on your order page.

I like the look of the product, but there is no mention whatsoever of websockets in the docs.

That is the thing missing from Charles for our QA folks.

It is highly annoying to have to hook the iOS app up to Xcode just to be able to see the wss traffic when tracking down a bug.

I've successfully used Fiddler Classic as alternative to Charles to look at live websocket traffic when debugging things before. Websocket support in general is a bit of a hidden feature though since you need to go to the request that established the connection and double-click the websocket logo to the left on it, which opens a new panel showing its traffic.

The newer "Fiddler Everywhere" might also be able to do it, possibly even better, but I dislike the UI and I'm used to Classic so I've stuck to that.

Yep, websockets are coming later this year, but it's not done yet I'm afraid.

Tracked here: https://github.com/httptoolkit/httptoolkit/issues/36. You can subscribe to the GH issue for updates if you're interested.

Thanks for the kind words! We have a Google Summer of Code student working with us on mitmweb, our web interface, at the moment, so we'll hopefully have a better GUI story soon as well :)

Yeah it's really hard though these days to sniff traffic from Android because most apps choose not to trust user-added root CAs anymore :(

It's not quite that. It's usually certificate pinning. Our iOS app won't talk to anything not issued by the list of CAs we include at build time.

This is specifically to prevent mitm attacks on the app.

Yeah certificate pinning is a thing too. But since Android 7.0 apps also have to specify whether they allow user-added root CAs and most don't!

You have to get the APK and mess with the manifest to bypass that. And bypassing pinning is even more difficult.

Edit: pimterry below me explains it better: https://news.ycombinator.com/item?id=27857429

I find this a problem because MITM isn't always bad. It can be used for inspecting apps for tracking and other malicious practices by app makers.

> But since Android 7.0 apps also have to specify whether they allow user-added root CAs and most don't!

I was unaware of this as I do little interaction with Android. TIL.

And yes, I do appreciate being able to MITM all kinds of apps, especially ones that talk to a device I own to be able to add functionality/integrations not supported by the manufacturer.

I also see the benefit of preventing MITM, in our case, it is because we intentionally offload logic onto the client to simplify GDPR/CCPA compliance(can't store what you don't collect) among other design decisions which mean a malicious client could circumvent rulesets we have in place.

> which mean a malicious client could circumvent rulesets we have in place

Note that your HTTP certificate pinning is easily bypassed on both Android and iOS by a determined actor. A malicious client will circumvent rulesets you have in place. If you do not validate client inputs, you will be exploited.

Indeed, it doesn't really differ that much from DRM. It's an attempt by the author of the software to impose control over the user, preventing them from using the software how they see fit.

If I've trusted my own root, and you've decided you wont trust anything on my root, I now need to take steps to disable the certificate validation routines completely on my device, in order to bypass your restrictions.

I get that there are cases where it's extremely valuable (and in some cases, required by regulators) to enforce certificate pinning, e.g. mobile banking apps, but there are plenty of cases where it's just bullshit DRM (e.g. gym app that performs unauthenticated requests to an https endpoint to retrieve occupancy stats on each of the chain's gyms).

In the latter case, all I wanted was to track how busy the gym was over time, so I could adjust my schedule to enable me to go when the gym was quiet. I couldn't be bothered to jailbreak my iphone and install nabla-c0d3/ssl-kill-switch2, so instead I quit my gym and switched to one that was less stupid.

> A malicious client will circumvent rulesets you have in place. If you do not validate client inputs, you will be exploited.

I agree. That is why there is still serverside enforcement, but performance tuning is heavily cache based and many client request strategies are specifically designed to not bust the cache and cause a high latency call.

Also, in our case, the app is the product. I'm not very positive on it's market fit, so you may never hear of it if it launches to a fizzle, as I suspect is a large probability.

I keep a jailbroken iPhone around to bypass cert pinning. Using frida or this handy project: https://github.com/nabla-c0d3/ssl-kill-switch2

To prevent the users from accessing their own data? Any other scenario is infeasible.

I just used this app the other week do dig into what I think is a bug with rclone. Seeing the exact http traffic to / from the AWS s3 endpoint made it much simpler to understand what was going on. The CLI is super intuitive, it's a great application all around.