Support modifying ClientHello to match JA3 fingerprinting

[AceRogue]

I find extra_exts is set to be empty by default. So I will have to modify the rustls if I want to set different extra_exts? Is it reasonable to add extra_exts in ClientConfig?

[djc]

Why do you want to use it? It's only intended for QUIC.

[AceRogue]

Because I may need to change JA3. Default tls fingerprint may be blocked by websites, such as Cloudflare. To change JA3 fingerprint will need to change CipherSuites, order of extra_exts and etc.

[djc]

Do you have a concrete requirement/website that you need to pass JA3 for?

See some earlier discussion in #1125 and linked issues/PRs.

[cpu]

Potentially also relevant; #1313

[cpu]

I think we should focus on #1313 and not support open ended modification to the ClientHello.

I'm going to close this issue, but if there's a strong case to be made for why Rustls should prioritize this general request for more control over the ClientHello we could revisit. I think it will be a challenging case to argue. In my experience most folks expressly interested in fine grained ability to evade fingerprinting will be better served by more specialized TLS libraries that have the resources to focus on that goal above others.

[XOR-op]

@cpu Hi, I'm curious if Rustls would be open to contributions on this feature but might not give priority to it, or there is no intention to integrate it even with some contributions? If it's the former scenario, I'd like to offer some help.

The most important reason I want to integrate this feature into rustls is the ecosystem: there are so many downstream dependencies on rustls, and most of them don't provide a way to use some specialized TLS libraries (even if forked rustls). So it's way complicated for an end-user to have this feature if they have only a specialized TLS library, since they also need some higher-level libraries e.g. tokio-rustls, reqwest, trust-dns, etc. What's more, from the prototype I'm implementing, adding this feature doesn't need too many modifications, and won't affect users if they don't use this feature at all.

[cpu]

👋 @XOR-op

I'm curious if Rustls would be open to contributions on this feature but might not give priority to it, or there is no intention to integrate it even with some contributions? If it's the former scenario, I'd like to offer some help.

I can't speak for the other maintainers but to me I think it depends on the scale of the changes required and how much they'll affect the rest of the codebase. If a contributor was able to propose a change that was easy to review and not especially invasive I think it would be something we'd be open to. If a large number of changes are required, or the contribution isn't well tested or easy to review it would be harder to prioritize working towards getting it merged vs supporting other efforts.

The most important reason I want to integrate this feature into rustls is the ecosystem: there are so many downstream dependencies on rustls, and most of them don't provide a way to use some specialized TLS libraries (even if forked rustls).

Isn't it possible (if cumbersome) to use a patch section to override the dependency?

[XOR-op]

Thank you for pointing out the dependency override. I have opened a pull request in #1564, which should not be very invasive and be easy to review.

[Gowee]

Isn't it possible (if cumbersome) to use a patch section to override the dependency?

It prevents the crate from being published to crates.io. For a published crate to integrate a rustls fork, all dependencies along the way (say, rustls -> tokio-rustls -> hyper) have to be forked and published separately.