Resumen

  • TLS 1.3 permite que un cliente que reanuda una sesión envíe datos 0-RTT junto al ClientHello. Reduce uno o dos viajes de red, pero esos datos no tienen garantía de no repetición entre conexiones.
  • RFC 8470 convirtió el riesgo en una cadena de responsabilidad: el cliente selecciona el envío temprano, los intermediarios conservan Early-Data: 1 y el origen decide si esa operación concreta tolera repetición.
  • 425 Too Early devuelve la misma intención a una fase más segura. El cliente debería reintentar automáticamente, pero nunca volver a hacerlo como datos tempranos. HTTP/3 mantiene la regla sobre QUIC.

El mismo mensaje podía producir dos historias

La utilidad del 0-RTT se entiende mejor desde el final. Un cliente envía una operación una vez y espera un efecto. La infraestructura, sin embargo, puede presentar los mismos bytes tempranos en dos conexiones distintas. Si una instancia actúa y otra induce un reintento legítimo, el sistema obtiene dos efectos aunque el usuario solo haya querido uno.

Ese resultado no implica que TLS 1.3 haya fallado en cifrar. El RFC 8446 permite a un cliente con un ticket de reanudación mandar datos de aplicación junto a su ClientHello. Como no espera el nuevo ServerHello, evita una o dos idas y vueltas. Precisamente por salir antes, las claves no incorporan la aleatoriedad nueva del servidor y el protocolo no garantiza que el bloque no pueda reproducirse en otra conexión.

El límite importa. Los datos no son texto claro ni pueden ser alterados a voluntad. Tampoco pueden duplicarse dentro de una sola conexión o transformarse en datos 1-RTT. La abertura se encuentra entre conexiones que aún aceptan el mismo estado recordado.

Repetición atacante y recuperación legítima

Un reintento nace de la decisión del usuario o del cliente: se perdió la respuesta, cayó el enlace o la aplicación aplica su política. Una repetición criptográfica puede ocurrir sin que el cliente lo sepa. No son sinónimos.

Pero una plataforma con varias zonas puede combinarlos. Una zona acepta el vuelo temprano y ejecuta. Otra no comparte exactamente el registro de repeticiones, rechaza el early data y completa un handshake ordinario. Si la primera respuesta no llega, el cliente reenvía en la segunda conexión. La duplicación directa y el reintento se han sumado.

TLS ofrece controles: tickets de un solo uso, registros de ClientHello, ventanas breves y zonas autoritativas para un ticket. Todos dependen de estado consistente y de un manejo prudente de reinicios. Incluso un filtro perfecto de bytes no puede decidir si dos lecturas, dos reservas o dos canjes tienen consecuencias aceptables.

La semántica pertenecía al recurso

HTTP dispone de métodos seguros e idempotentes, pero el método no es el recurso. Un GET puede gastar un enlace firmado, activar un trabajo costoso o registrar una medición facturable. Un POST diseñado con una clave única puede reconocer duplicados. El RFC 8470 trata la seguridad del método como evidencia para el cliente, no como veredicto universal para el servidor.

La pila TLS sabe si los bytes son tempranos. El agente sabe qué envió. Un proxy sabe a qué backend apunta. El origen sabe qué ocurrirá si la operación se procesa dos veces. Por eso TLS exige un perfil de aplicación antes de usar 0-RTT y prohíbe que una biblioteca active o reenvíe los datos por su cuenta.

La separación evita una delegación accidental de autoridad. Aceptar el handshake rápido no autoriza por sí mismo a consumir un derecho, mover dinero o crear una tarea.

Rechazar todo, esperar o devolver 425

RFC 8470 deja tres caminos. El servidor puede rechazar todo el early data en TLS. Es la frontera más simple, pero elimina la ventaja para todas las peticiones de ese vuelo porque TLS no selecciona una petición HTTP individual.

Puede aceptar los bytes y retrasar la acción hasta que termine el handshake. Leer lo suficiente para enrutar no equivale a producir el efecto. En protocolos multiplexados, una petición puede esperar y otra avanzar.

O puede devolver 425 a una sola petición. Así mantiene la opción rápida para recursos con política explícita y devuelve la operación sensible al cliente. El código no condena 0-RTT; lo hace revocable donde el conocimiento es mejor.

Early-Data: 1 no era una preferencia

El origen puede estar detrás de CDN, balanceadores y puertas de enlace. Su conexión inmediata quizá ya sea ordinaria, aunque el primer salto recibiera la petición antes de la negociación.

El campo Early-Data solo admite 1. El intermediario que reenvía una petición antes de completar su handshake con el cliente debe añadirlo si falta. Quien lo recibe no debe quitarlo. Si una instancia cree que la petición pudo ser repetida o ya enviada por otra, conserva la marca.

La marca es procedencia de riesgo. Esperar el handshake del siguiente salto no elimina la posible copia del salto anterior. Si el origen no puede actuar con seguridad sobre una petición marcada, debe devolver 425 incluso cuando su propio canal esté plenamente establecido.

Las variantes mal formadas o repetidas se interpretan como el mismo bit conservador. El campo no se usa en respuestas, trailers ni opciones Connection. Su pobreza semántica es una ventaja: ningún intermediario puede convertirlo en certificado de confianza.

La regla de recuperación era exacta

Al recibir 425 después de usar early data, el agente debería reintentar automáticamente. La nueva transmisión no puede volver a ser temprana. El cliente completa la negociación y reenvía la operación como datos normales.

No necesita cambiar la URI, el método o el cuerpo. No es un redirect. Tampoco es 421, porque la conexión puede tener autoridad para el origen. No es 429, porque no expresa cuota; ni 503, porque el servicio puede estar sano; ni 100 Continue, porque no decide si conviene enviar el cuerpo.

El servidor no debería usar 425 en una petición ordinaria sin early data ni cabecera. En ese caso no sabe si el cliente entiende el reintento especial. La respuesta no es almacenable de forma predeterminada y no representa el recurso solicitado. El registro IANA conserva el nombre preciso Too Early.

Un proxy solo puede limpiar su propio momento

Si una petición ya llegó marcada, el intermediario debe reenviar el 425: la exposición empezó aguas arriba. No puede convertir una historia insegura en segura con un reintento local sobre otro enlace.

Cuando el propio intermediario fue el primer receptor del early data y no recibió la marca, sí puede esperar que termine su handshake con el cliente y reintentar hacia el origen. Conoce el comienzo de la incertidumbre y puede mover esa misma petición fuera de él.

Una puerta de enlace no debe adelantar peticiones a un origen que no entiende RFC 8470. Si no conoce la capacidad del backend, espera o devuelve 425. El edge no recibe mandato para asumir consecuencias que pertenecen a la aplicación.

La acción, no el último paquete

Una petición puede empezar en 0-RTT y terminar después de la negociación. En QUIC, un stream clasificado como temprano puede entregarse tarde. El reloj de llegada no borra su procedencia.

La frontera operativa es cuándo comienza el efecto. Analizar cabeceras y seleccionar ruta puede ser neutral; escribir, llamar a un tercero, consumir una credencial o encolar no lo es. Cada instancia capaz de recibir una repetición debe mantener la misma prohibición de actuar antes de la prueba fresca, aunque sus técnicas concretas difieran.

Los reinicios son especialmente peligrosos. Una instancia nueva no recuerda ClientHello vistos antes de arrancar. Durante el solapamiento con su ventana de registro debe rechazar 0-RTT. El olvido de una máquina no puede ampliar el derecho del mensaje.

HTTP/3 añadió otra memoria, no una salida

El RFC 9114 mantiene las mitigaciones de RFC 8470 para 0-RTT sobre QUIC. Además, el cliente temprano depende de SETTINGS recordados de la sesión anterior. El servidor debe rechazar 0-RTT si no puede demostrar compatibilidad con su configuración actual; tras aceptarlo, no puede anunciar límites menores que contradigan datos ya enviados.

Esta compatibilidad no reemplaza 425. Los SETTINGS protegen el estado de HTTP/3; 425 protege los efectos del recurso. Una petición necesita ambas clases de evidencia.

Fuentes y límites de evidencia

El registro técnico cerrado es TLS 1.3, RFC 8446, Using Early Data in HTTP, RFC 8470, HTTP/3, RFC 9114 y el registro IANA de códigos HTTP, que lista 425 como Too Early. Las fuentes prueban normas y límites, no una cuota actual de despliegue, soporte universal, un incidente concreto, ahorro medido ni ejecución exactamente una vez.