Ability to change TLS Ja3/Ja4 based on browser version.

[shirshak55]

I’d like to propose a Node.js fork that adds explicit, low-level control over TLS hello instead of only randomizing fingerprints. Right now we can generate different JA3 and JA4 values by shuffling the cipher, but some servers still behave differently because the underlying TLS profile is not fully controllable.

If you are okay i can work on it.

Thanks.

[pimterry]

A Node.js fork for this is a massive project, and maintaining it would be a serious challenge even for a team of people full-time. It takes a lot of work to fork & maintain a runtime. I don't think that's a good approach. I'm a Node.js maintainer anyway, so I can work on any meaningful changes we need to make directly within the project (assuming others there agree of course - but so far this is a clear issue, and there's been good openness to solutions I've explored).

In fact, this is actually making very good progress now. The main challenges were in OpenSSL itself rather than Node, which I've now fixed there and which have been released for a while, and relatively recently been pulled into Node.js downstream so the required APIs are slowly becoming available there. There's more info and updates in nodejs/node#41112.

Using all this, I now have a working local Node setup that can do TLS impersonation sufficient to match at least Chrome & Firefox. It needs a bit more time to finish merging & releasing the changes in Node, and then this will be publicly usable. I'm expecting that will be within a few months, certainly before the end of the year. You can see the proof-of-concept code (rough, mostly AI, but working) that uses this on the poc branch of tls-impersonate npm package I'm planning here, and some example usage here.

I've also expanded https://github.com/httptoolkit/read-tls-client-hello/ so it captures & exposes all the handshake data required to support this in future, and published an echo service for that as well at https://testserver.host/tls/client-hello.

If you're interested in getting involved in Node itself to help work on improvements there that would be great of course! I think most of the immediate work to implement this is now in place, but if there's specific gaps you're aware of then let me know.

[shirshak55]

Yes, I am interested in getting Node itself. And, I already see you have 2 PR to fix it. Let me know if there is anything we can do there.

I think current httptoolkit uses node 22, and seems like we need openssl with your patch which will probably land in node js 27. Are we going to wait on that?

Thanks.

[pimterry]

We use v22 now, but we could probably jump to v24 in theory today. v26 will be released next week, and as long as there's no breaking issues there we could even jump to that right away, although it's normally better to wait a month or so to make sure there's no major issues.

From v26 onwards that tls-impersonate implementation will work at a basic level for everything except cert compression & EC point formats. That gives us enough to match the JA3 & JA4 of some recent Firefox versions (e.g. FF before 132 - about 18 months old, so I'd expect this to still pass most checks). My one last PR with cert compression lets us perfectly match JA4 signatures for modern Chrome too, and that eventually land in a future v26 version. That's all we really need.

For perfect JA3 signatures as well (now less used I think) for Chrome browsers we need the next OpenSSL release to make it 100% perfect (the EC point formats OpenSSL change). It's not possible to speed up the OpenSSL update step, since it depends on the OpenSSL LTS release schedule and how that fits with Node. Even doing it in a fork would be quite complicated since you'll probably need to modify various Node.js OpenSSL internals to make that work and that's not easy!

I'm focusing on Chrome here as the main test case since it's the most obvious & popular option. Modern Firefox is very similar though. In addition to needing these changes, Safari then still has a couple of issues: firstly 3DES ciphers (Safari still uses these, but OpenSSL and other browsers have dropped them as insecure - eventually Safari will update to do the same and this will solve itself) and secondly padding (this isn't required nowadays, so hopefully eventually they'll remove that too). Not much we can do there I think. To resolve either we'd need to use a custom build of OpenSSL which sounds nasty.

Conclusion: it's not too long a path, we'll be able to match recent Firefox within a month or two, match JA4 for Chrome & Firefox when cert compression lands, and then match JA3 & JA4 for both with Node v27.

[pimterry]

Just to update here, the tls-impersonate tests now confirm exactly what's supported and what's not - for example see the 'npm test' output in https://github.com/httptoolkit/node-tls-impersonate/actions/runs/24843174759/job/72722682735. We can match JA4 for Android apps (native or Flutter), we can match JA4 & JA3 for curl, we can't perfectly match any web browsers yet. I'll keep working on it 😄

[pimterry]

In addition to needing these changes, Safari then still has a couple of issues: firstly 3DES ciphers (Safari still uses these, but OpenSSL and other browsers have dropped them as insecure - eventually Safari will update to do the same and this will solve itself) and secondly padding (this isn't required nowadays, so hopefully eventually they'll remove that too).

This looks like that might be happening sooner than I thought: https://eclecticlight.co/2026/04/23/networking-changes-coming-in-macos-27/

[pimterry]

My Node cert compression PR was merged recently, and this below scheduled job has just run (https://github.com/httptoolkit/node-tls-impersonate/actions/runs/28356163237/job/83999536632) and automatically testing against the latest Node v26 it now fails with:

  1) Chrome TLS fingerprint impersonation
       should match Chrome extensions exactly:
     Error: Expected this test to fail on Node v26.4.0 (range: *), but it passed — the underlying issue may be fixed. Update the test to narrow the expectedFailure range or remove it.
      at Context.<anonymous> (file:///home/runner/work/node-tls-impersonate/node-tls-impersonate/test/test-helpers.ts:197:19)
      at process.processTicksAndRejections (node:internal/process/task_queues:104:5)

  2) Chrome TLS fingerprint impersonation
       should match Chrome JA4 fingerprint:
     Error: Expected this test to fail on Node v26.4.0 (range: *), but it passed — the underlying issue may be fixed. Update the test to narrow the expectedFailure range or remove it.
      at Context.<anonymous> (file:///home/runner/work/node-tls-impersonate/node-tls-impersonate/test/test-helpers.ts:197:19)
      at process.processTicksAndRejections (node:internal/process/task_queues:104:5)

  3) Firefox TLS fingerprint impersonation
       should match Firefox extensions exactly:
     Error: Expected this test to fail on Node v26.4.0 (range: *), but it passed — the underlying issue may be fixed. Update the test to narrow the expectedFailure range or remove it.
      at Context.<anonymous> (file:///home/runner/work/node-tls-impersonate/node-tls-impersonate/test/test-helpers.ts:197:19)
      at process.processTicksAndRejections (node:internal/process/task_queues:104:5)

  4) Firefox TLS fingerprint impersonation
       should match Firefox JA4 fingerprint:
     Error: Expected this test to fail on Node v26.4.0 (range: *), but it passed — the underlying issue may be fixed. Update the test to narrow the expectedFailure range or remove it.
      at Context.<anonymous> (file:///home/runner/work/node-tls-impersonate/node-tls-impersonate/test/test-helpers.ts:197:19)
      at process.processTicksAndRejections (node:internal/process/task_queues:104:5)

Which means this works! 🥳

That library (still very experimental, but working) can now exactly match the fingerprints for both Chrome and Firefox JA4. We can't match JA3 because it depends on extension ordering (but that's irrelevant for modern Chrome at least - real Chrome randomizes anyway) and it tests EC point formats (which I've fixed in OpenSSL v3.6, but we need to wait for the Node update, should be Node v26). But matching JA4 today should be enough in practice, so that's fine.

Not only can this set a fingerprint, that library also has functionality to directly match a arbitrary fingerprint. Right now HTTP Toolkit uses a single fingerprint for all connections, but with this in theory we can make every upstream connection exactly match the underlying downstream connection, which would be very neat indeed.

There will be some plumbing work required, I'll start on integrating all that within the next couple of weeks, and then we should be able to get near-perfect fingerprints everywhere.

[shirshak55]

Agree, JA3 doesn't need to match as chrome randomizes too.

Thank you so much for regular updates.

[pimterry]

I'm going to leave this open for now, will update & close once it's live in HTTP Toolkit.