Resumen

  • NewSessionTicket entrega una identidad PSK opaca para un handshake futuro. Aceptarla enlaza criptográficamente una conexión nueva con la negociación que la originó; no revive el transporte anterior ni demuestra que las decisiones de aplicación sigan siendo actuales.
  • Vida útil, edad ofuscada, nonce, hash KDF, SNI, modo PSK y binder tienen autoridades distintas. Ninguno demuestra por sí solo autorización vigente, mismo backend, aceptación de 0-RTT o permiso para reutilizar un estado empresarial antiguo.
  • Una reanudación defendible necesita contrato de estado versionado, dominio acotado de claves y servicios, decisión 0-RTT independiente, revalidación de todo poder mutable y una caída observable hacia handshake completo.

El atajo que cruzó dos relojes

Seis horas después de la emisión, una conmutación regional llevó el cliente a otro nodo. El ticket se descifró, la PSK fue seleccionada y la conexión terminó como reanudada. En el sistema de identidad, sin embargo, el rol administrativo ya había desaparecido.

La aplicación no consultó esa fuente. Recuperó del estado protegido la respuesta histórica y la trató como presente. TLS no había validado el rol; había validado la posesión de un secreto derivado del handshake anterior.

La incidencia fue una colisión de relojes. El reloj criptográfico permitía usar la credencial. El reloj de autorización había vencido. Una firma o un MAC pueden preservar el origen de una afirmación, pero no detener su envejecimiento.

Un ticket identifica otra PSK, no la conexión vieja

TLS 1.3 sustituyó los mecanismos anteriores de sesión por un intercambio PSK común. Tras el Finished del cliente, el servidor puede enviar NewSessionTicket. Cada mensaje relaciona el valor opaco del ticket con una PSK derivada del secreto de reanudación y de un ticket_nonce único.

El valor puede ser una clave de consulta a una base de datos o un paquete autocontenido, cifrado y autenticado por el servidor. El cliente no necesita interpretar ninguno. En la superficie del protocolo, ambos son identidades PSK.

Un servidor puede emitir varios tickets para conexiones paralelas o carreras entre interfaces. Los nonces distintos producen PSK distintas. Por eso una auditoría debe identificar la emisión o la época de clave, no limitarse a decir «misma sesión».

La reanudación crea un nuevo transcript, nuevas claves de tráfico y nuevos contadores de registro. No restaura el socket, el proceso, la transacción, el flujo QUIC ni la memoria de aplicación de la conexión anterior.

La vida útil no obliga a aceptar

ticket_lifetime empieza al emitir y no supera siete días. Cero ordena descartar. El cliente puede borrar antes y el servidor puede aplicar una vigencia menor.

El campo limita durante cuánto tiempo puede intentarse el atajo. No promete que el servidor lo aceptará hasta el último segundo. Rotación de claves, eliminación de base, cambio de topología, revocación o una política nueva pueden exigir un handshake completo.

ticket_age_add suma un valor aleatorio para ocultar la edad ante observadores pasivos. El servidor lo resta y compara la edad aparente con el tiempo transcurrido. Ese cálculo no hace único al uso: una copia conserva el mismo ticket y la misma aritmética.

Una edad fuera de tolerancia obliga a tratar la frescura con cautela. El servidor puede rechazar 0-RTT y aun aceptar la reanudación ordinaria. «Ticket descifrado», «PSK elegida» y «datos tempranos aceptados» son resultados diferentes.

El binder autentica historia criptográfica

El cliente ofrece identidades PSK y binders en el ClientHello. El binder vincula el secreto con esta negociación y, de forma transitiva, con el handshake que creó el secreto de reanudación.

Eso prueba continuidad de posesión. No prueba que una cuenta esté habilitada, que el dispositivo conserve su postura, que una suscripción siga activa ni que el riesgo no haya cambiado. La afirmación puede ser auténtica y estar caducada.

En una reanudación autenticada por PSK, el servidor no vuelve a enviar Certificate ni CertificateVerify. El contexto anterior cumple esa función. La aplicación debe enumerar qué hechos puede heredar y cuáles necesitan una fuente vigente.

OpenSSL puede emitir tickets nuevos después de autenticar al cliente tras el handshake; estos incorporan la identidad actualizada. La existencia de esa emisión demuestra un límite de versión. No actualiza retrospectivamente los tickets anteriores.

El servicio actual sigue teniendo nombre

El nuevo ClientHello vuelve a llevar SNI. El cliente solo puede reanudar si el certificado inicial era válido para el nombre actual y normalmente debería conservar el mismo nombre. La aplicación debe recibir el SNI nuevo, no una copia histórica.

RFC 9525 sitúa la identidad de referencia en el servicio solicitado ahora. SNI y ALPN ayudan a identificar servicio y protocolo. Poder abrir un ticket no lo hace válido para todos los nombres, inquilinos o usos que comparten infraestructura.

Compartir la clave de envoltura entre regiones mejora continuidad, pero amplía quién puede aceptar estado antiguo. BoringSSL expone la reanudación entre nombres como una política concreta. La capacidad técnica no debe decidir la autoridad por accidente.

El hash KDF también limita la selección: la suite de reanudación debe usar el mismo hash que la original. Esa compatibilidad no congela rutas, permisos ni parámetros de aplicación.

Reanudación y 0-RTT no son sinónimos

Un ticket puede incluir early_data y un máximo de bytes. Autoriza al cliente a ofrecer 0-RTT; no obliga al servidor a aceptarlo ni convierte una operación de aplicación en segura frente a replay.

La telemetría necesita tres pasos: ticket localizado o descifrado, PSK seleccionada y datos tempranos aceptados. El servidor puede rechazar el tercer paso por edad dudosa, memoria anti-replay ausente o parámetros distintos, y completar una conexión reanudada normal.

HTTP 425 actúa después. Permite que el origen rehúse ejecutar una petición llegada con procedencia temprana. No define qué estado puede atravesar dentro del ticket. El problema de esta investigación existe incluso donde 0-RTT está desactivado.

QUIC añade continuidad de parámetros de transporte y aplicación. La validez del ticket TLS no demuestra que los límites QUIC o los SETTINGS HTTP/3 recordados sigan siendo compatibles.

La arquitectura de almacenamiento reparte autoridad

Un ticket respaldado por base puede borrarse tras uso, auditarse como identidad consumible y limitarse a una autoridad concreta. La base pasa a ser dependencia de disponibilidad y consistencia; una réplica atrasada puede rechazar de más o aceptar dos veces.

Un ticket autocontenido puede sobrevivir a la caída de un nodo. Todos los nodos con la clave de envoltura, sin embargo, pueden interpretar su estado hasta retirar esa clave. Distribuir la clave equivale a distribuir capacidad de aceptación.

No hay una oposición simple entre estado seguro y sin estado peligroso. Cada modelo elige un dominio de fallo. Una base central puede bloquear el servicio; una clave demasiado compartida puede mantener decisiones viejas; un solapamiento largo de épocas puede ocultar una rotación incompleta.

OpenSSL expone estado de descifrado, nombre de clave, datos de aplicación, número de tickets y controles de supresión. GnuTLS ofrece activación y emisión adicional. El código de BoringSSL genera una edad nueva y separa las condiciones de datos tempranos.

Las API prueban que hay controles. No prueban qué configuración corre, qué claims viajan, qué nodos rotaron ni si la autorización se volvió a consultar.

Transportar referencias con fecha

Los hechos criptográficos estables pueden conservarse: identidad PSK, hash KDF, modo elegido y una referencia acotada al handshake autenticado. Los hechos empresariales mutables necesitan versión, caducidad y fuente.

Una aplicación puede guardar el identificador de usuario y la versión de autorización y comparar esta última con el sistema actual antes de conceder poder. Puede llevar una ruta de inquilino con expiración o emitir nueva generación tras cambiar la autenticación de cliente.

El diseño peligroso guarda conclusiones desnudas: administrador=true, «dispositivo confiable», «suscripción activa». El cifrado evita modificación no autorizada. No impide que una conclusión correcta ayer sea falsa hoy.

EAP-TLS utiliza tickets para reanudar autenticación y respeta el máximo de siete días. Esa capa debe definir qué significa reanudar y qué cambio invalida el atajo. TLS transporta la evidencia; no gobierna la política de acceso.

Pruebas que deben sobrevivir a una conmutación

Registrar una correlación segura o nombre de clave, nodo y región de emisión, instante, vencimiento anunciado y efectivo, época, modelo de almacenamiento, hash KDF y modo PSK. Al ofrecer, guardar edad, resultado de descifrado, índice seleccionado, SNI y ALPN actuales, resultado y causa de fallback.

Registrar 0-RTT aparte: ofrecido, elegible, aceptado o rechazado, límite, estado anti-replay y decisión de aplicación. resumed=true nunca debe implicar early_data_accepted=true.

Para el estado de negocio, guardar versión de esquema, autorización, revocación y ruta, junto con la autoridad que produjo cada decisión actual. La correlación no debe exponer ticket ni PSK.

Las pruebas negativas incluyen caducidad, vigencia acortada, clave retirada, autenticación fallida, fila eliminada, replay interregional, cambio de SNI/ALPN, hash incompatible y usuario revocado con ticket todavía descifrable.

El rechazo debe poder caer a handshake completo cuando la política lo permita. La emergencia debe retirar una época o versión de estado sin interrumpir el TLS ajeno a esa credencial.

Fuentes