You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some web services use TLS fingerprints to block undesired clients.
When using HTTPtoolkit, those fingerprints are changed, which can lead to server rejecting the request.
Thanks for the suggestion @xob0t! This is something I'm aware of and definitely interested in improving. There's already quite a few features in HTTP Toolkit to help with this, and testing https://cloudflare.manfredi.io/test/ for me locally with Chrome or Firefox shows You are not a verified bot and you are 67% human on my machine (seems to vary a bit, but ranging between 20% & 70%) compared to the 1% result that https://github.com/sleeyax/burp-awesome-tls?tab=readme-ov-file#showcase shows for Burp's defaults, so it's not in a terrible state.
One thing that can help is using HTTP/2 for all requests, which is an option in the Pro settings (HTTP Toolkit uses HTTP/1.1 by default for clients that support both, as it's a bit simpler for most use cases). There's some sites that use "is the request HTTP/2" as a fingerprinting technique too on top of TLS, so this can help ensure traffic is considered legitimate.
All that said, I'd like to take this further. The challenge is that HTTP Toolkit is built on Node, which doesn't support control of this yet, and that's partly because Node is based on OpenSSL, which doesn't support some required features yet. I've been very slowly but surely working on that though in both Node and OpenSSL over the last year or so. Keep an eye on nodejs/node#41112 for details of how that's going.
Once all the changes listed in there are done, it should be possible to forge a very wide variety of TLS fingerprints with Node.js natively (note that I'm one of the maintainers of Node.js, so I do have a vested interest here). Contributions to the todo list to help make that happen are very welcome! Unfortunately without that support, forging the fingerprint requires embedding Go within Node and completing changing the TLS stack which causes all sorts of problems, so it's not practical otherwise.
Some web services use TLS fingerprints to block undesired clients.
When using HTTPtoolkit, those fingerprints are changed, which can lead to server rejecting the request.
Solution: Support TLS fingerprint spoofing, akin to this burp extension https://github.com/sleeyax/burp-awesome-tls
Does this affect you too? Click below and add a 👍 to vote for this and help decide where HTTP Toolkit goes next, or go vote on the other most popular ideas so far.
The text was updated successfully, but these errors were encountered: