Skip to content

Conversation

@droe
Copy link
Contributor

@droe droe commented Jan 19, 2025

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

droe added 3 commits January 19, 2025 16:40
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].

An earlier version of the JA4 spec [5] also mistakenly used 0x0200 for
SSL 2 and 0x0100 for SSL 1.  This was fixed in [6] 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] https://github.com/FoxIO-LLC/ja4/blob/main/technical_details/JA4.md#tls-and-dtls-version
[6] FoxIO-LLC/ja4#150
SSL 1 was never actually deployed, the design was iterated upon to
become SSL 2 before it was released by Netscape [1] [2] [3] [4].  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`).

For these reasons, it seems to make sense to remove the fictional SSL 1
code entirely.

This also removes an issue where the resulting JA4 string would be "s3"
instead of the intended "s1".

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
These two tests contain DTLS flows using a version field of 0x0100 as
used by OpenSSL pre 0.9.8f, before OpenSSL switched to the standardised
version code points for its DTLS implementation.  The correct JA4
mapping is "d00", not "ds3".
@sonarqubecloud
Copy link

Copy link
Collaborator

@IvanNardi IvanNardi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fix; extremely good commit message, very appreciated!

@droe
Copy link
Contributor Author

droe commented Jan 19, 2025

You're welcome, thanks for reviewing. This change would look implausible to anyone without context.

@IvanNardi IvanNardi merged commit d55ff1f into ntop:dev Jan 19, 2025
38 checks passed
@droe droe deleted the droe/fix-ssl2-rm-ssl1 branch January 19, 2025 21:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants