O blog de segurança da FireAI

Por FireAI Security & Research Team · Publicado

DNS criptografado no macOS: DoH e DoT com perfis de configuração

DNS criptografado no macOS: DoH e DoT com perfis de configuração

O HTTPS esconde o que você envia para um site, mas antes que o seu Mac consiga sequer abrir essa conexão, ele precisa fazer uma pergunta em texto claro: "para qual servidor esse nome aponta?" Essa pergunta — uma consulta DNS — trafega sem criptografia por padrão na maioria das redes, o que significa que seu provedor de internet, o administrador da rede do seu escritório, ou qualquer pessoa compartilhando uma rede Wi-Fi sem proteção pode ver todos os domínios que você resolve, mesmo que as páginas em si estejam totalmente criptografadas depois.

Por que o DNS comum vaza informação

O DNS tradicional, padronizado décadas antes de o HTTPS se tornar o padrão da web, envia consultas por UDP ou TCP puro na porta 53, sem criptografia e, na maioria das configurações de rede doméstica ou pública, também sem autenticação do resolvedor. Um operador de rede não precisa quebrar o HTTPS para montar uma lista de todos os domínios que você visita — basta observar seu tráfego DNS, que fica em texto claro bem ao lado dele. É assim também que muitos filtros de conteúdo baseados em DNS e algumas formas de vigilância em nível de rede funcionam: não inspecionando seu tráfego criptografado, mas simplesmente registrando ou bloqueando a consulta que precisa acontecer antes de esse tráfego existir.

DoH e DoT: duas formas de criptografar a mesma consulta

Dois padrões do IETF resolvem isso envolvendo a própria consulta DNS em criptografia. O DNS-over-TLS, definido na RFC 7858, envolve as consultas DNS em uma conexão TLS criptografada dedicada na porta 853, o que a distingue do tráfego comum e facilita para uma rede identificá-la — e, em princípio, para uma rede bloqueá-la por completo, caso queira impedir especificamente o DNS criptografado. O DNS-over-HTTPS, definido na RFC 8484, em vez disso mapeia uma consulta DNS sobre uma requisição HTTPS padrão na porta 443, a mesma porta usada por quase todo tráfego web comum — uma escolha de design que torna as consultas DoH muito mais difíceis de distinguir, e portanto de bloquear separadamente, da navegação web em geral.

O suporte nativo da Apple desde o macOS 11

A Apple incorporou o DNS criptografado diretamente à sua pilha de rede, em vez de deixar isso a cargo de aplicativos de terceiros, anunciando o recurso na WWDC 2020 junto com o macOS Big Sur (macOS 11) e o lançamento equivalente do iOS 14. A sessão apresentou duas formas de ativá-lo: uma API NEDNSSettingsManager para que aplicativos o configurem programaticamente e — a opção que a maioria das pessoas de fato vai usar — um perfil de configuração carregando o payload com.apple.dnsSettings.managed, documentado na referência de gerenciamento de dispositivos da Apple, que permite especificar o endereço de um resolvedor DoH ou DoT e fazer com que todo aplicativo no sistema o use por padrão, sem necessidade de software de terceiros.

Um exemplo de perfil de configuração

Um perfil de configuração é uma property list em XML (um arquivo .mobileconfig) que o macOS consegue instalar pelas Ajustes do Sistema assim que você dá duplo clique nele ou o arrasta para o painel de Perfis. O exemplo abaixo aponta um Mac para o resolvedor público de DNS-over-HTTPS da Quad9 — um serviço amplamente usado, que não exige conta, e que também bloqueia por padrão conexões a domínios conhecidos por phishing e outras atividades maliciosas. Substitua os valores de identificador e UUID de exemplo antes de usá-lo; todo perfil real precisa do seu próprio PayloadUUID exclusivo.

quad9-doh.mobileconfig
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>PayloadContent</key>
  <array>
    <dict>
      <key>PayloadType</key>
      <string>com.apple.dnsSettings.managed</string>
      <key>PayloadIdentifier</key>
      <string>com.example.dns.quad9-doh</string>
      <key>PayloadUUID</key>
      <string>REPLACE-WITH-A-UNIQUE-UUID-1</string>
      <key>PayloadVersion</key>
      <integer>1</integer>
      <key>PayloadDisplayName</key>
      <string>Quad9 Encrypted DNS (DoH)</string>
      <key>DNSSettings</key>
      <dict>
        <key>DNSProtocol</key>
        <string>HTTPS</string>
        <key>ServerURL</key>
        <string>https://dns.quad9.net/dns-query</string>
        <key>ServerAddresses</key>
        <array>
          <string>9.9.9.9</string>
          <string>149.112.112.112</string>
          <string>2620:fe::fe</string>
          <string>2620:fe::9</string>
        </array>
      </dict>
    </dict>
  </array>
  <key>PayloadDisplayName</key>
  <string>Encrypted DNS - Quad9</string>
  <key>PayloadIdentifier</key>
  <string>com.example.dns.quad9-doh.root</string>
  <key>PayloadType</key>
  <string>Configuration</string>
  <key>PayloadUUID</key>
  <string>REPLACE-WITH-A-UNIQUE-UUID-2</string>
  <key>PayloadVersion</key>
  <integer>1</integer>
</dict>
</plist>

Para usar a Cloudflare em vez disso, defina ServerURL como https://cloudflare-dns.com/dns-query e ServerAddresses como 1.1.1.1 e 1.0.0.1 (com 2606:4700:4700::1111 e 2606:4700:4700::1001 para IPv6) — ou, para usar DNS-over-TLS em vez de DoH, defina DNSProtocol como TLS e ServerName como one.one.one.one, conforme a documentação de DoT publicada pela Cloudflare.

Instalando o perfil

  1. Salve o arquivo com a extensão .mobileconfig e dê duplo clique nele, ou abra os Ajustes do Sistema, vá em Privacidade e Segurança, depois Perfis, e arraste o arquivo para lá.
  2. O macOS mostrará o conteúdo do payload — incluindo o resolvedor que você configurou — antes de você aprová-lo; revise isso sempre, já que um perfil é exatamente a forma como um agente malicioso poderia redirecionar seu DNS caso você instale um de origem não confiável.
  3. Clique em Instalar e se autentique. Um perfil não assinado como este exemplo aparecerá com o status de verificação "Não assinado"; isso é esperado para um perfil montado manualmente e não é, por si só, um sinal de adulteração, mas para qualquer uso além de testes pessoais você deve assinar o perfil para que sua integridade possa ser verificada.

Verificando se funcionou

Não confie apenas no painel de ajustes — verifique pelo terminal.

Terminal
# Show the resolvers macOS is actually configured to use
scutil --dns
# Look for your interface's resolver entry — it should now show
# the DoH/DoT server address you configured, not your router or ISP's resolver

# Confirm a lookup succeeds and see which resolver answered
dig example.com

# Cloudflare's own diagnostic page also reports whether your
# connection is using encrypted DNS when you open it in a browser
open https://1.1.1.1/help

Se o scutil --dns ainda listar o endereço do seu roteador ou o resolvedor do seu provedor de internet como servidor DNS ativo, o perfil não entrou em vigor — verifique se você o instalou em Perfis e não apenas o baixou, e se nenhuma outra configuração de rede (veja abaixo) está sobrepondo-o.

Armadilhas que fazem isso parar de funcionar silenciosamente

  • Um aplicativo de VPN muito comumente sobrepõe as configurações de DNS do sistema enquanto está conectado, roteando as consultas pelo próprio resolvedor dele — verifique sua configuração de DNS novamente depois de se conectar a uma VPN, não só antes.
  • Portais cativos de Wi-Fi de hotel, aeroporto e cafeteria geralmente não conseguem concluir o fluxo de login por DNS criptografado, já que dependem de interceptar uma requisição DNS comum para redirecionar você a uma página de login; pode ser necessário remover ou desativar temporariamente o perfil para conseguir se conectar, e reinstalá-lo depois.
  • Alguns navegadores — Firefox e Chrome entre eles — trazem sua própria configuração de DoH separada, que pode sobrepor ou duplicar a configuração em nível de sistema; verifique as configurações de rede do próprio navegador se o comportamento dele não corresponder ao que o scutil --dns relata.
  • O iCloud Private Relay e o DNS criptografado resolvem problemas diferentes, ainda que sobrepostos — o Private Relay esconde seu IP dos sites que você visita no Safari, enquanto o DNS criptografado esconde quais domínios você resolve da sua rede; usar um não torna o outro redundante.

Onde FireAI e HisnLabs entram nessa história

FireAI does not provide encrypted DNS today — it is on the roadmap, not in the current release — so a configuration profile like the one above is what actually closes the DNS-leak gap; FireAI’s job is different, watching and controlling which apps get to make a connection at all once that lookup resolves.

O FireAI é o produto da HisnLabs: um firewall com IA que roda direto no seu Mac. Ele mostra, em linguagem simples, cada conexão que seus aplicativos fazem e deixa você decidir o que sai do seu Mac — a IA roda localmente, então seu tráfego nunca é enviado para nós nem para ninguém. A equipe de pesquisa em segurança da HisnLabs é quem mantém essas decisões confiáveis: cataloga quais domínios são telemetria comum e quais são um serviço de verdade, rastreia o país e a rede por trás de uma conexão e treina o modelo local (o recurso Autopilot) com padrões reais de tráfego, sem que nada disso saia do seu Mac.

Você pode ler as decisões técnicas por trás dele, ou testar o FireAI por 17 dias, em FireAI, da HisnLabs.

Fontes