FireAIs sikkerhetsblogg

Av FireAI Security & Research Team · Publisert

Kryptert DNS på macOS: DoH og DoT med konfigurasjonsprofiler

Kryptert DNS på macOS: DoH og DoT med konfigurasjonsprofiler

HTTPS skjuler det du sender til et nettsted, men før Mac-en i det hele tatt kan åpne den forbindelsen, må den stille et spørsmål i ren tekst: "hvilken server peker dette navnet på?" Det spørsmålet – et DNS-oppslag – går ukryptert som standard på de fleste nettverk, noe som betyr at internettleverandøren din, kontornettverksadministratoren eller alle som deler et usikret Wi-Fi-nettverk kan se hvert domene du løser, selv om sidene i seg selv er fullstendig kryptert etterpå.

Hvorfor vanlige DNS-lekkasjer

Tradisjonell DNS, standardisert tiår før HTTPS ble standard på nettet, sender spørringer over vanlig UDP eller TCP på port 53 uten kryptering og, i de fleste hjemme- og offentlige nettverksoppsett, ingen autentisering av resolveren heller. En nettverksoperatør trenger ikke å bryte HTTPS for å bygge en liste over hvert domene du besøker – den trenger bare å se på DNS-trafikken din, som er åpen rett ved siden av. Dette er også hvordan mange DNS-baserte innholdsfiltre og noen former for overvåking på nettverksnivå fungerer: ikke ved å inspisere den krypterte trafikken din, men ved ganske enkelt å logge eller blokkere oppslaget som må skje før den trafikken eksisterer.

DoH og DoT: to måter å kryptere samme oppslag på

To IETF-standarder løser dette ved å pakke inn selve DNS-spørringen i kryptering. DNS-over-TLS, definert i RFC 7858, omslutter DNS-spørringer i en dedikert kryptert TLS-tilkobling på port 853, og skiller den fra vanlig trafikk og gjør det enkelt for et nettverk å identifisere – og, i prinsippet, for et nettverk å blokkere det helt hvis det ønsker å stoppe kryptert DNS spesifikt. DNS-over-HTTPS, definert i RFC 8484, kartlegger i stedet en DNS-spørring til en standard HTTPS-forespørsel på port 443, den samme porten som brukes av nesten all vanlig nettrafikk - et designvalg som gjør DoH-spørringer langt vanskeligere å skille fra og derfor blokkeres separat fra generell nettsurfing.

Apples innebygde støtte siden macOS 11

Apple bygde kryptert DNS direkte inn i nettverksstabelen i stedet for å overlate den til tredjepartsapper, og kunngjorde funksjonen på WWDC 2020 sammen med macOS Big Sur (macOS 11) og den tilsvarende iOS 14-utgivelsen. Økten la ut to måter å slå den på: en NEDNSSettingsManager API for apper for å konfigurere den programmatisk, og - alternativet de fleste faktisk vil bruke - en konfigurasjonsprofil som bærer com.apple.dnsSettings.managed nyttelasten, dokumentert i Apples enhetsadministrasjonsreferanse, som lar deg spesifisere en DoH- eller DoT-løsers adresse og ha alle apper som kreves på systemet, uten å bruke den som standard.

Et eksempel på konfigurasjonsprofil

En konfigurasjonsprofil er en XML-egenskapsliste (en .mobileconfig-fil) som macOS kan installere gjennom systeminnstillinger når du dobbeltklikker den eller drar den inn i profilruten. Eksemplet nedenfor peker en Mac på Quad9s offentlige DNS-over-HTTPS-løser – en mye brukt tjeneste som ikke kreves konto, som også blokkerer tilkoblinger til domener kjent for phishing og annen ondsinnet aktivitet som standard. Bytt ut plassholderidentifikatoren og UUID-verdiene før du bruker den; hver ekte profil trenger sin egen unike 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>

For å bruke Cloudflare i stedet, sett ServerURL til https://cloudflare-dns.com/dns-query og ServerAddresses til 1.1.1.1 og 1.0.0.1 (med 2606:4700:4700::1111 og 2606:4700:4700::1001 for IPv6) — eller, for DNS-over-TLS i stedet for DoH, sett @@CODE7@CODE@CODE@@@ til @@ og @C one.one.one.one, i henhold til Cloudflares publiserte DoT-dokumentasjon.

Installerer den

  1. Lagre filen med utvidelsen .mobileconfig og dobbeltklikk på den, eller åpne Systeminnstillinger, gå til Personvern og sikkerhet, deretter Profiler, og dra filen inn.
  2. macOS vil vise nyttelastinnholdet – inkludert løseren du konfigurerte – før du godkjenner den; gjennomgå dette hver gang, siden en profil er nøyaktig hvordan en ondsinnet aktør kan omdirigere DNS-en din hvis du installerer en fra en ikke-klarert kilde.
  3. Klikk Installer og autentiser. En usignert profil som dette eksemplet vil vises som "Usignert" bekreftelsesstatus; som forventes for en håndbygget profil og er ikke i seg selv et tegn på tukling, men for alt utover personlig testing bør du signere profilen slik at integriteten kan verifiseres.

Å bekrefte at det fungerte

Ikke bare stol på innstillingspanelet - sjekk fra 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

Hvis scutil --dns fortsatt viser ruterens adresse eller Internett-leverandørens resolver som den aktive DNS-serveren, trådte ikke profilen i kraft – sjekk at du installerte den under Profiler i stedet for bare å laste den ned, og at ingen annen nettverkskonfigurasjon (se nedenfor) overstyrer den.

Fallgruver som gjør at dette slutter å virke stille

  • En VPN-app overstyrer ofte system-DNS-innstillinger mens den er tilkoblet, og dirigerer oppslag gjennom sin egen resolver i stedet – sjekk DNS-konfigurasjonen din igjen etter å ha koblet til en VPN, ikke bare før.
  • Captive portaler på hotell, flyplasser og kaféer Wi-Fi kan vanligvis ikke fullføre påloggingsflyten over kryptert DNS, siden de er avhengige av å avskjære en vanlig DNS-forespørsel for å omdirigere deg til en påloggingsside; Det kan hende du må midlertidig fjerne eller deaktivere profilen for å komme på nett, og deretter installere den på nytt når den er koblet til.
  • Noen nettlesere – Firefox og Chrome blant dem – leverer sin egen, separate DoH-innstilling som kan overstyre eller duplisere konfigurasjonen på systemnivå; sjekk nettleserens egne nettverksinnstillinger hvis oppførselen ikke samsvarer med det scutil --dns rapporterer.
  • iCloud Private Relay og kryptert DNS løser forskjellige, overlappende problemer — Private Relay skjuler IP-en din fra nettstedene du besøker i Safari, mens kryptert DNS skjuler hvilke domener du løser fra nettverket ditt; å bruke den ene gjør ikke den andre overflødig.

Hvor FireAI og HisnLabs kommer inn

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 er HisnLabs’ eget produkt: en KI-brannmur som kjører direkte på Macen. Den viser hver tilkobling appene dine gjør, i klart språk, og lar deg bestemme hva som forlater Macen din — KI-en kjører lokalt, så trafikken din sendes aldri til oss eller noen andre. HisnLabs’ sikkerhetsforskningsteam er de som holder disse vurderingene pålitelige: de katalogiserer hvilke domener som er vanlig telemetri og hvilke som er en ekte tjeneste, sporer landet og nettverket bak en tilkobling, og trener den lokale modellen (Autopilot-funksjonen) på ekte trafikkmønstre — uten at noe av det forlater Macen din.

Du kan lese om de tekniske valgene bak, eller prøve FireAI i 17 dager, på FireAI, fra HisnLabs.

Kilder