Hoje estamos a anunciar apoio para uma nova proposta de padrão DNS — uma co-autoria de engenheiros da Cloudflare, da Apple e da Fastly — que separa endereços de IP das consultas, de modo a que nenhuma entidade única possa ver os dois ao mesmo tempo. Melhor ainda, disponibilizámos o código-base para que qualquer pessoa possa experimentar o ODoH ou executar o seu próprio serviço ODoH!
Mas antes, o contexto. O "Domain Name System" (DNS) é a base de uma Internet utilizável por seres humanos. Mapeia nomes de domínio utilizáveis, como cloudflare.com, para endereços de IP e outras informações necessárias para se ligar a esse domínio. Pode ler uma introdução rápida sobre a importância e os problemas do DNS numa publicação no blog anterior. Para esta nossa publicação, apenas é preciso saber que no seu design inicial e na sua, ainda, predominante utilização, as consultas de DNS são enviadas em texto não encriptado. Isto significa que qualquer pessoa no caminho de rede entre o seu dispositivo e o resolvedor DNS pode ver tanto a consulta que contém o nome de host (ou site) que deseja, como o endereço de IP que identifica o seu dispositivo.
Para salvaguardar o DNS de curiosos e de terceiros, o IETF padronizou a encriptação DNS com o DNS sobre HTTPS ("DNS over HTTPS") (DoH) e o DNS sobre TLS ("DNS over TLS") (DoT). Ambos os protocolos evitam que as consultas sejam intercetadas, redirecionadas ou modificadas entre o cliente e o resolvedor. O apoio ao cliente para DoT e DoH está a crescer, tendo sido implementado em versões recentes do Firefox, iOS e muito mais. Mesmo assim, até que haja uma implementação mais ampla entre os provedores de serviços de Internet, a Cloudflare é um dos poucos provedores a oferecer um serviço público de DoH/DoT. Isto suscitou duas preocupações principais. Uma preocupação é a de que a centralização do DNS introduz pontos únicos de falha (no entanto, com data centers em mais de 100 países, a Cloudflare está desenhada para estar sempre acessível). A outra preocupação é a de que o resolvedor ainda pode ligar todas as consultas aos endereços de IP do cliente.
ACloudflare está empenhada na privacidade do utilizador final. Os utilizadores do nosso serviço de resolução de DNS público estão protegidos por uma política de privacidade forte e auditada . No entanto, para alguns, confiar à Cloudflare informações confidenciais de consulta é uma barreira à adesão, mesmo com uma política de privacidade tão forte. Em vez de confiar em políticas de privacidade e auditorias, e se pudéssemos dar aos utilizadores a opção de remover esse entrave com garantias técnicas?
A partir de hoje, a Cloudflare e parceiros estão a lançar suporte para um protocolo que faz exatamente isso: o Oblivious DNS over HTTPS, ou simplificando ODoH.
Parceiros ODoH:
Estamos entusiasmados em lançar o ODoH com vários parceiros de lançamento líderes que estão igualmente empenhados na privacidade.
Um componente chave do ODoH é um proxy que está separado do resolvedor de destino. E hoje, estamos a lançar o ODoH com vários parceiros de proxy líderes, incluindo: PCCW, SURF e Equinix.
“O ODoH é um novo conceito revolucionário desenhado para manter a privacidade dos utilizadores no centro de tudo. A nossa parceria ODoH com a Cloudflare posiciona-nos bem na privacidade e espaço da "Infraestrutura da Internet". Além da segurança e desempenho melhorados da rede da PCCW Global subjacente, que pode ser acedida a pedido através do Console Connect, o desempenho dos proxies na nossa rede é agora melhorada pelos resolvedores 1.1.1.1 da Cloudflare. Pela primeira vez, este modelo dissocia completamente o proxy do cliente dos resolvedores. Esta parceria fortalece o nosso foco já existente na privacidade, à medida que o mundo se move para um modelo mais remoto e a privacidade se torna um recurso ainda mais vital.” -- Michael Glynn, Vice-Presidente, Inovação Digital Automatizada, PCCW Global
"Fizemos uma parceria com a Cloudflare para implementar uma melhor privacidade do utilizador via ODoH. A mudança para ODoH é uma verdadeira mudança de paradigma, onde a privacidade ou o endereço de IP dos utilizadores não estão expostos a qualquer provedor, o que resulta em privacidade verdadeira. Com o lançamento do ODOH-Pilot, estamos a unir-nos à força da rede da Cloudflare para enfrentar os desafios de utilizadores em qualquer parte do mundo. A mudança para o ODoH não é apenas uma mudança de paradigma, mas enfatiza a forma como a privacidade é importante para qualquer utilizador mais do que nunca, especialmente durante 2020. Harmoniza-se com o nosso foco central e crença à volta da Privacidade.” — Joost van Dijk, Gestor Técnico de Produto, SURF
Como funciona o Oblivious DNS over HTTPS (ODoH)?
O ODoH funciona adicionando uma camada de encriptação de chave pública, bem como um proxy de rede entre clientes e servidores DoH, como o 1.1.1.1. A combinação destes dois elementos adicionados garante que apenas o utilizador tem acesso simultâneo tanto às mensagens DNS como ao seu próprio endereço de IP.
Há três intervenientes no caminho do OdoH. Olhando para a figura em cima, comecemos pelo destino. O destino desencripta consultas encriptadas pelo cliente, por meio de um proxy. Da mesma forma, o destino encripta respostas e devolve-as ao proxy. O padrão diz que o destino pode ou não ser o resolvedor (veremos isso mais tarde). O proxy faz o que um proxy deve fazer, na medida em que encaminha mensagens entre cliente e destino. O cliente comporta-se como faz em DNS e DoH, mas difere encriptando as consultas para o destino e desencriptando as respostas do destino. Qualquer cliente que opte por fazer isso pode especificar um proxy e um destino à escolha.
Juntos, a encriptação e o proxy adicionais dão as seguintes garantias:
- O destino vê apenas a consulta e o endereço IP do proxy.
- O proxy não tem visibilidade sobre as mensagens DNS nem capacidade para identificar, ler ou modificar a consulta que está a ser enviada pelo cliente ou a resposta que está a ser devolvida pelo destino.
- O conteúdo da consulta apenas pode ser lido pelo alvo pretendido, produzindo então a resposta.
Estas três garantias melhoram a privacidade do cliente, mantendo a segurança e a integridade das consultas DNS. No entanto, cada uma dessas garantias depende de uma propriedade fundamental — que o proxy e os servidores de destino não pactuam . Desde que não haja concertação, um invasor só será bem-sucedido se tanto o proxy como o destino forem comprometidos.
Um dos aspectos deste sistema que merece destaque é o facto do destino estar separado do resolvedor de "upstream" recursivo que executa a resolução de DNS. Na prática, esperamos que o destino seja o mesmo em termos de desempenho. Na realidade, o 1.1.1.1 é, agora, um resolvedor recursivo e um destino! Não há razão para que um destino tenha de existir separadamente de qualquer resolvedor. Se estão separados, então o destino é livre de escolher resolvedores e de agir apenas como um intermediário. O único requisito real é, lembre-se, que o proxy e o destino nunca pactuem.
Além disso, também é importante que os clientes tenham total controlo da seleção do proxy e do destino. Sem qualquer necessidade de programas como o TRR, os clientes podem ter, segurança e privacidade nas suas consultas. Os clientes também têm maior controlo sobre que informações são enviadas para os resolvedores recursivos. Uma vez que o destino só conhece o proxy, o destino e qualquer resolvedor "upstream" desconhecem a existência de quaisquer endereços de IP de cliente. Mais importante, isto significa que os clientes têm maior controlo sobre as suas consultas e das maneiras que estas podem ser utilizadas. Por exemplo, os clientes podem selecionar e alterar os seu proxy e destinos a qualquer altura, por qualquer razão que queiram!
Fluxo de mensagens ODoH
Em ODoH, o "O" refere-se a "Oblivious" (alheado), sendo que esta propriedade surge do nível de encriptação das próprias mensagens de DNS. Esta encriptação adicionada é de "ponta-a-ponta" entre o cliente e o destino e independente da encriptação de nível de ligação fornecida pelo TLS/HTTPS. Poderá perguntar-se porque razão é esta encriptação adicional sequer necessária na presença de um proxy. Isto ocorre porque são necessárias duas ligações TLS separadas para suportar a funcionalidade de proxy. Especificamente, o proxy termina uma ligação TLS do cliente e inicia outra ligação TLS com o destino. Os contextos da mensagem DNS entre essas duas ligações apareceriam, de outra forma, em texto por encriptar! Por essa razão, o ODoH encripta adicionalmente as mensagens entre o cliente e o destino para que o proxy não tenha acesso ao conteúdo da mensagem.
Todo o processo começa com clientes que encriptam a sua consulta para o destino usando HPKE . Os clientes obtêm a chave pública do destino via DNS, onde é agregada num registo de recursos HTTPS e protegida por DNSSEC. Quando o TTL para esta chave expira, os clientes solicitam uma cópia nova da chave conforme necessário (assim como fariam para um registo A/AAAA quando o TTL desse registo expira). O uso da chave pública validada pelo DNSSC de um destino garante que somente o destino pretendido possa desencriptar a consulta e encriptar uma reação (resposta).
Os clientes enviam estas consultas encriptadas para um proxy através de uma ligação HTTPS. Após a receção, o proxy encaminha a consulta para o destino designado. Depois, o destino desencripta a consulta, produz uma resposta enviando a consulta para um resolvedor recursivo, como o 1.1.1.1 e, em seguida, encripta a resposta para o cliente. A consulta encriptada do cliente contém material de chave encapsulado a partir do qual os destinos derivam a chave criptográfica simétrica de resposta.
Esta resposta é, então, enviada de volta ao proxy e, em seguida, encaminhada para o cliente. Toda a comunicação é autenticada e confidencial, uma vez que essas mensagens DNS são encriptadas de ponta-a-ponta, apesar de serem transmitidas por duas ligações HTTPS separadas (cliente-proxy e proxy-destino). A mensagem que, de outra forma, apareceria ao proxy como texto por encriptar é na realidade uma deturpação encriptada.
E o Desempenho? Tenho de sacrificar o desempenho para ter privacidade?
Temos feito muitas medições para descobrir e faremos mais à medida que há maior implantação do ODoH. O nosso conjunto inicial de configurações de medição abrangeu cidades nos EUA, Canadá e Brasil. É importante notar que as nossas medidas incluem não apenas o 1.1.1.1, mas também o 8.8.8.8 e 9.9.9. O conjunto completo de medições, até agora, está documentado em acesso aberto.
Nessas medições, era importante isolar o custo de fazer proxy e encriptação adicional, do custo da configuração da ligação TCP e TLS. Isto porque os custos de TLS e TCP são suportados pelo DoH, de qualquer maneira. Portanto, na nossa configuração, 'preparámos' as medições estabelecendo ligações uma vez e reutilizando essa ligação para todas as medições. Fizemos isto tanto para o DoH como para o ODoH, uma vez que a mesma estratégia pode ser usada em ambos os casos.
A primeira coisa que podemos dizer com confiança é que a encriptação adicional é mínima. Sabemos disso porque selecionámos aleatoriamente 10 000 domínios dos milhões de conjuntos de dados da Tranco e medimos tanto a encriptação do registo A com uma chave pública diferente, bem como sua desencriptação. O custo adicional entre uma consulta/resposta de DoH proxy e sua contraparte ODoH é consistentemente inferior a 1ms de percentil 99.
No entanto, o pipeline de solicitação e resposta do ODoH é muito mais do que apenas encriptação. Uma forma muito útil de analisar as medições é examinando o gráfico da distribuição cumulativa — se estiver familiarizado com este tipo de gráficos, vá diretamente para o próximo parágrafo. Em comparação com a maioria dos gráficos onde começamos ao longo do eixo x, com distribuições cumulativas começamos, muitas vezes, com o eixo y.
O gráfico abaixo mostra as distribuições cumulativas para os tempos de consulta/resposta em DoH, ODoH e DoH quando transmitidas pela Rede Tor. A linha horizontal tracejada que começa à esquerda a partir de 0,5 é a marca dos 50%. Ao longo desta linha horizontal, para qualquer curva representada, a parte da curva abaixo da linha tracejada é 50% dos pontos de dados. Agora veja o eixo do x, que é uma medida de tempo. As linhas que aparecem à esquerda são mais rápidas do que as linhas da direita. Um último detalhe importante é que o eixo x é representado numa escala logarítmica. O que é que isso significa? Repare que a distância entre os marcadores rotulados (10x) é igual em distribuições cumulativas, mas o 'x' é um expoente e representa ordens de magnitude. Assim, enquanto a diferença de tempo entre os dois primeiros marcadores é de 9ms, a diferença entre o 3.º e o 4.º marcadores é de 900ms.
Neste gráfico, a curva do meio representa as medições de OdOH. Também medimos o desempenho de alternativas de salvaguarda de privacidade, por exemplo, consultas DoH transmitidas pela rede Tor como representadas pela curva à direita no gráfico. (Estão reunidas alternativas adicionais de preservação de privacidade no relatório técnico de acesso aberto.) Comparado com outras variantes de DNS orientadas para a privacidade, o ODoH corta o tempo de consulta para metade ou melhor. Este ponto é importante, uma vez que raramente se consegue privacidade e desempenho ao mesmo tempo, portanto, é encorajador ver este tipo de melhoria!
O gráfico acima também nos diz que em 50% das vezes as consultas de ODoH são resolvidas em menos de 228ms. Agora compare a linha do meio com a linha à esquerda que representa o DoH de "forma linear" (ou normal) sem qualquer modificação. Essa linha representada à esquerda diz que em 50% das vezes as consultas DoH são resolvidas em menos de 146 ms. Olhando abaixo da marca de 50%, as curvas também nos dizem que metade das vezes essa diferença nunca é superior a 100ms. Por outro lado, olhar para as curvas acima da marca de 50% diz-nos que metade das consultas de ODoH são competitivas com DoH.
Essas curvas também escondem muitas informações, por isso é importante analisar ainda mais as medições. O gráfico abaixo tem três curvas de distribuição cumulativas diferentes que descrevem o desempenho do ODoH se selecionarmos proxies e destinos pela sua latência. Este é também um exemplo das revelações que as medições podem demonstrar, algumas das quais não são intuitivas. Por exemplo, olhando acima de 0,5, essas curvas dizem que metade dos tempos de consulta/resposta ODoH são praticamente indistinguíveis, independentemente da escolha do proxy e do destino. Agora, olhe para baixo de 0,5 e compare as duas curvas contínuas com a curva tracejada que representa a média geral. Esta região sugere que selecionar o proxy e o destino de menor latência oferece melhorias mínimas em relação à média, mas, mais importante, mostra que a seleção do proxy de latência mais baixa leva a um desempenho pior!
Permanecem questões em aberto, claro. Este primeiro conjunto de medições foi executado em grande parte na América do Norte. O desempenho muda a nível global? Como é que isso afeta o desempenho do cliente, na prática? Estamos a trabalhar para descobrir e esta versão vai ajudar-nos a fazer isso.
Interessante! Posso fazer experiências com o ODoH? Existe um serviço ODoH aberto?
Sim, e sim! Abrimos o código das nossas implementações ODoH interoperáveis no Rust, odoh-rs e Go, odoh-go e também integrámos o destino no Resolvedor DNS da Cloudflare. Isso mesmo, o 1.1.1.1 está pronto para consultas via ODoH.
Temos também clientes de teste de código aberto no Rust, odoh-client-rs, e Go, odoh-client-go, para demonstrar consultas do ODoH. Também pode ver a configuração HPKE usada pelo ODoH para encriptação de mensagens para 1.1.1.1 consultando o serviço diretamente:
$ dig -t type65 +dnssec @ns1.cloudflare.com odoh.cloudflare-dns.com
; <<>> DiG 9.10.6 <<>> -t type65 +dnssec @ns1.cloudflare.com odoh.cloudflare-dns.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19923
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;odoh.cloudflare-dns.com. IN TYPE65
;; ANSWER SECTION:
odoh.cloudflare-dns.com. 300 IN TYPE65 \# 108 00010000010003026832000400086810F8F96810F9F9000600202606 470000000000000000006810F8F92606470000000000000000006810 F9F98001002E002CFF0200280020000100010020ED82DBE32CCDE189 BC6C643A80B5FAFF82548D21601C613408BACAAE6467B30A
odoh.cloudflare-dns.com. 300 IN RRSIG TYPE65 13 3 300 20201119163629 20201117143629 34505 odoh.cloudflare-dns.com. yny5+ApxPSO6Q4aegv09ZnBmPiXxDEnX5Xv21TAchxbxt1VhqlHpb5Oc 8yQPNGXb0fb+NyibmHlvTXjphYjcPA==
;; Query time: 21 msec
;; SERVER: 173.245.58.100#53(173.245.58.100)
;; WHEN: Wed Nov 18 07:36:29 PST 2020
;; MSG SIZE rcvd: 291
Estamos a trabalhar para adicionar o ODoH ao resolvedores de stub existentes, como o cloudflared. Se tiver interesse em adicionar suporte para um cliente, ou se encontrar erros de funcionamento durante as implementações, por favor, contacte-nos através de [email protected]! Os anúncios acerca das especificações e o servidor de ODoH serão enviados para a mailing list IETF DPRIVE. Também a pode subscrever para acompanhar os anúncios e o debate sobre as especificações aqui.
Estamos empenhados em avançar no IETF, sendo que já vemos algum interesse de fornecedores de clientes. Eric Rescorla, CTO da Firefox, diz:
"O Oblivious DoH é uma excelente adenda ao ecossistema de DNS seguro. Estamos entusiasmados por vê-lo dar os primeiros passos e expectantes para o experimentar no Firefox."
Esperamos que mais operadores se juntem a nós pelo caminho e que forneçam suporte ao protocolo, ao executar quer proxies, quer destinos e esperamos que o apoio ao cliente aumente à medida que a infraestrutura disponível também aumenta.
O protocolo ODoH é uma abordagem prática para melhorar a privacidade dos utilizadores e visa aperfeiçoar de forma geral a adoção de protocolos DNS encriptados sem comprometer, no entanto, o desempenho e a experiência do utilizador ao usar a Internet.
Agradecimentos
Marek Vavruša e Anbang Wen foram fundamentais para fazer com que o resolvedor 1.1.1.1 suportasse o ODoH. Chris Wood e Peter Wu ajudaram a preparar e a testar as bibliotecas ODoH.