Open felipewarrener opened 3 days ago
Okay, I now see that this is not happening on much lower versions in this tool like Chrome 70. Based on some quick research, it seems the Chrome 108 and 109 were the first Chrome versions to implement TLS extension randomisation, so perhaps this tool should not be doing that randomisation for the Chrome 106 profile? It's possible the information I have found is incorrect.
Source: https://www.fastly.com/blog/a-first-look-at-chromes-tls-clienthello-permutation-in-the-wild/
Okay, I now see that this is not happening on much lower versions in this tool like Chrome 70. Based on some quick research, it seems the Chrome 108 and 109 were the first Chrome versions to implement TLS extension randomisation, so perhaps this tool should not be doing that randomisation for the Chrome 106 profile? It's possible the information I have found is incorrect.
Source: https://www.fastly.com/blog/a-first-look-at-chromes-tls-clienthello-permutation-in-the-wild/
ja3proxy is using utls under the hood and shuffling was added utls' HelloChrome_106 client back in November 2022. If I understand Chrome's feature description correctly, it was possible to activate extension shuffling since Chrome 106 by enabling a flag. But since the vast majority of users likely haven't manually enabled this flag, I'm not sure why shuffling was added by the utls project.
This results in random fingerprints, which I believe defeats the purpose of the tool?
If you don't mind sharing, what use case do you have which is defeated by TLS ClientHello extension shuffling? Or is it just the fact that extension shuffling is wrongfully enabled for this specific client, resulting in much rarer TLS fingerprints?
This proxy used to work for me, now the fingerprint hashes are becoming randomised on each request because the TLS extensions are being randomised on each request, just like a browser. This results in random fingerprints, which I believe defeats the purpose of the tool?
Proxy output from two curl requests:
The two curl requests: