Ask Your Question
0

Failure to "decode as" for LDAPS

asked 2022-01-24 11:44:19 +0000

bunnis gravatar image

updated 2022-01-24 16:51:08 +0000

Hello

I recently did a capture for LDAPS traffic and I have the sslkeys file for this session. Wireshark is decrypting the packets, however even if I set the traffic as "decode as" to LDAP, it doesn't show me the data as the normal LDAP view.

I did some googling and other people had a similar issue but were able to fix it. For example: https://ask.wireshark.org/question/25...

Could this be a bug with "Decode as" for LDAP protocol?

https://imgur.com/a/iQkTJkp

image:

PS: Im using wireshark 64 bit 3.6.1

edit retag flag offensive close merge delete

Comments

Yes I checked, as you can see from the image, Wireshark identifies by himself the Application Data Protocol. The packet view is always the same regardless of the "decode as" setting

bunnis gravatar imagebunnis ( 2022-01-24 12:47:17 +0000 )edit

As you can see, that field has "[]" around the name, this indicates its synthesized by Wireshark and can be set by a number of methods, often because of the port the TLS session is running on. This does not indicate a successful decryption.

You should configure Wireshark to create a TLS debug file (TLS preferences) and post that here.

grahamb gravatar imagegrahamb ( 2022-01-24 14:26:08 +0000 )edit

I tried to create the TLS debug file, however the file is always empty. I'm using a "pre master secret log file" instead of RSA key list, could it be because of that?

What I can confirm is that I see the Client Random of the particular connection in the sslkeys file. I can also see that the TLS handshake contains the Client Key Exchange and the Server Key Exchange. At the end of the stream I see an Encrypted Alert, suggesting that the stream is indeed not decrypted - which sounds weird to me.

There are additional encrypted HTTPS stream on this capture, which are successfully decrypted. I have also validated the same as above.

bunnis gravatar imagebunnis ( 2022-01-24 16:50:50 +0000 )edit

I've never come across the TLS debug file not being created when required. The debug log doesn't care how the keying material is provided.

HTTPS isn't LDAPS. Are you capturing on the LDAP client, if so what application is making the connection to the LDAP server? If it's regular Windows apps or the OS, it's likely they're using SChannel for TLS which does NOT generate keying material for decryption.

grahamb gravatar imagegrahamb ( 2022-01-24 17:03:50 +0000 )edit

The file is created, however no data is present. I'm capturing on a Netscaler, which can handle many types of protocols, like HTTPS and LDAP/LDAPS. So I have both protocols in the same capture, and also the keys for these connections. Note, I'm actually using the portable version of Wireshark, do you think that could have something to do with the debug file not outputing anything?

bunnis gravatar imagebunnis ( 2022-01-24 21:01:11 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2022-01-24 12:36:43 +0000

grahamb gravatar image

Are you sure the SSLKEYLOGFILE has keying material generated by the LDAP client or server?

edit flag offensive delete link more

Comments

After double-checking I found that the corresponding client random was not present in my ssl keys file. I must have made a mistake while checking it.

I'm closing this question and thank grahamb for his help.

bunnis gravatar imagebunnis ( 2022-01-25 10:25:55 +0000 )edit

We don't normally close answered questions here, instead the answer that helped solve the issue is "accepted" by clicking the checkmark icon to the left of it. This helps other users with similar questions.

I've converted my comment that seems to be the most appropriate into an answer.

grahamb gravatar imagegrahamb ( 2022-01-25 11:04:37 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2022-01-24 11:37:47 +0000

Seen: 952 times

Last updated: Jan 25 '22