Expose ability to customize ClientHello message about rustls

[XOR-op]

As the one who tried integrating this into upstream and currently is maintaining a fork of rustls, I would say it's possible to add this feature with minimal amount of lines of code change before #1475 is merged (5 files and <10 lines modification for each).

However, it's not feasible to only have a byte-level API exposed after the construction of ClientHello, because rustls will internally check the integrity of the ClientHello by the hash sent by the server. And I don't think we should violate this behavior. My current implementation modifies the construction process of ClientHello, whose modified values are also recorded and validated against by rustls. However, this piece of code change will be difficult to be made after #1475 is merged.

[ctz]

I think the goals of parroting other TLS implementations for the benefit of fingerprinting is at odds with other goals we have, such as not contributing to the ossification of TLS on the internet. That is why we randomise extension orders.

I have looked over craftls and I think it looks very good -- I think you should use it, contribute to it, and financially support it if it aligns with your needs. While maintaining a fork is extra work, that work would be borne by someone else if we extended the scope of rustls to cover parroting and that would reduce our ability to deliver on more mainstream features.

[hellais]

I have looked over craftls and I think it looks very good

That's great to hear. I have not looked at it with as much care, but I think the crux here is about coming up with the nicest way of supporting that kind of feature set, while minimising the effort on the fork side.

To this end, as an example, following a chat with @FiloSottile (one of the maintainers or crypto/tls), we came up with a design for doing a low maintenance fork of crypto/tls called utls-light.

My knowledge of rust in general and of rusttls in particular, is not as good as my knowledge of go, so the reason to bring this up here was to understand if there was a way to do something similar for rust too.

The main idea behind utls-light, is that we minimize the amount of lines of code that need to change compared to upstream, by using the raw bytes as the API to plug into modifying the clienthello and then hook into the places of the TLS state machine were we need to support the extra features.
All additional utls specific code lives in a separate file. This means that when changes happen in upstream they should in most cases apply with no conflict and when conflicts to arise they should not be too complex, because it's only a handful of lines of code added compared to upstream.

You can see what I mean by inspecting this diff: ooni/utls-light@2b6c2ef...4dfb1fc

OTOH looking at the changeset of the craftls I get the impression that if substantial changes were to happen in rusttls, the effort required to adapt the fork would be also quite substantial: 3andne/craftls@4d1b762...craft-0.22.0.

My question is therefore, given that I have gathered there is no interest to natively support this feature set in rusttls, would you be open to collaborating on making the integration of something like that as smooth as possible?

[cpu]

The main idea behind utls-light, is that we minimize the amount of lines of code that need to change compared to upstream, by using the raw bytes as the API to plug into modifying the clienthello and then hook into the places of the TLS state machine were we need to support the extra features.

That sounds interesting, but I'm having a hard time understanding what the shift was on the Go side in the stdlib crypto and x509 packages to enable this. I guess my question boils down to trying to understand what specifically the Go stdlib exposes to make this strategy workable for packages like utls-light that rustls is missing for it to be emulated in craftls.