What is Reddit's opinion of
HTTP Toolkit?
From 3.5 billion Reddit comments
27 reviews of this app found across Reddit:
What a bunch of crap. For folks who are unitiatited, OP has drank a lot of Apple kool-aid and is just parroting the company's lines.
https://httptoolkit.tech/blog/safari-is-killing-the-web/
​
Here are some interesting bits.
>More specifically, Safari's approach isn't protecting the web from bloat & evil Google influence, because:
>
>- Most features that Safari hasn't implemented have no hint of security, privacy or performance concerns, and they've been implemented in every other browser already.
>
>- The largest Safari complaint is unrelated to experimental features from the Chrome team: it's the showstopping bugs in implemented features, made worse by Safari's slow release cycle.
>
>- Refusing to engage with the contentious API proposals for real use cases doesn't actually protect the web anyway - it just pushes web developers and users into the arms of Chromium.
https://httptoolkit.tech/blog/safari-is-killing-the-web/
Safari is bad, and the way Apple handles it is even worse. They treat Safari like they’re some independent team of 5 people working on the browser. 2 updates a year? Come the fuck on dude.
As that article mentions you will need to install and use a CA cert on your phone with that wifi connection. I found this guide on how to do it but you'll have to work with your tech support in order to figure it out and they'll have to provide the appropriate cert. There's also a magisk module called "Move Certificates" that you may need to use to move user certs to system certs.
You're right, Android 11 changed the way it manages CA certificates. https://httptoolkit.tech/blog/android-11-trust-ca-certificates/
>The system store is used as the default to verify all certificates - e.g. for your apps' HTTPS connections - and as a normal user it's completely impossible to change the certificates here, and has been for quite some time.
>Until now however, you could install to the user certificate store, which apps could individually opt into trusting, but which they don't trust by default.
>In Android 11, the certificate installer now checks who asked to install the certificate. If it was launched by anybody other than the system's settings application, the certificate install is refused with an obscure alert message: [...]
>In practice, this change means the certificate install API no longer works, opening certificate files no longer works, and it's impossible to initiate a certificate install even from ADB (the Android debugging tool).
>It is still possible to install certificates using the device management API, but only in the special case where your application is a pre-installed OEM app, marked during the device's initial setup as the 'device owner'. If not, you're out of luck.
here's what you need to do to get started. Pretty sure all major games have ssl pinning enabled. You need to bypass that in order to intercept HTTPs traffic. Its much easier to do it on Android. Well I mostly work on Android so thats my preference. Can be done on iOS too. Few things you would need to install: BurpSuite, frida, adb tools, apktool, etc. I prefer to use frida to bypass ssl pinning. You'd also need to root your device. Follow the steps here to do this: https://httptoolkit.tech/blog/frida-certificate-pinning/
Once you set up your proxy and bypass sslpinning, you can see all http traffic from the app.
If they are not encrypting HTTP body, you're in luck as you'll be able to that data in burp. You can start your investigation on that data and see if you can mess with it to bypass application logic in some way. If the HTTP body is encrypted, then this will get tricky. You would have to decompile the application. I like JEB decompiler, but its not free and quite expensive. There are other open source decompilers available. Just google for them.
Once you decompile the app, find the code that is being used for encrypting HTTP traffic. Then you would have to write up some frida scripts to hook those methods to dump plaintext data to actually see whats being transmitted. You might be able to mess with the plain tect data in the frida scripts to achieve what you want. Search online on how to do this.
I ron't want to go into native JNI code. But its possible that encrpytion or any other critical logic is defined in those shared libraries. You can use Ghidra to decompile those.
Now once you're able to dump your plaintext HTTP data that is being transmitted, either just by burp proxy or using other methods I mentioned. You now need to see if the game server is sharing other player data the client app. If that the case, you might be in luck and maybe cheat the game. Otherwise you'd have investigate more to see if this is even possible.
It's hard to tell what is going wrong without more details about the type of request which is being made and any specific request headers which are being sent. If you're able to share some code there's a much better chance that someone will be able to help you.
I have found the tool Will it CORS? really helpful for figuring out how I need to configure things in different situations.
The OPTIONS verb is basically a silent request that gets sent first to get a feel from the server about what it's cool with accepting.
It's a lightweight and quick response to determine if the request you ultimately want to send is going to be valid or not, since any request to the server will return on the response headers what content-type it expects, what domains it will respond to, etc. If your request will fail any of those the browser now knows not to waste anyone's time with going through with the full request.
I'm actually fairly certain that the OPTIONS request is made all the time - it's just not visible to you most of the time on most browsers.
URL: HttpToolkit.tech
Purpose: Landing page for new product
Technologies Used: React, Styled Components, D3, Gatsby.
Feedback Requested: Design, copy, the product itself, anything really
Comments: I'm building a new side project (a tool for HTTP development), and this is the landing page, so I can start to see if people are interested in it.
If you look closely though, it's not just a landing page, but also an MVP for the design of the app itself. On desktop/tablet, the sections below with the details all have the real live JS component the UI will use, as an interactive background element. Good idea?
This is why you should stick to the golden rule of application development: assume your users are either dumb or want to do harm. Design a system with security in mind as your primary concern. Don't expose anything to the public that you're not afraid to expose.
This tactic works well when you're open-sourcing applications. One way of fetching secrets is by downloading the APK. The second is by using tools such as HTTP Toolkit. If you manage to reverse-engineer an API, you'll be able to gain an in-depth understanding of client-server communication.
very much disagree with you, due to all the points from this post.
the internet explorer comparison is drawn because it is installed by default and forced onto users, and yet has fallen behind. that describes Safari perfectly. it is impossible to use another browser on iOS.
Chromium is a really great browser and it adopts web standards way faster and more faithfully than Safari.
I do think that the lack of privacy in Chrome is concerning, and the Chromium monopoly is without doubt a problem.
I think this blog post has an interesting take in the issue https://httptoolkit.tech/blog/safari-is-killing-the-web/.
I use Firefox. We test in FF, Chrome and Edge still. Im not a fan of Chromes privacy concerns either, its why I use FF.
We dont bother with Safari though because its just riddled with issues. As a company is that the best policy? Lol no. If someone calls and complains that something isnt working with Safari we address it then, in the meantime we dont even bother.
Im too lazy to look up how to link this in reddit lol so here copy and paste, but this article summerizes the issues well.
You shouldn't need to make your own key. HTTP Toolkit can generate the key and do most of the setup for you. Have you seen the guide at https://httptoolkit.tech/docs/guides/android/?
It's even easier if you use a rooted device or an emulator, in which case it's 100% automatic setup. There's a guide to doing that with an emulator here: https://httptoolkit.tech/blog/inspect-any-android-apps-http/
Just that the user base might know more there is all. I recently read something maybe you can find an answer here https://httptoolkit.tech/blog/android-11-trust-ca-certificates/
Talks about the changes that took place from 10-11. Maybe u could reach out. Or find some info there. Good luck
Because I don’t want to support a browser that only updates every 6 months and is riddled with bugs and missing features for no reason.
Maybe I’m just jaded because I’m a web developer and developing for safari is a pain in the ass.
No worries. I can see how my comment could have been mistaken to mean otherwise. Also, in all fairness, there are areas where I agree Apple lags unacceptably behind the industry, particularly with Safari.
> Seriously: one of the reasons I use Firefox when I do any web development is because it's the new IE6. If I can get something to work on FF, I can be rest assured anything Chrome-derived will run it better.
Try developing for the actual new ie6, Safari
There lies the issue. Someone who is in the Apple ecosystem do not appreciate what it means to be a user outside of the walled garden.
​
Apple has such a choke hold on developers, and rabid fanbois just parrot company lines, that most people are caught in the reality distortion field.
​
Here's a much less hyperbolic take on what Safari is doing.
Ah ok. Yeah, that sounds like the dns.lookup problem.
It's technically async from the point of view of JS, but it uses a pool in libuv that only has 4 threads by default, so >4 DNS lookups will block each other and other low-level calls, including various crypto & FS operations. Your JS code will run like normal, but your async DNS/FS/etc calls will all suddenly take ages as they block each other internally.
I've been fighting the same thing. I don't know much about the Node 15 changes, but if you're looking to fix this in general I've found cacheable-lookup works really well, it was built as a component for DNS performance & caching in Got. I wrote a blog post a while back about fixing node's DNS using that, which is probably useful to you if you want more background & info to set this up.
If you have any more details about the Node v15/v16 change here though I'd love to hear them! Being able to simplify all this would be great.
A segfault is a low-level error invoked by a running application or code, in this case yours.
A lot changed between wherever stack you came from and Heroku-20.
This might help:
https://httptoolkit.tech/blog/how-to-debug-node-segfaults/
The important thing here is that this isn’t necessarily a Heroku-specific issue. Heroku runs apps over top of Ubuntu (in this case Ubuntu 20.04, hence the -20 in Heroku-20). If you have a way to run your app in a Ubuntu 20.04 VM with the same Node version, it might reproduce. In the end, though, there’s something the app is doing that’s cause a serious OS-level problem that is provoked in Ubuntu 20.04 but not earlier versions.
Also make sure you using as new a version of Node as possible in the LTS streams (14.x is the recommendation).
Hope that helps!
Depends how much detail you want on where it's coming from.
HTTP Toolkit can do HTTPS interception on its collected traffic, but you need to either run the software on a rooted device or emulator, or edit the software to trust the cert (more details in here: https://httptoolkit.tech/docs/guides/android). Stock Android won't trust custom certificate authorities without one of those. Sounds like neither will work for you though?
There still some hope anyway - if you're just looking to know who your software is talking to, you could use this VPN technique to collect every packets and check them for TLS handshakes (basically any TCP connection that starts with an 0x16 byte). Given that you immediately get the target IP for all encrypted traffic. You could also parse those handshakes and read out the SNI hostname, to know exactly which domain it is.
That won't give you a full URL or any other details, but it would tell you which server the update is coming from.
> What I'm curious about is that how do you decrypt eBay's HTTPS tunnel.
This did become more difficult by default on Android 7, but on rooted devices and emulators, you can still do this.
The change to the default settings is that only system CA certificates are trusted (not user-installed certificates). On normal devices you can't install such CA certificates, but on emulators & rooted devices you can (given a few tricks), and when you use ADB interception HTTP Toolkit will do that for you automatically. Any device that uses the default security settings (almost all apps) will trust the CA certificates installed by HTTP Toolkit on such devices automatically.
There's some more technical details on how this works here: https://httptoolkit.tech/docs/guides/android#intercepting-traffic-from-3rd-party-android-apps
> I want to redirect all HTTPS requests to my own localhost server on same network. Can I do that with this app?
Yes! As long as you either test on an emulator/rooted device, or you edit the relevant app's network security config. The docs have the full details: https://httptoolkit.tech/docs/guides/android
There's no redirection or host files required, it's just standard HTTP sent to localhost.
- The electron app starts the server (which runs on ports 45456 & 45457) and loads the page from
https://app.httptoolkit.tech. - That page makes requests to
http://localhost:45456, which sends requests to the local machine.
That means whichever machine you open app.httptoolkit.tech on, it always uses the server from your own machine, with no redirection required (because localhost is resolved by the user's machine, it's not the localhost of the server or anything like that). If you like, you can install HTTP Toolkit yourself, look at the network console, and see how it all works in my case, that might clear this up a little.
If you're already using OpenAPI for something, it's amazing, otherwise not so much. OpenAPI itself as a standard has a lot of great use cases though.
In my case, I'm building an HTTP development tool. This library means when I intercept HTTP requests to debug them, I can find the matching one of these 1400 API specs immediately, and then retrieve a bunch of metadata about the endpoint, and immediately add the description & a link to the docs, add explanations to request parameters and responses, and even automatically spot missing/invalid/deprecated requests. Being able to match arbitrary HTTP requests up with a detailed spec & documentation on demand is neat.
Name: <strong>HTTP Toolkit</strong> Headquarters: Barcelona Elevator pitch: Supercharged developer tools to debug, test & build with HTTP More details: Solo founder, just launched free version, working toward premium release soon Are you looking for anything? Users & feedback! Give it a go, let me know what you think. Discount for /r/startup subscribers: Everybody on the mailing list before the premium version goes live will get a serious launch discount.
I finished the landing page for my new side project (https://httptoolkit.tech), complete with interactive examples of the UI I'm planning embedded in the background of the features I'm talking about.
The core is Gatsby + React + styled components. The graph uses VX (way easier to get working with React than D3/Victory/Recharts), and the response body editor is built on Monaco (the editor that power VS Code).
Building live examples into the page has actually been a really fun way to prototype bits of UI, find tools I can use for the real MVP now, and iterate on what I'm building and how I'm pitching it at the same time.
It's things like this that really let you see the power of universal JS imo: you can build demo components for a desktop app and trivially get them working live in the landing page itself from day 1. Painfully cool.
Name: <strong>HTTP Toolkit</strong>
Location: Barcelona
Pitch: Suite of beautiful, cross-platform & open-source tools to debug & build with HTTP
More details:
HTTP Toolkit is a debugging web proxy, HTTP analyzer and HTTP client to help software developers work with HTTP. It works on Windows, OSX & Linux, comes with integrations for modern tools throughout, from Docker to GraphQL, and gives you everything you need for super rapid HTTP prototyping, or debugging complex issues with web apps, mobile apps, IoT, or anything else that speaks web.
This is in its early stages right now, and I'm looking for feedback! I want to know if this is something software developers want,and I want to know what people thing of the landing page itself. Tell me what you think :-).