ja3proxy
ja3proxy copied to clipboard
LyleMi
[Bug] fingerprints are no longer fixed - TLS extensions are being randomised?
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:
./ja3proxy -addr 127.0.0.1 -port 8888 -client Chrome -version 106
HTTP Proxy Server listen at 127.0.0.1:8888, with tls fingerprint 106 Chrome
2024/06/29 18:32:19 proxy to check.ja3.zone:443
2024/06/29 18:32:20 copy client to dest error: read tcp 172.104.190.201:60682->90.156.230.100:443: use of closed network connection
2024/06/29 18:32:24 proxy to check.ja3.zone:443
2024/06/29 18:32:25 copy client to dest error: read tcp 172.104.190.201:37124->90.156.230.100:443: use of closed network connection
The two curl requests:
curl -k -x http://localhost:8888 https://check.ja3.zone -H "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36"
{"hash":"ffbbbb688550c50cf2aee007c33a2313","fingerprint":"771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,45-10-65281-16-27-18-23-17513-5-43-0-51-35-11-13-21,29-23-24,0","ciphers":"TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,ECDHE-ECDSA-AES128-GCM-SHA256,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-ECDSA-AES256-GCM-SHA384,ECDHE-RSA-AES256-GCM-SHA384,ECDHE-ECDSA-CHACHA20-POLY1305,ECDHE-RSA-CHACHA20-POLY1305,ECDHE-RSA-AES128-SHA,ECDHE-RSA-AES256-SHA,AES128-GCM-SHA256,AES256-GCM-SHA384,AES128-SHA,AES256-SHA","curves":"001D:0017:0018","protocol":"TLSv1.3","user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36"}
curl -k -x http://localhost:8888 https://check.ja3.zone -H "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36"
{"hash":"07cf360d6a680c04a38b64dd8fb10be5","fingerprint":"771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,11-16-10-65281-27-35-23-5-0-51-13-43-45-17513-18-21,29-23-24,0","ciphers":"TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,ECDHE-ECDSA-AES128-GCM-SHA256,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-ECDSA-AES256-GCM-SHA384,ECDHE-RSA-AES256-GCM-SHA384,ECDHE-ECDSA-CHACHA20-POLY1305,ECDHE-RSA-CHACHA20-POLY1305,ECDHE-RSA-AES128-SHA,ECDHE-RSA-AES256-SHA,AES128-GCM-SHA256,AES256-GCM-SHA384,AES128-SHA,AES256-SHA","curves":"001D:0017:0018","protocol":"TLSv1.3","user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36"}
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?
@rosahaj web application firewalls reject specific fixed fingerprints of some TLS clients, some also enforce that the user-agent string match the JA3 fingerprint, it's harder to find a specific user-agent to use in the case that shuffling is happening as there's not a complete 'list' online mapping them to user-agents etc. So it's easier to stick with a fixed fingerprint and correct user-agent for me for the time being.