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

Decrypt application data pending DTLS abbreviated handshake using PSK

0

Hi,

I try to decrypt application data after an abbreviated handshake on DTLS using PSK (TLS_PSK_WITH_AES_128_CCM_8). My capture contain the first full handshake followed by decrypted application data. Then an abbreviated handshake, followed by several application data.

Problems:

  1. All the handshaked messages from abbreviated handshake are considered as Encrypted Handshake Message. (This is not a renegociation, this is an abbreviated handshake (epoch 0), so this should not be considered as an Encrypted Hanshake Message ?)
  2. Application Data can not be decrypted.

I use wireshark 2.2.0 on debian. I get the same behavior on MacOS same wireshark version.

I see there is a commit about abbreviated handshake in master : https://github.com/wireshark/wireshark/commit/10e84a612b629341acd9cd20876517e5bab63d37 I compiled master (v2.3.0rc0-663-gcea1737) and get the same issue.

Any idea ?

Simon

asked 12 Sep '16, 07:03

sbern's gravatar image

sbern
6113
accept rate: 0%

edited 13 Sep '16, 05:56

grahamb's gravatar image

grahamb ♦
19.8k330206

Can you post your ssl debug log, or even better can you share a capture in a publicly accessible spot, e.g. CloudShark?

(13 Sep '16, 05:58) grahamb ♦

The capture is available here

(13 Sep '16, 09:39) sbern

For decryption issues it would be helpful if you could also include the PSK that can be used to decrypt the pcap.

(13 Sep '16, 15:31) Lekensteyn

Sry, here is the psk value : cf93a7b3e0d86382749ed25a7a2493e3

(14 Sep '16, 06:01) sbern

@grahamb, @Lekensteyn, did you find anything ?

(28 Sep '16, 02:13) sbern

@sbern Yes, it has something to do with the CCM cipher mode that is in use. I have reproduced a TLS capture with a bunch of AESCCM(8) ciphers and will eventually fix it, but first I'll try to fix an issue with the RSA keys dialog. I will keep you updated.

(28 Sep '16, 04:30) Lekensteyn

@sbern I found the issue (CCM cipher was not correctly configured) and have a possible fix (but it needs to be polished). Can you open a bugreport at https://bugs.wireshark.org/bugzilla/ and upload a sample capture plus PSK? The link you posted is dead.

(29 Jan '17, 08:00) Lekensteyn

@Lekensteyn, I opened an issue : https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13370

I'm not totally sure if I uploaded exactly the same capture. I hope this one will do the job.

(30 Jan '17, 06:00) sbern
showing 5 of 8 show 3 more comments

One Answer:

0

Thanks for reporting the bug (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13370)!

The issue was that the capture contains a new session on the same source/destination address/port tuple. When decryption is enabled, Wireshark thinks that all following traffic is encrypted. Though in your case, there is actually a new session (which starts unencrypted).

Under the assumption that traffic is encrypted, Wireshark starts decrypting the traffic which results in garbage (since it was not really encrypted). Hence the confusing "Encrypted Handshake Message" interpretations. Normally the message authentication code (MAC) check would catch this and prevent the garbage from being used, but this check is limited to non-AEAD ciphers in Wireshark 2.2.x.

Correct validation of the authentication tag for AEAD ciphers like AES-CCM-8 (and also AES-GCM) is added to the current development version (v2.3.0rc0-2204-g8938a311ea) and will interpret the capture correctly. This fix will be released with Wireshark 2.4 (will be released in summer of 2017).

answered 31 Jan '17, 09:11

Lekensteyn's gravatar image

Lekensteyn
2.2k3724
accept rate: 30%