Transparenter Squid und https-Seiten ?!?!?

Gemeinsam ins Internet mit Firewall und Proxy.
Antworten
schmalzz
Beiträge: 102
Registriert: 02.07.2003 08:07:29

Transparenter Squid und https-Seiten ?!?!?

Beitrag von schmalzz » 13.04.2006 21:28:42

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
=============================
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 :-) )

Benutzeravatar
Cloonix
Beiträge: 589
Registriert: 20.11.2004 10:42:24
Wohnort: München
Kontaktdaten:

Beitrag von Cloonix » 14.04.2006 09:34:41

Morgen,
Squid as a Transparent Proxy
Important

This section gives instructions for transparent proxying of HTTP. HTTPS (normally TCP port 443) cannot be proxied transparently (stop and think about it for a minute; if HTTPS could be transparently proxied, then how secure would it be?).
mfG
proud to be 100% M$ free (except X300T)
http://claus.freakempire.de
http://debian.freakempire.de

schmalzz
Beiträge: 102
Registriert: 02.07.2003 08:07:29

Beitrag von schmalzz » 14.04.2006 15:28:31

Hi,

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

hellospencer
Beiträge: 10
Registriert: 20.07.2005 10:25:59

Beitrag von hellospencer » 26.04.2006 19:30:07

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.
http://www.squid-cache.org/Doc/FAQ/FAQ-1.html#ss1.12

Hast Du einen so konfiguierten squid laufen?

schmalzz
Beiträge: 102
Registriert: 02.07.2003 08:07:29

Beitrag von schmalzz » 27.04.2006 07:56:12

Hm,

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

schmalzz
Beiträge: 102
Registriert: 02.07.2003 08:07:29

Beitrag von schmalzz » 27.04.2006 22:28:01

hellospencer hat geschrieben:
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.
http://www.squid-cache.org/Doc/FAQ/FAQ-1.html#ss1.12

Hast Du einen so konfiguierten squid laufen?
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.

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

hellospencer
Beiträge: 10
Registriert: 20.07.2005 10:25:59

Beitrag von hellospencer » 28.04.2006 14:57:56

Das wär genau die Lösung, die du suchst:
Squid würde den https einfach "durchreichen" (können).
Der squid kann das. So gesehen ist er "the man in the middle".

Gruss

schmalzz
Beiträge: 102
Registriert: 02.07.2003 08:07:29

Beitrag von schmalzz » 29.04.2006 23:38:16

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

focus_fahrer
Beiträge: 5
Registriert: 07.02.2006 12:38:52

Beitrag von focus_fahrer » 01.05.2006 00:29:37

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

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
.
.
Des weiteren habe ich in etwa folgende IPTables-Regeln hinzugefügt:

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

hellospencer
Beiträge: 10
Registriert: 20.07.2005 10:25:59

Beitrag von hellospencer » 19.05.2006 13:37:03

Hat ein bisserl gedauert, war ziemlich beschäftigt. Also:
... dann ist es nur dann erforderlich den Squid neu zu kompilieren, wenn man auch die verschlüsselten Daten cachen und evtl. filtern möchte.
Die Daten werden nicht cached, sondern nur weitergereicht.
Damit soll fast jedes beliebige Protokoll getunnelt werden können, ...
Ja.
Oder funktioniert dies nur wenn der Proxy nicht transparent arbeitet ?
Transparenz ist dafür kein Kriterium, da dies ein Modus ist, in dem der Proxy arbeitet und nicht mit welchen Protokollen er arbeitet.
... welchen Vorteil hat dies gegenüber NAT ?
Dass es wesentlich langsamer ist. NAT über iptables läuft im Kernel (space), der squid im userspace. Kernelprozesse werden beim Scheduling bevorzugt (~ so circa).
... HTTPS-Anfragen und FTP-Verbindungen in den Log-Dateien von Squid protokollieren könnte
Ja.

Code: Alles auswählen

# Transparent proxy
iptables -A PREROUTING -t nat -i "$INTIF" -p tcp -s "$INTNET" --dport 80 -j DNAT --to "$INTIP":3128
HTTPS Verkehr muss man nicht umleiten, der squid lauscht auch auf port 443.

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

focus_fahrer
Beiträge: 5
Registriert: 07.02.2006 12:38:52

Beitrag von focus_fahrer » 22.05.2006 15:14:47

Hallo,

danke für deine Antwort, ich dachte schon ich hätte zu viel geschrieben und es hätte keiner Lust mir zu antworten.
hellospencer hat geschrieben: https_port 443 cert=/usr/local/squid/etc/cert.pem
ich konnte es noch nicht richtig testen, also auf der Debian-Maschine, aber ich habe mir unter vmware nochmals IPCOP angeschaut.
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...
hellospencer hat geschrieben: Die Daten werden nicht cached, sondern nur weitergereicht.
Also irgendwie hab ich das anders verstanden, wenn man es über https_port verwendet.

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
hellospencer hat geschrieben: acl SSL_ports port 443 563
http_access deny CONNECT !SSL_ports
Sind es nicht doch zwei verschiedene Dinge, https über die "CONNECT-Methode" über den Proxy zu übertragen oder den Proxy auf
dem Port 443 über "https_port 443" lauschen zu lassen ?

Gruß focus_fahrer

focus_fahrer
Beiträge: 5
Registriert: 07.02.2006 12:38:52

Beitrag von focus_fahrer » 30.05.2006 14:08:44

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:
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.
Und hier die zweite Variante mit der "CONNECT request"-Methode:
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.
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.
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

Antworten