O HTTPS esconde o que envia a um sítio web, mas antes de o seu Mac sequer conseguir abrir essa ligação, tem de fazer uma pergunta em texto simples: "que servidor corresponde a este nome?" Essa pergunta — uma consulta DNS — viaja por defeito sem cifragem na maioria das redes, o que significa que o seu fornecedor de internet, o administrador da rede do seu escritório, ou qualquer pessoa a partilhar uma rede Wi-Fi não protegida pode ver cada domínio que resolve, mesmo que as próprias páginas fiquem depois totalmente cifradas.
Por que o DNS simples revela informação
O DNS tradicional, normalizado décadas antes de o HTTPS se tornar a norma da web, envia consultas por UDP ou TCP simples na porta 53, sem cifragem e, na maioria das configurações de rede domésticas e públicas, também sem autenticação do resolvedor. Um operador de rede não precisa de quebrar o HTTPS para construir uma lista de todos os domínios que visita — só precisa de vigiar o seu tráfego DNS, que está em claro mesmo ao lado. É também assim que funcionam muitos filtros de conteúdo baseados em DNS e algumas formas de vigilância ao nível da rede: não inspecionando o seu tráfego cifrado, mas simplesmente registando ou bloqueando a consulta que tem de acontecer antes de esse tráfego sequer existir.
DoH e DoT: duas formas de cifrar a mesma consulta
Dois padrões do IETF resolvem isto envolvendo a própria consulta DNS em cifragem. O DNS-over-TLS, definido na RFC 7858, envolve as consultas DNS numa ligação TLS cifrada dedicada, na porta 853, distinguindo-a do tráfego comum e tornando fácil para uma rede identificá-la — e, em princípio, para uma rede a bloquear por completo se quiser impedir especificamente o DNS cifrado. O DNS-over-HTTPS, definido na RFC 8484, mapeia em vez disso uma consulta DNS num pedido HTTPS normal na porta 443, a mesma porta usada por quase todo o tráfego web comum — uma escolha de conceção que torna as consultas DoH muito mais difíceis de distinguir, e por isso de bloquear separadamente, da navegação web em geral.
O suporte nativo da Apple desde o macOS 11
A Apple integrou o DNS cifrado diretamente na sua pilha de rede, em vez de o deixar para aplicações de terceiros, anunciando a funcionalidade na WWDC de 2020, juntamente com o macOS Big Sur (macOS 11) e o lançamento equivalente do iOS 14. A sessão apresentou duas formas de o ativar: uma API NEDNSSettingsManager para as aplicações o configurarem programaticamente, e — a opção que a maioria das pessoas vai realmente usar — um perfil de configuração que transporta a carga útil com.apple.dnsSettings.managed, documentada na referência de gestão de dispositivos da Apple, que lhe permite especificar o endereço de um resolvedor DoH ou DoT e fazer com que todas as aplicações do sistema o usem por defeito, sem ser necessário nenhum software de terceiros.
Um exemplo de perfil de configuração
Um perfil de configuração é uma lista de propriedades em XML (um ficheiro .mobileconfig) que o macOS pode instalar através das Definições do Sistema assim que lhe der um duplo clique ou o arrastar 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 defeito ligações a domínios conhecidos por phishing e outra atividade maliciosa. Substitua os valores de identificador e UUID de exemplo antes de o usar; cada perfil real precisa do seu próprio PayloadUUID único.
<?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 DNS-over-TLS em vez de DoH, defina DNSProtocol como TLS e ServerName como one.one.one.one, segundo a documentação DoT publicada pela Cloudflare.
Instalar o perfil
- Guarde o ficheiro com a extensão
.mobileconfige faça-lhe duplo clique, ou abra as Definições do Sistema, vá a Privacidade e Segurança, depois Perfis, e arraste o ficheiro para lá. - O macOS mostrará o conteúdo da carga útil — incluindo o resolvedor que configurou — antes de o aprovar; reveja isto sempre, já que um perfil é exatamente a forma como um agente malicioso poderia redirecionar o seu DNS se instalar um a partir de uma fonte não fiável.
- Clique em Instalar e autentique-se. Um perfil não assinado como este exemplo aparecerá com o estado de verificação "Não assinado"; isso é esperado para um perfil construído à mão e não é em si um sinal de manipulação, mas para qualquer uso além de um teste pessoal deve assinar o perfil para que a sua integridade possa ser verificada.
Verificar se funcionou
Não confie apenas no painel de definições — verifique a partir do 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/helpSe o scutil --dns continuar a listar o endereço do seu router ou o resolvedor do seu fornecedor de internet como o servidor DNS ativo, o perfil não teve efeito — verifique se o instalou de facto em Perfis, em vez de o ter apenas descarregado, e se nenhuma outra configuração de rede (ver abaixo) o está a sobrepor.
Armadilhas que fazem isto parar de funcionar em silêncio
- Uma aplicação de VPN sobrepõe-se muito frequentemente às definições de DNS do sistema enquanto está ligada, encaminhando as consultas através do seu próprio resolvedor — verifique novamente a sua configuração de DNS depois de ligar uma VPN, não só antes.
- Os portais cativos do Wi-Fi de hotéis, aeroportos e cafés geralmente não conseguem completar o seu fluxo de início de sessão sobre DNS cifrado, já que dependem de intercetar um pedido DNS simples para o redirecionar para uma página de início de sessão; poderá ter de remover ou desativar temporariamente o perfil para conseguir ligar-se, e depois reinstalá-lo assim que estiver ligado.
- Alguns navegadores — o Firefox e o Chrome entre eles — trazem a sua própria definição de DoH, separada, que pode sobrepor-se à ou duplicar a configuração ao nível do sistema; verifique as próprias definições de rede do navegador se o seu comportamento não corresponder ao que o
scutil --dnsreporta. - O iCloud Private Relay e o DNS cifrado resolvem problemas diferentes, embora sobrepostos — o Private Relay esconde o seu IP dos sítios que visita no Safari, enquanto o DNS cifrado esconde que domínios resolve da sua rede; usar um não torna o outro redundante.
O papel do FireAI e da HisnLabs
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: uma firewall com IA que corre diretamente no seu Mac. Mostra, em linguagem clara, cada ligação que as suas aplicações fazem e deixa-o decidir o que sai do seu Mac — a IA funciona localmente, pelo que o seu tráfego nunca é enviado para nós nem para mais ninguém. A equipa de investigação em segurança da HisnLabs é quem mantém essas decisões fiáveis: cataloga que domínios são simples telemetria e quais são um serviço real, acompanha o país e a rede por detrás de uma ligação e treina o modelo local (a funcionalidade Autopilot) com padrões de tráfego reais, sem que nada disso saia do seu Mac.
Pode ler as decisões técnicas por detrás dele, ou experimentar o FireAI durante 17 dias, em FireAI, da HisnLabs.
