Google Chrome browser started to randomize the order of TLS extensions in ClientHello packet, to reduce the risk of ossification by external implementers that makes it difficult to deploy future modifications to TLS.

This feature was initially to be released in Chrome version 110, but seemed to have taken effect in versions 108 and 109 as well, beginning soon after the feature was enabled by default in Chromium source code.

Chrome Platform Status

clienthello-randomization/EXPLAINER.md at main · dadrian/clienthello-randomization · GitHub

Problem: Using a fixed extension order can encourage server implementers to fingerprint specific browsers and then assume specific implementation behavior. This can limit ecosystem agility when browsers implement future modifications to TLS, if the server implementations are not prepared for browsers to change their ClientHello.

Goals: This is not designed to prevent all fingerprint of TLS stacks. It is to ensure the ecosystem:

• is prepared for the structure of the ClientHello to change over time
• does not hardcode byte-offsets / assume specific orderings of fields

Interesting argument here Sorting Out Randomized TLS Fingerprints – Null Hypothesis that with a simple sorting of extensions you can still easily fingerprint any ‘randomized’ ClientHello… Requires an update to the fingerprinting software of course