5

I know that TLS ciphers such as TLS_RSA_WITH_AES_128_CBC_SHA transmit data as shown. From my understanding, the ciphertext must be a multiple of the block size, which in this case is 16 bytes. However, when I look at the below output from Wireshark, I'm confused.

After subtracting the 16 bytes corresponding to the IV from the beginning of the Encrypted Application Data, that leaves 100 bytes of ciphertext which is obviously not a multiple of 16. What am I not understanding?

EDIT: Based on the structure of the struct in the above link, I was under the impression that the MAC was appended to the plaintext prior to encryption and thus included in the ciphertext.

Wireshark Output

Improve this question

1 Answer 1

Reset to default
4

The final SHA in TLS_RSA_WITH_AES_128_CBC_SHA also means (among other things) that every packet has an HMAC-SHA-1 tag, to ensure the data has not been tampered with. This has length 20 bytes, as this is the digest length of SHA-1. So of the 116 bytes, the final 20 are this tag and we are left with 96 = 6 times 16 pure ciphertext (AES-CBC) bytes, the first 16 are the IV needed for the CBC mode, and there is some padding at the end but we have about 4 to 5 blocks of actual application data in here.

Improve this answer
2
  • Only if both endpoints implement the option/extension for encrypt-then-mac rfc7366 which IME is rare. 'Basic' TLS does HMAC before CBC-with-padding-to-blocksize.
    – dave_thompson_085
    Jun 18, 2018 at 1:01
  • @dave_thompson_085 Well, encrypt-then-mac seems the only explanation for the length we see. Maybe the OP could look at the handshake more closely.
    – Henno Brandsma
    Jun 18, 2018 at 22:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.