Lokaler TLS-Proxy mit Content-Matching zur Erweiterung von Pi-hole

Feature Requests
1

Pi-hole schützt zuverlässig auf DNS-Ebene. Moderne Inhalte wie serverseitige YouTube-Werbung oder verschlüsselte Tracker umgehen diesen Schutz. Ich schlage vor, Pi-hole um ein optionales, lokal laufendes TLS-Proxy-Modul mit Inhaltsanalyse zu erweitern.

Zielsetzung:
– Pi-hole und ein TLS-Proxy laufen auf demselben Gerät
– HTTP/HTTPS-Verkehr wird lokal umgeleitet (z. B. auf localhost:8443)
– Optional: TLS-Session-Keys vom Client übergeben (z. B. SSLKEYLOGFILE), um verschlüsselten Verkehr zu analysieren
– Kein zusätzlicher Server oder externe Tools notwendig

Vorgeschlagene Funktionen:
– Lokales TLS-Proxy-Modul (z. B. mitmproxy) auf localhost
– iptables-Weiterleitung von Port 443 zum Proxy
– Erweiterbare Inhaltsfilter über Plugin-API (z. B. Werbung, Tracker, NSFW)
– Unterstützung für TLS-Key-Logging durch kooperierende Clients
– Integration in Admin-Oberfläche (aktivieren/deaktivieren, Logs, Plugin-Status)
– Modular, standardmäßig deaktiviert, keine Einschränkungen bei Nichtverwendung

Warum sinnvoll:
– DNS-Blocking reicht gegen viele moderne Werbeformen nicht mehr
– TLS-Proxy ermöglicht tiefere Kontrolle und Sichtbarkeit im Heimnetz
– Technisch realisierbar mit bestehender Open-Source-Software
– Ideal für Nutzer, die Geräte ihrer Kinder oder Gäste absichern wollen

Machbarkeit:
– iptables-Redirects auf localhost sind erprobt
– mitmproxy funktioniert mit Root-CA oder Session-Keys
– UI-Erweiterung analog zur DHCP-Konfiguration denkbar
– Plugin-Schnittstelle kann vorhandene Pi-hole-Blocklogik nutzen

Zusammenfassung:
Diese Erweiterung macht Pi-hole zukunftsfähig für verschlüsselten Datenverkehr. Sie ist optional, realistisch umsetzbar und bietet tiefgreifendere Kontrolle bei gleichzeitiger Wahrung der bestehenden DNS-Funktionalität.

2

Ich sehe hier nicht wirklich den unmittelbaren Nutzen. Wir müssten zusätzlich eine komplette Inhaltsanalyse entwickeln, die es so derzeit einfach nicht gibt.

Nur zur Klarstellung: Der DNS Ansatz setzt vor der Verschlüsselung durch HTTPS an. Pi-hole hat derzeit keinerlei Probleme Werbung, die später über HTTPS übertragen wird zu blocken. Was hier gefordert wird ist ein völlig neuer Ansatz.

Pi-hole wird von Freiwilligen in ihrer Freizeit weiterentwickelt. Es gibt weder Sponsoring noch gibt es "hauptamtliche" Programmierer, die mit Pi-hole ihren Lebensunterhalt bestreiten. Daher halte ich es für sehr unwahrscheinlich, dass an solch einem (extrem umfangreichen!) gearbeitet werden kann. Sollte es substanzielle Beiträge aus der Community hierzu geben, wäre die Situation möglicherweise anders.

3

Pi-hole empfängt ausschließlich DNS-Anfragen, und auch ausschließlich DNS-Anfragen der Geräte, die Pi-hole als (einzigen) DNS-Server konfiguriert haben.

Eine lokale iptables-Umleitung von HTTPS-Verkehr zu einem TLS-Proxy würde also komplett ins Leere laufen, da Geräte ihre HTTPS-Verbindungen mit der jeweiligen Ziel-IP aufbauen würden (die ggf. hart verdrahtet oder von Pi-hole geliefert wurde).

Und sofern Pi-hole immer seine eigene Adresse ausliefern würde, wäre eine iptables-Weiterleitung für Port 443 nicht sinnvoll, da damit Pi-holes eigener Webserver umgangen würde.

Denkbar wäre stattdessen, dass der TLS-Proxy auf einer eigenen IP-Adresse operiert.

Dieser könnte dann ein eigenes Zertifikat fälschen, dass dann auf allen zu filternden Clients zu installieren und von diesen als vertrauenswürdig einzustufen wäre.

Und das funktioniert natürlich nur dann, wenn sich ein solches Zertifikat auch auf dem zu filternden Endgerät installieren lässt (was z.B. bei vielen TVs oder IoTs nicht möglich ist), und auch nur solange, wie der angesteuerte Server nicht Techniken zur Zertifikatsvalidierung verwendet.

Allerdings würde dann der komplette HTTPS-Verkehr über den TLS-Proxy laufen.
Gegenüber ein paar hundert Bytes für eine DNS-Anfrage würde das eine drastische Erhöhung des Datenvolumens bedeuten, die der Server zu bewältigen hat, so dass die Hardware am besten über zwei Netzwerkschnittstellen verfügen sollte, um die Bandbreite nicht zu halbieren.
Zusätzlich würde das Aufbrechen der HTTPS-Verschlüsselung eine erheblich höhere CPU-Leistung erfordern als das Analysieren und Blockieren von DNS-Anfragen.

Fraglich ist auch, ob serverseitiges Einbetten von Werbung in Datenströme (wie angeblich von YouTube derzeit erprobt) auf diese Weise überhaupt wirksam unterbunden werden kann. Das würde voraussetzen, dass Datenpakete mit Werbeinhalten im Datenstrom zweifelsfrei isoliert werden können.

Insgesamt bräuchte es dazu deutlich leistungsfähigere Hardware als für Pi-hole, und ein erfolgreicher MITM-Angriff des TLS-Proxys ist damit nicht garantiert.
Sofern z.B. Certificate Pinning zum Einsatz kommt, wird das Abfangen der TLS-Verbindung clientseitig nur noch Fehler produzieren, d.h. die angesteuerte Webseite ist dann nicht nutzbar.

Es gab Mitte der 2010er mit eBocker mal ein deutsches StartUp, was sich an einem Fix-und-Fertig-Gerät mit einem gegenüber Deinem Vorschlag nochmals erweitertem Funktionsumfang (u.a. um Firewall, Tor, VPN) versucht hat und 2019 pleite gegangen ist.

Als ich mich vor Jahren damit beschäftigt habe, gab es DNS-seitig einige Funktionen, die Pi-hole voraus hatte, z.B. Deep CNAME inspection, über das Pi-hole CNAME cloaking erkennen und blockieren kann.
IPv6-Unterstützung war damals in eBlocker äußerst rudimentär, und eBockers Einbindung ins heimische Netzwerk über ARP-Spoofing war problematisch bzw. völlig unbrauchbar, sobald ein zweiter Router oder L3-Switch im Netzwerk vorhanden war.

Gerät und Firma gibt's inzwischen nicht mehr, aber die zugrunde liegende Software wird seit 2020 als Open Source Projekt weiterentwickelt und wurde sowohl hier im Forum (z.B. hier) als auch in den Medien mehrfach besprochen (z.B. bei heise online).

4

Für so eine Lösung ist ein Pi absolut ungeeignet. Wir haben vor einiger Zeit eine solche Lösung für die Arbeit evaluiert. Der Hersteller hat dann dann zwei Pizza-Schachteln geliefert und die waren bei ca. 100 Test-Nutzern schon am Anschlag.

Dann muss für jedes Endgerät ein Zertifikat ausgerollt werden. Da es keine allgemeingültige Installationsanleitung gibt, musste man sich fast mit jedem Endgerät einzeln befassen - incl. der Problemanalyse bei Fehlern. Desweiteren gibt es Geräte, die keine Installation von Zertifikaten zulassen. Die könnte man natürlich ausnehmen, aber aus Sicherheitsgründen geht das dann nicht, weil ein Gerät x könnte sich dann als TV ausgeben und lustig Daten senden.

Viele Apps wie Banking, Krankenkassen, etc. verweigern den Dienst (zurecht) komplett, wenn sie so eine Konstruktion untergeschoben bekommen. Dann gab es massenhaft Beschwerden über fehlenden Content, weil die Regeln und Abhängigkeiten nicht so funktionierten, wie geplant.

Der Test war nach ca. 3 Wochen beendet und die Boxen wanderten an den Hersteller zurück.