Transparenter Squid und https-Seiten ?!?!?
Transparenter Squid und https-Seiten ?!?!?
Hi Leutz,
ich setze Squid als transparenten Proxy ein. Funzt mit http problemlos. Aber auf alle https-Seiten komme ich nicht. Als Firewallaufsatz zu iptables setze ich vuurmuur ein. Hab dort auch schon eine Regel für https definiert (also alles:443 -> Squidport). Hat auch nix gebracht.
Funzt das generell nicht über den transparenten Weg? Wenn ich den Squid als Proxy im Browser eintrage geht alles bestens.
Gruß
Markus
ich setze Squid als transparenten Proxy ein. Funzt mit http problemlos. Aber auf alle https-Seiten komme ich nicht. Als Firewallaufsatz zu iptables setze ich vuurmuur ein. Hab dort auch schon eine Regel für https definiert (also alles:443 -> Squidport). Hat auch nix gebracht.
Funzt das generell nicht über den transparenten Weg? Wenn ich den Squid als Proxy im Browser eintrage geht alles bestens.
Gruß
Markus
=============================
Debian Server System:
- PIII 800
- 512 MB Ram
- 500 GB Hitachi ATA (Daten)
- 80 GB HDD SATA Seagate (System)
- 3Ware Raid Kontroller
Debian Sarge 4.0
=> wird jetzt regelmäßig per DAR und SARAB gesichert (aus Schaden wird man klug )
Debian Server System:
- PIII 800
- 512 MB Ram
- 500 GB Hitachi ATA (Daten)
- 80 GB HDD SATA Seagate (System)
- 3Ware Raid Kontroller
Debian Sarge 4.0
=> wird jetzt regelmäßig per DAR und SARAB gesichert (aus Schaden wird man klug )
Hi,
danke für den Hinweis. Ist jetzt auch klar, ich dachte halt, Squid würde den https einfach "durchreichen" (können).
Gruß
danke für den Hinweis. Ist jetzt auch klar, ich dachte halt, Squid würde den https einfach "durchreichen" (können).
Gruß
=============================
Debian Server System:
- PIII 800
- 512 MB Ram
- 500 GB Hitachi ATA (Daten)
- 80 GB HDD SATA Seagate (System)
- 3Ware Raid Kontroller
Debian Sarge 4.0
=> wird jetzt regelmäßig per DAR und SARAB gesichert (aus Schaden wird man klug )
Debian Server System:
- PIII 800
- 512 MB Ram
- 500 GB Hitachi ATA (Daten)
- 80 GB HDD SATA Seagate (System)
- 3Ware Raid Kontroller
Debian Sarge 4.0
=> wird jetzt regelmäßig per DAR und SARAB gesichert (aus Schaden wird man klug )
-
- Beiträge: 10
- Registriert: 20.07.2005 10:25:59
http://www.squid-cache.org/Doc/FAQ/FAQ-1.html#ss1.12As of version 2.5, Squid can terminate SSL connections. This is perhaps only useful in a surrogate (http accelerator) configuration. You must run configure with --enable-ssl. See https_port in squid.conf for more information.
Hast Du einen so konfiguierten squid laufen?
Hm,
der Link geht momentan nicht. Wenn die Seite wieder verfügbar ist werd ich's überprüfen.
Gruß
der Link geht momentan nicht. Wenn die Seite wieder verfügbar ist werd ich's überprüfen.
Gruß
=============================
Debian Server System:
- PIII 800
- 512 MB Ram
- 500 GB Hitachi ATA (Daten)
- 80 GB HDD SATA Seagate (System)
- 3Ware Raid Kontroller
Debian Sarge 4.0
=> wird jetzt regelmäßig per DAR und SARAB gesichert (aus Schaden wird man klug )
Debian Server System:
- PIII 800
- 512 MB Ram
- 500 GB Hitachi ATA (Daten)
- 80 GB HDD SATA Seagate (System)
- 3Ware Raid Kontroller
Debian Sarge 4.0
=> wird jetzt regelmäßig per DAR und SARAB gesichert (aus Schaden wird man klug )
Nein, da müsste ich Squid selber übersetzen. Das ist mir dann doch zu aufwändig. Werd halt den https Verkehr in www per firewall erlauben. Denke das sollte nicht allzu problematisch sein.hellospencer hat geschrieben:http://www.squid-cache.org/Doc/FAQ/FAQ-1.html#ss1.12As of version 2.5, Squid can terminate SSL connections. This is perhaps only useful in a surrogate (http accelerator) configuration. You must run configure with --enable-ssl. See https_port in squid.conf for more information.
Hast Du einen so konfiguierten squid laufen?
Gruß
=============================
Debian Server System:
- PIII 800
- 512 MB Ram
- 500 GB Hitachi ATA (Daten)
- 80 GB HDD SATA Seagate (System)
- 3Ware Raid Kontroller
Debian Sarge 4.0
=> wird jetzt regelmäßig per DAR und SARAB gesichert (aus Schaden wird man klug )
Debian Server System:
- PIII 800
- 512 MB Ram
- 500 GB Hitachi ATA (Daten)
- 80 GB HDD SATA Seagate (System)
- 3Ware Raid Kontroller
Debian Sarge 4.0
=> wird jetzt regelmäßig per DAR und SARAB gesichert (aus Schaden wird man klug )
-
- Beiträge: 10
- Registriert: 20.07.2005 10:25:59
Ja,
da hast du Recht, das wäre für mich die optimale Lösung.
Ich werd's vielleicht doch mal probieren wenn ich die Zeit dazu finde.
Gruss und danke für den Hinweis.
da hast du Recht, das wäre für mich die optimale Lösung.
Ich werd's vielleicht doch mal probieren wenn ich die Zeit dazu finde.
Gruss und danke für den Hinweis.
=============================
Debian Server System:
- PIII 800
- 512 MB Ram
- 500 GB Hitachi ATA (Daten)
- 80 GB HDD SATA Seagate (System)
- 3Ware Raid Kontroller
Debian Sarge 4.0
=> wird jetzt regelmäßig per DAR und SARAB gesichert (aus Schaden wird man klug )
Debian Server System:
- PIII 800
- 512 MB Ram
- 500 GB Hitachi ATA (Daten)
- 80 GB HDD SATA Seagate (System)
- 3Ware Raid Kontroller
Debian Sarge 4.0
=> wird jetzt regelmäßig per DAR und SARAB gesichert (aus Schaden wird man klug )
-
- Beiträge: 5
- Registriert: 07.02.2006 12:38:52
Hallo,
ich habe auch das Problem mit einem transparenten Squid, dass ich darüber keine verschlüsselten Seiten aufrufen kann.
Da mein System bequem über APT mit Sicherheitsupdates versorgt werden soll, ohne ständig neukompiliert werden zu müssen, kommen für mich jedoch nur Binärpakete in Frage.
Wenn ich die erwähnte FAQ ( http://www.squid-cache.org/Doc/FAQ/FAQ-1.html#ss1.12) richtig verstanden habe, dann ist es nur dann erforderlich den Squid neu zu kompilieren, wenn man auch die verschlüsselten Daten cachen und evtl. filtern möchte.
Wenn man also nur ein "Durchreichen" durch die "CONNECT request"-Methode benötigt, wäre dies nicht erforderlich. Damit soll fast jedes beliebige Protokoll getunnelt werden können, also nicht nur HTTPS sondern z.B. auch FTP.
Liege ich damit richtig oder habe ich da etwas falsch verstanden ? Oder funktioniert dies nur wenn der Proxy nicht transparent arbeitet ?
Sollte es also so funktionieren, dass ich HTTPS und auch andere Protokolle mit dieser Methode transparent über den Squid "tunneln" kann, welchen Vorteil hat dies gegenüber NAT ?
Ein Vorteil in meinen Fall wäre es, dass ich HTTPS-Anfragen und FTP-Verbindungen in den Log-Dateien von Squid protokollieren könnte, auch wenn dort natürlich nur der Hostname und die entsprechende Port-Nummer auftauchen wird. Die komplette URL ist ja verschlüsselt und für Squid nicht sichtbar.
Ich müsste dann nicht eine extra LOG-Regel mit IPTables für HTTPS anlegen. Und da ULOG und auch syslog-ng auf dem Zielsystem (Sun Sparc) nicht funktionieren will, bin ich auf den Standard-Syslogger angewiesen. Mit diesem ist es jedoch nicht möglich, eine separate LOG-Datei für IPTables anzulegen, da die Meldungen unter der Facility "kern" geloggt werden.
Jetzt hätte ich hier jedoch die Frage, wie man dies richtig konfiguriert. Ich habe es bis jetzt leider nicht zum Laufen gebracht oder irgendwas nicht richtig verstanden, wie dieses "Durchreichen" funktioniert.
Ich war bisher der Meinung, dass folgende zusätzliche Einträge in der /etc/squid/squid.conf reichen würden (ist nicht die Komplette Konfig, wenn benötigt reiche ich sie noch gerne nach) :
Des weiteren habe ich in etwa folgende IPTables-Regeln hinzugefügt:
HTTP ohne SSL funktioniert, sobald ich jedoch eine Anfrage auf eine verschlüsselte Seite absende, wartet der Browser einfach nur vergeblich auf eine Antwort. Auch in den Logs von Squid taucht die Anfrage überhaupt nicht auf, wie dies sonst bei den unverschlüsselten Anfragen der Fall ist.
Ich habe mir unter VMWare einmal IPCop installiert und den Squid über das Webinterface transparent konfiguriert. Hier funktioniert dann auch HTTPS und auch FTP. Ein Blick in die Log-Datei von Squid zeigt hier auch korrekt die Zugriffe auf die verschlüsselten Seiten.
Ein Vergleich der Squid-Konfiguration von IPCop und der Konfig, die ich auf der Debian-Maschine einsetze zeigte, dass beide fast identisch sind. Oder ist die Konfig-Datei für Squid bei IPCop in mehrer Stücke aufgeteilt? Ich habe nichts dergleichen finden können.
Deshalb vermute ich, dass ich die Firewall-Regeln noch nicht richtig ganz richtig habe.
Weiß jemand von Euch, was ich hier noch ändern bzw. korrigieren müsste.
Gruß focus_fahrer
ich habe auch das Problem mit einem transparenten Squid, dass ich darüber keine verschlüsselten Seiten aufrufen kann.
Da mein System bequem über APT mit Sicherheitsupdates versorgt werden soll, ohne ständig neukompiliert werden zu müssen, kommen für mich jedoch nur Binärpakete in Frage.
Wenn ich die erwähnte FAQ ( http://www.squid-cache.org/Doc/FAQ/FAQ-1.html#ss1.12) richtig verstanden habe, dann ist es nur dann erforderlich den Squid neu zu kompilieren, wenn man auch die verschlüsselten Daten cachen und evtl. filtern möchte.
Wenn man also nur ein "Durchreichen" durch die "CONNECT request"-Methode benötigt, wäre dies nicht erforderlich. Damit soll fast jedes beliebige Protokoll getunnelt werden können, also nicht nur HTTPS sondern z.B. auch FTP.
Liege ich damit richtig oder habe ich da etwas falsch verstanden ? Oder funktioniert dies nur wenn der Proxy nicht transparent arbeitet ?
Sollte es also so funktionieren, dass ich HTTPS und auch andere Protokolle mit dieser Methode transparent über den Squid "tunneln" kann, welchen Vorteil hat dies gegenüber NAT ?
Ein Vorteil in meinen Fall wäre es, dass ich HTTPS-Anfragen und FTP-Verbindungen in den Log-Dateien von Squid protokollieren könnte, auch wenn dort natürlich nur der Hostname und die entsprechende Port-Nummer auftauchen wird. Die komplette URL ist ja verschlüsselt und für Squid nicht sichtbar.
Ich müsste dann nicht eine extra LOG-Regel mit IPTables für HTTPS anlegen. Und da ULOG und auch syslog-ng auf dem Zielsystem (Sun Sparc) nicht funktionieren will, bin ich auf den Standard-Syslogger angewiesen. Mit diesem ist es jedoch nicht möglich, eine separate LOG-Datei für IPTables anzulegen, da die Meldungen unter der Facility "kern" geloggt werden.
Jetzt hätte ich hier jedoch die Frage, wie man dies richtig konfiguriert. Ich habe es bis jetzt leider nicht zum Laufen gebracht oder irgendwas nicht richtig verstanden, wie dieses "Durchreichen" funktioniert.
Ich war bisher der Meinung, dass folgende zusätzliche Einträge in der /etc/squid/squid.conf reichen würden (ist nicht die Komplette Konfig, wenn benötigt reiche ich sie noch gerne nach) :
Code: Alles auswählen
.
.
acl SSL_ports port 443 563
acl CONNECT method CONNECT
.
.
http_access allow CONNECT local_network
.
.
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
.
.
Code: Alles auswählen
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 3128
HTTP ohne SSL funktioniert, sobald ich jedoch eine Anfrage auf eine verschlüsselte Seite absende, wartet der Browser einfach nur vergeblich auf eine Antwort. Auch in den Logs von Squid taucht die Anfrage überhaupt nicht auf, wie dies sonst bei den unverschlüsselten Anfragen der Fall ist.
Ich habe mir unter VMWare einmal IPCop installiert und den Squid über das Webinterface transparent konfiguriert. Hier funktioniert dann auch HTTPS und auch FTP. Ein Blick in die Log-Datei von Squid zeigt hier auch korrekt die Zugriffe auf die verschlüsselten Seiten.
Ein Vergleich der Squid-Konfiguration von IPCop und der Konfig, die ich auf der Debian-Maschine einsetze zeigte, dass beide fast identisch sind. Oder ist die Konfig-Datei für Squid bei IPCop in mehrer Stücke aufgeteilt? Ich habe nichts dergleichen finden können.
Deshalb vermute ich, dass ich die Firewall-Regeln noch nicht richtig ganz richtig habe.
Weiß jemand von Euch, was ich hier noch ändern bzw. korrigieren müsste.
Gruß focus_fahrer
-
- Beiträge: 10
- Registriert: 20.07.2005 10:25:59
Hat ein bisserl gedauert, war ziemlich beschäftigt. Also:
HTTPS Verkehr muss man nicht umleiten, der squid lauscht auch auf port 443.
Und noch ein Auszug aus der squid.conf, mit ein paar für die Konfiguration eines transparenten Proxys mit HTTPS Weiterleitung relevanten (wie ich glaube) Parametern.
Die Daten werden nicht cached, sondern nur weitergereicht.... dann ist es nur dann erforderlich den Squid neu zu kompilieren, wenn man auch die verschlüsselten Daten cachen und evtl. filtern möchte.
Ja.Damit soll fast jedes beliebige Protokoll getunnelt werden können, ...
Transparenz ist dafür kein Kriterium, da dies ein Modus ist, in dem der Proxy arbeitet und nicht mit welchen Protokollen er arbeitet.Oder funktioniert dies nur wenn der Proxy nicht transparent arbeitet ?
Dass es wesentlich langsamer ist. NAT über iptables läuft im Kernel (space), der squid im userspace. Kernelprozesse werden beim Scheduling bevorzugt (~ so circa).... welchen Vorteil hat dies gegenüber NAT ?
Ja.... HTTPS-Anfragen und FTP-Verbindungen in den Log-Dateien von Squid protokollieren könnte
Code: Alles auswählen
# Transparent proxy
iptables -A PREROUTING -t nat -i "$INTIF" -p tcp -s "$INTNET" --dport 80 -j DNAT --to "$INTIP":3128
Code: Alles auswählen
https_port 443 cert=/usr/local/squid/etc/cert.pem
acl SSL_ports port 443 563
http_access deny CONNECT !SSL_ports
httpd_accel_host virtual
httpd_accel_with_proxy on
-
- Beiträge: 5
- Registriert: 07.02.2006 12:38:52
Hallo,
danke für deine Antwort, ich dachte schon ich hätte zu viel geschrieben und es hätte keiner Lust mir zu antworten.
Hier kann ich jedoch nichts mit https_port finden und dennoch funktioniert es, da ich die Seitenaufrufe in der access.log finde,
natürlich nur der Hostname und der Ziel-Port 443. Auch mit "netstat -an" konnte ich IPCOP keinen Port 443 entlocken.
Aber mir würde es ja genügen, wenn Squid einfach nur "Durchreicht" und dafür Log-Einträge schreibt.
Eine IPTables LOG-Regel wäre hier nicht so schön, da dies alles in /var/log/messages landet, mit vielen anderen Einträgen...
Ist es damit nicht möglich den Squid als "richtigen" Man-in-the-middle zu betreiben, also dass dieser die Seitenaufrufe komplett
mitlesen kann. Auch nur so macht es Sinn, dass man auf dem Squid ein Zertifikat installieren muß, so wäre in diesem
Fall zwischen dem Browser und dem Proxy eine verschlüsselte Verbindung und eine weitere verschlüsselte Verbindung
zwischen Proxy und Webserver. Der Proxy "intern" würde die HTTP-Anfragen dann jedoch ganz normal verarbeiten.
(HTTPS-Requests und -Responses sind ja eigentlich ganz normale HTTP-Requests und HTTP-Responses,
welche jedoch über eine SSL/TLS-Verbindung getunnelt werden.
Ich dachte mit dem neukompilierten Squid wäre ähnliches möglich, wie dies mit Cyberguard Webwasher machbar sein soll:
http://www.cyberguard.com/products/webw ... lang=de_DE
dem Port 443 über "https_port 443" lauschen zu lassen ?
Gruß focus_fahrer
danke für deine Antwort, ich dachte schon ich hätte zu viel geschrieben und es hätte keiner Lust mir zu antworten.
ich konnte es noch nicht richtig testen, also auf der Debian-Maschine, aber ich habe mir unter vmware nochmals IPCOP angeschaut.hellospencer hat geschrieben: https_port 443 cert=/usr/local/squid/etc/cert.pem
Hier kann ich jedoch nichts mit https_port finden und dennoch funktioniert es, da ich die Seitenaufrufe in der access.log finde,
natürlich nur der Hostname und der Ziel-Port 443. Auch mit "netstat -an" konnte ich IPCOP keinen Port 443 entlocken.
Aber mir würde es ja genügen, wenn Squid einfach nur "Durchreicht" und dafür Log-Einträge schreibt.
Eine IPTables LOG-Regel wäre hier nicht so schön, da dies alles in /var/log/messages landet, mit vielen anderen Einträgen...
Also irgendwie hab ich das anders verstanden, wenn man es über https_port verwendet.hellospencer hat geschrieben: Die Daten werden nicht cached, sondern nur weitergereicht.
Ist es damit nicht möglich den Squid als "richtigen" Man-in-the-middle zu betreiben, also dass dieser die Seitenaufrufe komplett
mitlesen kann. Auch nur so macht es Sinn, dass man auf dem Squid ein Zertifikat installieren muß, so wäre in diesem
Fall zwischen dem Browser und dem Proxy eine verschlüsselte Verbindung und eine weitere verschlüsselte Verbindung
zwischen Proxy und Webserver. Der Proxy "intern" würde die HTTP-Anfragen dann jedoch ganz normal verarbeiten.
(HTTPS-Requests und -Responses sind ja eigentlich ganz normale HTTP-Requests und HTTP-Responses,
welche jedoch über eine SSL/TLS-Verbindung getunnelt werden.
Ich dachte mit dem neukompilierten Squid wäre ähnliches möglich, wie dies mit Cyberguard Webwasher machbar sein soll:
http://www.cyberguard.com/products/webw ... lang=de_DE
Sind es nicht doch zwei verschiedene Dinge, https über die "CONNECT-Methode" über den Proxy zu übertragen oder den Proxy aufhellospencer hat geschrieben: acl SSL_ports port 443 563
http_access deny CONNECT !SSL_ports
dem Port 443 über "https_port 443" lauschen zu lassen ?
Gruß focus_fahrer
-
- Beiträge: 5
- Registriert: 07.02.2006 12:38:52
Hallo,
um das Thema nochmals aufzugreifen:
Laut der FAQ auf der offiziellen Squid-Seite gibt es 2 verschiedene Möglichkeiten, wie mit SSL-verschlüsseltem Datenverkehr umgegangen werden kann. Unter dem Link http://www.squid-cache.org/Doc/FAQ/FAQ-1.html#ss1.12 ist dies zu finden.
Hier ein Auszug über die erste Variante:
Leider habe ich hier nichts näheres und verbindliches gefunden.
Eigentlich sollte dem nicht so sein, dass man neu kompilieren müsste, da dies mit der älteren Version 2.3 offensichtlich auch direkt unterstützt wurde. Siehe:
http://wiki.squid-cache.org/SquidFaq/Tr ... 4076ffdcb6
Siehe auch die Liste mit den verschiedenen Request-Methoden:
http://wiki.squid-cache.org/SquidFaq/Sq ... 476978681a
Weitere Informationen sind auch in der im Wiki enthaltenen neuen FAQ enthalten:
http://wiki.squid-cache.org/SquidFaq/Tr ... a711639d62
Gruß focus_fahrer
Edit: Noch zwei Links auf das Wiki hinzugefügt
um das Thema nochmals aufzugreifen:
Laut der FAQ auf der offiziellen Squid-Seite gibt es 2 verschiedene Möglichkeiten, wie mit SSL-verschlüsseltem Datenverkehr umgegangen werden kann. Unter dem Link http://www.squid-cache.org/Doc/FAQ/FAQ-1.html#ss1.12 ist dies zu finden.
Hier ein Auszug über die erste Variante:
Und hier die zweite Variante mit der "CONNECT request"-Methode:As of version 2.5, Squid can terminate SSL connections. This is perhaps only useful in a surrogate (http accelerator) configuration. You must run configure with --enable-ssl. See https_port in squid.conf for more information.
Muß man nun für diese 2.Variante Squid auch neu kompilieren, so dass dieser auf einem zweiten Port lauscht ? Dann wäre wahrscheinlich auch wiederum eine IPTables-Regel notwendig, die alle Anfragen mit Ziel-Port 443 an diesen HTTPS-Port von Squid umlenken.Squid also supports these encrypted protocols by ``tunelling'' traffic between clients and servers. In this case, Squid can relay the encrypted bits between a client and a server.
Normally, when your browser comes across an https URL, it does one of two things:
The browser opens an SSL connection directly to the origin server.
The browser tunnels the request through Squid with the CONNECT request method.
The CONNECT method is a way to tunnel any kind of connection through an HTTP proxy. The proxy doesn't understand or interpret the contents. It just passes bytes back and forth between the client and server.
Leider habe ich hier nichts näheres und verbindliches gefunden.
Eigentlich sollte dem nicht so sein, dass man neu kompilieren müsste, da dies mit der älteren Version 2.3 offensichtlich auch direkt unterstützt wurde. Siehe:
http://wiki.squid-cache.org/SquidFaq/Tr ... 4076ffdcb6
Siehe auch die Liste mit den verschiedenen Request-Methoden:
http://wiki.squid-cache.org/SquidFaq/Sq ... 476978681a
Weitere Informationen sind auch in der im Wiki enthaltenen neuen FAQ enthalten:
http://wiki.squid-cache.org/SquidFaq/Tr ... a711639d62
Gruß focus_fahrer
Edit: Noch zwei Links auf das Wiki hinzugefügt