Escolhi AdGuard Home e DNS criptografado sobre HTTPS para minha rede doméstica, acreditando que seria a última barreira para impedir que minhas atividades online fossem monitoradas. Até verifiquei se as consultas foram enviadas criptografadas em vez de apenas confiar no painel de configurações. Mas isso só foi verdade durante a busca de DNA. Por curiosidade, queria ver o que aconteceu depois da pesquisa de DNA. Foi quando percebi que o DNS criptografado resolve um problema diferente do que eu pensava.
DNA criptografado não mentiu
Acabou de resolver outro problema
Minha jornada pelo DNA tem sido uma montanha-russa. Comecei com Pi-hole para bloquear anúncios na web. Então mudei para Pi-hole + dnscrypt-proxy para DNS criptografado sobre HTTPS. Em seguida, mudei para o AdGuard Home (AGH) para simplificar a pilha. Em seguida, mudei brevemente para o Technitium para obter melhores recursos e especialmente resolução recursiva local. Mas o Technitium estava pedindo muito de mim, então voltei para o AGH, mas sem vinculações, para lidar com a resolução recursiva. E finalmente, agora eu uso AGH, às vezes com Unbound e principalmente Quad9 DoH.
Vamos falar um pouco sobre DNA. As consultas DNS tradicionais são propagadas em texto simples, expondo os metadados da minha rede. Quando a consulta está fora da minha rede, meu ISP ou qualquer pessoa no caminho pode ver todos os nomes de host que estou procurando. DoH ou DNS sobre HTTPS foi essencialmente projetado para resolver esse problema. Por exemplo, com minha configuração atual de AGH + Quad9 DoH, assim que o AGH envia uma consulta upstream, ele já está em uma conexão HTTPS criptografada com o Quad9. Implementei o DoH e testei-o em minha configuração, aceitando-o como uma forma infalível de evitar que meu ISP soubesse o que tenho feito.
Minha suposição inicial era que, quando não havia solicitações de DNS visíveis, meu ISP provavelmente também não saberia quais sites eu estava visitando. Naquele ponto, acreditei ter removido a maior fonte de metadados de navegação. Os dados podem ter permanecido na minha rede e no provedor DoH em que eu confiava. Porém, minha curiosidade não parou por aí. Já entendi que após detectar o endereço IP, o navegador iniciou a conexão HTTPS. E pensei que esse era o ponto certo para começar a procurar e, em vez disso, comecei a observar os apertos de mão TLS.
Um campo que ninguém criptografa
Seu navegador ainda informa para quem está ligando
OK, a AGH enviou as consultas por meio de uma conexão HTTPS criptografada, a Quad9 resolveu e o DNSSEC garantiu que não fossem quebradas. Finalmente, o navegador tinha o endereço IP de destino. O que aconteceu a seguir? Fiquei curioso para saber o que o navegador realmente enviou quando iniciou uma conexão HTTPS. Depois de algumas pesquisas sobre como poderia ver o que aconteceu a seguir, descobri que o Wireshark é a melhor ferramenta para obter uma resposta visual à minha pergunta.
Instalei imediatamente o Wireshark no meu Mac usando o Homebrew (brew install wireshark). E executei o comando tshark especificamente para “porta tcp 443” e “tls.handshake.type == 1”. O resultado foi algo que eu não esperava. Vi nomes familiares: reddit.com, google.com e xda-developers.com, porque os visitei durante minha admissão. Então vi uma enxurrada de domínios que nunca havia registrado: adblockplus.org, cdn-apple.com, grcv.io, sentinelpro.com e muitos outros que vi pela primeira vez. Meu primeiro pensamento: por que eles estavam visíveis? Eu uso DoH; eles deveriam estar escondidos. Foi então que minhas esperanças começaram a desmoronar.
sudo tshark -i en0 -f "tcp port 443" -Y "tls.handshake.type == 1"Enquanto observava os escopos dos pacotes, percebi um termo que nunca havia explorado antes – SNI. Depois de uma rápida pesquisa no Google, aqui está o que descobri. HTTPS criptografa o conteúdo, mas o navegador envia uma saudação do cliente TLS antes mesmo do início da criptografia completa. O TLS Client Hello é a primeira mensagem que o navegador envia ao servidor para iniciar uma conexão. E esta mensagem contém uma Indicação de Nome de Servidor (SNI). Por que um servidor precisa de um SNI? Como muitos sites na World Wide Web compartilham o mesmo endereço IP – hospedagem compartilhada, proxy compartilhado, sites irmãos – o SNI é usado para distingui-los.
Portanto, mesmo que o DNS fosse criptografado de ponta a ponta, o nome do host resolvido ainda seria exibido durante o handshake TLS. E qualquer pessoa como meu ISP pode ver facilmente o domínio de destino observando a conexão. Eles não conseguiram ler o conteúdo real da página da web que solicitei, mas conseguiram ler o endereço de destino.
Depois de toda essa descoberta, percebi algo irônico: aquilo nem era novidade para mim. Minha configuração do Pangolin usa o mesmo protocolo. O proxy reverso do Traefik usa SNI para decidir qual serviço auto-hospedado deve receber uma conexão de entrada. Só que nunca pensei sobre o que isso realmente significava do outro lado. E finalmente percebi: de que adiantava toda aquela criptografia DNS quando meu navegador ainda me dizia onde eu estava visitando? Minha mente inteligente perguntou imediatamente: se o SNI vazasse, ele também poderia ser criptografado?
ECH evita a lacuna (principalmente)
Nem todo mundo recebeu o memorando
“O SNI pode ser criptografado?” Essa pergunta levou a uma simples pesquisa no Google, depois a alguns blogs e a muitos fóruns de tecnologia. A resposta foi sim. Encrypted Client Hello (ECH), anteriormente Encrypted SNI, foi projetado para criptografar a parte SNI do Client Hello. Cada postagem e tópico do blog garantem que o ECH criptografe apenas a parte do handshake TLS que contém o nome real do servidor, e não a mensagem inteira de Olá do cliente. No papel, parecia a peça que faltava.
Então começo com a parte “como”. Se esta fosse a solução, o que devo fazer para implementá-la? Foi um trabalho de duas partes – o servidor que eu estava tentando solicitar deve ter esse protocolo habilitado, e o cliente que estou usando, ou seja, o navegador, deve suportar ECH. A parte do cliente foi fácil porque a maioria dos navegadores já suportava o protocolo, seja Safari, Firefox ou Chrome (também Chromium). No entanto, não consegui controlar diretamente a parte do servidor. Dependia da configuração do servidor.
Após algumas pesquisas rápidas, descobri que a adoção ainda era fraca, sendo a Cloudflare o único grande fornecedor na época a usá-la em qualquer escala real. Cloudflare era o maior e dominante CDN com suporte para ECH. Outras CDNs importantes ainda não conseguiram recuperar o atraso de forma significativa. E pelo que li, a Cloudflare aplica isso automaticamente em todos os planos, sem que os proprietários dos sites desistam. Muitos dos meus sites já estavam no Cloudflare, até mesmo alguns com planos gratuitos, então foi um bom momento para testar minha teoria.
Comecei executando um comando simples kdig para verificar se o ECH está habilitado em meu domínio. A saída detectou a chave ECH. Então o verdadeiro teste do mundo real começou. Executei o comando tshark com “tcp port 443” e “tls.handshake.type == 1” ao mesmo tempo e abri meu site no Chrome. O pacote interceptado comprovou a teoria; Em vez do meu nome de host real, o Client Hello mostrou cloudflare-ech.com enquanto o IP de destino permaneceu o mesmo.
kdig +short TYPE65 Então tentei verificar outro domínio; não anunciou ECH. Isso me levou a outra sessão de pesquisa e, pelo que descobri, tenho quase certeza de que o ECH é uma opção opcional em planos pagos, não habilitada por padrão. Não consegui verificar visualmente a mudança porque este domínio estava abaixo do nível pago da Cloudflare gerenciado pelo meu host.
Afinal, o suporte ao navegador agora está amplamente disponível, mas isso é apenas metade da equação. O provedor DNS, o CDN/servidor web e o próprio site devem suportar ECH. Até que isso seja concluído, o DNS criptografado por si só não ocultará completamente suas atividades online.
Criptografado, mas ainda não invisível
Minha pilha de DNA não estava quebrada. Minha compreensão do que estava realmente protegido no DNA criptografado. O DNS criptografado fez exatamente o que deveria fazer: tirar as consultas de DNS em texto simples da equação. Nunca se pretendeu fornecer privacidade de navegação completa. Descobriu-se que o ECH era a peça que faltava para completar o loop, mas dependia do servidor do outro lado estar ligado. Observe que o DNS criptografado não é inútil – ainda o mantenho ativado, mas não considero mais privacidade total.
