Prompt y contexto
Esta pregunta sobre fundamentos de HTTP y seguridad se adapta a roles de backend, plataforma, SRE e infraestructura. El escenario es una solicitud 0-RTT de TLS 1.3 que llega a un gateway: early data reduce la espera del handshake pero puede ser objeto de repetición (replay). Una respuesta sólida conecta la semántica de 425, la idempotencia de negocio y la política salto a salto (hop-by-hop).
Lo que evalúa el entrevistador
- Comprensión del beneficio de rendimiento de 0-RTT y su riesgo de repetición.
- Límites precisos entre 425, 429, 503 y 408.
- Uso de claves de idempotencia, registros de deduplicación y consulta de estado para efectos secundarios.
- Política consistente de early-data a través de gateways, orígenes e instancias.
Preguntas clarificadoras
Primero, confirma que existan pruebas de early data, si la operación tiene efectos secundarios, si el gateway preserva Early-Data y si el cliente puede reintentar tras un handshake completo. Luego, pregunta sobre claves de idempotencia, restricciones de unicidad, registros de deduplicación y estado compartido entre instancias. Un GET aún puede tener efectos secundarios de negocio, por lo que el nombre del método por sí solo no es una prueba de seguridad.
Marco de respuesta de 30 segundos
TLS 1.3 0-RTT permite a un cliente enviar early data antes de que finalice el handshake, pero esos datos pueden ser repetidos. Si no se demuestra que una solicitud es segura de procesar, el servidor devuelve 425 Too Early y solicita al cliente que reintente tras el handshake; el reintento no debe volver a utilizar early data. Acepta early data solo para operaciones idempotentes y seguras contra repetición con deduplicación. Los gateways y orígenes deben estar de acuerdo en Early-Data: 1, mientras se monitorea la amplificación de reintentos.
Análisis detallado paso a paso
- Plantear el riesgo. Los datos tempranos (early data) de 0-RTT siguen estando cifrados, pero un atacante puede copiar y repetir una solicitud válida. El riesgo principal son los efectos secundarios duplicados, no la pérdida directa de confidencialidad.
- Definir 425. Devuelve 425 cuando el procesamiento durante la fase de early-data no sea seguro. Un servidor no debe emitir 425 sin evidencia de early data; la respuesta no es almacenable en caché por defecto.
- Clasificar operaciones. Verifica los efectos secundarios reales incluso para lecturas. Los pagos, envíos y cambios de cuota normalmente deben esperar un handshake completo. Si se acepta early data, exige una clave de idempotencia, una restricción de unicidad o un registro de deduplicación.
- Especificar el reintento. Un cliente que envió early data reintenta tras un handshake completo, y el reintento no debe enviarse como early data. Limita el número de reintentos y el tiempo total.
- Mantener la consistencia entre saltos. Un intermediario de confianza puede añadir o reenviar
Early-Data: 1. Los gateways, balanceadores de carga y orígenes necesitan el mismo límite de confianza; de lo contrario, una instancia puede esperar mientras otra ejecuta un efecto secundario. - Controlar la amplificación. Durante una sobrecarga, las respuestas 425 y los reintentos de handshake pueden amplificar el tráfico. Limita el tamaño de early-data y la concurrencia, y monitorea la proporción de 425, la tasa de reintentos, las claves de negocio duplicadas y la latencia del handshake.
Respuesta modelo
Trataría Early-Data: 1 como una señal de riesgo de repetición, no como una solicitud confirmada ordinaria:
POST /payments HTTP/1.1
Early-Data: 1
Idempotency-Key: pay-123Si no se demuestra que la operación de pago es segura contra repeticiones, devuelvo 425 Too Early y hago que el cliente complete el handshake de TLS antes de reintentar con la misma clave de idempotencia; el reintento no debe volver a utilizar early data. Incluso para una operación segura contra repeticiones, utilizo una restricción de unicidad o un registro de deduplicación para evitar la ejecución duplicada. 425 no es limitación de tasa (429), indisponibilidad temporal amplia (503) ni un timeout del cliente (408). Los gateways y los orígenes comparten una misma política y registran el ID de solicitud, el marcador de early-data, el recuento de reintentos y las claves duplicadas para que los reintentos no amplifiquen la sobrecarga.
Errores comunes
- Decir que “0-RTT no está cifrado” → TLS aún lo cifra → el riesgo es la repetición.
- Reenviar 0-RTT sin cambios tras un 425 → el riesgo persiste → reintentar tras un handshake completo.
- Devolver 425 para cada POST → algunas escrituras tienen deduplicación confiable → evalúa los efectos secundarios y la evidencia.
- Tratar 425 como 429 → 425 maneja early data, mientras que 429 indica limitación de tasa → utiliza backoff y alertas independientes.
- Verificar únicamente en el gateway → los orígenes pueden ejecutarse de manera inconsistente → comparte los límites de confianza y el estado.
Preguntas de seguimiento
¿Cómo distingues 425 de 503?
425 aborda el riesgo de repetición durante la fase de early-data; 503 significa que el servicio no puede procesar la solicitud temporalmente. Elige 425 solo cuando exista evidencia de early data y la política requiera esperar al handshake.
¿Por qué no permitir únicamente GET?
Los nombres de los métodos HTTP no garantizan la ausencia de efectos secundarios de negocio. Algunas solicitudes GET activan contadores, precargas (prefetches) o cambios de estado, por lo que se deben evaluar los efectos reales y la deduplicación.
¿Cómo debe transmitir un gateway la información de early-data?
Un intermediario de confianza puede añadir o reenviar Early-Data: 1, pero debe evitar que clientes no confiables falsifiquen la señal e informar al origen de dónde provino el marcador y qué política se aplica.
¿Cómo demuestras que un cobro no puede ocurrir dos veces?
Utiliza la misma clave de idempotencia para una inserción única o registro de deduplicación, registra el estado final, consulta antes de reintentar y concilia los eventos de pago con la orden comercial posteriormente.