Danny-Dasilva / CycleTLS

Spoof TLS/JA3 fingerprints in GO and Javascript
GNU General Public License v3.0
823 stars 164 forks source link

HTTP2 and JA3 Not matching browser fingerprint #112

Open FloppaFriday opened 2 years ago

FloppaFriday commented 2 years ago

Description

as i already specified here: https://github.com/Danny-Dasilva/CycleTLS/issues/101 the HTTP2 fingerprint of cycletls doesnt match the fingerprint of the browser im attempting to imitate. This not matching data can be found both in chrome and firefox. Especially the HTTP2 issue is an problem because it causes detection. Frames send are incorrect for example the settings frame sends entirely different content as opposed to the browser. Because of that the values that tls.peet.ws calls akamai_fingerprint and akamai_fingerpring_hash are both different from the actual browser. additional to that newer chrome versions are returning Extension {{ 17513 }} is not Supported by CycleTLS please raise an issue when an attempt at an request is made Also another issue to look into would be the fact that some useragents arent sending any headers for example requesting tls.peet.ws with "Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36" as a header returns the response "no useragent"

Issue Type

Bug

Operating System

Windows 10

Node Version

Other

Golang Version

No response

Relevant Log Output

No response

Danny-Dasilva commented 2 years ago

additional to that newer chrome versions are returning Extension {{ 17513 }} is not Supported by CycleTLS please raise an issue when an attempt at an request is made

This extension has been supported since this release. This is a custom error handler I wrote into the code. I would update your local version to the latest release since you cannot get this error unless you are at least on version 0.0.19 or earlier.

I understand the importance of Frame headers. As I mentioned in the last issue I added specific checks we are sending the correct chrome and firefox frame headers depending on the user agent.

Here's an example for the latest chrome version on windows https://github.com/Danny-Dasilva/CycleTLS/blob/c84d740b4757c7bf80168047d1c7224012eafb15/tests/frameHeader.test.ts#L6-L48

Here's the lest firefox on windows https://github.com/Danny-Dasilva/CycleTLS/blob/c84d740b4757c7bf80168047d1c7224012eafb15/tests/frameHeader.test.ts#L53-L93

I am specifically testing chrome and firefox headers on the latest browser versions. I'm not sure how to reproduce your issue. I would try updating to the latest version.

FloppaFriday commented 2 years ago

I investigated the issue by myself for a bit and figured out that the header order isnt matching the actual header order of firefox. Also even after upgrading to the latest version i still have TLS_GREASE in my curves and im lacking the padding extension. Both header length and order arent matching. I tested it multiple times but instead of the browser(length 312) the library submits headers with length 307. Here are both results from tls.peet.ws in pastebin: browser: https://pastebin.com/FC5vvZ2U cycletls: https://pastebin.com/SsphAtf7

FloppaFriday commented 1 year ago

are there any updates to the issue?

FloppaFriday commented 1 year ago

The issue still occurs. When testing i figured out older browser versions are less likely to face this bug but the newer ones do.