2

I'm implementing a TLS-like system, and I'd like to set up a Finished message, to prevent the replay attacks.

As far as I understand TLS, it contains a hash on the previous handshake messages. This hash is then encrypted and signed with the negociated algorithm.

My question is about what to hash in this message. It isn't specified in the chapter about the Finished message, in the RFC...

Is it the messages (non-ciphered), or rather what was sent through the network (and which have been encrypted/signed) ?

Community
  • 1
3isenHeim
  • 313
  • 2
  • 13

1 Answers1

6

In SSL/TLS, what is hashed is the handshake messages, i.e. the unencrypted contents. The hash input includes the 4-byte headers for each handshake message (one byte for the message type, three bytes for the message length); however, it does not contain the record headers, or anything related to the record processing (so no padding or MAC). The "ChangeCipherSpec" message (a single byte of value 1) is not a "handshake message" so it is not included in the hash input.

Each handshake message may be split over several records; similarly, a single record may contain several handshake messages. This splitting and merging has no impact on the hashing process.

This is actually specified in the RFC:

  handshake_messages
     All of the data from all messages in this handshake (not
     including any HelloRequest messages) up to, but not including,
     this message.  This is only data visible at the handshake layer
     and does not include record layer headers.  This is the
     concatenation of all the Handshake structures as defined in
     Section 7.4, exchanged thus far.

Mandatory note: it must be stated that designing a protocol such as SSL/TLS is very hard; a lot of some details can be wrong and jeopardize security. The actual TLS got it wrong in several points, and this triggered a lot of trouble (see this answer). Defining your own protocol, and making your own implementation, are OK for purposes of learning or simply having fun, but I urge you to reconsider any velleity at deploying such things for production use.

Community
  • 1
Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • Thanks for the quick and complete answer ! I'm aware of the dangers of handmade cryptosystems, but in the case I'm working on, we simply *cannot* do otherwise. And that's why I look first deep into TLS to understand it. – 3isenHeim Mar 31 '16 at 14:47