https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3303
--- Comment #7 from Sake <[email protected]> 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. ___________________________________________________________________________ Sent via: Wireshark-bugs mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://wireshark.org/mailman/options/wireshark-bugs mailto:[email protected]?subject=unsubscribe
