https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3303
--- Comment #7 from Sake <sake@xxxxxxxxxx> 2009-04-22 13:49:12 PDT ---
(In reply to comment #6)
> Thanks a lot for the capture but most dissectors with multiple PDUs inside the
> same TCP segments create a new subtree for each PDU.
>
> I agree that your way make more sense but It's not a ssl specific bug.
Maybe the way to display multiple PDU's in one frame should be discussed on the
-dev list to get more peoples opinions. I totally agree that it's not a SSL
specific one :-)
> The fact that ServerHelloDone isn't displayed in the column info is a separate
> bug, for example the X11 dissector is able to get it right.
ACK, if multiple PDU's should be listed with multiple subtrees, then this would
ask for another solution indeed.
> What's bother me is that in my understanding your use of ONE_MORE_SEGMENT is
> incompatible with the caller function desegment_tcp().
As long as the dissector for the protocol that is using TCP as a transport is
able to split the data of the segment into PDU's, I think it's OK. But I must
admit I have not grasped the whole reassembly thing for a full 100%.
> For example if your look at the first attached capture, now ssl doesn't get the
> size of the PDU right (cf frame 14).
>
> About the bug report.
> In frame 14 the certificate is not decoded because its size is wrong (55326 for
> a TLS record size of 16384), the ssl dissector assumes that the handshake type
> is a false positive and gives up.
OK, back to the original bug :-)
I disagree with you here. The SSL record layer is responsible for fragmenting
SSL content into fragments of max 16384 (RFC 2246, par 6.2.1). The certificate
handshake message can be of a size up to 2^24-1 (RFC 2246, par 7.4.2). So in
this case, the SSL dissector should first instruct the TCP dissector to
reassemble the first SSL fragment of 16384 bytes. Then it will need to keep
that data in it's own fragment table and ask the TCP dissector to reassemble
the next SSL record of 16384 bytes, add it to the fragment table and so on,
until it has the whole 55326 bytes.
Of course with this trace this won't work, as IE has closed the connection
before the full 55326 bytes were actually transmitted. But I remember that
firefox did not have a problem with the certificate chain, so then Wireshark
should have been able to show the whole reassembled (at TCP & SSL) 55326 bytes
as a Certificate Handshake message (and it was not if I remember correctly, but
unfortunately, I don't have a trace of that situation).
I think we need to create a capture file with a >16384 bytes certificate that
does not get resetted halfway, so that we can work on a fix for this
fragmentation issue in SSL.
Cheers, Sake
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.