DUnderstanding the Pitfalls of SSLv2 - Implementing SSL/TLS Using Cryptography and PKI - page 620

15:57:38.845640 IP localhost.localdomain.50704 >
localhost.localdomain.pcsync-https: S 2610069118:2610069118(0)
win 32792 <mss 16396,sackOK,timestamp 24215142 0,nop,wscale 7>
0x0000: 4500 003c 0018 4000 4006 3ca2 7f00 0001
0x0010: 7f00 0001 c610 20fb 9b92 7e7e 0000 0000
0x0020: a002 8018 0e99 0000 0204 400c 0402 080a
0x0030: 0171 7e66 0000 0000 0103 0307
...
Recall however that the HTTPS protocol (but not necessarily SSL!) mandates
that the very fi rst packet sent after the connection is established must be an SSL
ClientHello . The next packet, therefore, is
15:57:38.846983 IP localhost.localdomain.50704 >
localhost.localdomain.pcsync-https: P 1:37(36)
ack 1 win 257 <nop,nop,timestamp 24215144 24215142>
0x0000: 4500 0058 001a 4000 4006 3c84 7f00 0001
0x0010: 7f00 0001 c610 20fb 9b92 7e7f 9bb0 f1f9
0x0020: 8018 0101 fe4c 0000 0101 080a 0171 7e68
0x0030: 0171 7e66 8022 0100 0200 0900 0000 1006
0x0040: 0040 0100 8007 00c0 0001 0203 0405 0607
0x0050: 0809 0a0b 0c0d 0e0f
The TCP header ends at byte 0x0034, so the SSL data begins at 0x0035. If you
refer to the specifi cation for the ClientHello , you see that it starts with a ver-
sion major and a version minor byte. However, this is preceded by a two-byte
length fi eld with the high-bit set to “1” to indicate that this is a two-, rather than
three-, byte header. Removing the high-bit, you get a length of 34 bytes (0x22 = 34
base 10), which you can see matches the packet length. This is followed by the
handshake type, a one-byte 0x01, which is the code for ClientHello . The receiver
is responsible for keeping track of the fact that this is a new connection, and
that a handshake message is expected.
The length header is followed by the ClientHello packet:
unsigned char version_major; // 00
unsigned char version_minor; // 02
unsigned short cipher_specs_length; // 0009
unsigned short session_id_length; // 0000
unsigned short challenge_length; // 0010
unsigned char *cipher_specs; // 0600400100800700c0
unsigned char *session_id; // (empty)
unsigned char *challenge; // 000102030405060708090a0b0c0d0e0f
You can compare this to the data that was loaded in the send_client_hello
function; remember that the challenge, which actually ought to be a random
number, is just an increasing sequence of bytes.