Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

HTTPS-Problem

Hallo,

Ich habe ein kleines Problem und weiß nicht recht weiter ...

Ich habe bei mir den HTTP/S-Proxy im Transparent-Mode laufen.

Bei manchen HTTPS-Seiten (Amazon, etc.) wird die Seite einfach nicht aufgebaut, andere funktionieren aber tadellos.

Bisher habe ich folgendes kontrolliert:

  • Web Security -> HTTP/S -> Advanced -> Allowed target services: HTTPS ist dort eingetragen.
  • Network Security -> Packet Filter: Eine Regel die mir von Intern erlaubt Web Surfing zu betreiben. Die Regel ist aktiv und HTTPS drinnen.


Ich habe dann versucht im HTTP/S-Proxy die Funktion Scan HTTPS (SSL) Traffic zu aktivieren und die Seiten wurden aufgebaut ... leider funktionieren dann manch andere Programme nicht.

Hat jemand eine Idee, wie ich das wieder so hinbekomme, dass er mir die Seiten aufbaut ohne das ich den SSL-Traffic scannen lasse?

Ich weiß das es vor dem heutigen Update auf Version 8.002 noch funktioniert hat.

Wäre für jede Hilfe dankbar!


This thread was automatically locked due to age.
  • Hallo Andreas,

    Danke für den Tipp, aber geht das denn nicht auch vielleicht anders?

    Laut BAlfson:
    It sounds like your HTTP/S Proxy is in "Transparent" mode and that you haven't selected to 'Scan HTTPS (SSL) traffic'. In order to allow HTTPS traffic, you need a packet filter rule 'Internal (Network) -> HTTPS -> Any : Allow'.


    Transparenten Proxy habe ich, "Scan HTTPS (SSL) traffic" will ich nicht haben, aber die Regel hab ich auch ... dennoch funktioniert es nicht.

    Oder lieg ich überhaupt falsch und es geht wirklich nur, wenn ich den Proxy einschalte? Aber warum hat es dann vor dem Update funktioniert???

    Ich bin ratlos. [:(]
  • Hi Nuradon,

    Webproxy: Transparenter Modus ohne HTTPS-Scan
    => passt schon

    Allerdings fordert diese Einstellung für alle nicht HTTP-Pakete entsprechende Filterregeln im Paketfilter.

    Paketfilter: [an oberster Stelle] Internes Netzwerk -> HTTPS -> Any: Allow / Logging: On
    => prüfen, ggf. auf grün (aktiv) setzen
    => notfalls alle anderen Regeln vorübergehend inaktiv (rot) setzen

    Masquerading: Internes Netzwerk -> Externe IP-Adresse
    => prüfen, ggf. einstellen

    Wir haben hier noch kein 8er am Laufen aber v7.507 sollte es auch tun. In deinen Browsern brauchst du keinen Proxy definieren, solange du den Proxy-Modus nicht umstellst.

    Poste dann einfach nochmal ein paar Zeilen von deinem Paketfilter-Log und dem Webproxy-Log. Evtl. solltest du dazu direkt eine HTTPS-Seite aufrufen, bspw. https://www.gmx.net oder so was.
    -- 
    HTH & Rgds

    Steffen
  • Also mit den Einstellungen wie du es geschrieben hast komme ich auf https://www.gmx.net.

    Die Meldung kommt im PF-Log:
    16:39:52 Packet filter rule #1 TCP 192.168.39.2 : 51607 → 213.165.64.71 : 443 [SYN] len=52 ttl=127 tos=0x00 srcmac=6c:f0:49:5:17:4e dstmac=40:61:86:1:ff:21


    Aber wenn ich versuche auf http://www.amazon.de/gp/css/homepage.html/ref=topnav_na?ie=UTF8&is-secure=true zuzugreifen kommt folgendes:
    16:45:42 Packet filter rule #1 TCP 192.168.39.2 : 51660 → 87.238.87.36 : 443 [SYN] len=52 ttl=127 tos=0x00 srcmac=6c:f0:49:5:17:4e dstmac=40:61:86:1:ff:21
    
    16:45:44 Packet filter rule #1 TCP 192.168.39.2 : 51661 → 95.100.145.51 : 443 [SYN] len=52 ttl=127 tos=0x00 srcmac=6c:f0:49:5:17:4e dstmac=40:61:86:1:ff:21
    16:45:44 Packet filter rule #1 TCP 192.168.39.2 : 51662 → 95.100.145.51 : 443 [SYN] len=52 ttl=127 tos=0x00 srcmac=6c:f0:49:5:17:4e dstmac=40:61:86:1:ff:21
    16:45:44 Packet filter rule #1 TCP 192.168.39.2 : 51663 → 95.100.145.51 : 443 [SYN] len=52 ttl=127 tos=0x00 srcmac=6c:f0:49:5:17:4e dstmac=40:61:86:1:ff:21
    16:45:44 Packet filter rule #1 TCP 192.168.39.2 : 51664 → 95.100.145.51 : 443 [SYN] len=52 ttl=127 tos=0x00 srcmac=6c:f0:49:5:17:4e dstmac=40:61:86:1:ff:21
    16:45:58 Default DROP TCP 79.186.252.163 : 12102 → 91.113.94.107 : 445 [SYN] len=48 ttl=115 tos=0x00
    16:46:01 Default DROP TCP 79.186.252.163 : 12102 → 91.113.94.107 : 445 [SYN] len=48 ttl=115 tos=0x00

    und er macht die Seite nicht auf (zeigt im Firefox, dass er lädt und das tut er ewig).
  • Hi,

    ich habe es eben bei mir mal probiert.

    Wenn ich deinen Link anklicke, dann geht unsere ASG als erstes im Webproxy 3 URLS durch (http://ocsp.verisign.com [1x], http://ocsp.comodoca.com [2x]), die der Kategorie "Internet Services" zugeordnet sind. Danach geht es bei mir im Paketfilter weiter, in dem der HTTPS-Traffic zu 88.221.137.51 geloggt wird.

    Dann bin ich auf der Amazon-Seite.

    Da wirst du wohl nochmal genau schauen müssen, ob du nicht vllt. doch im Webproxy hängen bleibst, weil evtl. "Internet services" geblockt wird... Wäre jetzt meine Erklärung dazu.
    -- 
    MfG, Steffen
  • Hallo Stefan,

    Wie kann ich das denn am Besten überprüfen?

    Weil eigentlich ist nur "Block Spyware infection and communication" aktiv, der Rest wird erlaubt.

    Danke aber trotzdem für die ganze Hilfe schon mal.
  • Ich hatte bis gerade noch das selbe Problem bei einem Kunden.

    Dort lief Trotz Ausgeschaltetem SSL Scan im Proxy und erstellter Paketfilterregel für HTTPS z.b. SFirm und Datev nicht ( Zertifikatfehler ). Genauso konnte man nur auf HTTPS Seiten auf denen ein Vertrauenswürdiges Zertifikat ( z.b. VeriSign ) installiert ist. 
    Ich habe nun Im Proxy eine Ausnahme erstellt die für das Interne Netz das Scannen von Zertifikaten und SSL abschaltet ( 3 Hacken unter HTTPS in der Proxy Ausnahme )
    danach lief alles wunderbar.

    Jemand ne Ahnung ob das so gewollt ist? Wie könnte ich das Umgehen?
  • Kannst du mir sagen wo genau du das eingestellt hast?

    Ich hab zwar versucht das einzurichten, aber bei mir scheint das einfach nicht zu funktionieren. [:(]
  • Klar ...

    Web Security -> HTTP/S -> Exception -> New execption list 


    • Irgend einen Namen eingegeben z.b. SSL Deaktivierung
    • Hacken bei HTTPS Scanning

      SSL scanning


      Certificate Trust Check


      Certificate Date Check


    • "For all requests" Im Dropdown dann das auswählen was du möchtest in meinem Fall war das:

      Coming from these Source Network: 


    • Dort habe ich dann das ganze Internal Lan genommen da auf den meisten Arbeitsplätzen Datev und SFirm genutzt wird.


    Das war es auch schon. Ich hoffe ich konnte dir helfen. Die Frage ist nur ob das so richtig ist oder ob man so das Problem einfach nur umgeht.
  • Ok, hab es genauso eingestellt.

    Jedoch geht es scheinbar immer noch nicht.
    Muss ich die Astaro eventuell neu starten? Oder muss dafür auch "Scan HTTPS (SSL) Traffic" aktiv sein?
  • Also trotz Astaro-Neustart hat das mein Problem immer noch nicht behoben ...

    Noch weitere Ideen/Tipps?