LyleMi / ja3proxy

Customizing TLS (JA3) Fingerprints through HTTP Proxy
MIT License
75 stars 22 forks source link

[Bug] fingerprints are no longer fixed - TLS extensions are being randomised? #15

Open felipewarrener opened 3 days ago

felipewarrener commented 3 days ago

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"}
felipewarrener commented 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/

rosahaj commented 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/

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.

rosahaj commented 3 days ago

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?