Introducción
La privacidad en la capa de red suele colapsar cuando la misma entidad controla tanto el anonimato como el contenido. Cloudflare aborda este dilema con su nuevo OHTTP Gateway, pero lo hace mediante una restricción severa: el servicio se niega a operar si detecta que las solicitudes llegan desde su propia infraestructura de Workers o servidores proxeados. Esta no es una limitación técnica accidental, sino una salvaguarda arquitectónica para cumplir con el modelo de confianza definido en el RFC 9458. Para los equipos de SRE y seguridad, esto significa que no pueden simplemente colocar el Gateway detrás de su CDN existente; deben diseñar una topología distribuida donde el relay y el gateway sean entidades independientes. El costo de esta privacidad es la complejidad operativa: Cloudflare no provee el relay, dejando la responsabilidad de la anonimización en el cliente.
Qué ocurrió
Cloudflare abrió una beta cerrada para el OHTTP Gateway, un servicio gestionado que actúa como el punto final de descifrado para solicitudes Oblivious HTTP (OHTTP). El componente central de la noticia no es la funcionalidad en sí, sino la política de rechazo: el Gateway devolverá un error si recibe tráfico cuyo origen puede correlacionarse con la infraestructura de Cloudflare. Los autores Lara Schull y Akshat Mahajan justifican esta postura argumentando que el modelo OHTTP «requiere que el relay y el servidor de aplicaciones sean operados por partes separadas y no coludidas».
Para evitar confusiones de marca y funcionalidad, Cloudflare renombró su producto anterior «Privacy Gateway» a «Cloudflare OHTTP Relay». El nuevo Gateway se vincula a una zona específica y escucha en una ruta fija: https://your-zone.com/.well-known/ohttp-gateway. Esta ruta estática impide que un cliente apunte su configuración a un dominio ajeno, asegurando que la clave pública HPKE se sirva desde el mismo contexto de seguridad que el endpoint de decodificación. Los clientes recuperan las claves públicas mediante una solicitud GET a esa misma ruta, pudiendo utilizar una dirección IP distinta a la que usarán para enviar las solicitudes cifradas, lo que añade una capa adicional de ofuscación de metadatos.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Desde la perspectiva de DevOps, la restricción de Cloudflare rompe el flujo de trabajo habitual de «todo en una nube». No es posible encadenar un Cloudflare Worker delante del Gateway para añadir lógica de negocio o filtrado antes de la decodificación, ya que el Gateway interpretará esa cadena como una violación de la independencia de operadores. Esto obliga a los equipos a mantener el relay en una infraestructura externa (AWS, GCP, Azure o bare-metal), incrementando la superficie de ataque y la necesidad de monitoreo distribuido.
Para los equipos de seguridad, el impacto es doble. Positivamente, se garantiza que Cloudflare no pueda correlacionar la identidad del cliente (IP) con el contenido de la solicitud, siempre que se respete la separación de roles. Negativamente, la protección se detiene en la capa de red. Cloudflare enfatiza que OHTTP «no toca el cuerpo de la solicitud interna». Si un desarrollador envía un token de sesión, un correo electrónico o un ID de usuario en el payload cifrado, el operador del Gateway (Cloudflare) obtiene esa identidad, neutralizando el propósito del protocolo. La seguridad depende ahora estrictamente de la disciplina de los desarrolladores para sanitizar los datos internos antes de cifrarlos.
Detalles técnicos
El protocolo OHTTP, estandarizado en el RFC 9458, divide el flujo HTTP en dos partes mediante criptografía de clave pública híbrida (HPKE). El cliente cifra el contenido de la solicitud utilizando la clave pública del Gateway y envía ese payload sellado a un Relay. El Relay ve la dirección IP del cliente pero es incapaz de leer el contenido. Luego, el Relay reenvía el payload cifrado al Gateway, que descifra el contenido pero solo ve la dirección IP del Relay, no la del cliente original.
La implementación de Cloudflare gestiona el ciclo de vida de las claves HPKE automáticamente, sirviéndolas en el endpoint .well-known/ohttp-gateway. Soporta tanto OHTTP estándar como el modo «chunked», recomendando este último para mejorar el rendimiento en conexiones persistentes. La autenticación del Relay hacia el Gateway puede configurarse usando Cloudflare Access con mTLS, credenciales de servicio estáticas o lógica externa personalizada. Sin embargo, esta autenticación protege solo la conexión de red entre el Relay y el Gateway; no valida la integridad ni la privacidad del cuerpo de la solicitud una vez descifrada.
Una crítica técnica relevante, surgida en la comunidad de Hacker News, señala la falta de secreto hacia adelante (forward secrecy) en la recuperación de claves. Si la clave privada del Gateway se ve comprometida, un atacante con acceso a las capturas de tráfico del Relay podría descifrar el historial de solicitudes pasadas, a diferencia de protocolos como TLS 1.3 con PFS. Además, comparado con un proxy SOCKS5, OHTTP ofrece ventajas de latencia al permitir conexiones TLS de larga duración entre cliente-relay y relay-gateway, evitando el handshake completo por cada solicitud, crucial para cargas de trabajo como DNS over HTTPS.
Qué deberían hacer los administradores y equipos técnicos
Primero, audite su arquitectura actual. Si planea implementar OHTTP, debe aprovisionar un Relay en un proveedor de nube distinto a Cloudflare. No intente usar Workers como intermediario. Configure el Relay para que no guarde logs de dirección IP de los clientes o utilice una solución de anonimato que elimine metadatos antes de reenviar el payload al Gateway.
Segundo, implemente validadores de esquemas estrictos en el lado del cliente antes de cifrar. Asegúrese de que ningún dato de identificación personal (PII) o credenciales de sesión viajen en el cuerpo de la solicitud OHTTP. Utilice tokens anónimos o referencias indirectas que el backend pueda resolver sin exponer la identidad original en el nivel de red.
Tercero, configure el acceso al Gateway usando mTLS o Cloudflare Access, pero entienda que esto protege la integridad del canal, no la privacidad del contenido. Monitoree los logs del Gateway para detectar anomalías en el volumen de descifrado, pero recuerde que estos logs mostrarán el tráfico ya descifrado. Si la confidencialidad del contenido es crítica, considere si OHTTP es la herramienta adecuada o si necesita una capa adicional de cifrado de aplicación (end-to-end encryption) dentro del payload.
Conclusión
El OHTTP Gateway de Cloudflare representa un avance maduro en la estandarización de la privacidad de red, pero su valor reside en su rigidez. Al negarse a operar dentro de su propio ecosistema, Cloudflare prioriza la veracidad de la promesa de privacidad sobre la conveniencia de la integración. Para los ingenieros, esto implica aceptar una complejidad operativa mayor a cambio de una garantía criptográfica sólida: la separación de quien ve el «quién» y quien ve el «qué». La implementación exitosa no depende solo de la configuración del Gateway, sino de la disciplina en la gestión de datos internos y la correcta segregación de responsabilidades de infraestructura entre el Relay externo y el Gateway gestionado.
Fuentes
https://www.infoq.com/news/2026/10/cloudflare-ohttp-gateway/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global