From what I read, the main change happens here: saucesteals/goproxy@804168e#diff-9eb708469ebd17cf090b3e0e1a04c074850beb22e94ea3d327ad0610ec7bad32

1. The connection is established between the client and goproxy
2. The ClientHello of the connection gets sniffed
3. The ClientHello gets fingerprinted and converted to a ClientHelloSpec, which is a blueprint to create new ClientHello matching the fingerprint.
4. A new connection gets dialed with our interception certificate and a UTLS client using the clientHelloSpec

I think I can simply record the ClientHello into a file and fingerprint it again and again at runtime.
This would have the benefit of keeping ground-truth data in-tree rather than only possibly faulty specs.

TODO

• Add environment variable to record the ClientHello to a given folder
• Add environment variable to re-use a saved ClientHello rather than using the TLS ClientHello

Managed to make it work!

I managed to make everything work.

My testing command:

curl -k --proxy localhost:8080 https://tls.peet.ws/api/tls | jq .tls.peetprint_hash

I first set my computer's global proxy to UTLSProxy and directed Safari to a website.
It saved the client hello.

I then relaunched with an environment variable that overwrites the ClientHello, pointed to the one I saved.
I then used cURL with utlsproxy and managed to get a Safari fingerprint

Next step

• Publish fork
• Check possibility of using an upstream proxy natively (net/http transport? I saw that it was removed in a commit in the goproxy fork — why, can I revert this? Is there an option in uTLS that natively allows to use an upstream proxy? Can I just hack it and add yet another environment variable?)
• If above fails, check out proxychains

I will leave this PR open to discuss ClientHello reuse and open a new one concerning upstream proxies.