[German] Was bedeutet DNS-Over-HTTPS für Pi-Hole?

Hallo an Alle

Ich stelle mir schon länger die Frage Was bedeutet DNS-Over-HTTPS für Pi-Hole.
Bzw. inwieweit beeinträchtigt diese Technik die Funktionsweise von DNS-Basierten Werbeblockern oder Sicherheitssystemen.
Ich werde irgendwie das ungute Gefühl nicht los, dass der ursprüngliche Gedanke hinter DNS-Over-HTTPS zwar gut gemeint ist, dessen Einsatz (im heimischen LAN) aber diverse Probleme mit sich bringen könnte. Was mir aber noch viel mehr Kopfzerbrechen bereitet… jeder Browser, jedes Programm oder App wäre in der Lage, seine eigenen DNS-Anfragen über HTTPS abzusenden. Das würde aber auch bedeuten, dass diese DNS-Anfragen am eigenen DNS-System vorbeigeschleust werden könn(t)en. Ich würde sozusagen als Administrator entmündigt werden. Hätte also keine Kontrolle mehr darüber, welche DNS-Anfragen gesendet werden da meine eigenen DNS Einstellungen übergangen werden. Somit wäre es nur eine Frage der Zeit, bis Pi-hole als DNS-Basierter Werbeblocker nach und nach seine Funktion als Werbeblocker verlieren würde. Oder wie seht Ihr das?
Bedeutet DNS-Over-HTTPS das Aus von DNS-Basierten Systemen wie Pi-Hole? :roll_eyes:

Speedy70

Sollte es soweit kommen wie Du es beschreibst, dann bedeutet es das Aus. Soll heißen wenn

weiß, dann gibt es für uns keine großen Möglichkeiten mehr dort einzugreifen. Es ginge noch über Firewall-basierte Eingriffe und auf den Geräten manuell hinterlegten Zertifikaten, der Aufwand kann jedoch schnell Überhand nehmen.

Was ist der aktuelle Stand?

  • Android: Bislang nicht ab Werk aktiviert, kann vom Nutzer deaktiviert werden (Android 9: Einstellungen -> Netzwerk & Internet -> Privates DNS)
  • Firefox: Es gibt eine recht einfache Möglichkeit festzulegen, dass DoH im aktuellen Netzwerk unerwünscht ist, da ein lokaler DNS Server läuft (siehe #2915 + #2916)
  • Chrome: Google plant seinen Browser den aktuellen DNS Server mit einer Liste von DoH-kompatiblen DNS Servers abzugleichen und nur dann zu DoH zu wechseln, wenn der eigene Anbieter DoH unterstützt.

Aktuell bedeutet DoH somit noch kein Problem, aber ja, wir wissen nicht wie die Hersteller sich entscheiden ihre Strategien "weiter"zuentwickeln.

Hallo Speedy70, ich teile dieses ungute Gefühl, und es gibt auch bereits diverse andere Forumsbeiträge zu diesem Thema, z.B.
[Blocking DNS over HTTPS with Pi Hole]
[EFF view on DOH and potential privacy problem with it]
[Blocking DNS-over-HTTPS (DoH)]

Letzteres ist ein Feature Request, momentan Out-of-Scope.

Dort habe ich auch bereits schon einen längeren Beitrag genau zu dem Thema verfasst, etwas off-topic wohl. Vielleicht wäre es sinnvoll, diese Posts irgendwie zu bündeln…

@DL6ER

Herzlichen Dank für deine Ehrliche und promte Antwort.
Ich hoffe nicht dass es irgendwann soweit kommt. Bzw. ich würde es vorziehen, wenigstens einen Hauch von Kontrolle in meinem Netzwerk behalten zu können. Und dafür ist Pi-hole für mich das ideale Werkzeug. Ich möchte ja gar nicht darüber nachdenken, auf welche “Glorreichen” Gedanken diese sogenannten BigPlayer noch kommen werden. Und all das unter dem Deckmäntelchen von Sicherheit und Datenschutz.

@Bucking_Horn
Danke für die Informationen.
Ich wühle mich schon länger durch diese Beiträge. Und je länger ich micht damit beschäftige, desto mulmiger wird mir dabei.
Auf der einen Seite versucht man dem Anwender eine Art “Pseudosicherheit” vorzugaukeln, und auf der anderen Seite eröffnet man mit dieser Technik ganz neue Angriffsflächen für alle Arten von Datenmissbrauch sowie Schadprogrammen. Naja… :pensive:

Thanxxxxx

Speedy70

Vielleicht noch nicht ganz, denn

  • die DNS-HTTPS-Requests müssen ja auch erst einmal den Zielserver auflösen. Solange das noch über klassische DNS-Wege geht, hat man noch die Chance, die bekannten DoH-Server an dieser Stelle zu blocken
  • auf der Client-Seite wäre man in der Lage, die angefragten Domänen noch im Klartext zu lesen und dort anhand einer Blockliste zu filtern. Das geht allerdings nur im Browser mit Plugins wie uBlock Origin und passenden Blocklisten.
    Apps, die DoH verwenden, liessen sich auf diese Weise jedoch nicht mehr einhegen :frowning_face:

Generell glaube ich, dass DoH mehr Sicherheitsprobleme aufwirft, als es im Gegenzug an Privatheit schafft. Ich verstehe aber den grundsätzlichen Wunsch nach Verschlüsselung der DNS-Abfragen und halte ihn auch für sinnvoll.

Es dürfte für die Diskussiion hilfreich sein, hier zwei grundsätzliche Einsatz-Szenarien zu unterscheiden:

  1. den Einsatz auf vagabundierenden Geräten in fremden Netzen
    Das sind z.B. Smartphones in WLAN-Cafés, Tablets bei den Nachbarn oder Laptops in Hotelzimmern
  2. den Einsatz in kontrollierten Umgebungen
    also im wesentlichen Rechner in Firmennetzen oder alle Geräte im eigenen Heimnetz

In Szenario 1 bringt der Einsatz von DNS-Verschlüsselung tatsächlich zunächst einen Zugewinn an Privatheit/Privacy, da hier die anderen Netznutzer im Café/Hotel/etc prinzipiell nicht mehr abhören und mitlesen können, welche DNS-Server ich kontaktiere. Es handelt sich also vor allem um einen Zugewinn an Privatheit im eigenen Netz. Das ist auch das Szenario, auf das die Protagonisten von DoH gerne verweisen.

Allerdings ist es mit Ankunft der DoH-DNS-Pakete bei den Verarbeitern dann vorbei mit der Privatheit - diese müssen ja entschlüsseln können und erhalten in der Folge nach wie vor ein vollständiges Profil der DNS-Anfragen eines Nutzers.
Im Zuge der Aktivierung von DoH auf Browsern ist allerdings eine zunehmende Konzentration der DNS-Provider zu erwarten, weg von den DNS-Servern der ISPs hin zu den Default-DNS-Providern der Browserhersteller (hier sei nur die Kooperation von Firefox mit Cloudflare erwähnt). Es werden also mit einiger Wahrscheinlichkeit immer mehr Benutzerprofile bei nur wenigen DNS-Providern konzentriert.

Für mich ist damit DoH im Ergebnis ein Verlust an Privatheit, und nicht ein Gewinn. Umso mehr, als mit DoT schon länger ein konkurrierendes Verfahren existiert, was durch die Bindung an einen neuen DNS-Port 853 zumindest eine vergleichbare Kontrolle des Datenverkehrs in kontrollierten Netzen (Szenario 2) erlauben würde.

Aber (und dieses Aber ist kein kleines):
Das gilt so pauschal nur, solange ich in einem freiheitlichen Regime lebe. Wäre ich unter einem Unrechtsregime von Überwachung und Verfolgung bedroht, würde ich genau auf DoH setzen, um zumindest der Überwachung zu entgehen (auch, wenn ich mich wahrscheinlich genau dadurch verdächtig machen würde).

Und das liegt an zwei weiteren Eigenschaften von DoH:

  • DoH läuft über den SSL-Port 443 und ist damit von normalen HTTPS-Anfragen nicht zu unterscheiden
  • DoH-Anfragen können damit auch von jedem Web-Server mit HTTPS-Unterstützung im Netz akzeptiert und auch verarbeitet werden, solange dieser die DNS-Anfragen weiterleitet oder selbst direkt beantwortet

Dies erschwert eine Überwachung ziemlich, denn jedes HTTPS-Paket sieht aus wie das andere und ist zudem verschlüsselt, und die Menge der zur theoretisch zur Auflösung befähigten (und damit zu überwachenden) Server ist nicht mehr auf die DNS-Server beschränkt, sondern entspricht der Menge der Webserver im Netz.


Was ich als überwachtes Individuum an DoH gut finde, macht mir jedoch in Szenario 2 das Leben schwer. Denn wenn ich mein eigenes Netz kontrolliere, ist mir der minimale Zugewinn an Privatheit innerhalb des Netzes egal - da bin ich ja schon privat.

Wichtiger ist da schon, dass Dritte ausserhalb meines Netzes die DNS-Anfragen nicht mehr einfach mitlesen können. Das ist mit DoH sichergestellt, allerdings gibt es dafür auch schon jetzt alternative Verfahren wie eben z.B. DoT. Hier stellt DoH also nur einen Zugewinn in Aussicht, der sich auch anders realisieren ließe.

Die Vorteile von DoH aus Sicht Szenario 2 sind damit minimal, oder im Vergleich mit alternativen Verfahren sogar nicht existent.

Aber aus Sicht des Administrators bringt DoH ein gehöriges Sicherheitsproblem:

Durch Verwendung von Port 443 sind DNS-Anfragen jetzt nicht mehr von normalen HTTPS-Verkehr unterscheidbar - auch DPI ist wegen der Verschlüsselung machtlos.

Damit können DNS-Anfragen zu internen Hosts potentiell das lokale Netz verlassen und bis zum DNS-Provider gelangen, der sie auch nicht auflösen kann und auch nach Weiterverteilung ins Netz der DNS-Server günstigstenfalls nicht aufgelöst bekommen wird.
Statt einer schnell funktionierenden internen Namensauflösung werden so gegebenfalls Informationen über den internen Aufbau meines Netzwerks exponiert und schlimmstenfalls mit einer falschen externen Adresse aufgelöst - zwei Umstände, die potentiellen Angreifern in die Hände spielen. Natürlich werden Firmen intern weiterhin klassisches DNS zu erzwingen versuchen, aber nur eine falsche Eingabe in einem falsch konfigurierten DoH-fähigen Browser kann das zunichte machen.

Umso mehr, als ja jeder Web-Server HTTPS-Anfragen zumindest entgegennehmen verarbeiten und damit eben auch potentiell DoH-DNS-Anfragen verarbeiten kann, sofern er entsprechend aufgerüstet wurde. Dies wird (neben interessanten neuen Premium-Content-Geschäftsfeldern) auch neue Möglichkeiten im Spoofing erschliessen, da so aufgelöste Hostnamen in URLs tatsächlich wie echte aussehen können. Diesem Umstand kann man nur wirkungsvoll begegnen, wenn DoH nur im Zusammenspiel mit DNS-Validierungen wie DNSSEC genutzt werden kann (Ich bin aktuell überfragt, ob das so geplant ist, ich habe den kürzlich erschienen RFC zu DoH noch nicht gelesen). Wir werden es also wohl mit ganz neuen Bedrohungsszenarien zu tun bekommen.

Aus Sicht des Heimnetzwerkers ist das zwar eher unwahrscheinlich, weil Firmen als Angriffsziele interessanter sind. Aber auch er leidet unter DoH, denn eine zentrale lokale Kontrolle des DNS-Verkehrs wie z.B durch Pi-hole ist damit nur noch schwer möglich.

Ich habe zudem in meinem Netzwerk den DNS-Port 53 für alle Geräte gesperrt, nur Pi-hole darf auf diesem Port telefonieren. Dadurch bleiben auch alle Geräte oder Apps brav virtuell zuhause, die gerne zu ihren eigenen Servern ausbüxen (TVs, Smartphones und Chromium haben da so ihre eigenen Adressen, die man ihnen nicht immer ausreden kann).
Diese Art der Portblockade ist mit DoH nicht möglich, da ich mit Port 443 quasi das gesamte Internbet blockieren würde. DoT hingegen könnte ich über Port 853 so kontrollieren.


Was bleibt an Alternativen?

Natürlich müssen auch die Hostnamen der DoH-Server erst einmal in eine IP-Adresse aufgelöst werden. Solange Standard-DNS noch der Standard bleibt, bietet dies zumindest die Möglichkeit, bekannte DoH-DNS-Server zu blocken - das ginge über entsprechende Blocklisten in Pi-hole oder Firewallregeln vor oder im Router/Gateway.
Es bleibt abzuwarten, inwieweit die DNS-Auflösung über Port 53 verfüpgbar bleibt, oder ob sie in Zukunft nicht einzig und ausschließlich die Auflösung von DoH-Namensservern erlaubt, um deren Verwendung zu erzwingen.

Da im Browser die Hostnamen noch im Klartext vorliegen, ist auch eine Kontrolle direkt im Browser noch möglich.
Existierende Plug-Ins wie uBlock Origin (uBO) könnten durch entsprechende Blocklisten zumindest den Abfluss von DNS-Anfragen an beklannte DoH-DNS-Server weiterhin unterbinden.
Ich sage ‘könnten’, weil sich auch an dieser Front etwas tut: Google will die Integration von Plug-Ins derart umstellen. dass eine Filterung nur noch mit einer statischen und zudem zahlenmässig beschränkten Blackliste möglich wäre. Statische Listen würden zwar in etwa der Pi-hole-Filterung entsprechen, aber sie wären auf derzeit geplant 30,000 Einträge kastriert. Und die umfangreichen dynamischen Filterungen, die uBO so hervorragend machen, wären damit prinzipiell unmöglich. Aber das nur am Rande…

Anders als bei Browsern dürfte die Kontrolle von Applikationen, die DoH verwenden, jedoch nahezu unmöglich sein.

In diesem Zusammenhang möchte ich noch auf einen Umstand eingehen, den @DL6ER mir an anderer Stelle zurecht vor Augen geführt hat: Versuche zur Umgehung von DNS-Filtern hat es schon immer gegeben. Es gibt sie auch heute, und auch böswillge Programme oder Apps versuchen heute bereits, zu externen Servern Kontakt aufzubauen und dabei einer Entdeckung zu entgehen.
Ich werde nur das Gefühl nicht los, dass DoH diese Art der Umgehung eher erleichtern wird.

Insgesamt finde ich es zwar begrüßenswert, dass man DNS-Anfragen verschlüsselt überträgt

Die Verlagerung der DNS-Auflösung aus dem Netzwerk hin zum Client sogar bis auf Applikationsebene halte ich jedoch für falsch und aufgrund von Sicherheitsbedenken sogar für gefährlich.

Das ebenfalls verfügbare und auch schon länger RFC-standardisierte DoT wäre aus meiner Sicht die weniger problematische Alternative - zumindest solange ich in einem freiheitlichen Staat lebe.

Aber das ist nur meine bescheidene Meinung :wink:

Nö, müssen Sie nicht. https://dns.google -> https://8.8.8.8 ist ein gültiges Ziel, welches durchaus fest eingebrannt sein könnte.

Ich denke nicht, dass ein Eingriff über Plugins funktionieren kann. Plugins sind zwar frei auf der aufgerufenen Seite alles abzuändern was sie für richtig erachten (weswegen ich sie auch nicht einsetze), ob sie aber Zugriff auf im Browser weit tiefer gehende Prozesse (DomainNameToIPaddress) haben, wage ich ernsthaft zu bezweifeln.

Ja und Nein. Wenn eine Anfrage auf Port 443 an einen Server gestellt wird, der (bekanntermaßen) DoH verteilt, ist man natürlich sofort erkannt.

Ja, aber! Zum Beginn einer HTTPS Übertragung wird eine TCP Verbindung aufgebaut. Über diese wird zunächst unverschlüsselt übertragen welche Domain besucht werden soll (“server name indication”).
Dies ist erforderlich, damit Server, die mehrere Domains anbieten, im nächsten Schritt das korrekte (ebenfalls unverschlüsselte) Zertifikat zurückschicken können.
Auf Grundlage dieses Zertifikats wird erst dann der TLS Handshake (Aushandlung des Algorithmus, Schlüsselaustausch, …) durchgeführt.

Ein unberechtigter Mitleser kann also zwar nicht an den Inhalt kommen, aber durchaus herausfinden, welchen Server man genau anschaut. Ein Unrechtsstaat kann weiterhin auch einfach systematisch alles verbieten was ihm nicht gefällt. Er braucht hierfür nicht alle möglichen Endpunkte zu belauschen, denn er kann ja einfach an der Quelle (dem Nutzer) lauschen und genau sehen wohin sich dieser verbindet.
Gleiches gilt dann natürlich auch für die DNS Inhalte.

Der Unrechtsstaat kann bei zugelassenen verschlüsselten DNS-Anfragen nun zwar nicht mehr unmittelbar mitlesen wonach der DNS Server gefragt wurde, diese Information braucht er aber auch gar nicht, da der Nutzer sich wenige Augenblicke später zu der angefragten IP verbinden und dabei - wie oben erwähnt - den angefragten Hostnamen seiner Anfrage unverschlüsselt voranstellen wird.

@DL6ER
@Bucking_Horn

Guten Morgäääääääään an Alle :sleeping:

Zuerst mal herzlichen Dank für die Ausführlichen Erläuterungen zum Thema!

Für mich als technisch interessierter Internetnutzer ist der technische Hintergrund nur sehr schwer nachvollziehbar. Und ich bin überzeugt davon, dass es 90% der Internetanwender genau so ergeht und es ihnen eigentlich vollkommen egal ist, wie oder warum etwas funktioniert. Hauptsache sie können Online Zocken, Einkaufen, ihre Facebook Seiten aufrufen und am Handy Online-Banking durchführen. Sie Vertrauen den Anbietern und der Technik.

Aber genau hier sehe ich das eigentliche Problem. Dieses Vertrauen bzw. dieses Unwissen der meisten Internetnutzer macht es den „BigPlayern“ sehr leicht, ihre Interessen durchzusetzen. Sie müssen nur das Thema Datenschutz in den Mund nehmen und schon sind alle beruhigt. Was soll schon schlecht daran sein? Dient ja Alles dem Datenschutz und der Sicherheit? Wir wollen doch nur das Beste für Euch und dass eure Daten geschützt sind!?

Aber ich frage mich dann Wem dient das das Ganze? Wer profitiert am Meisten davon? Sind es wirklich die Internetnutzer? Oder sind es doch nur wieder diese BigPlayer, die Werbetreibenden und die Abzocker die daraus Profit schlagen werden? Hier eröffnen sich ganz neue Geschäftsfelder und Einnahmequellen die mit Sicherheit auch genutzt werden. Und die Internetgemeinde wird/muss sich damit abfinden bzw. kann gar nichts dagegen tun bzw. müssen weiterhin Vetrauen! Mir gefällt diese Entwicklung ganz und gar nicht. Sie macht mir sogar etwas Angst.

Wenn diese Entwicklung in Zukunft so weiter geht, dann wird es ein Internet so wie wir es jetzt noch kennen, nicht mehr geben. Oder sehe ich das Ganze zu Schwarz?

Speedy70

Leider ist beides - Klartext fuer SNI und ein unverschluesseltes Zertifikat in dem Handshake - nicht wirklich etwas auf dem man aufbauen kann. Das Zertifikat wird nicht mehr unverschluesselt uebertragen mit TLS 1.3. SNI kann (zugegeben: Optional, als Extension) mit TLS 1.3 ebenfalls verschluesselt werden¹.

Die Idee, das hier also noch irgendwelche Moeglichkeiten des Eingriffs bestehen, ist zwar grundsaetzlich korrekt basierend auf dem aktuellen Verbreitungsstand von TLS Standards² (stand heute: < 20% sind auf TLS 1.3), dabei aber gleichzeitig bereits veraltet.

https://blog.cloudflare.com/encrypted-sni/
https://www.ssllabs.com/ssl-pulse/