JA4: Fix SSL 2 version and remove fictional SSL 1 version along with mis-mapping to s3 #2684
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.



Please sign (check) the below before submitting the Pull Request:
Link to the related issue:
n/a
Describe changes:
Fix version field for SSL 2 to the correct value and remove support for fictional SSL 1.
This also removes an issue where the resulting string for JA4 would be "s3" instead of the intended "s1".
SSL 2 uses a version field of 0x0002, not 0x0200. This is confirmed not only in the original Netscape spec [1] and RFC draft of the time [2], but also in major implementations such as OpenSSL [3] and Wireshark [4].
SSL 1 was never actually deployed, the design was iterated upon to become SSL 2 before it was released by Netscape. I don't think it's public knowledge what the version field for SSL 1 would have looked like, or if it even was two bytes large or at the same offset on the wire; given that SSL 2 used 0x0002 it seems more likely to have been 0x0001 than 0x0100.
Version field 0x0100, that is currently misattributed to SSL 1, was used by an early pre-RFC4347 implementation of DTLS in OpenSSL before 0.9.8f [5], when OpenSSL switched to the version field specified by RFC4347. This use of 0x0100 is also reflected in Wireshark's TLS dissector [4] (
DTLSV1DOT0_OPENSSL_VERSION).Because SSL 1 was never actually deployed, and there is neither spec nor implementation, there seems to be no point in implementing it based on pure guesswork.
An earlier version of the JA4 spec [6] also mistakenly used 0x0200 for SSL 2 and 0x0100 for SSL 1. This was fixed in [7] in August 2024.
[1] https://www-archive.mozilla.org/projects/security/pki/nss/ssl/draft02.html
[2] https://datatracker.ietf.org/doc/html/draft-hickman-netscape-ssl-00
[3] https://github.com/openssl/openssl/blob/OpenSSL_0_9_6m/ssl/ssl2.h#L66-L71
[4] https://github.com/wireshark/wireshark/blob/release-4.4/epan/dissectors/packet-tls-utils.h#L266-L277
[5] openssl/openssl@OpenSSL_0_9_8e...OpenSSL_0_9_8f
[6] https://github.com/FoxIO-LLC/ja4/blob/main/technical_details/JA4.md#tls-and-dtls-version
[7] FoxIO-LLC/ja4#150