Fix SSL 2 version constant to 0x0002 #1694
Conversation
|
It's just bytes order. PCPP here is using host order, and other libraries that you posted are using network order. |
|
If it was byte order, as you suggest, then the constants for SSL 3 and TLS would be wrong. |
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]. [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
|
I missed code in |
|
Closing and reopening to run CI after base branch change. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## dev #1694 +/- ##
==========================================
- Coverage 83.15% 83.11% -0.05%
==========================================
Files 277 277
Lines 48185 48205 +20
Branches 10165 10192 +27
==========================================
- Hits 40067 40064 -3
- Misses 7237 7244 +7
- Partials 881 897 +16
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
@droe So is this still an issue? |
|
Yes, certainly. Code point 0x0200 is wrong, 0x0002 as proposed in this PR is correct. |
|
@droe In Wireshark the values are: And in PCPP, the current (master) values are: According to the byte order, I think |
|
It should be 0x0002 for SSL 2. This is not a byte order problem (and you're swapping nibbles, not bytes). |
|
I meant: major is 0x00, minor is 0x02. If you swap the bytes, 0x02 can be 0x2. |
|
Not sure I understand what you're saying, uint8_t 0x02 and 0x2 are the same thing. You are running the version uint16_t from the wire through be16toh() at deserialization time, so the code ends up seeing SSLVersion 0x0002 in host byte order for the SSL 2 version bytes |
| @@ -117,7 +117,7 @@ namespace pcpp | |||
| enum SSLVersionEnum | |||
| { | |||
| /** SSL 2.0 */ | |||
| SSL2 = 0x0200, | |||
| SSL2 = 0x0002, | |||
There was a problem hiding this comment.
I wouldn't change the byte order here because it'll be different from the rest of the values in this enum
There was a problem hiding this comment.
@seladb Actually I think 0x0200 is wrong, and it should be 0x0020 based on other enum value byte order.
There was a problem hiding this comment.
Do you happen to have a SSLv2 pcap that we can use in tests? If so, it'd be great to add a test for it!
When I wrote this code I couldn't find a pcap file...
There was a problem hiding this comment.
https://github.com/Lekensteyn/wireshark-notes/blob/master/ssl3/sslv2.pcapng
I don't think you currently support SSL 2 record format or SSL 2 compatible SSL 3 handshakes (as per RFC 6101 Appendix E); if you or a user of PCPP were to support the latter, you will have to handle either "0x00 0x02" or "0x03 0x00" / "0x03 0x01" / ... in the handshake version field. Therefore I do believe the best and most correct and useful value for the constant in the enum would be 0x0002. (Also note that SSL 2.0 is called "SSL 0.2" in the old Netscape spec.)
There was a problem hiding this comment.
That's great, thanks! Would you consider adding a test with a single SSLv2 packet from this file?
There was a problem hiding this comment.
SSL2RecordSSL2ClientHelloTest : PASSED
SSL2RecordTLS1ClientHelloTest : PASSED
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].
[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