DNS encriptado: DoH e DoT

A lição anterior descreveu uma pesquisa DNS simples como um postal: legível por qualquer pessoa que o manuseie pelo caminho. Existem duas normas do IETF para colocar esse postal num envelope: DNS over TLS (DoT, RFC 7858) e DNS over HTTPS (DoH, RFC 8484). Ambas encriptam a mesma pesquisa; diferem principalmente na forma como a transportam.

DNS over TLS

A RFC 7858 declara o seu objetivo diretamente: "a encriptação fornecida pelo TLS elimina oportunidades de escuta e de adulteração no percurso das consultas DNS", resolvendo o facto de que "quase todas as consultas DNS são enviadas sem encriptação, o que as torna vulneráveis a escuta por um atacante." O DoT usa a sua própria porta dedicada, a 853, em vez da habitual porta 53. A RFC explica porquê: "esta recomendação contra o uso da porta 53 para o DNS over TLS destina-se a evitar complicações na seleção do uso ou não uso de TLS e a reduzir o risco de ataques de downgrade."

DNS over HTTPS

A RFC 8484 segue um caminho diferente: "cada par de consulta-resposta DNS é mapeado para uma troca HTTP", transportada na mesma porta 443 que o tráfego HTTPS comum usa. A RFC nota que isto tem um benefício secundário: "a porta predefinida do HTTPS, 443, e a capacidade de misturar tráfego DoH com outro tráfego HTTPS na mesma ligação podem dissuadir dispositivos sem privilégios no percurso de interferirem com as operações de DNS", porque uma pesquisa é mais difícil de isolar e bloquear quando parece qualquer outro pedido web.

O que a encriptação esconde, e o que continua a não esconder

Ambas as normas impedem que um operador de rede ou alguém a escutar o Wi-Fi leia as suas pesquisas em trânsito. Nenhuma delas as esconde do resolvedor a quem as enviou. A RFC 8484 é explícita quanto a o DoH não mudar o que o próprio servidor consegue ver: nota que "vários transportes de consultas e respostas DNS fornecem de facto dados que podem ser usados para correlacionar pedidos", e que os mecanismos web comuns, como endereços IP de cliente, cookies e informação de sessão TLS, significam que "não é conhecido que o DoH introduza novas preocupações para além das já associadas ao HTTPS" do lado do servidor. A RFC 7858 nota de forma semelhante que o DoT "não resolve outras questões de segurança no DNS" e que "mesmo com mensagens encriptadas, uma parte bem posicionada pode conseguir extrair certos detalhes a partir de uma análise dos tempos e tamanhos das mensagens." Em resumo: o DNS encriptado desloca quem vê as suas pesquisas de volta para o operador do resolvedor que escolheu, não remove a visibilidade por completo.

Há uma segunda lacuna que vale a pena conhecer. Encriptar a pesquisa DNS não esconde por si só a que site se liga a seguir: o cumprimento TLS (handshake) que se segue normalmente inclui o nome do anfitrião à vista. Como coloca a explicação da Cloudflare sobre a Indicação de Nome do Servidor (SNI), "a SNI inclui o nome do anfitrião na mensagem Client Hello, ou o primeiríssimo passo de um cumprimento TLS" — enviado antes de a encriptação ser estabelecida. Uma extensão chamada SNI Encriptada (ESNI), explica a mesma fonte, "acrescenta-se à extensão SNI ao encriptar a parte SNI do Client Hello", o que "impede que qualquer pessoa a espiar entre o cliente e o servidor consiga ver que certificado o cliente está a pedir." O suporte para esconder a SNI ainda depende do navegador e do site concordarem com isso, e ainda não é como todas as ligações funcionam.

Como o macOS o suporta

A Apple documenta uma configuração de Definições de DNS para Mac, iPhone e iPad que faz exatamente isto: permite a um dispositivo "encaminhar as consultas DNS de um dispositivo através de um servidor DNS encriptado usando DNS over HTTPS ou DNS over TLS." É entregue como um perfil de configuração, que pode restringir o resolvedor encriptado a domínios específicos através de "domínios de correspondência suplementares", ou aplicar-se apenas em certas redes usando "regras a pedido" que podem corresponder a coisas como o SSID da rede.