TLS 1.3: 0-RTT, datos tempranos y reanudación de sesiones

TLS 1.3 (RFC 8446, 2018) rediseñó el handshake de TLS para reducir la latencia y eliminar elementos heredados innecesarios. Un handshake completo de TLS 1.3 se completa en 1-RTT: el cliente envía ClientHello con los key_shares compatibles (claves públicas ECDH efímeras) en el primer envío; el servidor responde con ServerHello, su key_share, las extensiones cifradas, el certificado y Finished, todo en una sola respuesta. El cliente envía su Finished y puede enviar inmediatamente datos de aplicación. En comparación con el handshake de 2-RTT de TLS 1.2, esto reduce a la mitad el tiempo de establecimiento de conexiones nuevas.

TLS 1.3 utiliza HKDF (HMAC-based Key Derivation Function) con un esquema estructurado de derivación de claves. Después del intercambio de claves ECDHE, el secreto compartido se introduce en una jerarquía: Extract(early_secret, DHE) -> handshake_secret; después, Extract(handshake_secret, 0) -> master_secret. A partir de estos valores, HKDF-Expand-Label deriva claves independientes para el tráfico del handshake del cliente y del servidor, el tráfico de aplicación y la reanudación. Esta separación clara garantiza que la vulneración de una capa de claves no afecte a las demás, una mejora significativa frente a la derivación de claves más improvisada basada en PRF de TLS 1.2.

La reanudación de sesiones de TLS 1.3 utiliza claves precompartidas (PSK) derivadas de sesiones anteriores. Después de completar un handshake, el servidor envía un mensaje NewSessionTicket que contiene una identidad PSK y un valor de ticket (un bloque cifrado que contiene el secreto de reanudación). Al reconectarse, el cliente incluye la identidad PSK en ClientHello. Si el servidor la reconoce, ambas partes derivan una nueva clave de sesión a partir de la PSK y de un ECDHE nuevo, logrando una reanudación en 1-RTT con secreto hacia adelante. El ticket tiene una duración configurable (normalmente, 24 horas) y debe cifrarse con una clave del servidor que rote periódicamente.

TLS 1.3 permite utilizar datos tempranos de 0-RTT en sesiones reanudadas. El cliente utiliza la PSK de una sesión anterior para cifrar datos de aplicación que envía en el primer envío, antes de recibir cualquier confirmación del servidor. Esto elimina un viaje de ida y vuelta en las conexiones con servidores visitados anteriormente y proporciona una latencia casi nula en las conexiones repetidas. El servidor anuncia la compatibilidad con 0-RTT en NewSessionTicket mediante la extensión early_data, con un max_early_data_size. El servidor debe contar con un mecanismo para aceptar o rechazar los datos de 0-RTT e indica su aceptación en EncryptedExtensions.

Los datos de 0-RTT tienen una limitación de seguridad fundamental: son vulnerables a ataques de repetición. Un atacante situado en la ruta que capture el primer envío puede reproducirlo ante el servidor y hacer que este procese de nuevo los datos tempranos. Esto es inherente al diseño: el servidor todavía no ha enviado ningún mensaje, por lo que no ha aportado ningún elemento de frescura. Mitigaciones: (1) Tickets de un solo uso (el servidor invalida un ticket después del primer uso mediante una caché distribuida como memcached/Redis). (2) Tickets con límite temporal (rechazar 0-RTT después de un intervalo breve, por ejemplo, 5 segundos). (3) Idempotencia a nivel de aplicación (permitir 0-RTT únicamente para operaciones seguras equivalentes a GET).

El mecanismo más sólido contra las repeticiones de 0-RTT consiste en utilizar tickets de sesión de un solo uso. El servidor mantiene un almacén de «tickets usados» (una caché distribuida en implementaciones con varios servidores). Cuando llegan datos de 0-RTT, el servidor comprueba si el ticket se ha visto antes; si es así, rechaza los datos tempranos y vuelve a 1-RTT. Si no, marca el ticket como usado y procesa los datos tempranos. Para garantizar la coherencia, todos los servidores de un clúster deben compartir la caché de tickets usados. Redis con TTL cortos (que coincidan con la duración de los tickets) es una implementación habitual. Sin este mecanismo, 0-RTT no es seguro para operaciones no idempotentes, como los pagos.

La reanudación mediante PSK de TLS 1.3 sin DHE carece de secreto hacia adelante para la sesión reanudada: si la PSK se ve comprometida posteriormente, se puede descifrar todo el tráfico de la sesión reanudada. Para mantener el secreto hacia adelante, TLS 1.3 admite PSK-with-DHE: ClientHello incluye tanto una identidad PSK como un key_share nuevo. El servidor combina la PSK y el resultado de ECDHE para derivar las claves de sesión. Aunque la PSK se vea comprometida, la contribución de ECDHE garantiza que el tráfico anterior siga protegido. RFC 8446 recomienda PSK-with-DHE en todos los casos de reanudación en los que se requiera secreto hacia adelante.

TLS 1.2 tenía más de 300 combinaciones de conjuntos de cifrado, muchas de ellas inseguras. TLS 1.3 reduce esta cantidad a 5 conjuntos de cifrado, todos basados en AEAD: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256 y TLS_AES_128_CCM_8_SHA256. El intercambio de claves y la autenticación se negocian por separado mediante las extensiones supported_groups y signature_algorithms. Esta separación elimina la complejidad combinatoria de TLS 1.2 y garantiza que todas las conexiones TLS 1.3 utilicen cifrado autenticado.

En la práctica, 0-RTT resulta más útil en conexiones HTTP/2 en las que el cliente repite una solicitud GET (segura e idempotente) a un servidor visitado anteriormente. Los navegadores implementan 0-RTT con cautela: Chrome lo habilita para métodos HTTP seguros; las solicitudes POST nunca se envían como datos de 0-RTT. HTTP/3 sobre QUIC integra TLS 1.3 de forma nativa: el 0-RTT de QUIC reutiliza el mecanismo de TLS 1.3. En QUIC, 0-RTT también restaura los parámetros de transporte (control de flujo, límites de streams) de la sesión anterior, lo que reduce aún más la sobrecarga de establecimiento, más allá de la capa TLS.

TLS 1.3 incluye mecanismos para evitar ataques de degradación de versión. El campo random de ServerHello contiene un valor centinela cuando se negocia TLS 1.3: los últimos 8 bytes se establecen en un valor fijo (0x44 0x4F 0x57 0x4E 0x47 0x52 0x44 01 para el fallback a TLS 1.2). Los clientes compatibles con TLS 1.3 comprueban este valor centinela cuando el servidor negocia TLS 1.2, lo que permite detectar intentos activos de degradación. Además, el hash de la transcripción de Finished cubre todo el handshake, incluida la negociación de versión, por lo que cualquier manipulación resulta detectable. Valores SCSV (Signaling Cipher Suite Values) como TLS_FALLBACK_SCSV proporcionan una señal de degradación independiente para versiones anteriores de TLS.

La implementación de TLS 1.3 requiere prestar atención a varios detalles operativos. Las claves de cifrado de los tickets de sesión deben rotar (normalmente cada 24 horas) y sincronizarse entre los clústeres de servidores para permitir la reanudación en cualquier servidor. Las claves antiguas de descifrado de tickets deben conservarse durante la vida útil de estos para evitar fallos espurios del handshake. OCSP stapling cobra mayor importancia en TLS 1.3, ya que elimina un viaje de ida y vuelta para comprobar el estado del certificado. Los balanceadores de carga deben reenviar ClientHello de TLS 1.3 sin modificarlo; algunos dispositivos intermedios antiguos corrompen las extensiones desconocidas, por lo que es necesario utilizar modos de compatibilidad.

¿Por qué los datos tempranos de 0-RTT son vulnerables a ataques de repetición en TLS 1.3?

TLS 1.3 permite realizar handshakes completos en 1-RTT y reanudaciones en 0-RTT mediante tickets de sesión PSK. La derivación de claves utiliza HKDF con un esquema estructurado que produce claves independientes para cada capa de tráfico. Los datos tempranos de 0-RTT eliminan un viaje de ida y vuelta, pero son vulnerables a repeticiones; esto se mitiga mediante tickets de un solo uso y limitando 0-RTT a operaciones idempotentes. PSK-with-DHE mantiene el secreto hacia adelante durante la reanudación. TLS 1.3 restringe los conjuntos de cifrado a 5 opciones AEAD, eliminando las combinaciones heredadas inseguras. La prevención de degradaciones utiliza valores centinela en el campo random del servidor.