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

LDAP SSL malformed packet causing error in decoding

0

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

asked 09 Jan '14, 03:33

MSK's gravatar image

MSK
11113
accept rate: 0%

edited 09 Jan '14, 03:34


One Answer:

0

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 |õæLI­R8.š¯çŽÚ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

answered 12 Jan ‘14, 14:54

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

I was afraid that the both the capture and the key would be needed. Unfortunately this is not possible, i had a hard time posting the SSL debug log in itself. Is there another alternative that we can use? can i open a bug and provide the same information i provided here or it wouldn’t be enough?

The “Reassemble fragmented IPv4” option is checked and i have also noticed that this link http://ask.wireshark.org/questions/25156/ldap-ssl-decrypt-issue

describe the same issue (more or less)

Regards, MSK

(12 Jan ‘14, 23:09) MSK

can i open a bug and provide the same information i provided here or it wouldn’t be enough?

I believe without the key, there is no way to debug this, but of course you can try. Maybe one of the developers has seen that before, but had no time to fix it ;-)

The “Reassemble fragmented IPv4” option is checked

O.K. but is the frame itself part of a fragment (see the IP header options for fragmentation)

describe the same issue (more or less)

no, that’s a different problem as far as I could see.

(13 Jan ‘14, 07:06) Kurt Knochner ♦

HINT: you could try to decrypt the stream with ssldump (http://www.rtfm.com/ssldump/ - should be available in the repository of several Linux distributions). If that works, it’s a bug in the dissector. If ssldump fails to decrypt the traffic, your LDAP client messed up the encryption and/or the LDAP request.

(13 Jan ‘14, 07:10) Kurt Knochner ♦