A Cloudflare iniciou um teste fechado do Cloudflare OHTTP Gateway, um recurso pago que pode ser ativado no domínio do cliente para receber tráfego do Oblivious HTTP (OHTTP) por meio de uma infraestrutura gerenciada. O serviço é destinado a desenvolvedores que querem ocultar o endereço IP e os indicadores de identificação do cliente dos servidores de suas aplicações, especialmente quando esses servidores estão hospedados atrás da rede da Cloudflare ou no Workers.
Ao mesmo tempo, a empresa renomeou seu produto anterior Privacy Gateway para Cloudflare OHTTP Relay. A mudança reflete a existência de dois produtos diferentes no modelo OHTTP: o relay encaminha as solicitações criptografadas e oculta a identidade do cliente, enquanto o gateway descriptografa o encapsulamento da solicitação e reencapsula a resposta antes de entregá-la ao servidor da aplicação.
Como funciona o modelo OHTTP?
Na comunicação tradicional, o servidor da aplicação pode ver o endereço IP do cliente, as características do TLS e as informações de localização, o que pode permitir vincular várias solicitações ao mesmo usuário. No OHTTP, a solicitação passa por um relay independente que remove os indicadores de identidade do cliente antes de encaminhá-la. O conteúdo da solicitação permanece criptografado usando Hybrid Public Key Encryption (HPKE), de modo que o relay não vê o texto claro.
Em seguida, o gateway processa a parte criptográfica e entrega a solicitação ao servidor da aplicação no formato HTTP habitual. Dessa forma, estabelece-se uma separação de confiança: o relay vê a identidade da conexão, mas não vê o conteúdo da solicitação, enquanto o gateway e o servidor da aplicação veem o conteúdo da solicitação sem a identidade direta do cliente. Esse modelo exige que as duas entidades que desempenham os papéis de relay e gateway não operem de forma conivente.
O que o novo gateway acrescenta?
O OHTTP Gateway funciona como um recurso dentro do domínio da Cloudflare e pode ser ativado por meio de pontos de acesso específicos, como /.well-known/ohttp-gateway. O serviço oferece suporte ao OHTTP padrão e ao Chunked OHTTP, com recomendação de usar o tipo segmentado para processar as solicitações progressivamente. A Cloudflare também gerencia as chaves públicas HPKE e as fornece aos clientes, em vez de atribuir ao cliente a responsabilidade de gerenciar o ciclo de vida das chaves.
O serviço aproveita a rede global da Cloudflare, permitindo executar o gateway na borda da rede e reduzir a latência entre o relay e o gateway. Se os servidores da aplicação usarem a CDN da empresa, o processamento da solicitação e o acesso ao servidor poderão ocorrer na mesma infraestrutura. O gateway lida apenas com solicitações OHTTP, enquanto as solicitações comuns continuam chegando ao servidor sem passar pelo processamento OHTTP.
Controles de confiança e uso
O Cloudflare Access permite impor políticas de autenticação antes de descriptografar as solicitações, incluindo mutual TLS, credenciais de serviço estáticas e lógica externa personalizada. O gateway também recusa descriptografar solicitações provenientes do Cloudflare Workers ou de hosts encaminhados pela Cloudflare, para evitar que o relay e o gateway sejam operados pela mesma entidade e enfraqueçam a separação de confiança na qual o OHTTP se baseia.
A Cloudflare recomenda usar o OHTTP Gateway quando os servidores da aplicação estão atrás da Cloudflare ou quando a solicitação vem de um relay e de um cliente pertencentes a uma entidade externa, como em alguns casos de uso do Apple LiveCallerID. Já o Cloudflare OHTTP Relay, com o novo nome, é adequado para quem deseja usar o relay da Cloudflare e operar o gateway por conta própria fora da Cloudflare.
O que muda na prática?
O novo serviço reduz a carga operacional de criar um gateway OHTTP, mas não elimina os requisitos arquitetônicos fundamentais. O cliente ainda precisa implementar OHTTP, e o usuário também precisa de um relay independente; a Cloudflare enfatiza que o relay deve ser uma entidade confiável no que diz respeito a não inspecionar os registros nem vincular as identidades dos clientes às solicitações descriptografadas. O OHTTP também não protege os metadados presentes no próprio texto da solicitação, portanto cabe ao desenvolvedor não enviar o e-mail, o nome de usuário ou outros identificadores como parte do conteúdo da solicitação.
O serviço está atualmente disponível em um teste fechado e em uma lista de espera, e o anúncio não especificou uma data para o lançamento geral nem detalhes de preços. Portanto, a iniciativa representa uma expansão importante das ferramentas de privacidade de rede, mas ainda exige que as equipes de desenvolvimento tomem decisões independentes sobre o relay, o conteúdo da solicitação e o modelo de confiança entre as partes.