Squid SSL filtering liefert windows 10 update fehler 0x801901f7



  • sobald ich ssl unter squid aktiviere kann man die windows updates unter windows 10 nicht mehr suchen.
    es kommt dann diese fehlermeldung. (siehe screenshot)
    schaltet man ssl filterung wieder unter squid wieder aus werden die updates am windows 10 client wieder erfolgreich gesucht bzw angezeigt bzw gefunden.

    leider konnte ich nirgends im netz oder hier im forum eine anleitung bzw einen lösung zu diesem problem finden.

    kann mir jemand helfen ? oder bin ich der einzige der einen windows 10 client hinter einer pfsense firewall mit squid betreibt ?

    bitte um hilfe!!

    danke!




  • kann mir niemand helfen ??  :(



  • Moin,
    ich nutze auch den Proxy (transparent) allerdings ohne SSL!
    Bei mir funktionieren die Windows 10 Updates problemlos.
    Hast Du die Außnahmen gemäß dieser Liste https://technet.microsoft.com/de-de/library/bb693717.aspx eingerichtet!?

    Gruß
    Dirk


  • Moderator

    Erstmal Dank an Dirk, aber auch an den OP nochmal die Bitte: Du postest gestern Abend, heute morgen! bist du schon am Nachtreten warum/dass dir niemand hilft. Ein WENIG mehr Geduld wäre da doch schon ganz schön, zumal wir, auch wenns manchen vielleicht wegen schlechtem Wetter entfallen ist, immer noch Sommer und Urlaubszeit. Ich komme selbst aus gerade 2 Wochen Urlaub. Wenn man dann nach nichtmal 12h schon ein Fässchen aufmacht, muss ich da schon den Sinn hinterfragen.

    Gruß



  • den squid proxy mode habe ich auf "transparent" eingestellt. Zertifikat ist installiert (certmgr.msc)-> ist auch im ie, edge, firefox und chrome installiert. ich verwende ssl. ohne ssl also mit http proxy habe ich auch keine probleme bei windows updates. nur im ssl modus. surfen funktioniert. aber einige applikationen eben nicht. unter anderem windows updates werden zwar gesucht, aber die update funktion liefert den beschriebenen fehler (siehe screenshot oben).

    da ich mich mit dem acl zeug und so nicht wirklich auskenne und ich ein Neuling bin was pfsense betrifft, bitte ich euch um unterstützung.

    das wären die fragen:

    was muss ich eintragen damit

    1. die updatefunktion unter windows 10 keine fehlermeldung liefert? (siehe screenshot oben)
    2. die cache funktion von den windows 10 updates im squid funktioniert
    3. wo (in welchen feldern von squid) muss ich dann "was" eintragen. das ist teilweise auch auf der squid seite extrem kompliziert beschrieben und bezieht sich auch nur auf squid und nicht pfsense.

    damit wäre mir sehr geholfen. und ich denke auch vielen anderen die pfsense - squid und windows 10 clients in ihrem netz verwenden.

    danke nochmals!!



  • @monstermania:

    Moin,
    ich nutze auch den Proxy (transparent) allerdings ohne SSL!
    Bei mir funktionieren die Windows 10 Updates problemlos.
    Hast Du die Außnahmen gemäß dieser Liste https://technet.microsoft.com/de-de/library/bb693717.aspx eingerichtet!?

    Gruß
    Dirk

    ich habe die server in der "whitelist" eingetragen. brachte aber leider nichts. Zusätzlich sogar

    https://sls.update.microsoft.com
    https://v10.vortex-win.data.microsoft.com

    laut "Realtime" (Squid) brachte auch nichts.



  • Ohne den Thread kapern zu wollen: ich stehe vor dem gleichen Problem. Aktuelles pfSense 2.3.4p1 mit akt. squid Paket 0.4.37 (ist squid 3.5.26) ohne squidguard im transparentem Modus.

    Das Anliegen 2 des OP (cachen der Windows Updates durch pfSense squid Proxy) ist noch etwas anderes und komplexer. Mir geht es wenigstens erstmal um den ersten Teil: dass Windows Updates mit transp. SSL Proxy überhaupt funktionieren.

    Das Problem mit MS Windows Updates, div. Banken u.a. ist das Zertifikat Pinning. Diese Webseiten / URL müssen komplett (ohne Zertifikatbehandlung / aufbrechen der Verschlüsselung durch squid) durch den squid durchgeleitet werden. Zu sehen ist das wenn man solch eine URL im Browser aufruft und sich das gelieferte Zertifikat anschaut: kommt es von der pfSense oder von der echten Website.

    Da das mit dem bypass der Windows Update URL wegen der Menge der URL usw. komplexer ist teste ich das Ganze erstmal mit der URL reddit.com (immer schön Browser löschen, neue Sitzung und das Zertifikat anschauen ob das von der pfsense oder von extern signiert wurde).

    Die URL in die Whitelist (Menü Package / Proxy Server: Access Control / ACLs) einzutragen heisst nach meinem Verständnis nach nicht dass diese URL vom SSL Proxy nicht bearbeitet wird. Einträge dort bedeuten dass die URL überhaupt erstmal aufrufbar ist und nicht gleich komplett gesperrt wird. Das Zertifikat wird trotzdem durch den Proxy ersetzt. Dort die URL der Windows Updates (und z.B. reddit.com) einzutragen bringt meines Verständnis nach nichts, es wird weiterhin nicht funktionieren.

    Die entspr. URL sollten in das Feld 'Bypass Proxy for These Destination IPs' (Menü Package / Proxy Server: General Settings / General) rein. Aber wenn ich das mache und teste funktionieren diese Ausnahmen dennoch nicht: das Zertifikat der Website wird durch das der pfSense ersetzt und damit funktionieren u.a. die Windows Updates nicht.

    Es funktioniert wenn ich den ganzen Computer in die Liste 'Bypass Proxy for These Source IPs' eintrage, aber ich will ja nur diese URL für Computer am Proxy vorbeileiten.

    Wie also kommt man für einzelne URL bzw. URL mit Wildcards zu Ausnahmen im squid?

    Danke

    Nachtrag: Wenn ich im Feld 'Bypass Proxy for These Source IPs' (Menü Package / Proxy Server: General Settings / General) eine URL oder auch mal eine IP eintrage erscheinen diese Werte 'nirgends' in den üblichen Konfigurationsdateien unterhalb /usr oder /etc (z.B. /usr/local/etc/squid … ). Wo also bitte wird das hinterlegt?



  • Letztendlich habe ich alles aus den Whitelists usw. rausgenommen weil das nichts bringt. Das Problem ist wirklich dass MS für seine Updates viele URL mit jeweils mehr. IP hat und dann auch noch umleitet zu lokalen CDN. Wenn man etwas in die Ausnahmelisten der pfSense einträgt (z.B. auch Host Aliase) werden die im besten Fall immer kurz zu gerade gelieferten IP aufgelöst und funktionieren später nur noch bedingt. Daher anders: indem bei jeder URL Anfrage vor dem Aushandeln der Verschlüsselung das SSL Bumping für diese URL umgangen wird.

    Windows Updates funktionieren wenn man das in erweiterten Einstellungen (Menü Package / Proxy Server: General Settings / General ganz unten die Schaltfläche Show Advanced Options) einstellt.
    Folgendes habe ich unter Custom Options (Before Auth) eingetragen:
    acl DiscoverSNIHost at_step SslBump1
    acl NoSSLIntercept ssl::server_name_regex microsoft.com                   
    acl NoSSLIntercept ssl::server_name_regex .microsoft.com                   
    acl NoSSLIntercept ssl::server_name_regex windowsupdate.com
    acl NoSSLIntercept ssl::server_name_regex .windowsupdate.com
    acl NoSSLIntercept ssl::server_name_regex update.microsoft.com.akadns.net

    ssl_bump splice NoSSLIntercept
    ssl_bump peek DiscoverSNIHost
    ssl_bump bump all

    acl BrokenButTrustedServers dstdomain download.microsoft.com
    acl BrokenButTrustedServers dstdomain update.microsoft.com
    acl BrokenButTrustedServers dstdomain update.microsoft.com.akadns.net
    acl BrokenButTrustedServers dstdomain update.microsoft.com.nsatc.net
    acl DomainMismatch ssl_error SQUID_X509_V_ERR_DOMAIN_MISMATCH
    sslproxy_cert_error allow BrokenButTrustedServers DomainMismatch
    sslproxy_cert_error deny all

    Quelle u.a.:
    https://wiki.squid-cache.org/SquidFaq/WindowsUpdate  ganz unten Squid with SSL-Bump and Windows Updates.
    http://squid-web-proxy-cache.1019090.n4.nabble.com/Ssl-bump-tunneling-connection-by-using-Common-Name-td4681693.html

    Problem bei den o.g. Einstellungen: es werden praktisch alle https Anfragen zu microsoft.com und windowsupdate.com am Proxy vorbeigeleitet. Wenn man also schauen will was da drin ist bzw. was noch so alles per https verschickt wird und man das unterbinden möchte kommt man so nicht mehr ran. Ich hatte ursprünglich mehr und gezieltere URL ausschließlich für die MS Updates drin stehen (gemäß den MS Empfehlungen) aber das reichte immer nicht. Gebe ich den kompletten MS Traffic weiter funktioniert es :(

    Das Problem betrifft eben nicht nur MS Windows Updates sondern auch Skype, hotmail, div. Banken u.a.. Man kann dann halt weitere Ausnahmen treffen.



  • @bon-go:

    Letztendlich habe ich alles aus den Whitelists usw. rausgenommen weil das nichts bringt. Das Problem ist wirklich dass MS für seine Updates viele URL mit jeweils mehr. IP hat und dann auch noch umleitet zu lokalen CDN. Wenn man etwas in die Ausnahmelisten der pfSense einträgt (z.B. auch Host Aliase) werden die im besten Fall immer kurz zu gerade gelieferten IP aufgelöst und funktionieren später nur noch bedingt. Daher anders: indem bei jeder URL Anfrage vor dem Aushandeln der Verschlüsselung das SSL Bumping für diese URL umgangen wird.

    Windows Updates funktionieren wenn man das in erweiterten Einstellungen (Menü Package / Proxy Server: General Settings / General ganz unten die Schaltfläche Show Advanced Options) einstellt.
    Folgendes habe ich unter Custom Options (Before Auth) eingetragen:
    acl DiscoverSNIHost at_step SslBump1
    acl NoSSLIntercept ssl::server_name_regex microsoft.com                   
    acl NoSSLIntercept ssl::server_name_regex .microsoft.com                   
    acl NoSSLIntercept ssl::server_name_regex windowsupdate.com
    acl NoSSLIntercept ssl::server_name_regex .windowsupdate.com
    acl NoSSLIntercept ssl::server_name_regex update.microsoft.com.akadns.net

    ssl_bump splice NoSSLIntercept
    ssl_bump peek DiscoverSNIHost
    ssl_bump bump all

    acl BrokenButTrustedServers dstdomain download.microsoft.com
    acl BrokenButTrustedServers dstdomain update.microsoft.com
    acl BrokenButTrustedServers dstdomain update.microsoft.com.akadns.net
    acl BrokenButTrustedServers dstdomain update.microsoft.com.nsatc.net
    acl DomainMismatch ssl_error SQUID_X509_V_ERR_DOMAIN_MISMATCH
    sslproxy_cert_error allow BrokenButTrustedServers DomainMismatch
    sslproxy_cert_error deny all

    Quelle u.a.:
    https://wiki.squid-cache.org/SquidFaq/WindowsUpdate  ganz unten Squid with SSL-Bump and Windows Updates.
    http://squid-web-proxy-cache.1019090.n4.nabble.com/Ssl-bump-tunneling-connection-by-using-Common-Name-td4681693.html

    Problem bei den o.g. Einstellungen: es werden praktisch alle https Anfragen zu microsoft.com und windowsupdate.com am Proxy vorbeigeleitet. Wenn man also schauen will was da drin ist bzw. was noch so alles per https verschickt wird und man das unterbinden möchte kommt man so nicht mehr ran. Ich hatte ursprünglich mehr und gezieltere URL ausschließlich für die MS Updates drin stehen (gemäß den MS Empfehlungen) aber das reichte immer nicht. Gebe ich den kompletten MS Traffic weiter funktioniert es :(

    Das Problem betrifft eben nicht nur MS Windows Updates sondern auch Skype, hotmail, div. Banken u.a.. Man kann dann halt weitere Ausnahmen treffen.

    Hat nur einmal funktioniert. Beim zweiten Mal "updates suchen" kommt wieder der Fehler:"es konnte keine Verbindung mit dem Updatedienst hergestellt werden….." -> aber diesemal ohne Fehlercode.



  • ich hab jetzt zwei server hinzugefügt. und jetzt funktioniert es . könnt ihr einen unterschied feststellen oder ist dies Ergebnis bei mir jetzt nur Zufall?

    meine liste wäre:

    acl DiscoverSNIHost at_step SslBump1
    acl NoSSLIntercept ssl::server_name_regex sls.update.microsoft.com
    acl NoSSLIntercept ssl::server_name_regex .sls.update.microsoft.com
    acl NoSSLIntercept ssl::server_name_regex v10.vortex-win.data.microsoft.com
    acl NoSSLIntercept ssl::server_name_regex .v10.vortex-win.data.microsoft.com
    acl NoSSLIntercept ssl::server_name_regex microsoft.com                   
    acl NoSSLIntercept ssl::server_name_regex .microsoft.com                 
    acl NoSSLIntercept ssl::server_name_regex windowsupdate.com
    acl NoSSLIntercept ssl::server_name_regex .windowsupdate.com
    acl NoSSLIntercept ssl::server_name_regex update.microsoft.com.akadns.net

    ssl_bump splice NoSSLIntercept
    ssl_bump peek DiscoverSNIHost
    ssl_bump bump all

    acl BrokenButTrustedServers dstdomain v10.vortex-win.data.microsoft.com
    acl BrokenButTrustedServers dstdomain sls.update.microsoft.com
    acl BrokenButTrustedServers dstdomain download.microsoft.com
    acl BrokenButTrustedServers dstdomain update.microsoft.com
    acl BrokenButTrustedServers dstdomain update.microsoft.com.akadns.net
    acl BrokenButTrustedServers dstdomain update.microsoft.com.nsatc.net
    acl DomainMismatch ssl_error SQUID_X509_V_ERR_DOMAIN_MISMATCH
    sslproxy_cert_error allow BrokenButTrustedServers DomainMismatch
    sslproxy_cert_error deny all



  • Nein, kann ich nicht bestätigen. Das funktioniert mit meinen Einstellungen reproduzierbar an verschiedenen PC hinter der pfSense, mehrfach. Ich habe das caching von dyn. Inhalt allerdings ausgeschalten.

    Im Prinzip benutze ich die squid Standardeinstellungen nach einer Neuinstallation: ca in pfSense eingerichtet, root ca exportiert (und anschl. im PC im Speicher der vertrauenswürdigen Herausgeber des PC installiert), squid cache aktiviert (nur 1x auf speichern geklickt), squid aktiviert auf den Interface LAN und loopback, transparenten Modus aktiviert, SSL Filtering aktiviert und das root ca ausgewählt, squid logging aktiviert (wg. lightsquid), clamav aktiviert mit stdl. Updates und einmal die akt. AV Daten gezogen (+ gewartet bis alle Services grün), audio und video av scanning deaktiviert und als letztes im squid die o.g. erweiterten Einstellungen reinkopiert und gespeichert. Einmal squid Service reload - fertig. Dynamische Inhalte werden so nicht cached, Windows Updates demzufolge auch nicht, o.g. Punkt 2 des OP wird so nicht behandelt.

    Du hast zwei URL nachgetragen, nicht zwei Server. Zur Erklärung: die Einträge hinter acl NoSSLIntercept im oberen Teil lassen die dahinter stehenden URL den Proxy unbehandelt passieren, die werden im Schritt sslbump1 (zu Anfang des Verbindungsaufbau beim Handshake) sliced (durchgereicht). Die Einträge im unteren Teil ignorieren auftretende Zertifikatfehler (für die selbstsignierten MS Zertifikate).

    Deine zusätzlichen zwei URL / vier Zeilen im oberen Teil sind irrelevant: die zwei regex Einträge mit den URL von (.)microsoft.com decken alle darunter liegenden Subdomains (deine zusätzlichen URLs) ab. Ich glaube auch nicht dass deine zwei Zeilen im unteren Teil welche die Zertifikatüberprüfung für die Subdomains v10… und sls... ignorieren relevant sind - könnte man aber testen. Ich komme ohne aus.

    Nachtrag: Das ist sicher nicht der Weisheit letzter Schluss. Das ist mein Verständnis der Dinge die da ablaufen, wird sicher nicht vollständig und auch nicht ganz richtig sein in der Erklärung. Genauerer Erklärungen und Berichtigungen sind willkommen. Das beschriebene Szenario läuft noch nicht lange produktiv. Es fehlt eben auch noch das gewünschte Caching der Windows Updates der Clients. Ich weiss auch nicht ob o.g. Einstellungen wirklich richtig und ausreichend sind und nicht Seiteneffekte beim squidguard oder anderen Modulen zeigen. Eine Lösung per wpad scheidet bei mir gerade aus.



  • @bon-go:

    Nein, kann ich nicht bestätigen. Das funktioniert mit meinen Einstellungen reproduzierbar an verschiedenen PC hinter der pfSense, mehrfach. Ich habe das caching von dyn. Inhalt allerdings ausgeschalten.

    Im Prinzip benutze ich die squid Standardeinstellungen nach einer Neuinstallation: ca in pfSense eingerichtet, root ca exportiert (und anschl. im PC im Speicher der vertrauenswürdigen Herausgeber des PC installiert), squid cache aktiviert (nur 1x auf speichern geklickt), squid aktiviert auf den Interface LAN und loopback, transparenten Modus aktiviert, SSL Filtering aktiviert und das root ca ausgewählt, squid logging aktiviert (wg. lightsquid), clamav aktiviert mit stdl. Updates und einmal die akt. AV Daten gezogen (+ gewartet bis alle Services grün), audio und video av scanning deaktiviert und als letztes im squid die o.g. erweiterten Einstellungen reinkopiert und gespeichert. Einmal squid Service reload - fertig. Dynamische Inhalte werden so nicht cached, Windows Updates demzufolge auch nicht, o.g. Punkt 2 des OP wird so nicht behandelt.

    Du hast zwei URL nachgetragen, nicht zwei Server. Zur Erklärung: die Einträge hinter acl NoSSLIntercept im oberen Teil lassen die dahinter stehenden URL den Proxy unbehandelt passieren, die werden im Schritt sslbump1 (zu Anfang des Verbindungsaufbau beim Handshake) sliced (durchgereicht). Die Einträge im unteren Teil ignorieren auftretende Zertifikatfehler (für die selbstsignierten MS Zertifikate).

    Deine zusätzlichen zwei URL / vier Zeilen im oberen Teil sind irrelevant: die zwei regex Einträge mit den URL von (.)microsoft.com decken alle darunter liegenden Subdomains (deine zusätzlichen URLs) ab. Ich glaube auch nicht dass deine zwei Zeilen im unteren Teil welche die Zertifikatüberprüfung für die Subdomains v10… und sls... ignorieren relevant sind - könnte man aber testen. Ich komme ohne aus.

    ok. also dann danke ich dir mal für diese wirklich geniale Erklärung. Du hast mir sehr geholfen und ich denke auch vielen anderen !!! VIELEN DANK :-)



  • Danke. Ich habe noch etwas nachgetragen falls andere mal den Beitrag lesen - nicht dass die meine vmtl. vorhandenen Fehler und fehlerhaften Erklärungen für bare wahre Münze nehmen :D Mein Level der Erkenntnis ist nur ein klein wenig höher wie deines und noch unter Normfüllstand des Glases denke ich. Ich hoffe noch auf Verbesserungen und Korrrekturen meiner Erklärung, die wird es sicher geben.