client: add support for sending unsupported cipher suites

[djc]

Fixes #1125. @ctz I know you said that you didn't want to support this, but I just wanted to sketch out for myself how much complexity it is to implement this given that there have been increasing requests for this (I don't like that this is necessary either, but I fear it might be a reality of competing with OpenSSL). IMO the resulting change is not too bad. If you're open to it, I'll add some tests.

[ctz]

Unfortunately #1125 is an XY issue. Actually what we need to do to get the same JA3 fingerprint as another client is:

• have the same order of cipher_suites (adding them on the end isn't enough)
• have the same order and presence of extensions (this might mean implementing whole new TLS features)
• have the same order and presence of named groups (we might have enough configurability here already)
• have the same order and presence of ec point formats (i think we're good here, uncompressed=0 on its own is ubiquitous)

[djc]

So if we scope this to (a) adding unsupported cipher suites, (b) sorting cipher suites, (c) sorting extensions, it feels like we'd have made some progress, and this seems somewhat straightforward? We could have a

trait ClientHelloModifier {
    fn update_cipher_suites(&self, suites: &mut Vec<CipherSuite>);
    fn update_extensions(&self, extensions: &mut [ClientExtension]);
}

and store an Arc<dyn ClientHelloModifier> in the ClientConfig.

(Link to JA3: https://github.com/salesforce/ja3.)

[ctz]

Since this was last discussed, Chrome shipped randomised extension ordering as a countermeasure to fingerprinting:

• https://chromestatus.com/feature/5124606246518784
• JA3 uniqueness in modern version of Chrome (which randomizes ClientHello messages) salesforce/ja3#88

I think I'd prefer to expend effort doing the same (#1313) which is really the antithesis of this PR. Thoughts?

[djc]

I agree it makes sense to randomize the extension order in ClientHello (#1313). I don't think that will make the desire for fingerprintable ClientHellos go away anytime soon, since at least some of the servers employing fingerprinting methods are mainly concerned with relatively specialized clients that aren't Chrome.

[FireMasterK]

I think this pull request should be re-opened since the extensions could be sorted, thus allowing for fingerprintable ClientHellos again. Such techniques may already be implemented on some sites as https://browserleaks.com/tls, https://tlsfingerprint.io/norm_fp, etc suggest.

[djc]

@FireMasterK please open a new issue with your concrete use cases.