FireAIs säkerhetsblogg

Av FireAI Security & Research Team · Publicerad

Krypterad DNS på macOS: DoH och DoT med konfigurationsprofiler

Krypterad DNS på macOS: DoH och DoT med konfigurationsprofiler

HTTPS döljer det du skickar till en webbplats, men innan din Mac ens kan öppna den anslutningen måste den ställa en fråga i klartext: "vilken server pekar detta namn på?" Den frågan - en DNS-uppslagning - färdas okrypterad som standard på de flesta nätverk, vilket innebär att din internetleverantör, din kontorsnätverksadministratör eller någon som delar ett osäkrat Wi-Fi-nätverk kan se varje domän du löser, även om själva sidorna är helt krypterade efteråt.

Varför vanliga DNS-läckor

Traditionell DNS, standardiserad decennier innan HTTPS blev webbens standard, skickar frågor över vanlig UDP eller TCP på port 53 utan kryptering och, i de flesta hem- och publika nätverksinställningar, ingen autentisering av resolver heller. En nätverksoperatör behöver inte bryta HTTPS för att skapa en lista över alla domäner du besöker – den behöver bara titta på din DNS-trafik, som ligger i det fria bredvid. Det är också så många DNS-baserade innehållsfilter och vissa former av övervakning på nätverksnivå fungerar: inte genom att inspektera din krypterade trafik, utan genom att helt enkelt logga eller blockera uppslagningen som måste ske innan den trafiken existerar.

DoH och DoT: två sätt att kryptera samma uppslag

Två IETF-standarder löser detta genom att linda in själva DNS-frågan i kryptering. DNS-over-TLS, definierat i RFC 7858, lindar DNS-frågor i en dedikerad krypterad TLS-anslutning på port 853, vilket skiljer den från vanlig trafik och gör det enkelt för ett nätverk att identifiera - och, i princip, för ett nätverk att blockera det helt om det vill stoppa krypterad DNS specifikt. DNS-over-HTTPS, definierad i RFC 8484, mappar istället en DNS-fråga till en standard HTTPS-förfrågan på port 443, samma port som används av nästan all vanlig webbtrafik – ett designval som gör DoH-frågor mycket svårare att skilja från och därför blockeras separat från allmän webbsurfning.

Apples inbyggda stöd sedan macOS 11

Apple byggde in krypterad DNS direkt i sin nätverksstack istället för att lämna den till tredjepartsappar, och tillkännagav funktionen på WWDC 2020 tillsammans med macOS Big Sur (macOS 11) och motsvarande iOS 14-version. Sessionen angav två sätt att aktivera den: ett NEDNSSettingsManager API för appar att konfigurera det programmatiskt, och - alternativet de flesta faktiskt kommer att använda - en konfigurationsprofil som bär com.apple.dnsSettings.managed nyttolasten, dokumenterad i Apples enhetshanteringsreferens, som låter dig specificera en DoH- eller DoT-resolvers adress och har alla appar som krävs i systemet som standard, utan att använda den som standard.

Ett exempel på en konfigurationsprofil

En konfigurationsprofil är en XML-egenskapslista (en .mobileconfig-fil) som macOS kan installera via systeminställningar när du dubbelklickar på den eller drar den till profilrutan. Exemplet nedan pekar en Mac på Quad9s offentliga DNS-over-HTTPS-resolver – en allmänt använd tjänst som inte krävs för ett konto som också blockerar anslutningar till domäner som är kända för nätfiske och annan skadlig aktivitet som standard. Byt ut platshållaridentifieraren och UUID-värdena innan du använder den; varje riktig profil behöver sin egen unika 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>

För att använda Cloudflare istället, ställ in ServerURL till https://cloudflare-dns.com/dns-query och ServerAddresses till 1.1.1.1 och 1.0.0.1 (med 2606:4700:4700::1111 och 2606:4700:4700::1001 för IPv6) — eller, för DNS-over-TLS istället för DoH, ställ in @@CODE7@CODE@CODE@@@ till @CODE@@ och @C one.one.one.one, enligt Cloudflares publicerade DoT-dokumentation.

Installerar den

  1. Spara filen med tillägget .mobileconfig och dubbelklicka på den, eller öppna Systeminställningar, gå till Sekretess och säkerhet, sedan Profiler och dra filen in.
  2. macOS kommer att visa nyttolastens innehåll – inklusive den resolver du konfigurerade – innan du godkänner den; granska detta varje gång, eftersom en profil är exakt hur en skadlig aktör kan omdirigera din DNS om du installerar en från en opålitlig källa.
  3. Klicka på Installera och autentisera. En osignerad profil som det här exemplet kommer att visas som "Osignerad" verifieringsstatus; som förväntas för en handbyggd profil och inte i sig är ett tecken på manipulering, men för allt utöver personliga tester bör du signera profilen så att dess integritet kan verifieras.

Att verifiera att det fungerade

Lita inte bara på inställningsfönstret – kolla från terminalen.

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

Om scutil --dns fortfarande listar din routers adress eller din internetleverantörs resolver som den aktiva DNS-servern, trädde profilen inte i kraft - kontrollera att du installerade den under Profiler istället för att bara ladda ner den, och att ingen annan nätverkskonfiguration (se nedan) åsidosätter den.

Fallgropar som gör att detta slutar fungera tyst

  • En VPN-app åsidosätter ofta systemets DNS-inställningar medan den är ansluten och dirigerar uppslagningar genom sin egen resolver istället – kontrollera din DNS-konfiguration igen efter att ha anslutit till ett VPN, inte precis innan.
  • Captive portaler på hotell, flygplatser och kaféer Wi-Fi kan i allmänhet inte slutföra sitt inloggningsflöde över krypterad DNS, eftersom de är beroende av att fånga upp en vanlig DNS-förfrågan för att omdirigera dig till en inloggningssida; du kan behöva tillfälligt ta bort eller inaktivera profilen för att komma online och sedan installera om den när den är ansluten.
  • Vissa webbläsare - Firefox och Chrome bland dem - levererar sin egen, separata DoH-inställning som kan åsidosätta eller duplicera konfigurationen på systemnivå; kontrollera webbläsarens egna nätverksinställningar om dess beteende inte stämmer överens med vad scutil --dns rapporterar.
  • iCloud Private Relay och krypterad DNS löser olika, överlappande problem — Private Relay döljer din IP från webbplatserna du besöker i Safari, medan krypterad DNS döljer vilka domäner du löser från ditt nätverk; att använda den ena gör inte den andra överflödig.

Var FireAI och HisnLabs kommer in

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 är HisnLabs eget verktyg: en AI-brandvägg som körs direkt på din Mac. Den visar varje anslutning dina appar gör, på klarspråk, och låter dig avgöra vad som lämnar din Mac — AI:n körs lokalt, så din trafik skickas aldrig till oss eller någon annan. HisnLabs säkerhetsforskningsteam är de som håller de bedömningarna tillförlitliga: de katalogiserar vilka domäner som är vanlig telemetri och vilka som är en riktig tjänst, spårar land och nätverk bakom en anslutning och tränar den lokala modellen (Autopilot-funktionen) på verkliga trafikmönster — utan att något av det lämnar din Mac.

Du kan läsa om de tekniska besluten bakom, eller prova FireAI i 17 dagar, på FireAI, från HisnLabs.

Källor