Cloudflare comenzó una prueba cerrada de Cloudflare OHTTP Gateway, un complemento de pago que puede activarse en el dominio del cliente para recibir tráfico de Oblivious HTTP (OHTTP) mediante una infraestructura gestionada. El servicio está dirigido a desarrolladores que quieren ocultar la dirección IP y los indicadores de identificación del cliente a los servidores de sus aplicaciones, especialmente cuando dichos servidores están alojados detrás de la red de Cloudflare o en Workers.
Al mismo tiempo, la empresa cambió el nombre de su producto anterior Privacy Gateway a Cloudflare OHTTP Relay. El cambio refleja la existencia de dos productos diferentes en el modelo OHTTP: el relay reenvía las solicitudes cifradas y oculta la identidad del cliente, mientras que el gateway se encarga de descifrar el encapsulado cifrado de la solicitud y volver a encapsular la respuesta antes de entregarla al servidor de la aplicación.
¿Cómo funciona el modelo OHTTP?
En la comunicación tradicional, el servidor de la aplicación puede ver la dirección IP del cliente, las características de TLS y la información de ubicación, lo que podría permitir vincular varias solicitudes con el mismo usuario. En OHTTP, la solicitud pasa por un relay independiente que elimina los indicadores de identidad del cliente antes de reenviarla. El contenido de la solicitud permanece cifrado mediante Hybrid Public Key Encryption (HPKE), de modo que el relay no ve el texto sin formato.
Después, el gateway procesa la parte criptográfica y entrega la solicitud al servidor de la aplicación en el formato HTTP habitual. De este modo se establece una separación de confianza: el relay ve la identidad de la conexión, pero no el contenido de la solicitud, mientras que el gateway y el servidor de la aplicación ven el contenido de la solicitud sin la identidad directa del cliente. Este modelo exige que las dos entidades que desempeñan las funciones de relay y gateway no actúen de forma colusoria.
¿Qué aporta el nuevo gateway?
OHTTP Gateway funciona como una característica dentro del dominio de Cloudflare y puede activarse mediante puntos de acceso específicos, como /.well-known/ohttp-gateway. El servicio admite OHTTP estándar y Chunked OHTTP, y recomienda utilizar el tipo fragmentado para procesar las solicitudes progresivamente. Cloudflare también se encarga de gestionar las claves públicas HPKE y proporcionárselas a los clientes, en lugar de hacer responsable al cliente de gestionar el ciclo de vida de las claves.
El servicio aprovecha la red global de Cloudflare, lo que permite ejecutar el gateway en el perímetro de la red y reducir la latencia entre el relay y el gateway. Si los servidores de la aplicación utilizan la CDN de la empresa, la solicitud y el acceso al servidor pueden procesarse en la misma infraestructura. El gateway gestiona únicamente solicitudes OHTTP, mientras que las solicitudes normales siguen llegando al servidor sin pasar por el procesamiento OHTTP.
Controles de confianza y uso
Cloudflare Access permite imponer políticas de autenticación antes de descifrar las solicitudes, incluido mutual TLS, credenciales de servicio estáticas y lógica externa personalizada. El gateway también rechaza descifrar solicitudes procedentes de Cloudflare Workers o de hosts que pasan a través de Cloudflare, para evitar que el relay y el gateway sean operados por la misma entidad y debiliten la separación de confianza en la que se basa OHTTP.
Cloudflare recomienda utilizar OHTTP Gateway cuando los servidores de la aplicación están detrás de Cloudflare o cuando la solicitud procede de un relay y un cliente pertenecientes a un tercero, como ocurre en algunos casos de uso de Apple LiveCallerID. Por su parte, Cloudflare OHTTP Relay, con su nuevo nombre, es adecuado para quienes quieren utilizar el relay de Cloudflare y ejecutar el gateway por su cuenta fuera de Cloudflare.
¿Qué cambia en la práctica?
El nuevo servicio reduce la carga operativa de construir un gateway OHTTP, pero no elimina los requisitos arquitectónicos fundamentales. El cliente necesita implementar OHTTP y el usuario también necesita un relay independiente; Cloudflare recalca que el relay debe ser una entidad en la que se pueda confiar para no inspeccionar los registros ni vincular las identidades de los clientes con las solicitudes descifradas. Asimismo, OHTTP no protege los metadatos incluidos dentro del propio texto de la solicitud, por lo que corresponde al desarrollador no enviar el correo electrónico, el nombre de usuario ni otros identificadores dentro del contenido de la solicitud.
El servicio está disponible actualmente mediante una prueba cerrada y una lista de espera, y el anuncio no especificó una fecha de lanzamiento general ni detalles sobre los precios. Por ello, el paso representa una expansión importante de las herramientas de privacidad de red, pero todavía exige que los equipos de desarrollo tomen decisiones independientes sobre el relay, el contenido de la solicitud y el modelo de confianza entre las partes.