Si alguna vez has navegado por una URL HTTPS a través de un navegador, habrás experimentado el SSL handshake. Aunque no lo note, el navegador y el sitio web están creando una conexión HTTPS mediante un handshake SSL unidireccional.
El objetivo principal de un handshake SSL es proporcionar privacidad e integridad de los datos para la comunicación entre un servidor y un cliente. Durante el Handshake, el servidor y el cliente intercambiarán información importante necesaria para establecer una conexión segura.
Hay dos tipos de handshakes SSL descritos como SSL unidireccional y SSL bidireccional (Mutual SSL). La diferencia entre ambos es que en el SSL unidireccional, sólo el cliente valida la identidad del servidor mientras que en el SSL bidireccional, tanto el servidor como el cliente validan la identidad del otro. Normalmente, cuando navegamos por un sitio web HTTPS, se utiliza un SSL unidireccional en el que sólo nuestro navegador (cliente) valida la identidad del sitio web (servidor). El SSL bidireccional se utiliza sobre todo en la comunicación de servidor a servidor, en la que ambas partes deben validar la identidad de la otra.
Durante un apretón de manos SSL, el servidor y el cliente siguen el siguiente conjunto de pasos.
1. Hola del cliente
El cliente enviará la información que será requerida por el servidor para iniciar una conexión HTTPS.
En el registro anterior, podemos ver que el cliente saluda con TLS v1.2. Con esto, el cliente notifica al servidor que tiene el soporte para las versiones de TLS 1.2 e inferiores. La lista de cifrados soportados por el cliente también se puede ver en el registro anterior. De esta lista, el servidor seleccionará un conjunto de cifrado que soporte. Si la lista contiene suites de cifrado que el servidor no reconoce, no soporta o no desea utilizar, el servidor ignorará esos cifrados. Si no se encuentran suites de cifrado soportadas, el servidor enviará una alerta de fallo y cerrará la conexión.
2. Server Hello
El servidor responderá de vuelta con la configuración que seleccionó del Client Hello junto con su información para proceder con el handshake. El Hello del servidor será el siguiente.
Se seleccionará la versión TLS según la menor de las sugeridas por el cliente en el mensaje Hello del cliente y la más alta soportada por el servidor. El servidor también devolverá el conjunto de cifrado que seleccionó de la lista de cifrados presentada por el cliente.
Junto con el Server Hello, el servidor también enviará el certificado del servidor con la cadena de certificados. La cadena de certificados se validará con los certificados del almacén de confianza del cliente.
3. Mensaje de Intercambio de Claves del Servidor
Este mensaje será enviado por el servidor al cliente llevando los detalles requeridos para que el cliente genere el secreto pre-maestro. Este mensaje no se enviará si se utiliza el algoritmo de intercambio de claves RSA (más adelante) o cualquier otro algoritmo de intercambio de claves que no requiera la información del servidor para generar un secreto premaster.
Para el intercambio de claves de Curva Elíptica Diffie Hellman(ECDH), los siguientes detalles sobre la clave pública ECDH del servidor se envían al cliente.
4. Solicitud de Certificado
Este es el lugar donde SSL unidireccional difiere de SSL bidireccional. En el SSL unidireccional, la autenticidad del cliente no se valida. Por lo tanto, este paso se omite en el handshake SSL unidireccional.
Durante este paso, el servidor enviará una solicitud de certificado del cliente con el tipo de certificado, los algoritmos de firma del certificado y las autoridades de certificación admitidas por el servidor. Puede haber situaciones en las que la lista de autoridades de certificación puede estar vacía. En tales escenarios, el cliente puede elegir si enviar o evitar el envío del certificado del cliente (depende de la implementación del cliente)
Por último, el servidor envía el mensaje Server Hello Done indicando el final del Server Hello. Después de enviar este mensaje, el servidor esperará una respuesta del cliente.
5. Certificado del cliente
El cliente presenta su cadena de certificados al servidor. El certificado debe ser apropiado para el algoritmo de intercambio de claves del conjunto de cifrado negociado, y cualquier extensión negociada.
6. Mensaje de intercambio de claves del cliente
Este mensaje debe ser enviado por el cliente después del mensaje de certificado del cliente. Si no se presenta el certificado del cliente (en SSL unidireccional), el mensaje de intercambio de claves del cliente debe enviarse después de que el cliente reciba el mensaje ServerHelloDone.
Como todos sabemos los datos transferidos entre el servidor y el cliente en una conexión HTTPS serán encriptados. Para ello se utiliza el cifrado simétrico ya que el coste computacional es mucho menor que el cifrado asimétrico. Para utilizar el cifrado simétrico, es necesario que haya una clave común entre los dos extremos. El propósito de este mensaje es generar esa clave común entre ese cliente y el servidor sin exponerla a un extraño.
Hay dos métodos de intercambio de claves de cliente descritos en la especificación TLS v1.2. Son RSA y Diffie-Hellman.
Si se utiliza RSA como algoritmo de intercambio de claves, el cliente genera un secreto premaster de 48 bytes. El cliente encripta el secreto pre-maestro mediante la clave pública del certificado y lo envía al servidor. Sólo el servidor tendrá la clave privada correspondiente para descifrar y obtener el secreto premaster generado por el cliente.
Si se utiliza Diffie-Hellman, los parámetros de Diffie-Hellman se transmiten para permitir que tanto el cliente como el servidor generen el mismo secreto premaster.
Después, ambos lados generarán un secreto maestro utilizando el secreto premaster y el secreto maestro se utilizará para generar la clave simétrica para cifrar los datos de la sesión
7. Finished
Después de la autenticación exitosa y la generación de los secretos pre-maestros/maestros, se enviará un mensaje change cipher spec por parte del cliente y del servidor indicando que el resto de la comunicación será encriptada.
El mensaje Finished seguirá inmediatamente al mensaje change cipher spec. Este será el primer mensaje cifrado con los algoritmos negociados. Los datos de la aplicación serán transferidos sólo después de que ambas partes envíen el mensaje finished y verifiquen el contenido del mensaje.
https://tools.ietf.org/html/rfc5246
https://docs.microsoft.com/en-us/windows/desktop/secauthn/cipher-suites-in-schannel
https://www.websecurity.symantec.com/security-topics/what-is-ssl-tls-https
https://docs.apigee.com/api-platform/system-administration/keystores-and-truststores
https://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman
https://www.globalsign.com/en/ssl-information-center/what-are-certification-authorities-trust-hierarchies/
https://www.geeksforgeeks.org/rsa-algorithm-cryptography/
https://www.acunetix.com/blog/articles/establishing-tls-ssl-connection-part-5/