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.
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