Explícame el handshake de TLS 1.3.
Respuesta breve
El cliente y el servidor acuerdan un secreto compartido en un solo viaje de ida y vuelta usando Diffie-Hellman efímero (ECDHE). El ClientHello lleva los grupos compatibles y un key share; el servidor responde con su key share y su certificado, ambas partes derivan las mismas claves, y los datos de aplicación fluyen de inmediato, con confidencialidad hacia adelante por defecto.
El handshake de TLS 1.3 existe para resolver un problema: dos partes que nunca se han conocido necesitan acordar un secreto compartido a través de una red que un atacante puede leer, y deben estar seguras de que están hablando con la parte correcta. Lo logra en un solo viaje de ida y vuelta, que es la mejora estrella respecto a TLS 1.2.
El flujo, paso a paso
- ClientHello. El cliente abre con la versión de TLS que desea, un nonce aleatorio, las suites de cifrado que admite, los grupos nombrados (curvas elípticas) sobre los que puede hacer ECDHE y, crucialmente, un key share: una clave pública efímera para uno o varios de esos grupos. TLS 1.3 es opinado, así que el cliente apuesta a que el servidor aceptará uno de sus shares.
- ServerHello. El servidor elige una suite de cifrado y un grupo, devuelve su propio key share efímero, y ahora ambas partes tienen todo lo necesario para calcular el mismo secreto compartido mediante Diffie-Hellman.
- Derivación de claves. Ambas partes ejecutan el cálculo de ECDHE y pasan el resultado por la función de derivación de claves HKDF para producir las claves de tráfico. A partir de este punto, el resto del handshake está cifrado.
- Autenticación del servidor. Bajo ese cifrado, el servidor envía su certificado y un CertificateVerify: una firma sobre la transcripción del handshake que demuestra que posee la clave privada del certificado. El cliente valida la cadena de certificados hasta una CA de confianza.
- Finished. Ambas partes intercambian un MAC sobre toda la transcripción para confirmar que nada se ha manipulado, y los datos de aplicación fluyen.
Por qué es mejor que TLS 1.2
- Un viaje de ida y vuelta, no dos. Como el cliente envía de forma especulativa un key share en el primer mensaje, el servidor puede responder con todo lo necesario. TLS 1.2 requería un viaje de ida y vuelta adicional.
- La confidencialidad hacia adelante es obligatoria. TLS 1.3 eliminó el intercambio de claves RSA estático. Cada sesión usa claves efímeras, de modo que comprometer más adelante la clave a largo plazo del servidor no permite a un atacante descifrar el tráfico pasado que haya capturado.
- Un menú de cifrado más reducido y seguro. Las opciones débiles y rara vez correctas (RC4, MAC en modo CBC, renegociación, compresión) se eliminaron, reduciendo la superficie de ataque.
La trampa a vigilar
TLS 1.3 añade el 0-RTT («early data»), donde un cliente que regresa puede enviar datos de aplicación en su primer mensaje usando una clave precompartida. Es rápido, pero los datos 0-RTT son reproducibles por un atacante, por lo que solo deben transportar solicitudes idempotentes, nunca algo que modifique un estado. Una buena respuesta menciona este compromiso sin que se lo pidan.
Posibles preguntas de seguimiento
- ¿Qué cambió entre TLS 1.2 y TLS 1.3?
- ¿Qué es el 0-RTT y cuál es su riesgo de repetición?
- ¿Qué es la confidencialidad hacia adelante y por qué importa?