In SSL / TLS, ciò che è hash è i messaggi di handshake , cioè i contenuti non crittografati. L'input dell'hash include le intestazioni a 4 byte per ogni messaggio di handshake (un byte per il tipo di messaggio, tre byte per la lunghezza del messaggio); tuttavia, non contiene le intestazioni dei record o qualsiasi cosa relativa all'elaborazione dei record (quindi nessuna padding o MAC). Il messaggio "ChangeCipherSpec" (un singolo byte di valore 1) non è un "messaggio di handshake" quindi non è incluso nell'input dell'hash.
Ogni messaggio di handshake può essere suddiviso su più record; allo stesso modo, un singolo record può contenere diversi messaggi di handshake. Questa suddivisione e fusione non ha alcun impatto sul processo di hashing.
Questo è effettivamente specificato nella 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.
Nota obbligatoria: si deve affermare che la progettazione di un protocollo come SSL / TLS è molto difficile ; molti dettagli possono essere errati e mettere a repentaglio la sicurezza. L'attuale TLS ha sbagliato in diversi punti e questo ha causato molti problemi (vedi questa risposta ). Definire il proprio protocollo e realizzare la propria implementazione, è OK per scopi di apprendimento o semplicemente per divertirsi, ma ti esorto a riconsiderare qualsiasi velleità nell'implementazione di queste cose per l'uso in produzione.