Wireshark · Wireshark-users: Re: [Wireshark-users] Malformed SSL - Is it really?

["Small, James" <JSmall@xxxxxxxxxxxx>]

Hi Sake,

> > > [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.
> 

[Small, James] Sake, when I do that, these "SSL" frames no longer show
up as malformed, instead they show up as unreassembled:
No.     Time        Source                Destination           Protocol
Src Port Dst Port Delta       Info
    182 7.590722    172.24.101.100        172.24.100.107        SSL
443      1096     0.099158    [Unreassembled Packet]

Frame 182 (1314 bytes on wire, 1314 bytes captured)
Ethernet II, Src: StBernar_00:8c:e5 (00:07:e8:00:8c:e5), Dst:
Dell_00:be:6b (00:12:3f:00:be:6b)
Internet Protocol, Src: 172.24.101.100 (172.24.101.100), Dst:
172.24.100.107 (172.24.100.107)
Transmission Control Protocol, Src Port: 3128 (3128), Dst Port: 1096
(1096), Seq: 2330, Ack: 1407, Len: 1260
    Source port: 3128 (3128)
    Destination port: 1096 (1096)
    Sequence number: 2330    (relative sequence number)
    [Next sequence number: 3590    (relative sequence number)]
    Acknowledgement number: 1407    (relative ack number)
    Header length: 20 bytes
    Flags: 0x10 (ACK)
    Window size: 65535
    Checksum: 0x3d02 [correct]
    [SEQ/ACK analysis]
Hypertext Transfer Protocol
Secure Socket Layer
[Unreassembled Packet: SSL]


I guess I'm not sure if that's an error or not.  I was capturing from
the client, but does that mean that a reply from the server might have
gotten lost and caused this problem?  But if that were the case, I
should see a missing sequence number or retransmission in the stream
which I don't.

Also, as you suspected, transmitting via port 3128 is to a proxy, in
this case a St. Bernard iPrism Proxy Appliance.

> > Could you file this as a bug on bugzilla with a sample trace
> > (with the whole tcp-session if possible)?
> 

[Small, James] No problem if there's something wrong - at this point I'm
not sure.

Thanks,
  --Jim