Hey HN! I've been building this for a while, but up until now it's been a read-only HTTP debugging tool, and today's my first foray into proper mocking, which opens up a whole new world of fun (and practical use cases).
I hope this works out! Using fiddler us such a frustrating experience. The documentation is practically non existent and the ux is atrocious, and as far as I can tell the closest thing to a manual is a paid ebook by the developer (I was so pissed when I discovered this). I would be very happy to have an open source alternative!
What bothers me is not the price, it's that the only documentation available is an ebook that one of the developers wrote as a side project. The tool is very powerful, but it's a nightmare to use, and it doesn't matter how powerful it is if you spend more time struggling with the software than fixing the problem you have that requires it in the first place. I'm just happy that someone is attempting to create an alternative with a focus on usability and cross platform support.
I understand why you're doing it, but the download link redirecting me to an email capture page is quite jarring. If your download link is at the top of your homepage, and there's more product details below that link, it's pretty typical to hit download and assume it's a normal download link while you read the rest of the page. An easily dismissible modal would work better (or put an email capture in your app on first-run)
Hmm, interesting. I really just did it without much thought, I didn't think it was particularly unusual behaviour.
That said, this completely makes sense, I'm definitely going to look at that. I could fairly easily swap the 'sign up for updates' in directly in place of the download button when that's clicked I think, which would avoid the extra page and the modal all together, make everything much nicer, and still give keen users a clear opportunity to properly follow the project.
I don't see too much of a problem, just that if the download link does not come up right away (this could be caused by a user's browser settings or connection speed, which are beyond your control) it looks like they have been taken to a "Here, have some spam instead" page. I would just switch the position and styling of "Sign up for updates" and "You are now downloading..." so that confirming the download request is the primary message on the screen. You could also ask a user to wait three seconds and make them look at your (now less prominent) appeal to sign-up for emails while they do so.
The project looks very nice and I do a lot of HTTP work so I will try it out today. Good work!
+1 for easy access download without forcing an email submission.
update: K, I had gotten side tracked and forgot that it already downloaded and left me on the email submission page. User error. Downloads fine without email.
THIS would have been nice to have at the beginning of the summer.
The tests I wrote tested the boundary between my code and the HTTP library but the API I was writing against wasn't particularly well behaved and so that wasn't quite enough.
> Does that not require a system-level root CA to be installed and trusted?
No, happily :-)
The trick is that it starts the application to be intercepted for you, so it can control it a little. It then does some magic to get that specific instance of the application to trust the certificate. There's a lot going on there, but as an example: Chrome has a --ignore-certificate-errors-spki-list to inject the hashes of extra CAs that can be trusted in this specific Chrome instance. When HTTP Toolkit starts a Chrome process, it adds that command line option, with the hash of your locally generated CA.
There's nothing here with a lasting effect, and other running apps on your machine won't trust HTTP Toolkit unless you specifically configure them to. Only the processes spawned by HTTP Toolkit trust your CA, which avoids a lot of the downside of other similar tools like this.
So, I'm confused. Does this work on a set of programs where you know eg the right command line parameters to give them or on all programs?
For example, let's say I have a program which uses the openssl API to set a custom trust store. Do you mess with openssl to make sure your cert is in there, or will this break?
It works on a set of programs, plus terminal interception that works on anything (more or less) that you spawn from the given terminal.
For that terminal interception, HTTP Toolkit injects a lot of environment variables, including adding some wrappers to your path, which allow it to inject into a _lot_ of places. It sets `SSL_CERT_FILE` for example, which reconfigures the default CA for any processes started from that terminal that use OpenSSL. Again, all scoped to just this one terminal window.
In the case where you specifically manage the trust store as you describe I suspect that'll break (the requests will fail, but they'll still appear in HTTP Toolkit as just 'Certificate rejected for ABC.com', without the full details). The vast majority of applications don't do that though; they rely on the environment to tell them who to trust, and HTTP Toolkit creates the environment. For specific cases that don't, I also include a bunch of extra overrides and injections, so if there's anything that comes up that doesn't fit it's fairly easy to work around it.
I did look at it! It's still an option in my back pocket if I find things that don't work nicely, but right now this is much easier. I'd need to use LD_PRELOAD to hook lots of different libraries and tools (OpenSSL is just the start, and I also need to hook proxy settings), plus handle different versions of the hooked libs, and make it work reliably on Windows & Linux & Mac.
AFAICT, it's hard to do everywhere reliably for the general case, though as I say I might use it for specific niche cases later. At the moment there's zero native code required in this terminal hooking, which is very nice, and it's very nearly identical logic for all platforms too. It's not so bad, right now it's less than 1000 lines of code in total, and it works out of the box for Python/Node/Ruby/PHP/curl/npm/apt-get, etc etc etc.
An LD_PRELOAD approach would be useful for working around that flavour of certificate 'pinning' where the cert files are embedded in the application rather read from the filesystem. I don't know how common that is compared to the other pinning methods (public key pinning, hashing) but maybe you could make it work for those also. I guess you'd have to implement it for each individual library but does any other (free) mitm proxy offer this feature?
Netripper[0] can also intercept HTTPS with zero setup via DLL injection. I cobbled together a simple guide[1] on its use, though for Chrome, signature changes have made it a bit more challenging[2].
WOW. Just WOW. Easiest intercepter I have EVER used. (Charles, Fiddler, MITMProxy). After install I was able to edit requests and responses with the MOCK rules in no time.
The language was confusing but I got through it and WOW.
Nice job on the UI too, Linux UI's are hit or miss and HTTP Toolkit's is pleasant!
Alrighty, after tinkering yesterday an opportunity came up to use this for real work! And helped us mock testing for a bad JSON response we are seeing on a remote server, but mocked it locally for better error logging. (gave shoutout to HTTP Toolkit here > https://github.com/department-of-veterans-affairs/vets-websi...)
This just earned a subscription, will get it processed soon! Thanks again, a breeze to use!
There are full opensource alternative for this? I like the product, I'm testing it right now. But I'm curious if there is a way to accomplish something like this with existing opensource tools or a similar full opensource project.
HTTP Toolkit is fully open source, primarily AGPL: https://github.com/httptoolkit/. That includes the Pro version too - it's not open core, it's just open source all the way down.
There are other tools that exist anyway, but all the big ones (Fiddler & Charles, for Windows & OSX respectively) are very much closed source. The other similar open source competitor I'm familiar with is James Proxy (https://github.com/james-proxy/james) but that's now effectively unmaintained.
The parent was likely referring to AGPL, a somewhat-encumbered copyleft license, which most folks working in proprietary software are hesitant to touch. They are probably looking for a non-copyleft license.
Though, as a development tool, I don't see any issues using AGPL software.
Could be! It's all open-source but actually not all AGPL: the core desktop app is, but the internal libraries like https://github.com/httptoolkit/mockttp are generally MIT or Apache 2, so if you're looking to dig into and use those internals, it's pretty thoroughly unencumbered.
It's really just the runnable desktop app part that's AGPL. That encumbers you if you're making a directly derivative work (no running off with the whole app but closing the source, thank you), but otherwise it shouldn't limit you at all. This isn't like using a (A)GPL library in your codebase; it's a full application and you're an end user.
Absolutely! In fact AGPL v3 guarantees that right (otherwise in the US I think arguably the DMCA blocks breaking access protections like that).
In practice, I'm not too worried. It's a fair bit of a hassle, as you'd have to rebuild everything yourself. It'd also require a fork that would make keeping up to date with the main versions new features painful, and it's been moving pretty quickly!
It's only a few dollars a month, if that's expensive enough for you that the time & hassle to fork the whole thing would be worthwhile, email me at tim@httptoolkit.tech and I'll just give you a free subscription.
Yes, you're probably right about the DMCA. Would be a fascinating test case, given the availability of the source under an open license! But of course, will never happen.
I think I more saw it as a challenge to be honest! But if I do get to that point in the future I may take up your generous offer.
Great README docs by the way - spot on in content and delivery!
mitmproxy (/mitmdump) is awesome and powerful, and is ideal for integrating w/ other cli tools (like lnav) in chained scripts written in your language of choice. highly recommended.
As a UI desktop app, not really, although it depends what you're trying to do. However, the internals are all open-source too, so you can use them standalone and automate HTTP & HTTPS with that. Take a look at https://github.com/httptoolkit/mockttp
I think (maybe postman) had a nice gui, and then the same mocks could be loaded up as part of a test. I was thinking more along the lines of how the application actually inspects network traffic, is that something that could be setup & torn down within a unprivileged docker container for example?
It's a Node.js library, so you'd need a Node container and a little script to configure it. Mockttp can spin up an HTTP/HTTPS proxy configured to pass through traffic in a couple of lines, and from there you can add any other mocking rules you want (the Mock tab here is really just a UI over this) and you can subscribe to requests/responses/whatever and report that data elsewhere in any form you'd like (that's where all the data shown in the View tab here comes from).
The details get more complicated of course, but it's definitely possible.
Totally nice side effect. Since this launches "fresh Chrome/Firefox". I can use it to read all these paid news sites that track how many "free articles" I have and don't have to worry about resetting all my cookies. Just launch HTTP Toolkit then Fresh Firefox/Chrome, paste link and done.
You can also open the dev console and click "Clear site data". It won't evade complex tracking/fingerprinting techniques, but I don't think paywall sites use those to enforce the paywall (yet...).
That's great, thanks for the link! In recent Android versions it has become difficult to inspect the traffic precisely because certificates installed by users are no longer trusted, so one has to either root the phone or modify the apk.
Do you plan to automate app repackaging with the needed changes, or is there a better method for apps to trust local certificates?
> Do you plan to automate app repackaging with the needed changes, or is there a better method for apps to trust local certificates?
Eventually I'm aiming for the former, I'm fairly confident there is no better method. To start with, it'll be an Android app that configures your proxy settings (acting a VPN) and walks you through adding the certificate to the user store, and for your own apps I believe that's useful already: you just need to enable user stores in your app config (https://developer.android.com/training/articles/security-con...), and everything will Just Work.
For other apps though, on new-ish Android apps it's more difficult, as you say. My plan is to try and rewrite them, _probably_ as a Pro feature, but TBC. It should be a matter of:
- Get hold of the app APK (I think you can pull it with some adb tricks, slightly unclear)
- Edit the XML config to enable the user cert store, change the app id too (so it doesn't replace or have signature conflicts with the real app)
- Repackage & reinstall the resulting APK over adb
Is it possible for HTTP Mock to dump both the entire SSL session traffic, and the decrypted HTTP traffic (with fake tcp headers), to pcaps for future analysis?
The first noticeable feature is that HTTP Mock is cross-platform and Proxyman is exclusively built on macOS.
I'm not sure how zero-setup works, but it's cool feature indeed. I was frustrated to setup those certificate on Fiddler. I suppose that Fiddler tends to expert users, not me.
- It can do all the interception setup for you, for a single specific target. Fiddler et al set the system proxy, so there's a lot of other traffic going on, and you then need to make applications trust the certificate manually too. Notably some apps (like Node) ignore the system proxy settings entirely, which means you need code changes. HTTP Toolkit does some clever injection, and skips all of that.
- Nice & modern UI
- Built in docs for all standard HTTP status codes/headers/methods/etc
- The Pro features: validation & inline docs from 1400+ API specifications, testing & comparison of compression options, explanations for how your response will be cached & why (and warnings).
I keep meaning to do a proper comparison page (any day now), but that's the gist.
What about intercepting requests from other devices on the same network? Fiddler and Charles both let you set a proxy on Android/iOS devices pointing to your instance.
If you want to do intercept something manually, there's general instructions under the 'Anything' interception option. In short:
- Set the proxy on the device to point at your machine's local IP, usually on port 8000 (active port is shown under the 'Anything' option)
- Trust the generated MITM certificate on your device, so you can intercept HTTPS too (path to the certificate also shown under 'Anything').
Fundamentally, HTTP Toolkit, Charles & Fiddler are all HTTP & HTTPS proxies, so they all allow intercepting the same things, it's just a matter of how easy the setup process is.
I know it isn't exactly what you're doing, but you might want to look at nogotofail on the Android side. It has all the per-app goodness baked in, and you could probably borrow its approach.
Fiddler is a bit of an ugly duck, and you even have to give your e-mail address away to Telerik. However, it does have scripting ability and supports extensions and one can be very powerful in it if you know what to look for.
I actually use extension functionality to extend Fiddler a bit to emulate our internal authenticating proxies we have at work (like PingFederation).
Yeah, eventually I'd love to be able to do scripting etc, but it's dramatically more complicated.
There's the language debate to start with. E.g. Fiddler uses JScript.NET, which isn't exactly the language of choice nowadays. Realistically whatever language you choose, you have some big problems. Different groups want different tools, some want external packages, some want data stores, it's a whole thing.
It's a good point though, and I'd love to solve it. I've added an issue to my feedback repo to look at it: https://github.com/httptoolkit/feedback/issues/37. If you've got a minute, could you comment there and record the kind of scripts you'd like to write?
I'm not really sure what emulating internal authenticating proxies means in practice, for example. Are you rewriting requests to inject auth params, or validating outgoing requests, or something else?
Hmm, no idea. I'm using Chrome on a Mac, and it works fine, and my analytics suggest at least 400 other Chrome+Mac users have been getting through, so it's not a general problem...
Any chance you can export a HAR from your browser dev tools and send it to help@httptoolkit.tech? There's something very odd happening there, could be a Netlify bug.
You don't need to create an account for this! Click download, use the app, it's fine.
You can provide your email after download if you want updates from the mailing list (or you can not), and you can click 'Get Pro' somewhere and provide your email if you want a paid Pro account. The core app will give you pretty much everything Fiddler does though, on Mac, and doesn't require your email or anything else.
Let me know what you think :-)