Verschlüsseltes DNS unter macOS: DoH und DoT mit Konfigurationsprofilen

HTTPS verbirgt, was Sie an eine Website senden, aber bevor Ihr Mac diese Verbindung überhaupt öffnen kann, muss er eine Frage im Klartext stellen: „Auf welchen Server verweist dieser Name?“ Diese Frage — eine DNS-Abfrage — reist in den meisten Netzwerken standardmäßig unverschlüsselt, was bedeutet, dass Ihr Internetanbieter, der Netzwerkadministrator Ihres Büros oder jeder, der ein ungesichertes WLAN mitbenutzt, jede Domain sehen kann, die Sie auflösen — selbst wenn die Seiten selbst danach vollständig verschlüsselt sind.

Warum unverschlüsseltes DNS Daten preisgibt

Traditionelles DNS, standardisiert Jahrzehnte bevor HTTPS zum Standard des Webs wurde, sendet Abfragen über einfaches UDP oder TCP auf Port 53, ohne Verschlüsselung und, in den meisten Heim- und öffentlichen Netzwerken, auch ohne Authentifizierung des Resolvers. Ein Netzwerkbetreiber muss HTTPS nicht brechen, um eine Liste jeder von Ihnen besuchten Domain zu erstellen — er muss nur Ihren DNS-Verkehr beobachten, der direkt daneben im Klartext liegt. So funktionieren auch viele DNS-basierte Inhaltsfilter und manche Formen der Überwachung auf Netzwerkebene: nicht, indem sie Ihren verschlüsselten Verkehr untersuchen, sondern indem sie einfach die Abfrage protokollieren oder blockieren, die stattfinden muss, bevor dieser Verkehr überhaupt existiert.

DoH und DoT: zwei Wege, dieselbe Abfrage zu verschlüsseln

Zwei IETF-Standards lösen das, indem sie die DNS-Abfrage selbst verschlüsseln. DNS-over-TLS, definiert in RFC 7858, kapselt DNS-Abfragen in einer eigenen, verschlüsselten TLS-Verbindung auf Port 853, wodurch sie sich von gewöhnlichem Verkehr abhebt und für ein Netzwerk leicht zu erkennen ist — und im Prinzip auch vollständig blockierbar, falls ein Netzwerk gezielt verschlüsseltes DNS unterbinden will. DNS-over-HTTPS, definiert in RFC 8484, bildet eine DNS-Abfrage stattdessen auf eine gewöhnliche HTTPS-Anfrage auf Port 443 ab, denselben Port, den fast der gesamte normale Webverkehr nutzt — eine Designentscheidung, die DoH-Abfragen weit schwerer vom allgemeinen Websurfen zu unterscheiden und damit separat zu blockieren macht.

Apples native Unterstützung seit macOS 11

Apple hat verschlüsseltes DNS direkt in seinen Netzwerk-Stack eingebaut, statt es Drittanbieter-Apps zu überlassen, und die Funktion auf der WWDC 2020 zusammen mit macOS Big Sur (macOS 11) und dem entsprechenden iOS-14-Release angekündigt. Die Session zeigte zwei Wege, es zu aktivieren: eine NEDNSSettingsManager-API, mit der Apps es programmatisch konfigurieren können, und — die Option, die die meisten Menschen tatsächlich nutzen werden — ein Konfigurationsprofil mit der Payload com.apple.dnsSettings.managed, dokumentiert in Apples Referenz zur Geräteverwaltung, mit dem Sie die Adresse eines DoH- oder DoT-Resolvers angeben und jede App auf dem System diese standardmäßig nutzen lassen können, ganz ohne Drittanbieter-Software.

Ein Beispiel-Konfigurationsprofil

Ein Konfigurationsprofil ist eine XML-Property-List (eine .mobileconfig-Datei), die macOS über die Systemeinstellungen installieren kann, sobald Sie sie doppelklicken oder in den Bereich Profile ziehen. Das folgende Beispiel weist einen Mac auf den öffentlichen DNS-over-HTTPS-Resolver von Quad9 — einen weit verbreiteten, kontofreien Dienst, der außerdem standardmäßig Verbindungen zu Domains blockiert, die für Phishing und andere schädliche Aktivitäten bekannt sind. Ersetzen Sie die Platzhalter für Identifier und UUID, bevor Sie es verwenden; jedes echte Profil braucht seine eigene, eindeutige 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>

Um stattdessen Cloudflare zu verwenden, setzen Sie ServerURL auf https://cloudflare-dns.com/dns-query und ServerAddresses auf 1.1.1.1 und 1.0.0.1 (mit 2606:4700:4700::1111 und 2606:4700:4700::1001 für IPv6) — oder, für DNS-over-TLS statt DoH, setzen Sie DNSProtocol auf TLS und ServerName auf one.one.one.one, gemäß Cloudflares veröffentlichter DoT-Dokumentation.

Installation

Speichern Sie die Datei mit der Endung .mobileconfig und doppelklicken Sie sie, oder öffnen Sie die Systemeinstellungen, gehen Sie zu Datenschutz & Sicherheit, dann Profile, und ziehen Sie die Datei hinein.
macOS zeigt den Inhalt der Payload — einschließlich des konfigurierten Resolvers —, bevor Sie zustimmen; prüfen Sie das jedes Mal, denn ein Profil ist genau das Mittel, mit dem ein Angreifer Ihr DNS umleiten könnte, wenn Sie eines aus einer nicht vertrauenswürdigen Quelle installieren.
Klicken Sie auf Installieren und authentifizieren Sie sich. Ein unsigniertes Profil wie dieses Beispiel zeigt den Prüfstatus „Nicht signiert“; das ist bei einem von Hand erstellten Profil zu erwarten und für sich genommen kein Zeichen von Manipulation, aber für alles über persönliches Testen hinaus sollten Sie das Profil signieren, damit seine Integrität überprüft werden kann.

Überprüfen, ob es funktioniert hat

Verlassen Sie sich nicht nur auf die Einstellungen — prüfen Sie es im 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

Wenn scutil --dns weiterhin die Adresse Ihres Routers oder den Resolver Ihres Internetanbieters als aktiven DNS-Server anzeigt, hat das Profil nicht gegriffen — prüfen Sie, ob Sie es tatsächlich unter Profile installiert und nicht nur heruntergeladen haben, und ob keine andere Netzwerkkonfiguration (siehe unten) es überschreibt.

Fallstricke, die das stillschweigend außer Kraft setzen

Eine VPN-App überschreibt sehr häufig die System-DNS-Einstellungen, solange sie verbunden ist, und leitet Abfragen stattdessen über ihren eigenen Resolver — prüfen Sie Ihre DNS-Konfiguration erneut, nachdem Sie sich mit einem VPN verbunden haben, nicht nur davor.
Captive Portals in WLANs von Hotels, Flughäfen und Cafés können ihren Anmeldevorgang über verschlüsseltes DNS in der Regel nicht abschließen, da sie darauf angewiesen sind, eine unverschlüsselte DNS-Anfrage abzufangen, um Sie zu einer Anmeldeseite umzuleiten; möglicherweise müssen Sie das Profil vorübergehend entfernen oder deaktivieren, um online zu kommen, und es nach der Verbindung wieder installieren.
Manche Browser — darunter Firefox und Chrome — bringen eine eigene, separate DoH-Einstellung mit, die die Konfiguration auf Systemebene überschreiben oder duplizieren kann; prüfen Sie die eigenen Netzwerkeinstellungen des Browsers, wenn dessen Verhalten nicht dem entspricht, was scutil --dns meldet.
iCloud Private Relay und verschlüsseltes DNS lösen unterschiedliche, sich überschneidende Probleme — Private Relay verbirgt Ihre IP-Adresse vor den Websites, die Sie in Safari besuchen, während verschlüsseltes DNS vor Ihrem Netzwerk verbirgt, welche Domains Sie auflösen; das eine zu nutzen macht das andere nicht überflüssig.

Wo FireAI und HisnLabs ins Spiel kommen

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 ist das eigene Produkt von HisnLabs: eine KI-Firewall für den Mac, die direkt auf dem Gerät läuft. Sie zeigt jede Verbindung Ihrer Apps in verständlicher Sprache und lässt Sie entscheiden, was Ihren Mac verlässt — die KI arbeitet lokal, Ihr Datenverkehr wird also nie an uns oder irgendjemand anderen gesendet. Das Sicherheitsforschungsteam von HisnLabs sorgt dafür, dass diese Entscheidungen verlässlich bleiben: Es katalogisiert, welche Domains gewöhnliche Telemetrie und welche ein echter Dienst sind, verfolgt Land und Netzwerk hinter einer Verbindung und trainiert das lokale Modell (die Autopilot-Funktion) mit echten Verkehrsmustern — ohne dass irgendetwas davon Ihren Mac verlässt.

Die technischen Entscheidungen dahinter können Sie nachlesen — oder FireAI 17 Tage lang ausprobieren — unter FireAI, von HisnLabs.