Ready for Trial: TLS ClientHello extension permutation

960 views
Skip to first unread message

David Adrian

unread,
Aug 25, 2022, 12:40:34 PM8/25/22
to blin...@chromium.org

Contact emails

davi...@chromium.orgdad...@google.com

Specification

https://datatracker.ietf.org/doc/rfc8446

Design docs


https://docs.google.com/document/d/1NIeWj_xFE3p7Q2IxVjnztO4_Aqih3VAskHlLYqDFjvk/edit?resourcekey=0-FCsdas1l23L830egKOun4A

https://github.com/dadrian/clienthello-randomization/blob/main/EXPLAINER.md

Summary

Randomize the order of TLS ClientHello extensions, to reduce ossification.



Blink component

Internals>Network>SSL

TAG review



TAG review status

Not applicable

Risks



Interoperability and Compatibility

It is possible that Chrome’s ClientHello extension ordering is already ossified. This change may cause compatibility issues with middleboxes or other network monitoring software. We will do a slow rollout and monitor breakage.



Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

Ergonomics

n/a, not developer facing



Activation

n/a, not developer facing



Security

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. Chrome will randomly order extensions, subject to the pre_shared_key constraint in the RFC. This will reduce the risk of server and middleboxes fixating on details of our current ClientHello. This should make the TLS ecosystem more robust to changes.



WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?



Goals for experimentation


Monitor breakage and complaints, if any.

Ongoing technical constraints


It is possible that the extension ordering is already ossified. This change may cause compatibility issues with middleboxes. We will do a slow rollout and monitor breakage.

Debuggability

n/a, inner function of TLS stack



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

No

Flag name



Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1351809

Estimated milestones

DevTrial on desktop106
DevTrial on Android106


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5124606246518784

This intent message was generated by Chrome Platform Status.

Dennis Jackson

unread,
Sep 6, 2022, 11:47:13 AM9/6/22
to blink-dev
We (Mozilla) are supportive of this experiment and are looking at doing something similar in Firefox. This work is tracked in 1789436.

Kind regards,
Dennis

David Adrian

unread,
Nov 17, 2022, 12:07:48 PM11/17/22
to blink-dev
Updating this to say:

1) I screwed up and this really should have been an Intent to Experiment.
2) We've been experimenting behind Finch / staged rollouts, and have seen no change in overall metrics, and no increase in SSL errors, from Canary/Dev, through Beta and 1% Stable.

We also heard off-thread from the folks who run https://tlsfingerprint.io/, and they are aware of and working around the change in ClientHello structure.

I plan to send an Intent to Ship later today.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4cb933c7-3dac-4c98-8020-2398c8ed3775n%40chromium.org.
Reply all
Reply to author
Forward
0 new messages