-
Notifications
You must be signed in to change notification settings - Fork 165
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
Spoofed TLS/JA3 fingerprint is detected by some sites #47
Comments
Incredibly useful info, I was noticing similar issues. Technically speaking that |
Followup, upon further investigation this appears related to this fix . It seems |
An update from my side: I've tried reverting af9b002 and you were right, now the used protocol was TLS v1.3 indeed. However, and this is very odd, CycleTLS still got detected. So regardless of this, it looks like the TLS version is not the (only) way of the spoofing detection. |
Update: I have been using https://tls13.1d.pw/ to test the tls 1.3 handshake and have discovered a few more variables that need to be set dynamically. As mentioned in this ticket there are a few extensions which cannot be parsed from the ja3 token and need to be manually set. Problem 1For tls 1.3 the main issue lies in extension Expected tls 1.3 behavior
you can see this on on tls13 or wireshark Requests will sometimes just work because the correct Solution 1I believe the fix for this is just to handle this Problem 2There is a fundamental detection problem here where the Solution 2Occasionally we also get errors when the NotesThe tls13 as well as http2 provide decent external testing but the response formats make it hard to debug what is missing/what should be included. Ja3er also has a known bug which sometimes does not return the correct ja3 extensions. I will have a fix out which should (hopefully) allow you to consistently hit tls 1.3 servers although long term I believe developing the server component of this (http2/tls1.3) with declarative json formatted extension lists as well as the ja3 token/User Agent is important for making sure this repo is robust. Along with this maybe some documentation on how to parse ja3 tokens and how the server handshakes work to make debugging this easier in the future. |
Reverted/fixed some issues causing a failed TLS 1.3 handshake. It still has some intermittent request failures but I need to inspect/fix the Utls library to implement a permanent fix. With the default parrots defined in Utls e.g.
I would test detection on the current 0.0.14 release and if there are still issue let me know. I also added in custom error handling related to tls 1.3 so if that error appears let me know. |
Great job on fixing the issue, thank you for your work! |
Actual behavior
It looks like that there are a few websites (I mean services, but not naming them for obvious reasons) that can detect, that the TLS/JA3 fingerprint is spoofed and return with a 403 Forbidden status code. Unfortunately I have not found the reason yet.
Expected behavior
No server should be able to detect that the fingerprint is spoofed.
To Reproduce
Additional Information
I'm quite new to TLS spoofing but tried to find out and fix what causes this. Unfortunately the only difference I noticed between my browser and my script using Wireshark (for the first time) is that CycleTLS used TLSv1.2 while my browser used TLSv1.3 during the Client Hello. Maybe the server knows that the browser with this fingerprint should use v1.3 and blocked the request because of that?
OS: MacOS Catalina 10.15.7
Browser: Firefox v92.0.1
UA:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:92.0) Gecko/20100101 Firefox/92.0
JA3:
771,4865-4867-4866-49195-49199-52393-52392-49196-49200-49162-49161-49171-49172-156-157-47-53-10,0-23-65281-10-11-35-16-5-51-43-13-45-28-21,29-23-24-25-256-257,0
The text was updated successfully, but these errors were encountered: