You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Should TLSVersion for TLS1.3 be 771 or 772?
Per RFC 8446 :
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.
The text was updated successfully, but these errors were encountered: