This is our old Q&A Site. Please post any new questions and answers at


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.


  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 : I compiled master (v2.3.0rc0-663-gcea1737) and get the same issue.

Any idea ?


asked 12 Sep '16, 07:03

sbern's gravatar image

accept rate: 0%

edited 13 Sep '16, 05:56

grahamb's gravatar image

grahamb ♦

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 and upload a sample capture plus PSK? The link you posted is dead.

(29 Jan '17, 08:00) Lekensteyn

@Lekensteyn, I opened an issue :

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

Thanks for reporting the bug (!

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).

permanent link

answered 31 Jan '17, 09:11

Lekensteyn's gravatar image

accept rate: 30%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 12 Sep '16, 07:03

question was seen: 2,358 times

last updated: 31 Jan '17, 09:11

p​o​w​e​r​e​d by O​S​Q​A