Wireshark-bugs: [Wireshark-bugs] [Bug 1503] SSLv2 record length and version shown wrong

From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Sat, 31 Mar 2007 14:44:46 +0000 (GMT)

http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1503


sake@xxxxxxxxxx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sake@xxxxxxxxxx




------- Comment #1 from sake@xxxxxxxxxx  2007-03-31 14:44 GMT -------
(In reply to comment #0)
> SSLv2 packet header is interpreted badly: if I click on 'Length' field in SSLv2
> record wireshark will highlight 2 bytes in the 'Packet bytes' window but the
> value of the Length field is ok.
> 
> In my case it is '80 7a'. The Length value is 122 (0x7a).

In case of SSLv2 handshakes, the length can be either 2 or 3 bytes. If
byte[0]&80==1, the length uses 2 bytes. If not, it uses 3 bytes. In your case,
the bit is set, so two bytes are used. This means the length is calculated as
follows: byte[0]&0x7f << 8 + byte[1]. Since both bytes are used in calculating
the length, both bytes are selected in the byte-pane. To me this looks like
correct behaviour.

> Also, what is missing is the 0x80 value being interpreted as SSLv2 handshake
> (content_handshake_v2 = 128 = 0x80)

Actually your packet is performing a TLSv1 handshake on top of a SSLv2
record-layer. There seems to be a little mixup in the names of fields/filters
and also some difference in how the SSLv2 and SSLv3 dissection-code are
handling things.

I will have a look into this.

Cheers,


Sake


-- 
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.