Wireshark-dev: [Wireshark-dev] [PATCH] Fix false malformed SSL handshake messages (Was: Catch 2
Hi,
Although I'm still interested in a theoretical answer to the
problem of keeping state info on a per packet basis (see below),
here is a workaround for the bug.
Could someone review this patch?
Cheers,
Sake
On Sat, Apr 14, 2007 at 01:00:24PM +0200, Sake Blok wrote:
> 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
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
Attachment:
fix-malformed-ssl.patch.gz
Description: application/gunzip
