LDAP SSL malformed packet causing error in decoding

Question

Hi everybody,

I'm trying to debug LDAP SSL communication and experience a problem with SSL decryption. After a malformed packet is seen from the client, all the client data are no longer decoded by wireshark. Kindly note that the server data is still decoded by wireshark and the SSL debug file shows some information of the data that was no decrypted in wireshark.

Below is the link to the ssl debug log and a snapshot of the packets as seen in wireshark

SSL debug: link text

image: link text

Could you advise me on a way to resolve that issue so that I could decode all the packets? Could it be a bug?

Thank you

Answer 1

Let's have a look at the 'malformed' frame #21 in the debug log.

dissect_ssl enter frame #21 (first time)
  conversation = 0000000007AFC998, ssl_session = 0000000007AFCFA8
  record: offset = 0, reported_length_remaining = 202
dissect_ssl3_record: content_type 23 Application Data
decrypt_ssl3_record: app_data len 32, ssl state 0x3F
packet_from_server: is from server - FALSE
decrypt_ssl3_record: using client decoder
ssl_decrypt_record ciphertext len 32
Ciphertext[32]:
| 2d 62 f5 53 ae 48 a8 54 91 eb 4e 92 3b ff 5f 2b |-bõS®H¨T‘ëN’;ÿ_+|
| f5 e6 4c 49 ad 52 38 88 9a af e7 8e da 68 4c e1 |õæLIR8.š¯çŽÚhLá|
Plaintext[32]:
| 30 b5 c5 d7 ce 5b d2 41 c9 e3 a8 88 1b 45 b5 e0 |0µÅ×Î[ÒAÉã¨..Eµà|
| 2d f8 2e 22 80 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a |-ø."............|
ssl_decrypt_record found padding 10 final len 21
checking mac (len 1, version 301, ct 23 seq 2)
tls_check_mac mac type:SHA1 md 2
Mac[20]:
| b5 c5 d7 ce 5b d2 41 c9 e3 a8 88 1b 45 b5 e0 2d |µÅ×Î[ÒAÉã¨..Eµà-|
| f8 2e 22 80                                     |ø.".            |
ssl_decrypt_record: mac ok
ssl_add_data_info: new data inserted data_len = 1, seq = 64, nxtseq = 65
association_find: TCP port 46329 found 0000000000000000
association_find: TCP port 8400 found 0000000006DEFED0
dissect_ssl3_record decrypted len 1
decrypted app data fragment[1]:
| 30                                              |0               |
dissect_ssl3_record found association 0000000006DEFED0

As you can see, the decrypted data part (only one byte: 0x30) is not a valid LDAP frame (obvious). The question is, why the dissector believes there is only 32 bytes of ‘app_data len’, whereas the frame len itself is 268 bytes. That does not match. Interesting: The frame and the MAC get decrypted correctly!??!

This could be a dissector bug. Is the frame in question somehow fragmented (at IP level)?

Please open a bug request at https://bugs.wireshark.org

HOWEVER to be able to debug this particular problem, you would have to provide some ‘private’ data, as

the capture file itself
the server key

I’m not sure if that’s possible, as the ssl debug log suggests you have taken the capture file at a production site !?!

Regards
Kurt