1
$\begingroup$

I'm currently looking at an encrypted Client Finished message in Wireshark from a TLS session. The cipher suite that was agreed on in previous messages was TLS_RSA_WITH_AES_256_CBC_SHA.

By my understanding, the encrypted message should have a Handshake Protocol header which is made up of the handshake type and the length. This should be 4 bytes in total. There should then be 12 bytes of verify_data, followed by a 20 byte MAC (SHA-1 digest size). This takes us to 36 bytes. Now according to RFC 2246 section 6.2.3.2, it should then be padded out so that the length in total is a multiple of the block length (in this case 16 for AES-256).

That means it should have 12 bytes of padding, where each padding value has a value of 12 (0x0C), followed by a padding length field which will also have a value of 12. What I don't understand is, if you add all that up, you get an encrypted length of 49 bytes, but the wireshark packet has 48 bytes.

Is anybody able to explain the difference?

$\endgroup$
2
  • $\begingroup$ For code use back ticks (` above the ~ on US keyboards, also known as "grave accent") instead of single quotes. $\endgroup$
    – Maarten Bodewes
    Aug 10, 2015 at 17:05
  • $\begingroup$ Sorry, wasnt aware that counted as code! :p $\endgroup$ Aug 10, 2015 at 20:52

1 Answer 1

3
$\begingroup$

In RFC2246, if you need 12 bytes of padding total, that means that you have 11 padding bytes, followed by a padding length field. So, each padding byte has a value of 11 (0x0b), as well as the padding length field. This is implied by the requirement that the total TLSCiphertext.length must be a multiple of the block size, and this TLSCiphertext.length includes the padding length field itself.

$\endgroup$
3
  • $\begingroup$ The confusing thing is, the example they give in RFC2246, shows that they need 6 bytes of padding, but then have 7 bytes with the number 6 in them... $\endgroup$ Aug 11, 2015 at 7:42
  • $\begingroup$ I take it if the padding size were 0, you would just have no padding and no padding length field? $\endgroup$ Sep 4, 2015 at 14:02
  • $\begingroup$ @chadianscot: no, you always have a padding length field. Otherwise, how would the decryptor know whether or not there is padding there? $\endgroup$
    – poncho
    Sep 4, 2015 at 15:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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