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.
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.