Squid stellt auf einigen Seiten falsche Zertifikate aus
-
Hallo zusammen,
ich setze Pfsense 2.3.2-p1 mit Squid 0.4.23_1 ein.
Ich habe dort auch die SSL Filterung aktiviert, da ich später auch Downloads untersuchen möchte und Webseiten sperren. So jetzt zu meinem Anliegen, in den meisten Fällen läuft alles wie es soll ich bekomme auf HTTPS-Seiten gültige Zertifikate von PFSENSECA->Seite klappt in manchen Fällen klappt das Ganze aber nicht, da wird anstatt PFSENSECA->Seitenname eine IP-ADRESSE ausgestellt mit einem abgelaufenen Datum. Als Beispiel habe ich mal https://emby.media genommen siehe Bilder.
Ohne Squid
Mit SQUIDIch denke es ist ein Einstellungs Problem meiner Seite, konnte aber noch nicht ermitteln welcher das ist.
Hoffe ihr könnt mir weiterhelfen.
Danke und Gruß
-
Mit Squid die SSL Filterung zu benutzen bedeutet zwangsläufig, dass Squid sich mit dem Webserver und dessen Zertifikat verbindet und dein lokaler Browser mit Squid mit SSL, daher ist es schon richtig, dass das Zertifikat deines Squid Servers (internal) angezeigt wird. Es wird die SSL-Kette durch Squid unterbrochen um eben den INhalt filtern zu können.
Nur das von dir erstellte pfSense (Squid) Zertifikat ist wohl zum 11. September abgelaufen, daher kann keine Verbindung von Squid zum Server hergestellt werden, steht ja auch in der Beschreibung drin.
Daher musst du über den pfSense Cert.Manager ein neues Zertifikat erstellen mit einer längeren Lebensdauer. Dieses Zertifikat muss dann wiederum bei Squid in den SSL Filter Einstellungen ausgewählt werden. -
Hi danke für die Antwort,
Da habe ich wohl nicht weit genug ausgeholt :) Das mein SQUID Zertifikat die unter Zertifikate ausstellt ist mir bekannt, er macht es auch auf fast bei allen Seiten richtig wie zum Beispiel Facebook da bekomme ich internal-ca -> *.facebook.com gültig bis 26.11.2026 und bei vielen anderen auch und bei machen wie mein Beispiel Emby oder auch hier https://pfsense.org stellt er ein falsches Zertifikat aus. Wenn ich Transparent-Modus deaktiviere und den Proxy Manuel im Internet Explorer zuweise passiert das nicht mehr, genauso, wenn ich es über wpad mache. Dann stimmen restlos alle Zertifikate. Nur fehlt mir dann die Möglichkeit für bestimmte Domains Bypass regeln anzulegen die ich aber zwingend brauche.
Gruß
-
Hast du das beachtet?
"Install the CA certificate as a Trusted Root CA on each computer you want to filter SSL on to avoid SSL error on each connection."
Ich gehe aber mal davon aus, dass du das schon eingestellt hast, da du sonst generell Fehler bekommen solltest.
Daher noch folgendes schrittweise:
1. Prüfe dass dein Zertifikat eine korrekte Angabe des pfSense Hosts bei "CN" hat.
2. Stelle auf "Accept Remote Certificate with errors" um, das hatte einige Fehler bei mir beseitigt. Der "Nachteil" der Einstellung ergibt sich aus der Beschreibung. Zudem deselektiere alles bei "Certificate Adapt"
3. Stelle das akzeptierende Interface nur auf dein LAN um
-
Hi, danke für die Antwort.
Das hatte ich alles so eingestellt, hat aber trotzdem nicht funktioniert.
Ich bin jetzt umgestiegen und mache anstatt Transparent Proxy, das Ganze mit WPAD, jetzt werden auch alle Zertifikate richtig ausgestellt. Aber natürlich läuft auch das nicht 100% wie gewünscht, ich habe unter Squidguard einige Blacklisten aktiviert die auf eine selbst erstellte sperrseite umgeleitet werden (redirect mode: ext url err page) das Ganze hat unter Transparent Proxy noch sauber funktioniert mit WPAD klappt das Ganze nur noch mit http Seiten, bei https Seiten versucht er bei der Umleitung https://http/* aufzurufen was natürlich zu keinem Erfolg führt und ich eine Interne Fehlerseite von SQUID bekomme.
Weiß jemand wo das Problem herkommt und wie ich da Abhilfe schaffen kann?Danke und Gruß
-
Mir sind grade noch 2 Sachen aufgefallen die vielleicht helfen,
wenn ich www.domain.de:443 schreibe klappt es auch hingegen https://www.domain.de nicht.
Bei erster Variante habe ich auch im Squid Realtime LOG als adresse http://www.domain.de:443 bei der https Variante fehlt bei Gesperreten Seiten das https und zeigt nur an domain.de.
Und im LOG vom Squidguard habe ich bei funktionierender Umleitung GET REDIRCT was ja richtig ist, bei HTTPS kommt CONNECT REDIRECT
Gruß
-
kann es sein, dass https://www.domain.de ggf. von der pfSense direkt abgegriffen wird (für die WebUI)?
-
kann es sein, dass https://www.domain.de ggf. von der pfSense direkt abgegriffen wird (für die WebUI)?
Die Frage verstehe ich nicht ganz. Kannst du das nochmal genauer erklären, bitte?
PS:
Wenn ich https://connect.mediabrowser.tv aufrufe, dann klappt ds grundsätzlich, ich bekomme allerdings die Meldung, dass das zertifikat abgelaufen ist.
Da Squid - je nach Konfiguration - die Zertifikatsinformationen der Webseite an den User übermittelt, deutet es also darauf hin, dass in diesem Fall das Webseitenzertifikat abgelaufen ist/sein könnte.
Squid passt ja nur den CN an und stellt es an Hand deiner CA aus, das Datum lässt er aber unangetastet, sonst würde Squid ja deinem Browser immer gültige Zertifikate ausstellen, auch wenn das Zertifikat der Webseite eben nicht gültig ist.PPS:
Ich habe aber auf anderen Seiten auch hin und wieder das Problem, dass diese sich per Squid nicht öffnen lassen, sonst aber schon.Grüße
-
Guten Morgen,
to JeGr: mein WebUI läuft über 8080 also https://proxy.domain.local:8080 das dürfte ja nicht stören oder?
To Nachtfalke:
Die Adresse ist ja aber eigentlich https://emby.media und ohne Transparent macht Squid es ja auch richtig, die Seite stört mich eigentlich auch gar nicht war nur ein Beispiel ich habe dasselbe Problem bei unter Seiten vom Zoll, Lieferanten, Wetransfer und unter Seiten vom Zoll was ein Größeres Problem ist :)
Und da das Ganze mit direktem Proxy und WPAD funktioniert bis auf das die gesperrten HTTPS-Seiten nicht umgeleitet werden ist das der bessere Weg, nur das muss ich noch in den Griff bekommen, hätte nur nicht gedacht das mir das ganze Thema so viel Probleme bereitet :)Um das Ganze noch mal Bildlich darzustellen
http:
https:
Und hier noch ein LOG Ausschnitt
SQUIDGUARD:
30.11.2016 07:45:06 192.168.1.101/192.168.1.101 www.amazon.de:443 Request(default/blk_BL_shopping/-) - CONNECT REDIRECT 30.11.2016 07:45:06 192.168.1.101/192.168.1.101 www.amazon.de:443 Request(default/blk_BL_shopping/-) - CONNECT REDIRECT 30.11.2016 07:45:05 192.168.1.101/192.168.1.101 www.amazon.de:443 Request(default/blk_BL_shopping/-) - CONNECT REDIRECT 30.11.2016 07:45:05 192.168.1.101/192.168.1.101 www.amazon.de:443 Request(default/blk_BL_shopping/-) - CONNECT REDIRECT 30.11.2016 07:45:02 192.168.1.101/192.168.1.101 www.amazon.de:443 Request(default/blk_BL_shopping/-) - CONNECT REDIRECT 30.11.2016 07:43:54 192.168.1.101/192.168.1.101 http://www.amazon.de/favicon.ico Request(default/blk_BL_shopping/-) - GET REDIRECT 30.11.2016 07:43:54 192.168.1.101/192.168.1.101 http://www.amazon.de/ Request(default/blk_BL_shopping/-) - GET REDIRECT
Squid:
30.11.2016 07:45:06 192.168.1.101 TAG_NONE/200 www.amazon.de:443 - - 30.11.2016 07:45:06 192.168.1.101 TAG_NONE/200 www.amazon.de:443 - - 30.11.2016 07:45:05 192.168.1.101 TAG_NONE/503 https://www.amazon.de/ - - 30.11.2016 07:45:05 192.168.1.101 TAG_NONE/200 www.amazon.de:443 - - 30.11.2016 07:45:05 192.168.1.101 TAG_NONE/200 www.amazon.de:443 - - 30.11.2016 07:45:03 192.168.1.101 TAG_NONE/200 www.amazon.de:443 - - 30.11.2016 07:43:54 192.168.1.101 TCP_MISS/200 http://www.amazon.de/favicon.ico - 217.160.0.164 30.11.2016 07:43:54 192.168.1.101 TCP_MISS/200 http://www.amazon.de/ - 217.160.0.164
Gruß
-
to JeGr: mein WebUI läuft über 8080 also https://proxy.domain.local:8080 das dürfte ja nicht stören oder?
Nicht die WebUI per se, aber es gibt ja untendrunter noch den Haken für die Weiterleitung der alternativen Ports. Sprich wenn UI auf 443, wird 80 auf 443 umgeleitet. Bei 8443 oder 8080 bspw. bin ich mir gerade unsicher, ob der Haken nicht auf 80,443 auf den anderen Port umleitet. Ich kann mich erinnern da mal mit 2.2 Probleme gehabt zu haben mit einem HAProxy der komischerweise plötzlich zur pfSense umleitete.
-
Ich habe jetzt unter System -> Advanced die Hacken gesetzt bei "Disable webConfigurator redirect rule " und "Disable webConfigurator anti-lockout rule " hat leider nichts geändert, gibt es irgendwo noch Einstellungen die den Port betreffen?
Gruß
-
Hallo zusammen,
ich glaube zwar das mir momentan scheinbar keiner weiterhelfen kann, aber mir ist noch eine Sache aufgefallen und zwar würde ich das Problem auf Squidguard eingrenzen. Wenn ich in Squid eine Domain Blackliste wird diese gesperrt und ich bekomme eine Squid Seite die mir sagt das https://irgendwas gesperrt ist und da steht der richtige und komplette URL-Name, gleich Seite mit squidguard geblockt und es kommt wieder der https://http quatsch.
Gruß