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
_______________________________________________
Wireshark-users mailing list
[EMAIL PROTECTED]
http://www.wireshark.org/mailman/listinfo/wireshark-users

Reply via email to