Chrome 107 is experimenting with randomizing the order of TLS ClientHello extensions

[A-Posthuman]

See here:

https://groups.google.com/a/chromium.org/g/blink-dev/c/zdmNs2rTyVI/m/MAiQwQkwCAAJ

it's not clear to me if this is enabled on most installations yet, but there is a report here of some cases of encountering it:

refraction-networking/utls#132

that project implemented a PR to address it:

refraction-networking/utls#133

Something to keep an eye on apparently?

[lwthiker]

Thanks, important to keep an eye on this. If anything it should make web impersonation easier.

[windbridges]

Today I was studying how TLS fingerprinting works and noticed just such a thing in my browser chrome 108.0.5359.125. About every 1-2 minutes the order of TLS extensions randomizes and the ja3 hash changes:

0d3ba32b4a67eb16a540ee5a54acc1aa
77618024b14bfdc4aa7e21d5036d77b3
a78358673be36da9a3796fe4bd7ff334
f04b9a9d7b1e14902fd0f1bba680b57c
...etc.
I did not find any repetitions.

That said, when I ran the latest stable version of chrome in the Docker container, I found no such behavior there, the hash was static. Most likely some experimental option is enabled in my working chrome.

[A-Posthuman]

This behavior may now be more enabled on Chrome 110. I'm seeing a different JA3 hash on https://tls.peet.ws/api/all every time I reload it.

[lwthiker]

A bit of a late reply... we support this behavior since our Chrome 110 impersonation (merged in #148).