I've tried to understand the content of the Finished message of TLS. I'm using WireShark to capture the traffic between my browser and the internet. I noticed a "strangeness" when the chosen ciphersuite is AES_GCM. Being it a stream-cipher, it has no padding, so, if I got it right, the data being sent in the Finished message should be:

  • 8 bytes Explicit Nonce
  • 12 bytes verify_data
  • 16 bytes authentication tag

That is, 36 bytes in total. The "problem" is that the Finished message packet size is 40 bytes.

And here it is:


enter image description here

Why is the message packet 40 bytes? And what are the red bytes?

And why does WireShark see two Hello Requests?

And another this... the Client answers with a 176 bytes packet:


enter image description here

What am I missing?

  • Are you sure this is not a decoding error? Anything after ChangeCipherSpec is encrypted. Are you sure it's not just WireShark trying to interpret some binary garbage that it can't decrypt? Jun 26, 2015 at 14:19

1 Answer 1


EDIT: I didn't realize when I answered, but this is a dupe of Crazy Finished Message in TLS

The decodings as HelloRequest are indeed as @Stackz suggests because Wireshark can't decode encrypted records. It tries anyway, and only if it detects a decode failure it suppresses the decode and displays "Encrypted Handshake Message". Here it didn't detect the decode was completely bogus.

Every handshake message (within a handshake record) begins with a prefix of 1-byte msg_type and 3-byte length, see https://www.rfc-editor.org/rfc/rfc5246#section-7.4 . Thus you have:
* 8 bytes explicit nonce
* 16 bytes encryption of 1byte=0x14 type, 3bytes=0x00000C len, 12bytes verify_data
* 16 bytes authtag

On the client side, maybe the client immediately initiated another handshake; 136 bytes is plausible for ClientHello, especially if "optimized" with knowledge what the server just agreed to.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .