ubuntuusers.de

Transparenter Proxy mit HTTPS (Connect-Methode)

Status: Ungelöst | Ubuntu-Version: Server 14.04 (Trusty Tahr)
Antworten |

jbredereck

Anmeldungsdatum:
22. Oktober 2016

Beiträge: Zähle...

Hallo,

ich versuche einen transparenten SQUID-Proxy aufzusetzen, der für die Clients im LAN auch HTTPS-Verbindungen transparent durchreicht.

Die Informationen, die ich dazu im Netz finde sind widersprüchlich, daher wollte ich mich hier im Forum erkundigen, ob das überhaupt so möglich ist.

Die Grundproblematik ist, dass HTTPS-Verbindungen nicht über die normalen HTTP-Mechanismen durchgereicht werden können, da der Proxy ja nicht in den verschlüsselten HTTPS-Datenstrom "reinsehen" kann. Um das zu umgehen gibt es zwei Möglichkeiten:

a) Man-in-the-Middle mit eigenem SSL-Zertifikat b) CONNECT-Verbindung ohne Caching und ohne den Datenstrom überhaupt zu ändern

Die Variante a) scheidet bei uns aus, da wir hierbei die Zertifikate der Ziel-Server nicht mehr prüfen könnten

Die Variante b) scheint nur möglich zu sein, wenn der Browser weiss, dass er gerade mit einem Proxy spricht. D.h. wenn ich im Browser den Squid als HTTPS-Proxy hinterlege, ist über die CONNECT-Methode problemlos ein Durchreichen des HTTPS-Traffics möglich.

Ich möchte aber eine Lösung bei der die Clients keinen Proxy bei sich hinterlegen müssen. Hierzu macht man klassischerweise einen TCP-Redirect via IPTABLES und leitet den HTTP(S)-Datenverkehr einfach auf den Port des Proxies um.

Jetzt zu meiner Frage: Ist es überhaupt möglich eine "nackte" HTTPS-Verbindung auf den Proxy-Port umzuleiten und Squid so zu betreiben, dass er den HTTPS-Request als Proxy-Request interpretiert, einen CONNECT zum Ziel-HTTPS-Server aufbaut und die empfangenen Daten 1:1 an den Client durchleitet?

Theoretisch müsste es möglich sein, denn ich habe einen "Wrapper" gefunden, der genau das macht:

https://phinfinity.com/2014/04/01/transparent-pass-through-proxy-with-iptables-part-2-for-https/

Dieser "tproxyhttps" tut eigentlich exakt, dass was ich oben beschreiben habe: Er nimmt einen umgeleiteten HTTPS-Request und "baut" daraus einen Proxy-Request, den Squid ohne weitere Config-Anpassung versteht und mit der CONNECT-Methode beantworten kann.

Das Problem: Dieser Wrapper läuft meist nicht länger als ein paar Minute und segfaultet dann reproduzierbar.

Eigentlich wäre mir eine generische Squid-Lösung ohne Third-Party-Tools auch lieber. Und eigentlich würde ich davon ausgehen, dass Squid auch einen Modus anbietet, bei dem dieser Wrapper gar nicht notwendig ist. Daher meine Frage an euch: Wie müsste ich Squid ggf. konfigurieren, damit direkt umgeleitete HTTPS-Requests über die Connect-Methode korrekt interpretiert und durchgeleitet/beantwortet werden?

Sämtliche Konfigurations-Beispiele (http_port intercept), die ich auf squid-cache.org gefunden habe, beziehen sich leider nur auf HTTP und sind daher nicht wirklich hilfreich.

Ich bin für jeden Hinweis dankbar!

Viele Grüße, Jörn

misterunknown Team-Icon

Ehemalige
Avatar von misterunknown

Anmeldungsdatum:
28. Oktober 2009

Beiträge: 4403

Wohnort: Sachsen

jbredereck schrieb:

Jetzt zu meiner Frage: Ist es überhaupt möglich eine "nackte" HTTPS-Verbindung auf den Proxy-Port umzuleiten und Squid so zu betreiben, dass er den HTTPS-Request als Proxy-Request interpretiert, einen CONNECT zum Ziel-HTTPS-Server aufbaut und die empfangenen Daten 1:1 an den Client durchleitet?

In der Doku steht dazu dieser Abschnitt.

Das Problem: Dieser Wrapper läuft meist nicht länger als ein paar Minute und segfaultet dann reproduzierbar.

Dann müsstest du den Wrapper fixen…

Und eigentlich würde ich davon ausgehen, dass Squid auch einen Modus anbietet, bei dem dieser Wrapper gar nicht notwendig ist.

Warum? Squid ist ja kein TCP-Proxy.

Daher meine Frage an euch: Wie müsste ich Squid ggf. konfigurieren, damit direkt umgeleitete HTTPS-Requests über die Connect-Methode korrekt interpretiert und durchgeleitet/beantwortet werden?

Das geht nicht. Sonst bräuchtest du ja keinen Wrapper. Hast du dir deinen Link mal durchgelesen? Offenbar nicht. Das solltest du ändern. Dann verstehst du das Problem auch.

jbredereck

(Themenstarter)

Anmeldungsdatum:
22. Oktober 2016

Beiträge: 4

misterunknown schrieb:

jbredereck schrieb:

Jetzt zu meiner Frage: Ist es überhaupt möglich eine "nackte" HTTPS-Verbindung auf den Proxy-Port umzuleiten und Squid so zu betreiben, dass er den HTTPS-Request als Proxy-Request interpretiert, einen CONNECT zum Ziel-HTTPS-Server aufbaut und die empfangenen Daten 1:1 an den Client durchleitet?

Das Problem: Dieser Wrapper läuft meist nicht länger als ein paar Minute und segfaultet dann reproduzierbar.

Dann müsstest du den Wrapper fixen…

Der Wrapper ist eine Behelfs-Krücke. Eine ordentliche Implementierung des entsprechenden Wrapper-Modus direkt in SQUID wäre der saubere Ansatz. Meine Frage zielte darauf ab, ob ein solcher Modus in Squid evtl. schon implementiert ist und ich dies in der Doku nur übersehen habe. Offenbar scheint dieser Modus allerdings wirklich nicht implementiert zu sein. Schade, aber lässt sich nicht ändern.

Und eigentlich würde ich davon ausgehen, dass Squid auch einen Modus anbietet, bei dem dieser Wrapper gar nicht notwendig ist.

Warum? Squid ist ja kein TCP-Proxy.

Naja, im CONNECT-Modus ist er rein technisch schon ein TCP-Proxy. Die verschlüsselten TCP/SSL-Pakete werden 1:1 durchgeleitet. Der einzige Unterschied ist, dass der Browser diesen TCP-Proxy-Modus explizit anfordern muss. Es wäre durchaus Möglich den CONNECT-Modus auch ohne explizite Anforderung (z.B. auf einem separaten Port) direkt bereitzustellen, so wie es der Wrapper tut. Aber offensichtlich ist das schlichtweg (noch) nicht in SQUID implementiert.

Daher meine Frage an euch: Wie müsste ich Squid ggf. konfigurieren, damit direkt umgeleitete HTTPS-Requests über die Connect-Methode korrekt interpretiert und durchgeleitet/beantwortet werden?

Das geht nicht. Sonst bräuchtest du ja keinen Wrapper. Hast du dir deinen Link mal durchgelesen? Offenbar nicht. Das solltest du ändern. Dann verstehst du das Problem auch.

Es wäre nicht das erste Mal, dass es Wrapper oder Addons für Funktionen gibt, die eine Software in späteren Versionen auch generisch anbietet. Offenbar gibt es Bedarf für dieses Feature, ansonsten würde sich niemand hinsetzen und solch einen Wrapper schreiben. Der Ideal-Zustand wäre, dass ein solcher Wrapper gar nicht gebraucht wird, weil die entsprechende Funktion direkt in SQUID implementiert ist.

Du stellst es so dar, als wäre das Problem nicht in Squid direkt lösbar. Defacto wollen die Squid-Entwickler dieses Feature nur nicht anbieten. Das ist schade, aber muss man respektieren. Inzwischen habe ich das Problem durch einen direkten TCP-Redirect via IPTables (an Squid vorbei) gelöst.

misterunknown Team-Icon

Ehemalige
Avatar von misterunknown

Anmeldungsdatum:
28. Oktober 2009

Beiträge: 4403

Wohnort: Sachsen

jbredereck schrieb:

Der Wrapper ist eine Behelfs-Krücke. Eine ordentliche Implementierung des entsprechenden Wrapper-Modus direkt in SQUID wäre der saubere Ansatz.

Das geht nicht, denn der Wrapper besteht ja nicht nur aus dem Python-Programm, sondern auch aus einem Sack voll iptables-Regeln. Das heißt der Wrapper verlässt sich dort auf bestimmte Werte. Das hat auch zur Folge, dass sowas auf einem Remote-System gar nicht möglich wäre.

Naja, im CONNECT-Modus ist er rein technisch schon ein TCP-Proxy. Die verschlüsselten TCP/SSL-Pakete werden 1:1 durchgeleitet. Der einzige Unterschied ist, dass der Browser diesen TCP-Proxy-Modus explizit anfordern muss.

Richtig, aber aus Sicht der Squid-Entwickler ist bereits das ein unschöner Hack. Das heißt die CONNECT-Methode ist schon etwas, was nicht die natürliche Aufgabe des Squids ist.

Der Ideal-Zustand wäre, dass ein solcher Wrapper gar nicht gebraucht wird, weil die entsprechende Funktion direkt in SQUID implementiert ist.

Wie gesagt: Es ist nicht nur eine Funktion im Squid, sondern auch im Betriebssystem.

Defacto wollen die Squid-Entwickler dieses Feature nur nicht anbieten.

Das hat nichts mit "nicht wollen" zu tun. Es ist schlicht nicht die Aufgabe des Squids.

Inzwischen habe ich das Problem durch einen direkten TCP-Redirect via IPTables (an Squid vorbei) gelöst.

Das ist IMHO die sauberste Lösung.

jbredereck

(Themenstarter)

Anmeldungsdatum:
22. Oktober 2016

Beiträge: 4

misterunknown schrieb:

jbredereck schrieb:

Der Wrapper ist eine Behelfs-Krücke. Eine ordentliche Implementierung des entsprechenden Wrapper-Modus direkt in SQUID wäre der saubere Ansatz.

Das geht nicht, denn der Wrapper besteht ja nicht nur aus dem Python-Programm, sondern auch aus einem Sack voll iptables-Regeln. Das heißt der Wrapper verlässt sich dort auf bestimmte Werte. Das hat auch zur Folge, dass sowas auf einem Remote-System gar nicht möglich wäre.

In dem verlinkten Blogpost gibt es zwei Implementierungen. Hast du den Blog-Post zu ende gelesen? Die IPTables/Python-Implementierung war der ursprüngliche Ansatz. Später hat der Entwickler ein natives C-Programm namens thttpsproxy geschrieben. Hier der Link zu dem Source-Code:

http://web.iiit.ac.in/~anish.shankar/phinfinity_downloads/tproxyhttps.c

Ich hatte mich auf diesen in C geschriebenen Wrapper bezogen.

Ich sehe nicht, dass in diesem Quellcode irgendwelche IPTables-Regeln notwendig wären. Natürlich muss der Admin weiterhin seinen HTTPS-Traffic via IPTables auf den Squid-Port umleiten, damit der Traffic von Squid "intercepted" werden kann. Aber das ist beim normalen HTTP-Interception-Modus jetzt auch schon der Fall und nichts HTTPS-spezifisches.

Der Ideal-Zustand wäre, dass ein solcher Wrapper gar nicht gebraucht wird, weil die entsprechende Funktion direkt in SQUID implementiert ist.

Wie gesagt: Es ist nicht nur eine Funktion im Squid, sondern auch im Betriebssystem.

Nein, schau dir mal den C-Code an. Dort sind keine OS-Features enthalten. Der Wrapper generiert lediglich aus dem IP-Header einen CONNECT-Request. Dieser C-Code, der die IP-Header entsprechend parsed könnte auch direkt Bestandteil des Squid-Binaries sein.

Defacto wollen die Squid-Entwickler dieses Feature nur nicht anbieten.

Das hat nichts mit "nicht wollen" zu tun. Es ist schlicht nicht die Aufgabe des Squids.

Ok, dann lass es mich anders formulieren: Die Squid-Entwickler wollen sich auf klassische HTTP-Requests konzentrieren und HTTPS nicht anfassen. Damit ist Squid dann ein Auslaufmodell, denn der Trend geht ganz klar zu HTTPS-Only. Mozilla hat bereits angekündigt in Zukunft beim Zugriff auf unverschlüsselte Webseiten eine Warnung einzublenden und HTTPS zum Default zu erklären. Ein Proxy der damit nicht klar kommt ist in meinen Augen früher oder später obsolet.

Inzwischen habe ich das Problem durch einen direkten TCP-Redirect via IPTables (an Squid vorbei) gelöst.

Das ist IMHO die sauberste Lösung.

Naja, die Proxy-Lösung hätte den Vorteil gehabt, dass hierbei das zentrale ACL-Regelwerk Anwendung gefunden hätte. Wenn ich meinen Traffic am Proxy vorbei schleuse muss ich auf diese Features verzichten und die ACLs und das Logging auf anderer Ebene lösen.

misterunknown Team-Icon

Ehemalige
Avatar von misterunknown

Anmeldungsdatum:
28. Oktober 2009

Beiträge: 4403

Wohnort: Sachsen

jbredereck schrieb:

Später hat der Entwickler ein natives C-Programm namens thttpsproxy geschrieben. Hier der Link zu dem Source-Code:

Oha. Ich hab den nur überflogen. Das C Programm hatte ich nicht gesehen.

Ok, dann lass es mich anders formulieren: Die Squid-Entwickler wollen sich auf klassische HTTP-Requests konzentrieren und HTTPS nicht anfassen.

Mal ne andere Frage: Hast du es mal versucht einzurichten? Hier sieht es so aus, als ob der SO_ORIGINAL_DST-Header schon ausgewertet wird. Ich weiß aber nicht, wie lange das schon dort drin ist.

jbredereck

(Themenstarter)

Anmeldungsdatum:
22. Oktober 2016

Beiträge: 4

misterunknown schrieb:

Ok, dann lass es mich anders formulieren: Die Squid-Entwickler wollen sich auf klassische HTTP-Requests konzentrieren und HTTPS nicht anfassen.

Mal ne andere Frage: Hast du es mal versucht einzurichten? Hier sieht es so aus, als ob der SO_ORIGINAL_DST-Header schon ausgewertet wird. Ich weiß aber nicht, wie lange das schon dort drin ist.

Ja, ich hatte es natürlich versucht. Leider ohne Erfolg. Ich war mir aber unsicher, ob ich nur etwas übersehen habe, oder ob es grundsätzlich nicht geht. Daher ja mein Post hier im Forum in der Hoffnung, dass vielleicht schonmal jemand anders es generisch mit Squid hinbekommen hat. Denn wie du selbst sagst: Den SO_ORIGINAL_DST-Eintrag aus dem IP-Header auszulesen ist jetzt kein Hexenwerk und etwas, dass der Squid durchaus auch ohne 3rd-Party-Wrapper beherrschen KÖNNTE. Wenn ich das richtig verstehe, dann macht das der Squid seit der 3er-Version im Intercept-Modus sogar für HTTP-Traffic bereits. Daher verstehe ich ja gerade nicht, was dagegen spricht, es auch für HTTPS so zu machen.

Antworten |