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, encrypted and signed with the chosen algorithm.

The server first builds his Finished frame, with a hash of all the previous messages. Then it's sent to the client.

Does the client have to take the server's Finished message as a "previous message" ? (to compute a hash)

Because if not, the contents to hash are just the same as the server, but in a different order (which will produce a completely different hash).

They say this in the chapter on the Finished message :

All of the data from all messages in this handshake (not including any HelloRequest messages) up to, but not including, this message.

In my opinion, the client indeed has to take the received Finished message (from the server) along other handshake messages.

  • A hashing function gives an output ("hash") which is always of a constant length. For example, MD5 gives a 128-bit long string, SHA-1 gives 160 bits, SHA-2 gives 224, 256, 384, or 512 bits depending on the function used, and so on. – feral_fenrir Sep 22 '15 at 10:52
  • Oh yeah right, sorry for the mistake. – 3isenHeim Sep 22 '15 at 10:57
  • Finished is not signed but contains the keyed PRF of the hash of the prior messages plus nonces and a label. It is then protected by the newly-activated ciphersuite just as ApplicationData is; for most suites this is HMAC then encrypt, for some new TLS1.2 suites it is Authenticated Encryption (GCM or CCM) which does encrypt and MAC in a single primitive. All as stated in the RFC. – dave_thompson_085 Sep 22 '15 at 18:57
2

That section of the RFC also states:

The value handshake_messages includes all handshake messages starting at ClientHello up to, but not including, this Finished message. This may be different from handshake_messages in Section 7.4.8 because it
would include the CertificateVerify message (if sent). Also, the
handshake_messages for the Finished message sent by the client will
be different from that for the Finished message sent by the server,
because the one that is sent second will include the prior one.

The client sends its Finished message first, and then the server sends its message, including the previous Finished message from the client.

But won't be the hash too long ?

A cryptographic hashing algorithm always outputs hashes of the same length. Adding more length to the input does not increase the output length.

|improve this answer|||||

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.