ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: [Wireshark-dev] Catch 22 in SSL dissector?

From: Sake Blok <sake@xxxxxxxxxx>
Date: Sat, 14 Apr 2007 13:00:24 +0200
Hi All,

Because of a recent discussion on the users list about malformed
SSL packets, I discovered a bug in the SSL dissector I am trying
to fix. The bug I discoveres appears in a SSL handshake after the
change cypher spec. The next SSL handshake record is encrypted. It 
is indeed shown as a "Encrypted Handshake Message" most of the 
times. But if the first octet of the Encrypted Handshake happens
to be a valid Handshake Type, then the SSL dissector tries to
dissect it and fails. This results in a malformed packet.

In trying to solve this, I thought I could use the struct
SslDecryptSession which keeps the state of the ssl session. 
Unfortunately this struct is only filled on the first pass and
not in the second pass when the protocol tree is being built.
When the SSL session is decrypted, this is not a problem, 
because the data passed to dissect_ssl3_handshake is already
decrypted. But when the SSL session in not decrypted, I need
this state information to determine if the next SSL header needs
to be dissected.

I guess that this approach is simply not possible, since building
the protocol tree is like "random access", each packet can be
selected at random, so the state information can't be kept.

Is there a way to keep some state-information per packet? I
don't know exactly what is kept in the conversations, but I guess
that it is on a flow basis, not on a packet basis. Are there 
any other protocols where dissection depends on a per-packet
state? How do they do that?

If a per-packet state is not possible, then I could fix this 
bug with the workaround to do a sanity check on the length
of the SSL-handshake. But, that would be a workaround, not
a fix :(

Cheers,


Sake