[TLS] TLS client fingerprinting

[Joseph Birr-Pixton]

Hello,

Recently I've become aware that "TLS fingerprinting" is a thing. I
understand it has been deployed by Google, Cloudflare, Apple and others to
(at a guess)  "authenticate" TLS clients. For example, I understand that
certain Google Android cloud services refuse to interop with anything that
doesn't look like openssl-1.1.1 with a specific configuration. That is very
disappointing.

GREASE is ineffective at diffusing fingerprinting -- and that was never its
goal -- because it seems fingerprinting processes ("JA3" seems popular?)
actively remove the published GREASE code points if they are encountered.

But it seems the spirit of GREASE was to avoid the protocol rusting shut,
and here we have another case of the protocol becoming defined by
implementation rather than standard -- now TLS implementations have to
strictly follow a fingerprint accidentally defined by other implementations
or risk interop failure. We now receive defect reports asking us to
determine and identically reproduce the behaviour of old OpenSSL versions.
This is a terrible situation -- cipher suites, extensions, and named groups
all have rusted shut.

I'd like to ask if there any latent knowledge in the WG:

1. why do extensions not have a defined order (such as in order of code
point) to reduce this as a source of fingerprinting? I'm aware of the
specific ordering constraint on the TLS1.3 PSK binder extension, but as far
as I know this is the only time extension ordering has ever been specified.
It seems odd that TLS1.3 had such a variety of privacy improvements, but
not here?

2. what's going on in appendix E.3 in RFC8446? There's a reference there to
[HCJC16] but the text does not address the main fingerprinting findings in
[HCJC16] at all.

Thanks,
Joe
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS client fingerprinting

[Dennis Jackson]

Anecdotally, I'm aware of similar reports where TLS fingerprinting is 
used as part of anti-bot efforts and various projects try to work around 
it, e.g. curl-impersonate .


David Benjamin and I spoke about this at IETF 115 and felt that 
randomizing the order of client hello extensions (subject to the PSK 
coming last) was a natural solution. Compared to a fixed order, this 
ensures lazy middleboxes don't assume a particular extension is always 
in the same position and so cause breakage in a future version.


Chrome 110 releases to stable next week and has TLS Client Hello 
Extension Permutation 
 enabled by default. 
We have a patch  
ready to go for this in Firefox as well, which we plan to land in the 
coming months.


There are still plenty of other fingerprinting vectors which this won't 
address of course, but it is one step along the way.


Best,
Dennis
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls