Consigna y contexto
Una API de pagos habilita la reanudación de sesiones TLS 1.3. Algunas solicitudes llegan antes de que se complete el handshake y el gateway devuelve 425 Too Early. Explica qué solicitudes pueden usar early data, cómo prevenir efectos secundarios por repetición, cómo lo señalan los proxies y cuándo puede reintentar un cliente.
Qué evalúa el entrevistador
- Comprender que 0-RTT reduce la latencia pero no proporciona la protección contra repetición de un handshake ordinario.
- Distinguir correctamente entre 425, un tiempo de espera (timeout) de red y un rechazo de negocio, y usar
Early-Data: 1. - Conectar claves de idempotencia, una ventana de desduplicación, la política del gateway y la máquina de estados del servidor.
- Demostrar con métricas y simulacros que los reintentos no cobran dos veces.
Preguntas para clarificar
- ¿Qué cliente, CDN, gateway u origen termina TLS y puede saber si la información es early data?
- ¿La solicitud es un GET o lectura, o realiza un cobro, envío, otorgamiento o publicación con efecto secundario?
- ¿Existe una clave de idempotencia globalmente única, cuánto tiempo se retiene y se comparte entre regiones?
- ¿Un solo gateway genera 425 y cada SDK puede entenderlo y reconstruir el cuerpo?
- ¿Cómo se alinean el límite de tiempo de reintento, la vigencia de la autorización de pago y el estado visible para el usuario?
Respuesta en 30 segundos
0-RTT permite que un cliente que reanuda TLS 1.3 envíe datos de aplicación de forma temprana, pero un atacante podría repetir esos datos. Un servidor debe rechazar los early data para solicitudes con efectos secundarios; un intermediario compatible puede señalizarlo con Early-Data: 1 y el origen puede devolver 425. Después de un handshake completo, un cliente reintenta solo cuando la repetición es segura. Para operaciones de escritura de pago, primero consulta el resultado de idempotencia o espera la confirmación de negocio; un 425 no es prueba de que el cobro haya fallado.
Respuesta a fondo
Paso 1: Definir el límite de 0-RTT
La reanudación en TLS 1.3 permite early data para ahorrar un viaje de ida y vuelta (round trip). El servidor no debe tratarlo como una prueba nueva y no repetible: un atacante puede copiar los mismos bytes y enviarlos de nuevo durante la ventana permitida.
Paso 2: Clasificar los efectos secundarios
Los GET públicos, las consultas de solo lectura o las solicitudes estrictamente idempotentes pueden considerar early data cuando las condiciones del protocolo y del negocio lo permitan. Cobrar, crear una orden, otorgar derechos o publicar un mensaje debe deshabilitarlo a menos que el servidor cuente con idempotencia confiable y desduplicación atómica.
Paso 3: Entender Early-Data y 425
Un intermediario compatible con early data puede agregar Early-Data: 1 al reenviarlo. Un origen que no esté dispuesto a aceptar el riesgo de repetición devuelve 425, lo que significa que la solicitud llegó demasiado pronto; el cliente debe reenviarla tras el handshake. La ausencia del encabezado no es prueba de cero riesgo de repetición, por lo que se debe verificar el despliegue completo.
Paso 4: Diseñar la política del gateway
El gateway mantiene una lista de permitidos por método, ruta y tipo de autenticación. Rechaza early data en rutas de pago, inventario y cambios de autorización, mientras registra el estado de la conexión para rutas de lectura. Debe preservar el 425 en lugar de reescribirlo como un 500 genérico.
Paso 5: Diseñar la idempotencia y la desduplicación
El cliente crea una clave impredecible para cada intención de negocio. El servidor confirma atómicamente el efecto secundario y el resultado de la desduplicación, o utiliza un límite atómico equivalente. Una clave duplicada devuelve el primer resultado y nunca vuelve a cobrar. El TTL cubre los reintentos máximos de red, el retraso en cola y la conciliación.
Paso 6: Especificar reintentos seguros
Después de un 425, se establece una conexión completa y se reenvía únicamente mientras el plazo sea válido y se pueda reconstruir el cuerpo. Los GET pueden reintentarse automáticamente. Una solicitud de pago con clave de idempotencia lee primero su estado; una escritura sin protección contra repetición pasa a confirmación de negocio. Limita los reintentos por intención y utiliza retroceso exponencial (backoff).
Paso 7: Verificar y observar
Registra el volumen de early data, la tasa de 425, la tasa de reintentos por ruta, las claves duplicadas, los cobros exitosos y las diferencias de conciliación. Inyecta fallas de proxy y de cliente para probar el rechazo, el reintento con handshake completo, el timeout, la entrega duplicada y la desduplicación interregional. La aceptación debe demostrar a lo sumo un efecto secundario por intención de negocio.
Respuesta modelo
Pondría las escrituras de pago en la lista de denegación de early data. Si el terminador de TLS recibe early data, reenvía Early-Data: 1; el origen devuelve 425 para esa escritura y mantiene un ID de solicitud para diagnóstico. Después de un handshake completo, el cliente no repite a ciegas: consulta la orden o el cobro mediante la clave de idempotencia y reintenta una sola vez cuando el estado es desconocido y el plazo lo permite. El servidor almacena atómicamente la clave, el resultado del negocio y el registro de desduplicación, con un límite interregional. Los GET de solo lectura pueden reintentarse automáticamente. Monitoreo los 425, las claves duplicadas y las diferencias de conciliación, y realizo simulacros en la ruta para demostrar que no hay cobros dobles.
Errores comunes
- Asumir que TLS 1.3 0-RTT es automáticamente seguro contra repeticiones.
- Reintentar 425 indefinidamente o reescribirlo como 500.
- Decidir la seguridad basándose únicamente en el método HTTP; algunos GET aún causan efectos secundarios.
- Mantener la clave de idempotencia solo en el cliente sin desduplicación atómica en el servidor.
- Tratar un timeout como prueba de que el servidor no hizo nada en lugar de consultar el estado.
Preguntas y respuestas de seguimiento
Pregunta de seguimiento 1: ¿En qué se diferencia 425 de 503?
425 aborda el riesgo de repetición en early data e invita a una reevaluación tras un handshake completo. 503 significa indisponibilidad temporal del servicio; su política de reintentos depende de la capacidad y de Retry-After.
Pregunta de seguimiento 2: ¿Quién agrega Early-Data?
Un intermediario que entiende el mecanismo agrega Early-Data: 1 al reenviar early data al origen. Verifica el punto de terminación TLS y que los proxies no descarten ni falsifiquen la señal.
Pregunta de seguimiento 3: ¿Es suficiente una clave de idempotencia para pagos con 0-RTT?
No. La clave debe ser impredecible, persistirse atómicamente con el resultado, desduplicarse en las regiones requeridas, retenerse el tiempo suficiente y demostrar que devuelve el mismo resultado ante duplicados.
Pregunta de seguimiento 4: ¿Por qué consultar después de un timeout del cliente?
Un timeout solo demuestra que el cliente no vio ninguna respuesta. Consultar el estado de idempotencia permite distinguir entre exitoso, en proceso y no ejecutado, evitando un segundo cobro.
Pregunta de seguimiento 5: ¿Cómo harías un despliegue canary?
Comienza con rutas de solo lectura y un grupo pequeño de clientes. Monitorea 425 y el éxito de los reintentos por ruta; deshabilita automáticamente early data ante efectos secundarios duplicados, anomalías de conciliación o señales de proxy faltantes.