misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
VolkerRaschek schrieb: Okay verstanden, das ist ziemlich schade. Kann man dann grundsätzlich davon ausgehen, dass getunnelte Verbindungen über SSL nicht gecacht sondern nur unterbunden werden können?
Ich bin mir nicht sicher, ob ich die Frage verstanden habe: Grundsätzlich können nur HTTP-Anfragen vom Proxy gecached werden. HTTPS kann aus offensichtlichen Gründen nicht gecached werden. Es sei denn natürlich du machst SSL-Interception.
|
VolkerRaschek
(Themenstarter)
Anmeldungsdatum: 19. August 2014
Beiträge: 358
Wohnort: Eifel
|
misterunknown schrieb: Es sei denn natürlich du machst SSL-Interception.
Ich habe mir den Artikel mal durch gelesen. Ich habe ehrlich gesagt nicht alles verstanden, wie das funktionieren bzw. die die Vorgehensweise sein soll.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
VolkerRaschek schrieb: Ich habe mir den Artikel mal durch gelesen. Ich habe ehrlich gesagt nicht alles verstanden, wie das funktionieren bzw. die die Vorgehensweise sein soll.
Die Theorie ist ganz einfach: Wenn der Client eine HTTPS-Verbindung aufbauen will, fragt er den Proxy an, dieser wiederum initiiert seinerseits eine HTTPS-Verbindung zum eigentlichen Webserver. Da der Proxy den Request nicht nur "durchleitet", sondern einen "neuen" Request schickt, kann er die vom Webserver erhaltenen Informationen sehen und auch Cachen. Dem Client liefert er den Inhalt dann über die ursprüngliche HTTPS-Verbindung aus. Für letztere verwendet der Proxy ein selbstsigniertes Zertifikat. Dem muss der Client natürlich vertrauen, sonst merkt er, dass die SSL-Verbindung nicht zum erwarteten Ziel geht.
|
VolkerRaschek
(Themenstarter)
Anmeldungsdatum: 19. August 2014
Beiträge: 358
Wohnort: Eifel
|
misterunknown schrieb: Die Theorie ist ganz einfach.
Ja wohl, das ist es wirklich. Also interessieren einen Squid mit dem Verfahren auf zu bauen hätte ich schon. Ich will den Squid Server nicht schwer irgendwo einsetzen, der steht in meiner VM falls jetzt irgendwelche Andeutungen auf Mitschnitte von SSL-Verbindungen kommen. Nun stelle ich mir allerdings gerade die Frage, ob es überhaupt möglich ist mit der squid Version aus den Paketquellen so einen Proxy auf zu setzen. Nicht das da beim build die Optionen wie SSL fehlen. Auf der Verlinktenseite wird ja geschrieben, dass der Server mit den folgenden Optionen installiert werden sollte. Squid must be built with: ./configure --with-openssl --enable-ssl-crtd
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
VolkerRaschek schrieb: Nun stelle ich mir allerdings gerade die Frage, ob es überhaupt möglich ist mit der squid Version aus den Paketquellen so einen Proxy auf zu setzen. Nicht das da beim build die Optionen wie SSL fehlen. Auf der Verlinktenseite wird ja geschrieben, dass der Server mit den folgenden Optionen installiert werden sollte.
Also ich gehe davon aus, dass du für diesen Fall den Squid selbst bauen müsstest (oder wahlweise selbst paketieren). Ich kann hier zwar nur auf einem Debian-System gucken, aber hier fehlen beide benötigten Optionen; bei Ubuntu wird das nicht anders sein.
|
VolkerRaschek
(Themenstarter)
Anmeldungsdatum: 19. August 2014
Beiträge: 358
Wohnort: Eifel
|
Okay, ich hab mir das gerade mal angeschaut. Ich mag mir den jetzigen Proxy nicht gerne kaputt machen. Ich habe dafür eine neue VM angelegt in der ich den Squid zusammen bauen muss. Grundsätzlich muss ich sagen, dass ich mit dem Zusammenbauen von Paketen keine Erfahrung habe, ich habe bisher immer Pakete aus den Quellen oder anderen PPA's installiert. Ich habe die Squid-Version 3.5.20 heruntergeladen und habe vor den Squid mit folgenden Optionen zu installieren.
--prefix=/usr \
--localstatedir=/var \
--libexecdir=${prefix}/lib/squid \
--datadir=${prefix}/share/squid \
--sysconfdir=/etc/squid \
--with-default-user=proxy \
--with-logdir=/var/log/squid \
--with-pidfile=/var/run/squid.pid \
--with-openssl \
--enable-ssl-crtd \ Nun fällt mir ein, dass die Direktive https_port ja nicht funktioniert. Ist die Funktion mit --with-openssl enthalten?
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
VolkerRaschek schrieb: Ich habe die Squid-Version 3.5.20 heruntergeladen und habe vor den Squid mit folgenden Optionen zu installieren.
--prefix=/usr \
--localstatedir=/var \
--libexecdir=${prefix}/lib/squid \
--datadir=${prefix}/share/squid \
--sysconfdir=/etc/squid \
--with-default-user=proxy \
--with-logdir=/var/log/squid \
--with-pidfile=/var/run/squid.pid \
--with-openssl \
--enable-ssl-crtd \
Nun fällt mir ein, dass die Direktive https_port ja nicht funktioniert. Ist die Funktion mit --with-openssl enthalten?
Nein, meines Wissens muss die Option --enable-ssl heißen. Die brauchst du aber nicht unbedingt, wenn du nur SSL-Interception machen willst, weil das geht ja auch über Port 3128. Es schadet aber auch nicht, den Squid3 damit zu bauen, dann kannst du später auch noch https_port testen.
|
VolkerRaschek
(Themenstarter)
Anmeldungsdatum: 19. August 2014
Beiträge: 358
Wohnort: Eifel
|
Okay,
ich hab das jetzt mal laufen lassen.
Ich musste schon einige Pakete nach installieren weil er bei "make all" immer gemekert hat. Ich hänge bei folgendem Fehler. | ./configure: line 7788: AC_ENABLE_SHARED: command not found
./configure: line 7794: syntax error near unexpected token `2.2'
./configure: line 7794: `LT_PREREQ(2.2)'
Makefile:542: recipe for target 'config.status' failed
make: *** [config.status] Error 2
|
Leider weiß ich absolut nicht, was für ein Paket ect ich herunterladen muss oder was ihm da genau fehlt.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
Ich bin da auch grade nicht so firm drin, ich denke aber, dass "AC_ENABLE_SHARED" irgendwas mit autoconf zu tun hat. Du solltest alle Abhängigkeiten so nachinstallieren können:
apt-get install automake
Das Paket sollte alle Abhängigkeiten mitbringen.
|
VolkerRaschek
(Themenstarter)
Anmeldungsdatum: 19. August 2014
Beiträge: 358
Wohnort: Eifel
|
misterunknown schrieb: Ich bin da auch grade nicht so firm drin, ich denke aber, dass "AC_ENABLE_SHARED" irgendwas mit autoconf zu tun hat. Du solltest alle Abhängigkeiten so nachinstallieren können:
apt-get install automake
Das Paket sollte alle Abhängigkeiten mitbringen.
Ja, das hat es auch. Ich habe am Wochenende squid installieren können. Unter /etc/sbin liegt die Datei squid.
root@proxy3:/usr/sbin# ls -la squid
-rwxr-xr-x 1 root root 56268968 Aug 26 17:34 squid Ich versuche squid mit
/usr/sbin/squid start
zu starten, aber der prompt kommt direkt wieder zurück. Ich bekomme keine Ausgabe, ob der Dienst nun gestartet ist oder nicht. Im syslog steht folgendes
Aug 31 09:49:47 proxy3 squid[703]: Squid Parent: will start 1 kids
Aug 31 09:49:47 proxy3 squid[703]: Squid Parent: (squid-1) process 705 started Die Prozesse laufen anscheinend.
root@proxy3:/usr/sbin# ps aux | grep proxy
proxy 705 0.0 2.3 85120 23992 ? S 09:49 0:00 (squid-1) start
proxy 706 0.0 0.1 21100 1632 ? S 09:49 0:00 (logfile-daemon) /var/log/squid/access.log Nur wie kann ich den Proxy steuern?
service squid start | restart | stop
Funktionieren nicht.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
VolkerRaschek schrieb: Ich versuche squid mit
/usr/sbin/squid start
zu starten, aber der prompt kommt direkt wieder zurück. Ich bekomme keine Ausgabe, ob der Dienst nun gestartet ist oder nicht.
Erstmal: Wenn du squid einfach als Binary startest, brauchst du das Argument "start" nicht. Das ignoriert er schlichtweg. Der Prozess startet als Dienst, das heißt der Befehl kehrt direkt wieder zurück, im Hintergrund läuft der Squid-Prozess aber weiter und tut seinen Dienst. Im syslog steht folgendes
Aug 31 09:49:47 proxy3 squid[703]: Squid Parent: will start 1 kids
Aug 31 09:49:47 proxy3 squid[703]: Squid Parent: (squid-1) process 705 started
Genau. Er informiert dich, dass ein Kindprozess gestartet wurde und mit welcher PID.
Nur wie kann ich den Proxy steuern?
service squid start | restart | stop
Funktionieren nicht.
Richtig. Wenn du eine Software per Hand kompilierst und installierst, gibt es erstmal keine so komfortablen Tools, als wenn es aus einer Distribution kommt. Daher kannst du den Prozess grundsätzlich erstmal nur killen (kill) und starten. Später kannst du dir noch ein Init-Skript bzw. ein systemd.target schreiben, womit du dann auch die üblichen Befehle (/etc/init.d/squid {start,stop,restart}, bzw. systemctl start squid) nutzen kannst. Du kannst dich auch aus den Vorlagen der Distri-Pakete bedienen.
|
VolkerRaschek
(Themenstarter)
Anmeldungsdatum: 19. August 2014
Beiträge: 358
Wohnort: Eifel
|
Okay, dass kann ich später ja noch einpflegen.
Grundsätzlich geht es mir um die Umsetzung von dem squid mit SSL Bumbing. Ich habe den Code von der Wiki-Seite übernommen und der squid.conf hinzugefügt. Der Client nutzt nun proxy3 für die Verbindung ins Internet. Die Zertifikate habe ich extra generiert und das Root-Zertifikat der CA im Browser importiert. Trotzdem erhalte ich die Fehlermeldung. Diese Verbindung ist nicht sicher
Der Inhaber von www.google.de hat die Website nicht richtig konfiguriert.
Firefox hat keine Verbindung mit dieser Website aufgebaut, um Ihre Informationen vor Diebstahl zu schützen.
Diese Website verwendet HTTP Strict Transport Security (HSTS), um mitzuteilen,
dass Firefox nur über gesicherte Verbindungen mit ihr kommunizieren soll.
Daher ist es nicht möglich, eine Ausnahme für dieses Zertifikat anzulegen.
www.google.de uses an invalid security certificate.
The certificate is only valid for the following names:
proxy3.example.local, proxy3, 10.1.1.32
Ich kann die Fehlermeldung insoweit nachvollziehen, dass der Name proxy3.example.local nicht mit google.com übereinstimmt und die Fehlermeldung kommt. Doch wie müsste das Zertifikat aussehen, damit es allgemein gültig ist? Hier mal squid.conf für Verbesserungsvorschläge.
#
# Recommended minimum configuration:
#
# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7 # RFC 4193 local private network range
acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
#
# Recommended minimum Access Permission configuration:
#
# Deny requests to certain unsafe ports
http_access deny !Safe_ports
# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports
# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager
# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
#http_access deny to_localhost
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
always_direct allow all
acl broken_sites dstdomain .google.com
ssl_bump none broken_sites
ssl_bump client-first all
# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localnet
http_access allow localhost
# And finally deny all other access to this proxy
http_access deny all
# Squid normally listens to port 3128
http_port 3128 ssl-bump cert=/etc/ssl/public/proxy3.crt \
key=/etc/ssl/public/proxy3.key \
options=NO_SSLv3,NO_TLSv1_2,NO_TLSv1_1 \
cipher=ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS \
cafile=/etc/ssl/public/ca.crt
# Uncomment and adjust the following to add a disk cache directory.
#cache_dir ufs /var/cache/squid 100 16 256
# Leave coredumps in the first cache dir
coredump_dir /var/cache/squid
#
# Add any of your own refresh_pattern entries above these.
#
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
Gruß
Volker
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
VolkerRaschek schrieb: Ich kann die Fehlermeldung insoweit nachvollziehen, dass der Name proxy3.example.local nicht mit google.com übereinstimmt und die Fehlermeldung kommt. Doch wie müsste das Zertifikat aussehen, damit es allgemein gültig ist?
Also ich habe sowas selbst noch nicht gemacht, daher kann ich dir nur mit Erfahrung/Hörensagen/Educated Guessing (😬) helfen. Aus meiner Sicht hast du 2 Möglichkeiten:
Du kannst ein Wildcard-Wildcard-Zertifikat erstellen, welches auf alle Namen hört. Dazu musst du wissen, dass das Wildcard-Zeichen * nicht auf Punkte matched. Das heißt dein Zertifikat müsste auf den Name *, *.* und *.*.* hören, je nachdem wie viele Subdomain-Level du unterstützen willst. Dazu brauchst du ein Multidomain-Zertifikat. die SSL-Zertifikate dynamisch erzeugen
Hier mal squid.conf für Verbesserungsvorschläge.
# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
#http_access deny to_localhost
Wenn du keinen guten Grund hast, auch Zugriffe auf localhost zuzulassen, würde ich es generell verbieten. Ich weiß ja nicht, welche Dienste noch auf deinem Proxy-Server laufen, aber oftmals ist es ja so, dass man für localhost die Zugriffsbeschränkungen etwas laxer einstellt. Daher sollte man da mit dem Proxy keine "Brücke" zwischen lokalem und nicht-lokalem Verkehr bauen. Ansonsten fällt mir nichts ins Auge.
|