3

I'm a little bit confused about the contents of Finished Message used during Handshake Protocol. In particular, this message (clientside) contains the connection-id originally sent from the server and it also contains a hash value derived from all previous handshake message and master secret.

So this message is encrypted with a key derived from master secret or only connection-id is encrypted, and Finish Message is still transmitted in plain?

Another question is about detecting replay attack serverside. The server receives Finished Message from client; how can server correctly detect a replay attack from Finished Message and why we use connection-id and hash only one isn't enough?

schroeder
  • 123,438
  • 55
  • 284
  • 319
Spartacus
  • 31
  • 1
  • 3

2 Answers2

8

There is no "connection-id" in the Finished messages. For that matter, there appears to be no "connection-id" concept at all in the whole SSL/TLS standard. The closest concept is that of a session ID, which is exchanged through the ClientHello and ServerHello messages, not the Finished messages. By definition, the session ID is not specific to a single connection.

The contents of the Finished message are a hash computed over all the previously exchanged handshake messages, in both directions. The Finished message being sent after the ChangeCipherSpec, it is protected with the newly negotiated cryptographic algorithms and keys, i.e. encrypted and MACed.

The protection against replay attack relies on the way the Finished message contents are computed: since the hash is done over all handshake messages, it includes, in particular, the client_random and server_random elements sent by both client and server. An attacker trying to do a replay cannot reuse both randoms, because, by definition, the attacker is replaying the client while talking to the genuine server, or replaying the server while talking to the genuine client.

As a SSL walkthrough, I recommend this answer.

Community
  • 1
Tom Leek
  • 168,808
  • 28
  • 337
  • 475
0

Your question isn't clear but I'll answer what I can understand. But first, the definitive reference for TLS protocols are the base RFCs 2246, 4346, and 5246, extended by other RFCs when some optional features (like certain extensions) are used; you should read those for such detailed questions.

The Finished message contains the PRF of the master secret, a direction flag, and a hash of the handshake messages (excluding HelloReq if used). There is no 'connection-id' in SSL/TLS, but there is a 'session-id' that is usually (not always) sent by the server in ServerHello; the entire ServerHello along with all other handshake messages, is included in the handshake hash.

Finished messages are sent in each direction (client to server and server to client); the sequence depends on whether you do a full handshake or an abbreviated one (resumption). The Finished messages, like all messages following ChangeCipherSpec, are encrypted and HMACed (or AEAD-encrypted which doesn't need an HMAC) using keys derived from the master secret plus both client and server nonces. Correct decryption and authentication of Finished essentially proves agreement on the master secret, and because it must be the FIRST such encrypted message, it guarantees detection of a mismatch before user data is possibly exposed.

Replaying a message in the same connection is either ignored or a protocol violation and thus useless. I'll assume your intended attack is replaying a previously valid Finished as part of a new, false connection attempt of some kind. If you use the same Finished for a different handshake, it doesn't match and fails. It could only work if you could do the same handshake again, but you can't because at least the nonce, and in many cases some premaster input also, is newly selected by the other (legit) party and different.

dave_thompson_085
  • 9,759
  • 1
  • 24
  • 28