A seconda di come lo vedi, ci sono uno, due, tre o molti altri "stretti di mano".
Una prima distinzione è tra "SSL-2.0" e "SSL-3.0 e versioni successive". Il formato dei record e dei messaggi di handshake per SSL-2.0 differisce molto dai record e dai messaggi utilizzati nelle versioni successive del protocollo. A parte il formato e gli algoritmi implementati, una differenza semantica tra SSL-2.0 e le versioni successive del protocollo è che in SSL-2.0, entrambi client e server inviano elenchi di suite di crittografia e il client sceglie, non il server. Nelle versioni successive, il client invia una lista e il server sceglie.
Quando si esegue un handshake SSL-3.0 +, il client invia un messaggio ClientHello e il server risponde con ServerHello . Il ClientHello può contenere molte estensioni , che sono (per definizione) aperte, e sta a te decidere se le estensioni "cambino" l'handshake o meno. In ogni caso, se il client e il server accettano di riprendere una sessione (riutilizzano un ID di sessione e ricordano la sessione passata, oppure il client invia un ticket di sessione , ottieni la stretta di mano abbreviata :
Client Server
ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
In tutti gli altri casi, ottieni l'handshake "normale", che assomiglia a questo:
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Il " * " sopra indica che il messaggio non è sempre lì. Ad esempio, il server invierà un ServerKeyExchange solo se la suite di crittografia chiama tale messaggio ("ECHDE_RSA" implica un tale messaggio, mentre "RSA" da solo non lo fa).
Quindi questo porta a un numero di possibili combinazioni di messaggi inviati o non inviati. Inoltre, un certo numero di RFC extra definisce alcuni messaggi extra , che non appaiono nel diagramma sopra; per esempio. RFC 5077 definisce un nuovo messaggio di handshake NewSessionTicket che può verificarsi prima di un ChangeCipherSpec dal server. Allo stesso modo, RFC 6066 definisce i nuovi tipi di messaggio CertificateURL e CertificateStatus . RFC 4680 definisce anche SupplementalData che sia il client che il server possono inviarsi l'un l'altro.
Come scegli di classificare tutte queste funzioni e se inducono differenze notevoli , dipende da te. Inoltre, non può esserci un elenco definitivo ed esauriente di varianti, dal momento che le nuove estensioni che attivano nuovi tipi di messaggi o nuovi flussi di handshake possono sempre essere definiti successivamente.