search

salesforce / ja3

JA3 is a standard for creating SSL client fingerprints in an easy to produce and shareable way.
BSD 3-Clause "New" or "Revised" License
2.61k stars 289 forks source link

TLS1.3 TLSVersion Inconsistencies #78

Open ne4u opened 2 years ago

ne4u commented 2 years ago

Should TLSVersion for TLS1.3 be 771 or 772?

Per RFC 8446 :

In previous versions of TLS, this field was used for version negotiation and represented the highest version number supported by the client. Experience has shown that many servers do not properly implement version negotiation, leading to "version intolerance" in which the server rejects an otherwise acceptable ClientHello with a version number higher than it supports. In TLS 1.3, the client indicates its version preferences in the "supported_versions" extension (Section 4.2.1) and the legacy_version field MUST be set to 0x0303, which is the version number for TLS 1.2. TLS 1.3 ClientHellos are identified as having a legacy_version of 0x0303 and a supported_versions extension present with 0x0304 as the highest version indicated therein.

I'm of the opinion that TLSVersion should be correctly set to the actual version negotiated as JA3 spec doesn't dictate where the version is sourced: the legacy version or the version from "supported_versions" extension.

I've noticed that Wireshark will report the JA3 String for TLS1.3 with 771. However, Browserleaks will report 772.

wwhtrbbtt commented 1 year ago

In my opinion it should be the version that is actually negotiated, not the locked 0x0303 value. More datapoints are always good

wwhtrbbtt commented 1 year ago

The JA3 string should represent only what is part of the initial client hello.

Ah, that something I havent thought of. Makes sense