Szyfrowany DNS na macOS: DoH i DoT z profilami konfiguracyjnymi

HTTPS ukrywa to, co wysyłasz do witryny internetowej, ale zanim Twój Mac będzie mógł w ogóle otworzyć to połączenie, musi zadać pytanie zwykłym tekstem: „na jaki serwer wskazuje ta nazwa?” To pytanie – wyszukiwanie DNS – jest domyślnie przesyłane w większości sieci w postaci niezaszyfrowanej, co oznacza, że Twój dostawca Internetu, administrator sieci w biurze lub każda osoba korzystająca z niezabezpieczonej sieci Wi-Fi może zobaczyć każdą rozpoznaną domenę, nawet jeśli same strony zostaną później w pełni zaszyfrowane.

Dlaczego zwykłe wycieki DNS

Tradycyjny system DNS, ustandaryzowany kilkadziesiąt lat przed tym, jak protokół HTTPS stał się domyślnym rozwiązaniem w Internecie, wysyła zapytania za pośrednictwem zwykłego protokołu UDP lub TCP na porcie 53 bez szyfrowania, a w większości konfiguracji sieci domowych i publicznych również bez uwierzytelniania mechanizmu rozpoznawania nazw. Operator sieci nie musi łamać protokołu HTTPS, aby utworzyć listę każdej odwiedzanej domeny — wystarczy, że będzie obserwował ruch DNS, który znajduje się tuż obok. W ten sam sposób działa wiele filtrów treści opartych na DNS i niektóre formy nadzoru na poziomie sieci: nie poprzez sprawdzanie zaszyfrowanego ruchu, ale po prostu poprzez rejestrowanie lub blokowanie wyszukiwania, które musi nastąpić, zanim ruch ten będzie istniał.

DoH i DoT: dwa sposoby szyfrowania tego samego wyszukiwania

Dwa standardy IETF rozwiązują ten problem, otaczając samo zapytanie DNS szyfrowaniem. Usługa DNS-over-TLS, zdefiniowana w dokumencie RFC 7858, otacza zapytania DNS w dedykowanym szyfrowanym połączeniu TLS na porcie 853, odróżniając go od zwykłego ruchu i ułatwiając identyfikację sieci oraz, co do zasady, całkowicie ją blokuje, jeśli chce konkretnie zatrzymać szyfrowany DNS. Funkcja DNS-over-HTTPS, zdefiniowana w dokumencie RFC 8484, zamiast tego odwzorowuje zapytanie DNS na standardowe żądanie HTTPS na porcie 443, tym samym porcie używanym przez prawie cały zwykły ruch sieciowy — jest to wybór projektowy, który sprawia, że zapytania DoH są znacznie trudniejsze do rozróżnienia i dlatego blokowane oddzielnie od ogólnego przeglądania sieci.

Natywne wsparcie Apple od wersji macOS 11

Firma Apple wbudowała zaszyfrowany system DNS bezpośrednio w swój stos sieciowy, zamiast pozostawiać go aplikacjom innych firm, ogłaszając tę funkcję na konferencji WWDC 2020 wraz z systemem macOS Big Sur (macOS 11) i równoważną wersją iOS 14. W sesji przedstawiono dwa sposoby jego włączenia: interfejs API NEDNSSettingsManager dla aplikacji umożliwiających jego programową konfigurację oraz – opcja, z której faktycznie skorzysta większość ludzi – profil konfiguracyjny zawierający ładunek com.apple.dnsSettings.managed, udokumentowany w dokumentacji dotyczącej zarządzania urządzeniami firmy Apple, który pozwala określić adres modułu rozpoznawania nazw DoH lub DoT i sprawić, aby każda aplikacja w systemie używała go domyślnie, bez konieczności stosowania oprogramowania innych firm.

Przykładowy profil konfiguracyjny

Profil konfiguracyjny to lista właściwości XML (plik .mobileconfig), którą macOS może zainstalować w Ustawieniach systemu po dwukrotnym kliknięciu lub przeciągnięciu do panelu Profile. Poniższy przykład wskazuje komputer Mac na publiczny moduł rozpoznawania nazw DNS-over-HTTPS firmy Quad9 — powszechnie używaną usługę niewymagającą posiadania konta, która domyślnie blokuje również połączenia z domenami znanymi z phishingu i innych złośliwych działań. Zastąp identyfikator zastępczy i wartości UUID przed ich użyciem; każdy prawdziwy profil potrzebuje własnego, unikalnego PayloadUUID.

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>

Aby zamiast tego używać Cloudflare, ustaw ServerURL na https://cloudflare-dns.com/dns-query i ServerAddresses na 1.1.1.1 i 1.0.0.1 (z 2606:4700:4700::1111 i 2606:4700:4700::1001 dla IPv6) — lub w przypadku DNS-over-TLS zamiast DoH ustaw DNSProtocol na TLS i ServerName na one.one.one.one, zgodnie z opublikowaną dokumentacją DoT Cloudflare.

Instalowanie go

Zapisz plik z rozszerzeniem .mobileconfig i kliknij go dwukrotnie lub otwórz Ustawienia systemu, przejdź do Prywatność i bezpieczeństwo, następnie Profile i przeciągnij plik.
macOS wyświetli zawartość ładunku — w tym skonfigurowany przez Ciebie moduł rozpoznawania nazw — zanim go zatwierdzisz; sprawdzaj to za każdym razem, ponieważ profil jest dokładnie tym, w jaki sposób złośliwy aktor może przekierować Twój DNS, jeśli zainstalujesz go z niezaufanego źródła.
Kliknij Zainstaluj i uwierzytelnij. Niepodpisany profil, taki jak ten przykład, będzie wyświetlany jako status weryfikacji „Niepodpisany”; jest to oczekiwane w przypadku profilu tworzonego ręcznie i samo w sobie nie jest oznaką manipulacji, ale w przypadku wszelkich działań wykraczających poza testy osobiste należy podpisać profil, aby można było zweryfikować jego integralność.

Sprawdzenie, czy zadziałało

Nie ufaj tylko panelowi ustawień — sprawdź to w terminalu.

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

Jeśli scutil --dns nadal wyświetla adres routera lub narzędzie rozpoznawania nazw Twojego dostawcy usług internetowych jako aktywny serwer DNS, profil nie zadziałał — sprawdź, czy zainstalowałeś go w obszarze Profile, a nie tylko go pobrałeś, i czy żadna inna konfiguracja sieci (patrz poniżej) go nie zastępuje.

Pułapki, które sprawiają, że przestaje to działać cicho

Aplikacja VPN bardzo często zastępuje systemowe ustawienia DNS, gdy jest podłączona, zamiast tego kieruje wyszukiwania przez własny moduł rozpoznawania nazw — sprawdź ponownie konfigurację DNS po połączeniu z VPN, a nie tylko przed.
Portale przechwytujące w sieci Wi-Fi w hotelach, na lotniskach i w kawiarniach zazwyczaj nie są w stanie zakończyć procesu logowania za pośrednictwem zaszyfrowanego DNS, ponieważ polegają na przechwytywaniu zwykłego żądania DNS w celu przekierowania Cię na stronę logowania; może być konieczne tymczasowe usunięcie lub wyłączenie profilu, aby połączyć się z Internetem, a następnie zainstalować go ponownie po nawiązaniu połączenia.
Niektóre przeglądarki — wśród nich Firefox i Chrome — udostępniają własne, oddzielne ustawienia DoH, które mogą zastąpić lub zduplikować konfigurację na poziomie systemu; sprawdź ustawienia sieciowe przeglądarki, jeśli jej zachowanie nie jest zgodne z raportem scutil --dns.
iCloud Private Relay i szyfrowany DNS rozwiązują różne, nakładające się problemy — Private Relay ukrywa Twój adres IP przed witrynami odwiedzanymi w przeglądarce Safari, podczas gdy zaszyfrowany DNS ukrywa przed siecią rozpoznawane domeny; użycie jednego nie powoduje, że drugi staje się zbędny.

Jaką rolę odgrywają FireAI i 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.

FireAI to własny produkt HisnLabs: zapora sieciowa z AI działająca bezpośrednio na Macu. Pokazuje prostym językiem każde połączenie nawiązywane przez twoje aplikacje i pozwala ci decydować, co opuszcza twojego Maca — jej AI działa lokalnie, więc twój ruch nigdy nie jest wysyłany do nas ani do nikogo innego. Zespół badań nad bezpieczeństwem HisnLabs dba o to, by te decyzje pozostały trafne: kataloguje, które domeny to zwykła telemetria, a które prawdziwa usługa, śledzi kraj i sieć stojące za połączeniem oraz trenuje lokalny model (funkcję Autopilot) na rzeczywistych wzorcach ruchu — a nic z tego nie opuszcza twojego Maca.

Możesz przeczytać o decyzjach technicznych, które za tym stoją, albo wypróbować FireAI przez 17 dni na FireAI od HisnLabs.