Randomize the order of TLS ClientHello extensions, to reduce potential ecosystem brittleness. This change is only visible to HTTPS server implementers.
This reduces risk of ossification by external implementers that makes it difficult to deploy future modifications to TLS. The TLS protocol used for HTTPS begins with a ClientHello message. This message contains a set of extensions. Using a fixed extension order can encourage server implementers to fingerprint Chrome and then assume specific implementation behavior. This can limit ecosystem agility when Chrome implements future modifications to TLS, if the server implementations are not prepared for Chrome to change its ClientHello. The TLS RFC, Section 4.2, specifies that extensions MAY appear in any order. When multiple extensions of different types are present, the extensions MAY appear in any order, with the exception of "pre_shared_key" (Section 4.2.11) which MUST be the last extension in the ClientHello This randomizes the order of extensions, subject to the pre_shared_key constraint in the RFC. This will reduce the risk of server and middleboxes fixating on the details of the current structure of ClientHello. This should make the TLS ecosystem more robust to changes.
Docs: https://docs.google.com/document/d/13hbMJDFU8kZ_qtLukNYoWZOEnr0wRKeP6XBmY_TQ0B4/edit https://github.com/dadrian/clienthello-randomization/blob/main/EXPLAINER.md