2

In many examples I came across while researching this issue, length = 12 is mentioned.

However:

According to the RFC, verify_data length is always 12 in older versions. However, in TLS 1.2, the length may be longer - depending on the cipher suite.

    struct {
              opaque verify_data[verify_data_length];
          } Finished;

          verify_data
             PRF(master_secret, finished_label, Hash(handshake_messages))
                [0..verify_data_length-1];

In previous versions of TLS, the verify_data was always 12 octets
      long.  In the current version of TLS, it depends on the cipher
      suite.  Any cipher suite which does not explicitly specify
      verify_data_length has a verify_data_length equal to 12.  This
      includes all existing cipher suites.  Note that this
      representation has the same encoding as with previous versions.
      Future cipher suites MAY specify other lengths but such length
      MUST be at least 12 bytes.

verify_data is defined as a PRF using a certain algorithm. AFAIK and according to rfc4868, when using SHA384, the PRF output length will be 48 and not 12.

   PRF-HMAC-SHA-384 = afd03944d84895626b0825f4ab46907f
                      15f9dadbe4101ec682aa034c7cebc59c
                      faea9ea9076ede7f4af152e8b2fa9cb6

I also recorded a PCAP of an SSL stream that uses SHA384, and the verify_data length is 12:

cipher in server hello

finished message

What should be the structure and the length of finished message when using SHA384?

Thanks!

Inna
  • 21
  • 1

1 Answers1

1

This discussion is about the issue. You may find it interesting, while I don't see there answer to your question.

dimba
  • 26,717
  • 34
  • 141
  • 196