Desmitificando el handshake TLS: Qué es y cómo funciona

El protocolo Transport Layer Security (TLS) está diseñado para añadir seguridad a las comunicaciones de red. Es la diferencia entre HTTP y HTTPS al navegar por Internet.

El uso de TLS genera trabajo adicional para el cliente y el servidor, pero ofrece beneficios, entre ellos:

•     Confidentiality: TLS wraps traffic in an encrypted tunnel.  This makes it impossible for an eavesdropper to read or modify the traffic on its way to its destination.
•     Authentication: TLS proves the identity of the server to the client.  This is helpful in protecting against phishing sites.
•     Integrity: TLS includes protections that help with identifying if data has been modified or corrupted in transit.

Todas estas son características valiosas al navegar por la web. Por eso TLS es tan popular y por qué la mayoría de las visitas a un sitio web comienzan con un handshake TLS.

¿Qué es el handshake TLS?

Al igual que un apretón de manos en la vida real, el handshake TLS es una introducción. Establece que dos ordenadores desean comunicarse entre sí de forma segura.

Un handshake TLS también define algunas de las reglas para esta conversación. Tanto el cliente como el servidor acuerdan que desean los beneficios de TLS, pero necesitan ponerse de acuerdo sobre los detalles. Un handshake TLS los lleva desde un "Hola" inicial hasta el punto en que pueden empezar a comunicarse de forma privada.

Antes de profundizar en los detalles del handshake TLS, es importante comprender algunos términos clave. TLS es un protocolo centrado en la seguridad, lo que significa que utiliza mucha criptografía. Algunos términos importantes que debe conocer al hablar de TLS incluyen:

• Asymmetric Encryption: Asymmetric or “public key” cryptography uses two related keys: a public and a private key.  Anything encrypted with a public key can be decrypted with the corresponding private key.  Similarly, a digital signature generated with a private key can be validated with the associated public key.
• Symmetric Encryption: Symmetric encryption uses the same key for both encryption and decryption.  This is useful because it is more efficient than encryption with asymmetric cryptography.  The TLS handshake is designed to set up a shared symmetric encryption key.
• Cipher Suites: A cipher suite is a combination of cryptographic algorithms used in the TLS protocol.  This includes an asymmetric encryption algorithm for the handshake, a symmetric encryption algorithm for encrypting the data sent over the connection, a digital signature algorithm, and a hash function used for verifying that data has not been corrupted in transit.
• Digital Certificate: A digital certificate proves the ownership of a public key.  Servers present a digital certificate during the TLS handshake so that the client knows that they’re communicating with the right person.

Dentro del Handshake de TLS

El objetivo del handshake de TLS es que el cliente y el servidor acuerden una clave de cifrado simétrico compartida de forma segura. Para ello, utilizan cifrado asimétrico, lo que permite enviar mensajes cifrados utilizando únicamente una clave pública.

Los detalles del handshake de TLS dependen del algoritmo de cifrado asimétrico utilizado. Un cliente y un servidor que emplean RSA siguen los siguientes pasos:

*Fuente de la imagen

1. Client Hello: The client kicks off the TLS handshake by sending configuration information to the server.  This includes data like the TLS version(s) supported by the client, which cipher suites it can use, and some random data called the “client random”.
2. Server Hello: The server responds with a message including its choices of TLS version and cipher suite, its digital certificate, and the “server random”.
3. Premaster Secret: The digital certificate provided by the server contains its public key, which can be used for encrypting messages sent to the server.  After verifying the validity of the certificate, the client generates another random value called the premaster secret.  Using the server’s public key, the client encrypts this value and sends it to the server.
4. Session Keys: The server uses its private key to decrypt the premaster secret.  At this point, both the client and the server have the client random, server random, and the premaster secret.  From these, they calculate a shared session key.  Since the premaster secret is a secret value – it was only sent in an encrypted form over the network – the session key is secret as well.
5. Client Finished: To complete the TLS handshake, the client sends a message to the server that is encrypted with the session key.  The server decrypts this message and verifies its correctness.  If it matches, the server knows that the client correctly calculated the session key.
6. Server Finished: The server also sends a message encrypted with the shared session key.  Decrypting and verifying this message proves to the client that the server correctly calculated the session key.

En este punto, el cliente y el servidor disponen de una clave de cifrado compartida conocida solo por ellos. Durante el resto de la sesión de TLS, todos los mensajes se cifrarán utilizando esta clave de sesión.

Una estructura alternativa

Como se mencionó anteriormente, el uso de diferentes algoritmos de cifrado asimétrico puede provocar pequeños cambios en los pasos. Por ejemplo, si el cliente y el servidor optan por utilizar Diffie-Hellman en lugar de RSA, el contenido de los mensajes enviados en los pasos 2 y 3 se modifica ligeramente:

• En el paso 2, el servidor enviará un paquete firmado digitalmente que contiene el client random, el server random y su parámetro Diffie-Hellman.
• Tras validar la firma digital, el cliente responde con un mensaje que contiene su parámetro Diffie-Hellman en lugar de un premaster secret.

Utilizando estos parámetros Diffie-Hellman y los client y server randoms, es posible que el cliente y el servidor calculen una clave privada secreta compartida. Al final, Diffie-Hellman y RSA producen el mismo resultado de formas ligeramente diferentes.

Más allá del handshake básico

El proceso aquí descrito es el handshake básico de TLS, que se utiliza en la mayoría de las sesiones de TLS. Sin embargo, es posible añadir pasos adicionales que proporcionan ciertos beneficios.

Por ejemplo, el handshake básico de TLS utiliza un certificado digital para autenticar el servidor ante el cliente, pero no autentica el cliente ante el servidor. Una versión modificada del handshake de TLS puede enviar también el certificado digital de un cliente al servidor, logrando así la autenticación mutua.