On Thu, Apr 12, 2007 at 10:09:41PM +0200, Sake Blok wrote:
> > Transmission Control Protocol, Src Port: 3128 (3128), Dst Port: 1136 (1136), Seq: 9184, Ack: 1341, Len: 1260
> > Hypertext Transfer Protocol
> > Secure Socket Layer
> > TLSv1 Record Layer: Application Data Protocol: http
> > Content Type: Application Data (23)
> > Version: TLS 1.0 (0x0301)
> > Length: 1048
> > Encrypted Application Data: 986EF11CE4141826D529372C664768C27C0E749FFC4BB768...
> > [Malformed Packet: SSL]
> >
> > Is the packet really malformed, or is it possible that Wireshark
> > doesn't support the cipher being used? If so, is there any way to
> > tell if the packet is really malformed versus Wireshark just not
> > understanding it/the encryption scheme?
Oh, it could also be that there are frames missing in the tcp-stream.
That means the ssl-dissector can't reassemble it's stream properly
and that creates a "malformed" packet. You can check this by
disabling the "Allow subdissector to reassemble TCP streams"
option in the tcp protocol preferences. The "malformed" message
will then disappear.
> Could you file this as a bug on bugzilla with a sample trace
> (with the whole tcp-session if possible)?
Only if it is not a reassembly issue of course :)
Cheers,
Sake