Resumen

  • HelloRetryRequest no reinicia TLS 1.3. El segundo ClientHello debe repetir el primero salvo una lista estrecha de cambios autorizados: una nueva contribución para el grupo pedido, retirada de early data, devolución de cookie y recálculo de binders.
  • El protocolo sustituye los bytes de ClientHello1 por un mensaje sintético message_hash que contiene su resumen, y autentica ese compromiso junto con la petición y los mensajes posteriores. La operación sin estado comprime la historia; no la elimina.
  • La evidencia operativa debe guardar ambos ClientHello, el motivo, la diferencia permitida, la política de cookie, el grupo final, las alertas y la latencia añadida. Un enlace completado no prueba que la petición fuera válida ni que el grupo final fuera la preferencia inicial del cliente.

Una captura que empezó demasiado tarde

El diagnóstico parecía claro. ClientHello2 llevaba una sola contribución, ServerHello elegía el mismo grupo y CertificateVerify y Finished terminaban sin alerta. El sistema resumió: el cliente ofreció ese grupo y el servidor lo aceptó.

El primer mensaje ausente contaba otra secuencia. El cliente había enumerado varios grupos en supported_groups, pero sólo había anticipado una contribución para otro. El servidor no quiso usar aquella predicción y envió HelloRetryRequest para pedir un grupo que el cliente ya había declarado compatible, aunque no había mandado su contribución. La única clave del segundo Hello era una respuesta a la decisión del servidor, no una prueba de preferencia originaria.

Configuración admitida, compatibilidad anunciada, contribución anticipada, grupo solicitado y selección final son hechos distintos. La observabilidad que empieza en el segundo vuelo atribuye al cliente la preferencia del servidor, esconde una vuelta de red y vuelve engañosa la explicación de una migración criptográfica.

Una corrección regida por lista cerrada

La especificación vigente de TLS 1.3 exige que ClientHello2 sea igual a ClientHello1 salvo excepciones explícitas. Si la petición contiene key_share, el cliente reemplaza la lista por una única contribución nueva para el grupo indicado. Retira early_data, copia el cookie recibido y recalcula los binders PSK sobre el historial que incluye la petición. Una extensión futura sólo puede autorizar otra diferencia si aparece en HelloRetryRequest y define su regla.

No es una recomendación de parecido general. Es una lista de permisos. La frontera de los campos modificables tiene tanta importancia como el algoritmo resultante.

El grupo pedido debe figurar en el supported_groups original y no puede ser uno que ya tuviera contribución en el primer key_share. Deben rechazarse una petición sin cambio útil, una segunda petición, una suite no ofrecida o un ServerHello cuyo grupo contradiga el solicitado.

Así, retry deja de significar “volver a probar” sin límites. El servidor puede pedir una corrección válida una sola vez. No puede reabrir todos los parámetros ni insistir hasta imponer otra política.

message_hash mantiene la primera oferta dentro de la historia

Los cálculos criptográficos de TLS dependen de un resumen ordenado de los mensajes del establecimiento. Un servidor que quiera emitir un cookie y abandonar estado por cliente no desea almacenar cada ClientHello completo ni un estado intermedio específico de su biblioteca.

TLS reemplaza ClientHello1 en el transcript por un mensaje sintético de tipo 254, message_hash, cuyo cuerpo es Hash(ClientHello1). Después incorpora HelloRetryRequest, ClientHello2, ServerHello y los mensajes de autenticación. CertificateVerify, Finished y el binder posterior siguen comprometidos con la primera propuesta.

El resumen es un compromiso, no una copia reversible. Los extremos pueden detectar que la historia autenticada se rompió, pero el operador no puede reconstruir extensiones y contribuciones originales a partir del hash. El protocolo prueba continuidad; una captura o registro estructurado explica la diferencia.

Soportar, anticipar y seleccionar son estados diferentes

El cliente TLS 1.3 intenta ahorrar una vuelta anticipando contribuciones de clave en su primer mensaje. Generarlas para todos los grupos compatibles aumenta cálculo y tamaño. Enviar sólo una reduce bytes, pero puede provocar una petición si el servidor exige otro grupo también admitido.

Los grupos híbridos poscuánticos hacen visible el intercambio. OpenSSL permite definir conjuntos comparables, preferencias y contribuciones anticipadas. Su documentación advierte que un ClientHello grande puede cruzar el límite de un segmento TCP y tropezar con un cortafuegos defectuoso; diferir una contribución grande reserva la vuelta adicional para servidores que realmente la pidan. GnuTLS también distingue la política de grupos de la opción de enviar una sola contribución TLS 1.3.

Por tanto, una fila de inventario que diga “soporta X” no basta. La implementación puede conocer X, la configuración habilitarlo, el primer Hello anunciarlo sin mandar una contribución, el servidor solicitarlo y la conexión elegirlo finalmente. Cada estado necesita su propia evidencia.

Early data no atraviesa la desviación

Si el primer ClientHello incluía early_data, el segundo debe retirarlo. HelloRetryRequest demuestra que el camino 0-RTT no fue aceptado en ese establecimiento.

El cliente, sin embargo, pudo enviar bytes de aplicación antes de recibir la petición. La aplicación decide si la operación se puede repetir, si ya vio una respuesta y cómo conciliar efectos. El éxito posterior en 1-RTT no convierte por sí mismo una acción con efectos laterales en idempotente.

La telemetría debe separar intento de early data, rechazo por HRR, decisión de retransmitir y resultado de negocio. La etiqueta “reanudación exitosa” borra la transición decisiva.

Un cookie prueba únicamente lo que fue diseñado para probar

El servidor puede incluir un cookie opaco en HelloRetryRequest y exigir que ClientHello2 lo devuelva sin cambios. Puede comprometer el hash del primer Hello, parámetros elegidos, tiempo o contexto de encaminamiento. La protección de integridad demuestra procedencia y ausencia de modificación dentro de los límites de custodia, vigencia y validación.

DTLS 1.3 añade otro uso: vincular el cookie a la dirección aparente para comprobar el camino de retorno antes de amplificar una respuesta. La rotación de secretos, las ventanas solapadas y las marcas de tiempo muestran que un token sin estado también tiene ciclo de vida.

La alcanzabilidad no es identidad. Devolver un cookie puede demostrar recepción en una dirección durante cierto periodo; no identifica a una persona, un rol de dispositivo ni un permiso de aplicación. Tampoco evita comparar los dos ClientHello. El token transporta estado, pero no ensancha la autoridad de la transición.

Las extensiones deben entrar en el mismo historial

Encrypted Client Hello ofrece un ejemplo acotado. El random de HelloRetryRequest es fijo, de modo que ECH no puede colocar allí la confirmación como en ServerHello. Define una extensión encrypted_client_hello que deriva la señal del ClientHello interno y de la petición modificada.

La lección no consiste en convertir este análisis en una guía ECH. Una extensión debe especificar qué puede cambiar, dónde aparece su señal y cómo se incorpora al historial autenticado. No obtiene un universo de negociación privado.

Evidencia capaz de sobrevivir a un incidente

Un registro defendible comienza antes de lo que muchos cuadros llaman conexión. Conserva el hash y, donde la política lo permita, los campos analizados de ClientHello1; el HelloRetryRequest exacto; un hash del cookie, no su secreto; los campos de ClientHello2; y ServerHello final. Cada decisión queda asociada a versiones de implementación y configuración.

Para grupos, registrar lista habilitada, orden anunciado, contribuciones anticipadas, preferencia del servidor, grupo solicitado, devuelto y negociado. Para la petición, motivo, conformidad de la diferencia, alerta de rechazo y posible segundo intento. Para el efecto, RTT añadido, tamaño de ambos Hello, segmentación, resultado de early data, finalización y población cliente.

También hace falta evidencia negativa. Probar el rechazo de un grupo no anunciado, uno ya compartido, una petición sin cambio, una suite alterada, una segunda petición y un ServerHello incoherente. El ejecutor de pruebas de BoringSSL modela variantes inválidas porque rechazar correctamente forma parte de la interoperabilidad.

El establecimiento completado es el final del relato, no la prueba de que cada decisión anterior fue legítima. La prueba está en la cadena verificable de cambios limitados.

Fuentes