Squid stellt auf einigen Seiten falsche Zertifikate aus

epionier

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.

Rau

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ß

epionier

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

Rau

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ß

Rau

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ß

JeGr

kann es sein, dass https://www.domain.de ggf. von der pfSense direkt abgegriffen wird (für die WebUI)?

Nachtfalke

@JeGr:

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

Rau

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ß

JeGr

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.

Rau

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ß

Rau

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ß