This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Malformed 32 byte TLS/SSL packet

0

I have the following packet when trying to examine an SSL session. This is a local capture but I have a capture from the target network as well. I see the same packet on both ends.

Frame 16: 540 bytes on wire (4320 bits), 540 bytes captured (4320 bits)
Internet Protocol Version 4, Src: 172.20.2.164 (172.20.2.164), Dst: 169.20.69.250 (169.20.69.250)
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total Length: 526
    Flags: 0x02 (Don't Fragment)
    Header checksum: 0x790d [correct]
Transmission Control Protocol, Src Port: 57599 (57599), Dst Port: https (443), Seq: 2331060189, Ack: 18913651, Len: 474
Checksum: 0x56c7 [validation disabled]
Secure Sockets Layer
     TLSv1 Record Layer: Application Data Protocol: tcp
        Content Type: Application Data (23)
        Version: TLS 1.0 (0x0301)
        Length: 32
        Encrypted Application Data: 6a19a737cd1b4b0478dadd0a907f3b48fe6ba2b1c4a0bc6d...
    [Malformed Packet: TCP]
        Expert Info (Error/Malformed): Malformed Packet (Exception occurred)

IP's have been changed but the issue is the TLS record length. This is the packet being transmitted and received and the server is able to decrypt and process it correctly. The packet is what I believe to be the "GET" request. I just don't understand why the TLS length is so short. This is not part of a fragment. I am using the WireShark 1.6.2. Is this a problem with WireShark or the traffic? This is not a one off packet, my session contains multiple "malformed" 32 length TLS records, always from my client to the server.

asked 19 Jun '12, 09:34

DigitalCowboy's gravatar image

DigitalCowboy
1111
accept rate: 0%

I found that WireShark appears to be ignoring the followup SSL data, after that first 32 byte chunk (which decrypts to a G) there is another SSL record that is not being parsed correctly. Is this error fixed in later versions of WireShark?

(19 Jun '12, 14:05) DigitalCowboy

One Answer:

0

There is only one way to to be sure whether this issue has been fixed in a later release and that is to test it with a later release. But as I have not seen this kind of behavior with the SSL dissector, my guess is it is a bug triggered by your specific capture that might not have been fixed yet.

If the problem still exists with the latest 1.6.x release, please file a bug report on https://bugs.wireshark.org and attach the capture file (you can mark it as private to make it only available to the core-developers).

answered 20 Jun '12, 06:05

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%