Resumo

  • A RFC 9540 define o parâmetro vazio ohttp em registros SVCB ou HTTPS, o recurso /.well-known/ohttp-gateway no mesmo host e a busca da configuração de chaves do gateway.
  • O mecanismo não descobre nem certifica o relay; anúncio, identidade do endpoint, chave utilizável e resposta concluída são recibos diferentes.
  • Uma configuração, um redirecionamento ou um dohpath exclusivo pode separar um cliente do conjunto, mesmo com criptografia correta, tornando a consistência um controle independente.

O alerta nasceu de uma comparação que o painel não fazia. Dois clientes consultaram o mesmo resolvedor, encontraram suporte a OHTTP, validaram o endpoint e receberam respostas. Para os indicadores de disponibilidade, eram experiências idênticas. Para a privacidade, não eram: um deles recebeu uma configuração de chave que nenhum outro ponto de observação conhecia.

Não houve quebra criptográfica. O próprio material criptográfico formou o identificador.

Publicada em fevereiro de 2024, a RFC 9540 leva a descoberta de Oblivious HTTP aos registros Service Binding. Ela descreve como localizar o gateway e obter suas chaves, mas também trata diretamente de ataques de direcionamento. Seu mérito de governança é mostrar que “descoberto” não é sinônimo de “privado” e que o resultado depende de autoridades que não cabem num único status.

Um campo vazio altera a escolha do serviço

O ohttp SvcParamKey precisa ter valor vazio na forma textual e no fio. A presença informa que o serviço descrito pode funcionar como alvo OHTTP por meio de um gateway associado.

Ainda assim, o indicador participa da seleção. Quando aparece na lista mandatory, clientes que não entendem ohttp devem ignorar o registro. Fora dessa lista, ele anuncia uma modalidade opcional. Vários registros podem oferecer configurações distintas.

O recibo obtido é limitado: determinada fonte DNS anunciou determinada capacidade, naquele momento, com aquele TTL e aquelas regras. Ele não comprova que o cliente escolheu OHTTP, que o gateway estava alcançável ou que todos receberam o mesmo material. Em DNS aberto sem proteção DNSSEC, um agente no caminho pode remover a informação SVCB e provocar downgrade. Verificar o caminho conhecido ou combinar DNS criptografado e DNSSEC reduz o risco, sem testemunhar sobre o comportamento posterior do gateway.

Um sistema de evidências deve preservar a resposta bruta, o resolvedor, o ponto de observação, o estado DNSSEC, o transporte, mandatory, os candidatos e a razão da escolha. Resumir tudo a ohttp=true elimina a autoridade que fez a afirmação e a decisão que ela causou.

A descoberta termina antes do relay

OHTTP distribui visibilidade. O relay enxerga a identidade de rede do cliente e o destino do gateway, mas não o conteúdo encapsulado. O gateway abre a mensagem, porém não deveria receber diretamente a identidade de rede do cliente. O alvo processa a aplicação.

A RFC 9540 encontra alvo e gateway. A descoberta do relay fica fora do escopo. O modelo presume que o cliente já possui um relay confiável, capaz de alcançar gateways em geral ou de informar quais consegue alcançar.

Essa premissa requer decisão própria. Quem escolheu o relay? Que registros ele guarda? Qual jurisdição e qual operador o controlam? Ele compartilha infraestrutura, incentivos comerciais ou identificadores com o gateway? Como o combate a abuso altera a retenção? Conformidade com a RFC 9540 não resolve nada disso. Um selo de “OHTTP habilitado” não pode esconder a escolha de confiança que permanece aberta.

O caminho conhecido precisa ser percorrido duas vezes

Após encontrar ohttp, o cliente usa /.well-known/ohttp-gateway no mesmo host do alvo. O servidor pode redirecionar esse recurso. Porém, o cliente não pode entregar ao relay a URI redirecionada que recebeu ao buscar a configuração.

Se o fizesse, o gateway poderia inserir um valor exclusivo na URI do cliente e reconhecê-lo quando o relay voltasse com esse valor. O relay deve partir sozinho do caminho conhecido e seguir seus próprios redirecionamentos. Pode memorizar um destino comum à população; não deve herdar um rastro individual.

Logo, a observabilidade precisa manter dois percursos: o observado pelo cliente durante a obtenção da chave e o observado pelo relay durante a entrega da mensagem encapsulada. Guardar apenas a “URL final do gateway” destrói a comparação que revelaria personalização.

A exposição acontece antes da primeira consulta protegida

Para encapsular, o cliente faz um GET ao gateway com Accept: application/ohttp-keys. Uma busca direta revela seu endereço IP ao gateway. Isso pode ser aceitável quando o objetivo é apenas dissociar consultas individuais de um assinante já conhecido. Não atende a uma promessa de ocultar localização e pode permitir que o gateway escolha material exclusivo para aquele endereço.

Um proxy esconde o IP, mas cria outro observador. Além disso, é necessário examinar a configuração devolvida. Uma chave pode ser sintaticamente correta, usar algoritmos aprovados e existir apenas para uma pessoa. Como mensagens OHTTP podem ser relacionadas pela configuração usada, chave A para um cliente e chave B para todos os demais produz um grupo unitário sem violar o algoritmo.

A RFC recomenda alguma técnica de consistência, como confirmar a chave com um proxy compartilhado. Ao detectar direcionamento, o cliente pode abandonar e denunciar o gateway. A operação deve definir população de comparação, janela temporal, pontos independentes, rotação legítima e ação diante de divergência. “Chave válida” responde se é possível criptografar; “chave consistente” responde se o cliente recebeu tratamento comum.

dohpath também pode virar etiqueta

Em DoH oblivious, um dohpath exclusivo identifica o cliente mesmo quando a chave é compartilhada. A mitigação pode ser aceitar somente um valor conhecido, como /dns-query{?dns}, ou comparar valores arbitrários com outra fonte. A RFC permite amostragem conforme ameaça e capacidade. O nível de certeza deve seguir a cobertura dessa amostragem, não superá-la.

DDR e DNR também não têm a mesma autoridade. No DDR, continuam valendo as verificações de certificado previstas para o resolvedor descoberto. No DNR, DHCP ou Router Advertisement podem entregar os parâmetros e a confiança vem da designação de rede. Nenhum dos dois impede sozinho um caminho exclusivo. O certificado demonstra controle de identidade do endpoint, não tratamento igual entre clientes.

Privacidade exige uma sequência de recibos

Um serviço governável registra separadamente: o anúncio de ohttp; a interpretação de mandatory; a aceitação da designação DDR ou DNR; a identidade do endpoint; o recebimento de uma chave utilizável; a consistência de chave, rota e redirecionamento; a aprovação e o alcance do relay; a conclusão da transação; e a propriedade de privacidade realmente sustentada pelas observações.

O sucesso posterior não regulariza o que faltou antes. Uma resposta não legitima uma designação. Um certificado não comprova chave comum. Uma chave comum não comprova independência entre relay e gateway. Privacidade é uma conclusão delimitada sobre um conjunto de evidências, não um booleano emitido pelo parser.

Essa separação torna OHTTP mais confiável. Ela deixa a organização declarar com precisão se obteve disponibilidade, separação de consultas ou proteção mais ampla de identidade. O anúncio é uma entrada valiosa para a investigação; vira risco quando é promovido a veredito.

Fontes