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).