Allow offering ciphersuites in the Client Hello that are not yet supported.

[Hainish]

This is very edge-case-y. A strict set and ordering of ciphersuites is required by Google's server-side authentication in order to proceed with a login: see https://stackoverflow.com/questions/22832104/how-can-i-see-hidden-app-data-in-google-drive.

Attempting to migrate https://github.com/EFForg/rs-google-play/ from openssl, I encountered the limitation that only supported ciphersuites are offered in the Client Hello. Of course, this is a very reasonable assumption. Unfortunately, in my case Google's ciphersuite strictures will limit me from migrating, as a login fails when using the ClientConfig to offer the ciphers supported by rustls.

Ideally, I would be able to specify a list of ciphers I would like to proceed with, even if they aren't supported, knowing that Google will actually pick a supported cipher in the Server Hello: TLS_AES_256_GCM_SHA384 (0x1302)

Here is my attempt at migrating, valid but login fails: EFForg/rs-google-play@4779fde
Corresponding issue: EFForg/apkeep#152

[djc]

@Hainish how would the client session fail if the server does pick a cipher suite that's not actually supported?

[Hainish]

@djc of course the failure mode is up to you. I'd suggest exposing an UnsupportedCipherSuite API that returns a Result<_, rustls::UnsupportedCipherEstablishedError> when the server chooses an unsupported cipher in the Server Hello. That way any consumer of ClientConfig will be forced to explicitly choose a list of ciphers they know are unsupported by rustls, and there will be minimal confusion if an unsupported cipher is chosen.

[ctz]

I'm very sorry, but I don't think we're going to do this. If I were you I would consider maintaining a fork of rustls that tracks Google's TLS fingerprinting requirements.

I'd probably also send a snarky ID to the TLSWG that documents Google's requirements , and mark it is obsoleting RFC8701. That would be mostly for entertainment, though, since I don't think companies the size of Google are frequently embarrassed into changing course.

[JJTech0130]

Hrm, yes, I'm encountering this issue because some of Apple's services do fingerprinting. If the server is using a JA3 whitelist, you also have to change the extensions around. I guess I'll just fork it...

[JJTech0130]

for now it will probably be specifically tailored to my use-case (mimicking the signature of URLSession)