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:
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 edited 13 Sep '16, 05:56  grahamb ♦ showing 5 of 8 show 3 more comments |
One Answer:
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 |
Can you post your ssl debug log, or even better can you share a capture in a publicly accessible spot, e.g. CloudShark?
The capture is available here
For decryption issues it would be helpful if you could also include the PSK that can be used to decrypt the pcap.
Sry, here is the psk value : cf93a7b3e0d86382749ed25a7a2493e3
@grahamb, @Lekensteyn, did you find anything ?
@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.
@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.
@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.