DNS criptografado: DoH e DoT

A aula anterior descreveu uma busca de DNS simples como um cartão-postal: legível por qualquer um que o manuseie no caminho. Existem dois padrões do IETF para colocar esse cartão-postal em um envelope: DNS sobre TLS (DoT, RFC 7858) e DNS sobre HTTPS (DoH, RFC 8484). Os dois criptografam a mesma busca; eles diferem principalmente em como a transportam.

DNS sobre TLS

A RFC 7858 declara seu objetivo diretamente: “a criptografia fornecida pelo TLS elimina oportunidades de espionagem e adulteração no caminho das consultas de DNS”, tratando do fato de que “quase todas as consultas de DNS são enviadas sem criptografia, o que as torna vulneráveis à espionagem por um atacante”. O DoT usa sua própria porta dedicada, 853, em vez da porta 53 habitual. A RFC explica por quê: “essa recomendação contra o uso da porta 53 para DNS sobre TLS é para evitar complicação na escolha de uso ou não uso do TLS e para reduzir o risco de ataques de downgrade”.

DNS sobre HTTPS

A RFC 8484 segue um caminho diferente: “cada par de consulta-resposta de DNS é mapeado em uma troca HTTP”, transportado pela mesma porta 443 que o tráfego HTTPS comum usa. A RFC observa que isso tem um benefício colateral: “a porta padrão 443 do HTTPS e a capacidade de misturar o tráfego DoH com outro tráfego HTTPS na mesma conexão podem dissuadir dispositivos sem privilégios no caminho de interferir nas operações de DNS”, porque uma busca fica mais difícil de isolar e bloquear quando parece qualquer outra solicitação web.

O que a criptografia esconde, e o que ainda não esconde

Os dois padrões impedem que um operador de rede ou espião de Wi-Fi leia suas buscas em trânsito. Nenhum dos dois as esconde do resolvedor para o qual você as enviou. A RFC 8484 é explícita de que o DoH não muda o que o próprio servidor consegue ver: ela observa que “vários transportes de consultas e respostas de DNS de fato fornecem dados que podem ser usados para correlacionar solicitações”, e que mecanismos web comuns, como endereços IP do cliente, cookies e informações de sessão TLS, significam que “não se sabe que o DoH introduza novas preocupações além daquelas associadas ao HTTPS” no lado do servidor. A RFC 7858 observa de forma semelhante que o DoT “não trata outras questões de segurança no DNS” e que “mesmo com mensagens criptografadas, uma parte bem posicionada pode conseguir extrair certos detalhes a partir de uma análise dos horários e tamanhos das mensagens”. Em resumo: o DNS criptografado devolve a quem vê suas buscas para o operador do resolvedor que você escolheu, não remove a visibilidade por completo.

Existe uma segunda lacuna que vale a pena conhecer. Criptografar a busca de DNS não esconde, por si só, a qual site você então se conecta: o aperto de mão TLS que vem em seguida normalmente inclui o nome do host à mostra. Como a explicação da Cloudflare sobre a Indicação de Nome de Servidor (SNI) coloca, “a SNI inclui o nome do host na mensagem Client Hello, ou o primeiríssimo passo de um aperto de mão TLS” — enviada antes de a criptografia ser estabelecida. Uma extensão chamada SNI Criptografada (ESNI), a mesma fonte explica, “se soma à extensão SNI ao criptografar a parte SNI do Client Hello”, o que “impede que qualquer um espionando entre o cliente e o servidor consiga ver qual certificado o cliente está solicitando”. O suporte para esconder a SNI ainda depende de o navegador e o site concordarem com isso, e ainda não é como toda conexão funciona.

Como o macOS oferece suporte a isso

A Apple documenta uma configuração de Ajustes de DNS para Mac, iPhone e iPad que faz exatamente isso: ela permite que um dispositivo “encaminhe as consultas de DNS de um dispositivo através de um servidor de DNS criptografado usando DNS sobre HTTPS ou DNS sobre TLS”. Ela é entregue como um perfil de configuração, que pode restringir o resolvedor criptografado a domínios específicos por meio de “domínios de correspondência suplementares”, ou aplicar-se apenas em determinadas redes usando “regras sob demanda” que podem corresponder a coisas como o SSID da rede.