Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Record and re-use TLS profiles #6

Open
clouedoc opened this issue May 27, 2024 · 3 comments · May be fixed by #7
Open

Record and re-use TLS profiles #6

clouedoc opened this issue May 27, 2024 · 3 comments · May be fixed by #7

Comments

@clouedoc
Copy link

I am looking to inspect an HTTPS flow with Mitmproxy without altering the TLS fingerprint.

So, I am looking for this kind of setup:

Android device --> Mitmproxy --> proxychains(utlsproxy)

I will document my findings here.

@clouedoc
Copy link
Author

clouedoc commented May 27, 2024

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

image
  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

@clouedoc
Copy link
Author

clouedoc commented May 27, 2024

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

@clouedoc
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant