La tua domanda non è chiara, ma risponderò a ciò che posso capire. Ma in primo luogo, il riferimento definitivo per i protocolli TLS sono gli RFC di base 2246, 4346 e 5246, estesi da altri RFC quando vengono utilizzate alcune funzioni opzionali (come alcune estensioni); dovresti leggere quelli per domande così dettagliate.
Il messaggio Finished contiene il PRF di il segreto principale, un indicatore di direzione e un hash dei messaggi di handshake (escluso HelloReq se usato). Non esiste un 'id-connessione' in SSL / TLS, ma esiste un 'id-sessione' che è solitamente (non sempre) inviato dal server in ServerHello ; l'intero ServerHello insieme a tutti gli altri messaggi di handshake, è incluso nell'hash di handshake.
I messaggi
Finished vengono inviati in ogni direzione (da client a server e da server a client); la sequenza dipende dal fatto che si esegua una stretta di mano completa o una abbreviata (ripresa). I messaggi Finished , come tutti i messaggi che seguono ChangeCipherSpec , sono crittografati e HMACed (o crittografati con AEAD che non necessitano di un HMAC) utilizzando chiavi derivate dal segreto principale più sia client che server nonces. La decifratura corretta e l'autenticazione di Finished dimostrano essenzialmente un accordo sul master secret, e poiché deve essere il PRIMO messaggio crittografato di questo tipo, garantisce il rilevamento di una mancata corrispondenza prima che i dati dell'utente siano eventualmente esposti.
La riproduzione di un messaggio nella stessa connessione può essere ignorata o violata dal protocollo e quindi inutile. Immagino che il tuo attacco previsto riproduca un Finished precedentemente valido come parte di un nuovo tentativo di connessione falsa di qualche tipo. Se usi lo stesso Finished per un diverso handshake, non corrisponde e fallisce. Funzionava solo se si poteva fare di nuovo la stessa stretta di mano, ma non si può perché almeno il nonce, e in molti casi anche qualche input premaster, viene nuovamente selezionato dall'altro (legittimo) partito e diverso.