Handshake de TLS 1.3 paso a paso

TLS (Transport Layer Security) protege los datos en tránsito por Internet. Todas las conexiones HTTPS utilizan TLS. TLS 1.3, estandarizado en RFC 8446 (2018), eliminó los algoritmos heredados y redujo de 2 a 1 los viajes de ida y vuelta del handshake.

El cliente envía: la versión de TLS (1.3), un nonce aleatorio de 32 bytes, una lista de suites de cifrado compatibles (por ejemplo, TLS_AES_256_GCM_SHA384) y extensiones de intercambio de claves que contienen claves públicas ECDH para los grupos compatibles (X25519, P-256).

El servidor selecciona una suite de cifrado y un grupo para el intercambio de claves, genera su propio par de claves efímeras ECDH y responde con su clave pública. En este punto, ambos lados pueden calcular el secreto compartido mediante ECDH.

TLS 1.3 utiliza HKDF (función de derivación de claves basada en HMAC) siguiendo una secuencia: secreto inicial → secreto del handshake → secreto maestro. Cada etapa deriva claves independientes para el tráfico de handshake del cliente y del servidor, y para los datos de aplicación.

El servidor envía su Certificate, CertificateVerify (una firma sobre la transcripción del handshake utilizando su clave privada) y Finished (un HMAC sobre la transcripción). Todo se cifra con la clave de tráfico del handshake.

El cliente verifica la cadena de certificados, comprueba la firma de CertificateVerify, verifica el MAC de Finished y, después, envía su propio mensaje Finished. El handshake se completa ahora en un solo viaje de ida y vuelta (1-RTT).

TLS 1.3 admite la reanudación 0-RTT (cero viajes de ida y vuelta) mediante una clave previamente compartida (PSK) de una sesión anterior. El cliente puede enviar datos de aplicación inmediatamente, pero los datos 0-RTT carecen de protección contra repeticiones y deben ser idempotentes.

TLS 1.3 exige exclusivamente cifradores AEAD: AES-128-GCM-SHA256, AES-256-GCM-SHA384 y ChaCha20-Poly1305-SHA256. Todos utilizan ECDHE o DHE para el intercambio de claves. Las suites débiles (RC4, 3DES y CBC) han desaparecido.

Después del handshake, todos los datos se encapsulan en registros TLS: encabezado de 5 bytes (tipo de contenido, versión y longitud) + carga útil cifrada con AEAD. El número de secuencia es implícito y se utiliza como parte del nonce de AEAD para evitar repeticiones.

Como TLS 1.3 siempre utiliza un intercambio de claves efímeras (ECDHE), la vulneración de la clave privada de larga duración del servidor no permite descifrar sesiones anteriores. Cada sesión tiene un par de claves efímeras único que se destruye después del handshake.

En Wireshark: ClientHello muestra random + key_share; ServerHello muestra el grupo seleccionado; los registros posteriores aparecen como "Application Data" (cifrados). Exporte SSLKEYLOGFILE para descifrarlos con las claves de sesión.

¿Cuántos viajes de ida y vuelta requiere un handshake completo de TLS 1.3?

TLS 1.3 combina ECDHE, HKDF, cifradores AEAD y autenticación basada en certificados en un handshake de 1-RTT con secreto directo perfecto obligatorio. A continuación: la capa de registros de TLS y las suites de cifrado en profundidad.