Server — ServerKeyExchange

Questo messaggio contiene i parametri dell’algoritmo di scambio delle chiavi di cui il client ha bisogno dal server per ricavare segreti intermedi che verranno utilizzati quando si costruiscono le chiavi della sessione finale per la crittografia simmetrica da entrambe le parti. È facoltativo, poiché alcuni algoritmi di scambio di chiavi come RSA key exchange non richiedono questi parametri, poiché il certificato del server stesso sarà sufficiente per il client per costruire e comunicare in modo sicuro il segreto pre-master con il server.

Ad es. se il metodo di scambio di chiavi scelto dal server in un passaggio precedente è Diffie-Hellman (DH), il server include questo messaggio dopo il certificato, che includerà i componenti pubblici necessari per generare il segreto principale.

Server — CertificateRequest

Questo messaggio verrà inviato, se l’autenticazione client SSL è abilitata nel server. Questo non è normalmente richiesto nella maggior parte dei server Web, ma per i requisiti di sicurezza elevati, il server può richiedere il certificato del client per l’autenticazione. Insieme alla richiesta di certificato, il sever invia i tipi di client che sono accettabili e indica anche un elenco di nomi distinti di autorità di certificazione attendibili dal server. Questo elenco include le autorità CA disponibili nel truststore del server.

Server — ServerHelloDone

Infine, il server invia il messaggio ServerHelloDone che indica al client che il server è finito passando parametri di sicurezza. Questo messaggio termina la parte del server della negoziazione della stretta di mano. Questo messaggio non contiene altre informazioni.

Client — Certificate

Il client risponde con un certificato client se il server richiede l’autenticazione client con il messaggio di richiesta del certificato. Tuttavia, prima dell’invio del certificato, il client verificherà che il DN dell’emittente del certificato del client possa essere trovato nell’elenco dei nomi distinti delle CA attendibili inviate dal server. Se il DN dell’emittente non è stato trovato, il client non invierà il certificato al server. Nel lato server se l’autenticazione del certificato client è obbligatoria, l’handshake TLS fallirà qui. In caso contrario, il client invierà il proprio certificato e tutti i certificati intermedi necessari che si concatenano al DN corrispondente elencato nel messaggio di richiesta del certificato.

Client — ClientKeyExchange

Il messaggio ClientKeyExchange contiene il segreto pre-master, che viene generato dal client. Questo è condotto secondo la suite cipher aggreed da entrambe le parti in un passaggio precedente. Sia il client che il server lo useranno per generare un segreto principale da cui entrambi deriveranno le chiavi crittografiche finali necessarie per stabilire il canale codificato. Il client crittografa il segreto pre-master con la chiave pubblica del server in modo tale che se un intercettatore dovesse intercettare questo bit di dati non sarà in grado di decrittografarlo poiché non ha accesso alla chiave privata del server. La chiave master fornisce al server i dati necessari per generare le chiavi per la crittografia simmetrica. Tuttavia, se la suite di crittografia scelta per questa sessione era DH, ClientKeyExchange contiene i parametri DH pubblici del client anziché un segreto pre-master.

Client — CertificateVerify

Questo messaggio viene utilizzato dal client per dimostrare al server di possedere la chiave privata corrispondente al relativo certificato di chiave pubblica. Il messaggio contiene informazioni hash (hash di tutti i messaggi scambiati finora durante il processo di handshake) che sono firmati digitalmente dal client. È necessario se il server ha emesso un CertificateRequest al client, in modo che il client abbia inviato un certificato in risposta che deve essere verificato sul lato server.

Client — ChangeCipherSpec

Il messaggio ChangeCipherSpec è solo un messaggio del client per informare il server che tutti i dati inviati dal client da qui in poi saranno crittografati utilizzando i parametri di sicurezza concordati. A questo punto, sia il client che il server hanno tutti i componenti necessari per generare il master secret e quindi derivare le chiavi di sessione crittografiche.
Entrambe le parti verificano che l’handshake sia proceduto come previsto e che entrambe abbiano generato chiavi identiche inviando un messaggio finale crittografato che indica l’un l’altro che CipherSuite è attivato.

Client — Finished

In primo luogo, il client invia un messaggio finito crittografato al server. Questo messaggio è un hash crittografico (message digest), di tutti i precedenti messaggi di handshake combinati, seguito da un numero speciale che identifica il ruolo del client, il segreto principale e il padding. Questo viene crittografato con la chiave di sessione appena generata e inviato al server.

Server — ChangeCipherSpec

Ora il server invia un messaggio ChangeCipherSpec al client per dire al client che tutti i dati dopo questo messaggio saranno crittografati.

Server — Finished

Il messaggio ChangeCipherSpec è seguito da un messaggio Finito crittografato dal server al client. Questo è un hash crittografico generato dal server, di tutti i componenti utilizzati durante il processo hanshake insieme a un numero speciale che identifica il ruolo del server.