Il client suggerisce ma il server sceglie . Il client invia una lista delle suite di crittografia supportate (ed è disposta ad utilizzare). Questo elenco dovrebbe essere ordinato di preferenza. Il server risponde scegliendo una suite di crittografia in questo elenco. I server ben educati cercano di seguire le preferenze dei clienti, ma questo non è veramente obbligatorio. In definitiva, il server sceglie.
Alla fine della stretta di mano, vengono inviati% messaggi diFinished, che sono crittografati e MACed con i segreti negoziati. I contenuti di questi messaggi sono valori hash calcolati sui messaggi handshake completi, incluso l'elenco di suite di crittografia supportate dal client. Ciò significa che un MitM non può alterare quell'elenco senza essere catturato a un certo punto.
(Tuttavia, questo non è del tutto vero in presenza di TLS FalseStart : il client potrebbe essere convinto di inviare la sua richiesta con la suite di crittografia più debole supportata, ma la vera debolezza qui sarebbe che il client è quindi disposto a supportare una suite di crittografia debole, non che un attacker di MitM abbia un certo livello di controllo nella scelta della suite di crittografia Anche con FalseStart, l'alterazione esterna da parte dell'utente malintenzionato verrà rilevata dal server e la richiesta non verrà rispettata, per non parlare della risposta.)
(SSLv2 non includeva l'elenco delle suite di cifratura nei suoi messaggi finiti ed è stato molto pubblicizzato come uno dei "grandi difetti" di SSLv2.)