OHTTP Gateway: privacidade depende de separar quem vê a rede de quem vê o conteúdo

A Cloudflare anunciou a beta fechada do OHTTP Gateway, planejado como adicional pago numa zona, e renomeou o antigo Privacy Gateway para OHTTP Relay.[17] A proposta é receber requisições sem associar o conteúdo ao IP e ao fingerprint TLS do usuário.[17] Para quem desenvolve, o ponto central é a separação de confiança, não a simples presença de criptografia.

O que muda para quem desenvolve

No Oblivious HTTP, o relay conhece identificadores de rede do cliente, mas encaminha conteúdo cifrado; o gateway decripta a requisição para a aplicação sem conhecer a identidade de rede original.[17] A privacidade depende de participantes separados e não coniventes.[17]

Minha leitura é que esse desenho muda a pergunta de arquitetura: quais informações cada participante consegue reunir sozinho ou em conjunto? A resposta precisa incluir logs e conteúdo da aplicação, não apenas o caminho criptográfico.

Uma aplicação fora da Cloudflare pode usar seu Relay com gateway separado, enquanto uma aplicação atrás do CDN ou em Workers pode usar o novo Gateway com relay de terceiro.[17] No novo serviço, Cloudflare Access atua antes da decriptação e pode autenticar relays.[17] Não confunda a autenticação desse intermediário com uma necessidade automática de identificar a pessoa na requisição interna.

Como aplicar

Antes de integrar, desenhe uma tabela com cliente, relay, gateway e aplicação. Para cada participante, registre acesso a IP, conteúdo, horário, credenciais e identificadores persistentes. Acrescente quem administra cada um e quem pode consultar os respectivos registros.

Faça uma revisão de payloads com exemplos sintéticos. Marque campos que permitiriam reconhecer a pessoa mesmo sem IP: e-mail, nome de usuário ou um identificador estável. Pergunte quais são indispensáveis à função e quais podem ser removidos. O protocolo não sanitiza o corpo interno; identificadores enviados ali podem anular o objetivo de privacidade.[17]

Num piloto autorizado, confira separadamente a requisição vista pelo relay e a recebida pela aplicação. O critério de aceite deve demonstrar a separação pretendida e verificar que o diagnóstico de erros não recombina essas informações por conveniência. Não use dados pessoais reais para provar anonimização.

Cuidados e limites

O serviço está em beta fechada, sem preço tabelado ou disponibilidade geral apresentados no anúncio, e exige cliente OHTTP e relay realmente independente.[17] Isso impede tratá-lo como componente imediatamente disponível para qualquer implantação.

O Gateway recusará decriptar tráfego proveniente de Workers ou hosts proxied na própria Cloudflare como proteção contra erros na separação de confiança.[17] Essa regra não substitui a revisão do restante do fluxo.

A arquitetura adiciona participantes, integração e pontos de falha. Avalie esse custo contra a informação que o produto realmente precisa conhecer. OHTTP pode reduzir associação entre rede e conteúdo; não torna automaticamente anônima uma aplicação que pede identificação dentro do próprio pedido.

Fonte

[17] Fonte: Cloudflare Blog