Dependiendo de cómo lo veas, hay uno, dos, tres o muchos más "apretones de manos".
Una primera distinción es entre "SSL-2.0" y "SSL-3.0 y versiones posteriores". El formato de los registros y los mensajes de intercambio para SSL-2.0 difiere mucho de los registros y mensajes utilizados en las versiones de protocolo posteriores. Además del formato y los algoritmos implementados, una diferencia notable entre semántica entre SSL-2.0 y las versiones posteriores del protocolo es que en SSL-2.0, ambos el cliente y el servidor envían listas de paquetes de cifrado, y el cliente elige, no el servidor. En versiones posteriores, el cliente envía una lista y el servidor elige.
Al realizar un protocolo de enlace SSL-3.0 +, el cliente envía un mensaje ClientHello y el servidor responde con un ServerHello . El ClientHello puede contener muchas extensiones , que son (por definición) abiertas, y depende de usted considerar si las extensiones "cambian" el protocolo de enlace o no. En cualquier caso, si el cliente y el servidor acuerdan reanudar una sesión (reutilizan una ID de sesión y recuerdan la sesión pasada o el cliente envía un ticket de sesión , luego obtienes el protocolo de enlace abreviado :
Client Server
ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
En todos los demás casos, obtienes el saludo "normal", que se ve así:
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
El " * " anterior significa que el mensaje no siempre está ahí. Por ejemplo, el servidor enviará un ServerKeyExchange solo si la suite de cifrado solicita un mensaje de este tipo ("ECHDE_RSA" implica un mensaje de este tipo, mientras que "RSA" solo no lo hace).
Esto lleva a una serie de combinaciones posibles de mensajes enviados o no enviados. Además, una serie de RFC adicionales definen algunos mensajes extra , que no aparecen en el diagrama anterior; p.ej. RFC 5077 define un nuevo mensaje de reconocimiento NewSessionTicket que puede aparecer justo antes de ChangeCipherSpec del servidor. De manera similar, RFC 6066 define los nuevos tipos de mensajes CertificateURL y CertificateStatus . RFC 4680 también define SupplementalData que el cliente y el servidor pueden enviarse entre sí.
La forma en que elija clasificar todas estas características, y si inducen diferencias notables , depende de usted. Además, no puede haber una lista definitiva y exhaustiva de variantes, ya que las nuevas extensiones que activan nuevos tipos de mensajes o nuevos flujos de reconocimiento pueden definirse después.