Chrome's TLS Extension Randomisation Experiment: Assessing its Impact on TLS Fingerprinting
Transport Layer Security (TLS) fingerprinting is a commonly used technique for identifying client processes. In an effort to reduce the risk of server and middlebox fingerprinting of Chrome's current ClientHello and to make the TLS ecosystem more resilient to changes, Google Chrome conducted a recent experiment to randomize a portion of the TLS fingerprint. This experiment was included in Chrome version 108, which was released on December 8, 2022. You can read the status of the current experiment on the chrome status site
The aim of this experiment was to make it more difficult for server implementers to fingerprint Chrome and assume specific implementation behavior by using a fixed extension order. By randomly ordering extensions (subject to the pre_shared_key constraint in the RFC), Chrome hoped to reduce the risk of server and middlebox fixating on details of its current ClientHello.
The above graph correlates to the Chrome experiment and subsequent release of the feature. The number of unique TLS signatures dramatically increased.
From Peakhour data, we can see a significant large number of unique fingerprints appearing since the date of the experiment, making it relatively impossible to identify the Chrome network stack by a TLS fingerprint alone. However, an analysis by David McGrew, a Cisco Fellow, has cast doubt on the effectiveness of this experiment. In his article, McGrew proposed a lexicographical sorting of TLS extensions and found that 98.8% of signatures were unique after sorting. He argues that the canonical ordering of the TLS extensions in the TLS fingerprint can achieve nearly the same level of entropy as randomizing them and still be effective at client identification. Furthermore, he claims that the RFC should be amended to state that extensions SHOULD be sent in an ordered fashion in the ClientHello packet. McGrew also highlights the potential dangers of allowing unordered extension lists, as it could create a \"subliminal channel\" that could be used for tracking or transmitting information. Lets now graph over the same period the number of TLS signatures with TLS extension sorting.
The above graph correlates to David's assertion that sorting TLS extensions has minimal impact on TLS fingerprinting.
It appears that David's assertion is correct, the unique number of TLS fingerprints has minimal impact on TLS fingerprinting. Lets now look at in the wild data for Chrome 109:
| Hashed sorted TLS Fingerprint | Unique unsorted TLS fingerprints | Browser | Version | % of clients | % of hits |
|---|---|---|---|---|---|
| 3241796329 | 2 | Chrome Mobile WebView | 109 | 6.14 | 1.01 |
| 3313291307 | 8566 | Chrome | 109 | 1.83 | 1.54 |
| 1537819294 | 26587 | Chrome Mobile | 109 | 6.05 | 4.64 |
| 3944870384 | 1 | Chrome Mobile iOS | 109 | 4.31 | 5.35 |
| 3241796329 | 51594 | Chrome Mobile | 109 | 16.9 | 14.43 |
| 1537819294 | 121346 | Chrome | 109 | 15.66 | 20.7 |
| 3241796329 | 156405 | Chrome | 109 | 35.52 | 37.79 |
It's interesting that the experiment does not run on WebView.
Conclusion
While Chrome's experiment may have reduced the risk of server and middlebox fingerprinting of Chrome's current ClientHello, it seems that the randomization of TLS extensions alone is not enough to prevent TLS fingerprinting, and is in fact a useful indicator that it is The Real Chrome.