ubuntuusers.de

Squid/SquidGuard mit HTTPS

Status: Ungelöst | Ubuntu-Version: Ubuntu 17.10 (Artful Aardvark)
Antworten |

Moderich

Anmeldungsdatum:
20. September 2008

Beiträge: 20

Hallo zusammen!

Ich habe da mal eine kleine Frage: ich versuche gerade einen transparenten Proxy mit Squid u.a. als Contentfilter mit Squidguard für mein Heimnetzwerk aufzusetzen. Das funktioniert soweit ganz gut für unverschlüsselte Verbindungen (HTTP), für HTTPS habe ich allerdings so meine Probleme. Einige Seiten können ohne Probleme aufgerufen werden (wenn ich mir die Chain of Trust anschaue ist das von mir erstellte Zertifikat involviert), aber für die meisten Seiten liefert mir Firefox

SSL_ERROR_BAD_CERT_DOMAIN

zurück. Wenn ich das Ganze mit Konquerer mache und die Warnung akzeptiere bekomme ich dort

Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)

. Meine erste Vermutung wäre Public Key Pinning, aber das ist nur so ein Schuß ins Dunkle...

Die eigentliche Frage ist jetzt ja eigentlich ob es generell möglich ist einen Contentfilter auf diese Weise zu realisieren? Auch nach vielrumgooglen konnte ich bis jetzt keine befriedigende Antwort finden ☹. Prinzipiell sollte Squid ja dies unterstützen...Was fehlt mir also noch? Eigentlich bin ich ja nicht wirklich an den Inhalten interessiert; die Filterung nach URLs über Blacklists reicht ja schon (Squidguard).

Vielen Dank schonmal!!

P.S.: hier meine squid.conf:

acl localnet src 192.168.1.0/24	
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

http_access deny !Safe_ports

http_access deny CONNECT !SSL_ports

http_access allow localhost manager
http_access deny manager

http_access allow localnet
http_access allow localhost

http_access deny all

http_port 3129 intercept

https_port 3130 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/home/test/squid.pem

ssl_bump none localhost
ssl_bump server-first all

sslproxy_flags DONT_VERIFY_PEER

sslproxy_cert_error allow all

cache_peer localhost parent 8118 7 no-query default

coredump_dir /var/spool/squid3

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

via on

always_direct allow all

forwarded_for on

url_rewrite_program /usr/bin/squidGuard -c /etc/squidguard/squidGuard.conf
url_rewrite_children 5

sebix Team-Icon

Moderator, Webteam

Anmeldungsdatum:
14. April 2009

Beiträge: 5582

Moderich schrieb:

Einige Seiten können ohne Probleme aufgerufen werden (wenn ich mir die Chain of Trust anschaue ist das von mir erstellte Zertifikat involviert), aber für die meisten Seiten liefert mir Firefox

SSL_ERROR_BAD_CERT_DOMAIN

zurück.

Fuer welche Domain ist denn das Zertifikat ausgestellt?

Wenn ich das Ganze mit Konquerer mache und die Warnung akzeptiere bekomme ich dort

Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)

.

Kommt die Meldung von Squid?

Moderich

(Themenstarter)

Anmeldungsdatum:
20. September 2008

Beiträge: 20

sebix schrieb:

Fuer welche Domain ist denn das Zertifikat ausgestellt?

Meine Domain ist mein.netz; das Zertifikat wurde auf proxy.mein.netz ausgestellt (ist ja schon mal falsch wenn ich so drüber nachdenk 😳).

sebix schrieb:

Kommt die Meldung von Squid?

Wenn ich die Meldung richtig interpretiere sollte sie doch von Squid kommen, oder?

Aber ich sinniere doch schon die ganze Zeit darüber ob das Ganze funktionieren kann...Über Squid mit TLS-bumping mit eigenem Zertifikat verliere ich doch die Möglichkeit die Gültigkeit der "richtigen" Zertifikate zu überprüfen. Falls es doch so funktioniert bekomme ich doch Probleme mit HPKP denke ich mal. Ich glaube mich entsinnen zu können mit transparenten Proxies geht das Ganze sowieso nicht, da diese alles bis auf HTTP durchtunneln, allerdings bin ich mir nicht ganz sicher ob das mit Squid wirklich der Fall ist. Wenn ich Squid nicht als transparenten Proxy konfiguriere muss ich den Proxy ja im Browser angeben; dort kann ich aber jeden beliebigen öffentlichen Proxy angeben und somit den Contentfilter wieder aushebeln.

Wie kann man dieses Dilemma nun lösen? Ich denke mal z.B. Schulen etc. sollten doch sicherlich dieselbe Fragestellung haben wie ich, und ich denke mal dass sie das (hoffentlich) irgendwie gelöst haben (ich weiß, das widerläuft der Idee von TLS, aber bei meinem kleinen Heimnetzwerk will ich ja keine sensiblen Daten ausspähen...von daher würds ja wie gesagt reichen die URL zu filtern...)

sebix Team-Icon

Moderator, Webteam

Anmeldungsdatum:
14. April 2009

Beiträge: 5582

Moderich schrieb:

sebix schrieb:

Fuer welche Domain ist denn das Zertifikat ausgestellt?

Meine Domain ist mein.netz; das Zertifikat wurde auf proxy.mein.netz ausgestellt

Und die Browser beschweren sich darueber, dass proxy.mein.netz ungleich der Domain ist, die du ansurfst. Ist ihre Aufgabe ☺

Wenn du das richtig machen willst, musst du fuer den Proxy eine CA erstellen, der alle Clients vertrauen und der Proxy erstellt dann Zertifikate fuer die aufgerufenen Domains, unterschrieben mit der CA. Damit vertrauen alle Clients, die dieser eigene CA vertrauen, auch diesen Zertifikaten.

sebix schrieb: Über Squid mit TLS-bumping mit eigenem Zertifikat verliere ich doch die Möglichkeit die Gültigkeit der "richtigen" Zertifikate zu überprüfen.

Ja, das muss nun der Proxy alleine machen.

Falls es doch so funktioniert bekomme ich doch Probleme mit HPKP denke ich mal.

Ja.

Wenn ich Squid nicht als transparenten Proxy konfiguriere muss ich den Proxy ja im Browser angeben; dort kann ich aber jeden beliebigen öffentlichen Proxy angeben und somit den Contentfilter wieder aushebeln.

Wenn du das in deinem Netzwerk nicht verboten hast schon.

Moderich

(Themenstarter)

Anmeldungsdatum:
20. September 2008

Beiträge: 20

sebix schrieb:

Moderich schrieb:

sebix schrieb:

Fuer welche Domain ist denn das Zertifikat ausgestellt?

Meine Domain ist mein.netz; das Zertifikat wurde auf proxy.mein.netz ausgestellt

Und die Browser beschweren sich darueber, dass proxy.mein.netz ungleich der Domain ist, die du ansurfst. Ist ihre Aufgabe ☺

Hm, irgendwie sollte das doch stimmen, da sich doch der Browser nur mit dem Proxy verbindet und dies somit die einige mögliche Domain ist, oder? Das dazugehörige Zertifikat habe ich erstellt und importiert; der Browser nörgelt da wie gesagt bei einigen Seiten auch nicht rum.

Moderich schrieb:

Über Squid mit TLS-bumping mit eigenem Zertifikat verliere ich doch die Möglichkeit die Gültigkeit der "richtigen" Zertifikate zu überprüfen.

sebix schrieb: Ja, das muss nun der Proxy alleine machen.

Welche Möglichkeiten gibt es da? Liefert Squid soetwas mit? Muss mich da mal in die Dokumentation einlesen...Firefox und Konsorten haben doch schon vordefinierte Zertifizierungstellen; die müsste ich doch dann dem Proxy auch bekanntmachen und ihn dazu bringen diese auch zu benutzen...

Moderich schrieb:

Falls es doch so funktioniert bekomme ich doch Probleme mit HPKP denke ich mal.

sebix schrieb: Ja.

Soweit ich das Prinzip verstanden habe merkt sich der Browser doch bei der ersten Verbindung mit der jeweiligen Seite das dazugehörige Zertifikat und überprüft es bei jedem weiteren Besuch ob es noch dasselbe ist. Mit TLS-bumping wird ja dann ein anderes Zertifikat verwendet, was ja da auch beabsichtigt ist. Ich müsste also den Browser dazubringen sämtliche zugeordneten Zertifikate zu "vergessen", damit er das von mir erzeugte Zertifikat als das korrekte akzeptiert, oder?

Moderich schrieb:

Wenn ich Squid nicht als transparenten Proxy konfiguriere muss ich den Proxy ja im Browser angeben; dort kann ich aber jeden beliebigen öffentlichen Proxy angeben und somit den Contentfilter wieder aushebeln.

sebix schrieb: Wenn du das in deinem Netzwerk nicht verboten hast schon.

Das immerhin ist ja mit der Firewall einfach zu beheben ☺

encbladexp Team-Icon

Ehemaliger
Avatar von encbladexp

Anmeldungsdatum:
16. Februar 2007

Beiträge: 17521

Um es kurz zu machen: Transparente Proxies, welche aus HTTPS machen sollen, sind ein Todes Pferd.

Man rollt eigene CAs aus, und scheitert dann relativ regelmäßig an Clients die kein SNI sprechen (soll es geben) oder die Zertifikate sehr genau prüfen (HPKP, Certificate Transparency, OSCP…).

mfg Stefan

Moderich

(Themenstarter)

Anmeldungsdatum:
20. September 2008

Beiträge: 20

Gibt es denn dann überhaupt eine Möglichkeit einen Content-Filter für HTTPS zu realisieren? Evtl. Client-seitig? Wie gesagt, eigentlich geht es ja nur um eine URL-Filterung. Die verschlüsselten Pakete müssen ja auch wissen wohin sie müssen; diese Information kann doch schwierig verschlüsselt übermittelt werden, oder? Oder sehe ich da schon wieder irgendwas zu einfach? Falls ja, zumindest beim Schlüsselaustausch sollte die Verbindung ja noch unverschlüsselt sein;da sollte man doch nach der Adresse filtern können..?

encbladexp Team-Icon

Ehemaliger
Avatar von encbladexp

Anmeldungsdatum:
16. Februar 2007

Beiträge: 17521

Auf dem Client, also in Form einer Browser / Anwendungserweiterung kann man so ziemlich alles realisieren, praktikabel ist das nicht. Es hat schon seinen Grund warum Virenscanner und andere "Sicherheitssoftware" den Aufwand betreibt eigene CAs auf den Client zu implementieren, um dann an den unverschlüsselten Traffic zu kommen.

Im Endeffekt ist jede Art von Contentfilter auch automatisch ein Eingriff in die Sicherheit der Anwendung, dem Wunsch des Anwenders nicht zensiert / eingeschränkt zu werden und dementsprechend ein Angriff auf dessen Sicherheitswunsch.

Gleichzeitig sind, vor allem durch Lets Encrypt, die Kosten für HTTPS bzw. SSL/TLS im allgemeinen Weggefallen.

Effektiv macht dein Browser eine Namensauflösung, also z.B. domain.tld ▶ 1.2.3.4 und öffnet dann ein TCP Socket auf 1.2.3.4 Port 443. Unverschlüsselt wird per SNI das Wunschziel mitgeteilt, ohne SNI (es gibt noch alte Software!) ist in der Anfrage die lesbar Übertragen wird keine Domain Information. Das ist der Grund warum mit Fake CAs gearbeitet wird, welche jedem Client bekannt sein müssen. Denn so kannst du an deiner "Sicherheitssoftware" das SSL/TLS sauber selbst terminieren, und dann die Verbindung zum Ziel aufbauen.

tl;dr: Du musst mit einer Fake CA arbeiten. Wie lange das bei modernen Anwendungen noch funktionieren wird ist fraglich, das bestreben der Seitenbetreiber ihre Kunden und Daten, und damit ihr Kapital zu schützen, wächst stetig.

mfg Stefan

sebix Team-Icon

Moderator, Webteam

Anmeldungsdatum:
14. April 2009

Beiträge: 5582

Moderich schrieb:

Soweit ich das Prinzip verstanden habe merkt sich der Browser doch bei der ersten Verbindung mit der jeweiligen Seite das dazugehörige Zertifikat und überprüft es bei jedem weiteren Besuch ob es noch dasselbe ist.

Nein. Jedenfalls ohne zusaetzliche Add-Ons oder dergleichen.

Moderich

(Themenstarter)

Anmeldungsdatum:
20. September 2008

Beiträge: 20

Hm ja, ich verstehe...Kurz zusammengefasst: es ist also quasi eher schwierig bis unmöglich als Normalsterblicher einen Contentfilter für HTTPS-Seiten zu implementieren, obwohl, wie encbladexp schrieb schon erwähnt hat es Virenscanner es mit einigem Aufwand doch schaffen diese Verbindung aufzubrechen mit den selben Mitteln die auch Squid bietet. Man kann es also soweit konfigurieren dass es soweit wie möglich klappt; sobald die Kinder es dann schaffen diese Hürde zu überspringen sind sie dann wahrscheinlich alt genug um den Contenfilter dann komplett wegzulassen 😛

Antworten |