Entrevista general: ¿Cómo diseñarías un relay y un gateway de Oblivious HTTP?

Pregunta y alcance

Un cliente de telemetría desea que el servicio de destino (target) no pueda vincular las solicitudes con la identidad del cliente, mientras que el nodo de reenvío no pueda leer el contenido de la solicitud. Diseña el cliente, relay, gateway y target de OHTTP, cubriendo el descubrimiento de claves, encapsulamiento HPKE, manejo de errores, defensa contra replay, mapeo de recursos, límites de tasa y monitoreo.

El estándar RFC 9458 estandariza el reenvío de mensajes HTTP cifrados: el relay ve la conexión del cliente, mientras que el gateway descifra y llama al target, de modo que ninguno de los dos debería conocer de forma independiente tanto la identidad como el contenido. OHTTP no es una red anónima; la longitud de los mensajes, la temporización (timing), la colusión entre relay y gateway, los metadatos del cliente y los identificadores de la aplicación aún requieren un tratamiento por separado.

Qué está evaluando el entrevistador

• Definir qué pueden ver el Client, Relay, Gateway y Target, y dónde termina la confianza.
• Explicar la clave pública del gateway, el encapsulamiento de solicitudes/respuestas con HPKE y los tipos de medios (media types).
• Diseñar la defensa contra replay, los límites de tamaño de solicitud, los tiempos de espera (timeouts) y el mapeo de errores.
• Manejar el mapeo de recursos uno a uno entre relay y gateway, el análisis de tráfico y el riesgo de colusión.
• Gestionar la rotación de claves, el almacenamiento en caché, los reintentos y el desfase de reloj (clock skew) del cliente.
• Validar mediante métricas de aceptación, fallas de descapsulamiento, rechazo de replays, latencia y distribución de longitudes.

Preguntas para aclarar primero

1. ¿Se trata de telemetría unidireccional, lecturas públicas o escrituras de alto valor? Las escrituras sensibles necesitan una autenticación y controles de replay más estrictos.
2. ¿El relay y el gateway son operados por entidades distintas, o una sola organización puede ser dueña de ambos?
3. ¿El target devuelve resultados diferentes según la autorización del usuario, el inquilino (tenant) o la región?
4. ¿Cuáles son los límites de tamaño de solicitud, ventana de procesamiento por lotes (batching), latencia y tolerancia a pérdidas?
5. ¿Pueden los clientes volver a descubrir la configuración tras la expiración de la clave, y qué campos de registro (logs) deben redactarse?

Una respuesta en 30 segundos

Establecería cuatro límites: el cliente se conecta al relay, el relay reenvía únicamente un mensaje encapsulado y el gateway lo descifra antes de llamar al target. El cliente descubre la configuración de clave del gateway y utiliza HPKE para encapsular el HTTP binario; la respuesta se encapsula en la dirección inversa. El gateway utiliza una ventana de tiempo, un identificador único de solicitud o idempotencia de la aplicación para rechazar replays, mientras que el relay limita los recursos de conexión y de mensajes. Las claves se rotan con un periodo de superposición y se monitorean las fallas de descapsulamiento, el rechazo de replays, la latencia y las distribuciones de longitud; no se debe presentar OHTTP como una protección contra la colusión o el análisis de tráfico.

Análisis detallado paso a paso

1. Definir las cuatro responsabilidades

El Client conoce el recurso del target y la clave pública del gateway. El Relay conoce la conexión de red del cliente pero no debe leer el contenido encapsulado. El Gateway descifra y envía HTTP convencional al Target, el cual ve al gateway como su origen. Se debe separar el despliegue, los registros y los permisos de acceso para que una sola parte no pueda correlacionar trivialmente la identidad y el contenido.

2. Descubrir y validar la configuración de claves

El cliente obtiene una configuración de clave del gateway que contiene un identificador de clave, los algoritmos HPKE y una clave pública. Requiere una fuente autenticada, una versión y una fecha de expiración; se deben rechazar algoritmos no compatibles y claves caducadas. Durante la rotación, se publican las claves antiguas y nuevas de forma conjunta hasta que los cachés de los clientes y las ventanas de solicitud hayan transcurrido.

3. Encapsular solicitud y respuesta

El cliente codifica una solicitud HTTP binaria y la encapsula con HPKE como una carga útil de tipo message/ohttp-req. El gateway descapsula y valida el método, el recurso de destino, el tamaño y el tipo de contenido. Encapsula la respuesta como message/ohttp-res. El relay no debe analizar el HTTP interno ni enrutar basándose en el estado en texto claro.

Client -- TLS --> Relay -- opaque OHTTP --> Gateway -- HTTP --> Target
Client <-- opaque response -- Relay <-- OHTTP response -- Gateway

4. Gestionar autenticación, replay e idempotencia

OHTTP oculta la identidad de red; no autentica a un usuario de negocio. Para las escrituras, utiliza una firma de aplicación, un nonce de un solo uso, una ventana de tiempo o una clave de idempotencia. El gateway mantiene un estado mínimo de detección de replays y rechaza mensajes encapsulados repetidos. Los lotes de telemetría pueden incluir identificadores de eventos idempotentes para que los reintentos no dupliquen el conteo.

5. Manejar errores y mapeo de recursos

Si el descapsulamiento falla, el gateway devuelve un error estructurado de clave o de encapsulamiento sin exponer detalles de la clave privada. Los errores de negocio del target regresan dentro de una respuesta OHTTP. El mapeo de recursos entre relay y gateway debe ser fijo y verificable para que un mensaje no llegue al target equivocado. Aplica límites separados para timeouts, tamaño y sobrecarga en cada capa.

6. Evaluar la fuga de privacidad y el análisis de tráfico

El cifrado no evita que el relay vea la IP del cliente, la temporización y las longitudes de los mensajes, ni que el gateway vea la frecuencia de las solicitudes y los campos de aplicación descifrados. El relleno (padding), el procesamiento por lotes, los límites de tasa y los registros separados pueden reducir la correlación a costa de latencia y costos operativos. No afirmes que OHTTP neutraliza la colusión entre relay y gateway.

7. Estrategia canary, monitoreo y fallback

Comienza con una cohorte reducida de clientes y recursos dedicados de relay/gateway. Rastrea aciertos de configuración, éxito de descapsulamiento, rechazo de replays, errores 5xx del target, latencia p95, rangos de tamaño de mensaje y tasa de fallback. Durante un incidente, deshabilita OHTTP de forma granular por target o versión de cliente; el fallback a HTTPS convencional requiere una revisión de privacidad. Conserva identificadores de configuración, clases de error y hashes de solicitudes, no campos de identidad internos.

Ejemplo de respuesta de alta calidad

Separaría el cliente, el relay, el gateway y el target en cuatro dominios de responsabilidad. El cliente obtiene y valida la configuración de claves HPKE del gateway, encapsula HTTP binario y lo envía al relay. El relay reenvía bytes opacos. El gateway descapsula, verifica el tamaño y el mapeo de recursos, y llama al target con su propia identidad; la respuesta se encapsula en el camino de regreso.

OHTTP no proporciona autenticación de negocio ni evita la colusión entre relay y gateway. Por lo tanto, las escrituras requieren firmas de aplicación, nonces o claves de idempotencia, junto con una verificación de replay por ventana de tiempo en el gateway. Rota las claves con una ventana de superposición y restringe las conexiones del relay y los recursos de mensajes. Implementa un despliegue canary monitoreando fallas de descapsulamiento, rechazo de replays, latencia, distribución de tamaño y errores de negocio; permite el fallback a HTTPS convencional solo tras una revisión explícita de privacidad.

Errores comunes

• Tratar al relay como un proxy que descifra → el límite de privacidad desaparece → permítele manejar solo la conexión externa y el mensaje opaco.
• Asumir que OHTTP autentica usuarios → el target no puede identificar a un principal de negocio legítimo → añade una firma de aplicación o token de autorización.
• Ignorar la longitud del mensaje y la temporización → el análisis de tráfico aún puede correlacionar solicitudes → utiliza padding y batching midiendo el impacto en la latencia.
• Reintentar escrituras sin idempotencia → la telemetría se duplica o los efectos secundarios se repiten → utiliza nonces, identificadores de eventos y ventanas de replay.
• Compartir registros vinculables entre relay y gateway → una parte puede recuperar tanto la identidad como el contenido → separa operadores, campos y permisos de acceso.

Preguntas de seguimiento y respuestas

¿Puede OHTTP evitar la colusión entre el relay y el gateway?

No. El protocolo depende de la confianza limitada y de la separación operativa. Las partes que coluden pueden correlacionar la identidad de la conexión con el contenido descifrado, por lo que las organizaciones, los registros y los controles de acceso deben mantenerse independientes.

¿Cómo previene el gateway los ataques de replay?

Utiliza una ventana de tiempo, un nonce, un ID de evento idempotente o una firma de aplicación para las escrituras; mantén un estado de detección mínimo y rechaza los mensajes encapsulados repetidos. TLS en cada conexión por sí solo no previene el replay entre diferentes conexiones.

¿Por qué es necesario el mapeo de recursos?

Un relay debe reenviar una solicitud encapsulada al recurso previsto de gateway/target. El mapeo fijo permite que los límites de clave, política, límite de tasa y auditoría sean verificables, y evita la entrega a un gateway incompatible.

¿Cómo se rota una clave pública de gateway?

Publica una nueva configuración versionada y con fecha de expiración mientras se retiene la clave antigua durante las ventanas de caché, batching y reintentos. Observa los aciertos y las fallas de descapsulamiento por ID de clave, y luego retira la clave privada antigua.

¿Es adecuado OHTTP para escrituras de alto valor?

Solo con precaución. Oculta la identidad de red pero no sustituye la autenticación, la autorización, la idempotencia o la auditoría. Valida el principal de la aplicación y el límite de replay antes de aceptar su compromiso entre latencia y privacidad.

¿Qué se debe registrar en el monitoreo?

Registra el ID de configuración, el recurso de relay/gateway, la clase de error, el rango de tamaño de solicitud, el rechazo de replays y la latencia de extremo a extremo. No registres por defecto dominios internos, identificadores de usuario ni contenido encapsulado sin procesar.