Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 1 subscriber
  • Views 9478 views
  • Users 0 members are here
Options
Suggested
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

WAF: Host Header durchreichen

tetris
Hallo, 

kann mir jemand mal die Option erklären, ich verstehe es irgendwie auch mit manual und Google nicht... 

Danke [:)]


This thread was automatically locked due to age.
  • 0
    Relativ einfach:

    Wenn Du hinter der WAF bpsw. einen Apache betreibst, der mit vHosts konfiguriert ist (also unterschiedliche Webseiten für unterschiedliche angefragte Hostnamen ausliefert), dann musst Du den HTTP Host Header natürlich weiterleiten, damit der Apache die entsprechende Seite ausliefert.

    Jetzt klarer?
  • 0
    Hm.. prinzipiell ja... aber  [;)]

    Ich habe eine Seite. Dieser ist definiert via vHost  und NameVirtualhost *:443.

    Nun bekomme ich aber die Meldung 400 vom Apache (wenn die Option aktiviert ist) -->  

    Hostname domain.de provided via SNI and hostname www.domain.de provided via HTTP are different


    Wenn ich die Hostheader durchreichen Option ausschalte, dann kommt der Fehler nicht.
  • 0
    Benötigst Du denn den Virtual Host an dieser Stelle? Ich sehe hier SNI, also dass Du virtuelle Hosts über SSL ansprechen willst. Das tut doch gar keine Not. Ich würde hier mal das entsprechende Setup und insbesondere Deine Hostnamen, die Du definiert hast und über die Du den Service ansprichst, überprüfen.

    Generell ist SNI auch böse[tm] und die Astaro unterstützt SNI nach vorn weg eh nicht, also mMn überflüssig. Man kann es aber wohl nicht explizit ausschalten, nur implizit über den Verzicht auf NameVirtualHosts:
    Using Multiple SSL Certificates in Apache with One IP Address
  • 0 in reply to christianlouis
    Also die Host Konfigurationen sind sauber... alle nach diesem Schema angelegt. Klar es ist nur ein Host: 


    

    

     ServerName www.yoursite.com

     DocumentRoot /var/www/site

     SSLEngine on

     SSLCertificateFile /path/to/www_yoursite_com.crt

     SSLCertificateKeyFile /path/to/www_yoursite_com.key

     SSLCertificateChainFile /path/to/DigiCertCA.crt


    Das SNI habe ich im HostContainer auskommentiert: 

    SSLStrictSNIVHostCheck off


    Eigentlich sollte es dann doch keine Probleme geben.
  • 0
    Nö; aber wenn Du eh keine virtual hosts über den Hostnamen aussteuerst, dann lass die Option bei diesem einen Host einfach weg. Da stört sie ja dann tatsächlich nur mehr als dass sie nützt.
  • 0 in reply to christianlouis
    Ist das so? Also andersrum... warum meinst Du, dass die Option stört?
  • 0
    Also, Du betreibst ja nicht mehrere vHosts auf SSL auf der gleichen IP. Sprich, Du lieferst auf dieser IP Adresse immer nur eine SSL Seite zurück und differenzierst dort nicht zwischen unterschiedlichen Seiten (mit ggf. unterschiedlichen Zertifikaten) aus. 
    Falls Du das tun wollen würdest, wäre der Host Header sinnvoll, um zu wissen, welche der unterschiedlichen vHosts Du ansprichst. 
    Wenn Du das nicht tust, ist der Host Header nicht notwendig, er muss also nicht weitergeleitet werden und da die Weiterleitung  / das Einschalten der Option dazu bei Dir zu Problemen führt, die Du anderweitig nicht hast, lass es halt weg.

    Christian
  • 0 in reply to christianlouis
    Generell ist SNI auch böse[tm] und die Astaro unterstützt SNI nach vorn weg eh nicht

    Das stimmt seit 9.100 nicht mehr. Wurde zwar nicht offiziell bestätigt, funktioniert bei mir aber wunderbar, s. http://www.astaro.org/gateway-products/web-server-security/47727-sni-support-9-1-a.html
    Warum soll SNI böse sein? Unterstützen doch alle aktuellen Browser problemlos...

    SSLStrictSNIVHostCheck off
    Das schaltet nur den StrictSNI-Check ab, nicht SNI an sich.

    Wenn du SNI nutzt, müssen der ServerName, den du in der UTM und im Apache angegeben hast, übereinstimmen. Außerdem muss natürlich das Zertifikat auf diesen Namen ausgestellt sein.



     ServerName www.yoursite.com
     DocumentRoot /var/www/site
     SSLEngine on
     SSLCertificateFile /path/to/www_yoursite_com.crt
     SSLCertificateKeyFile /path/to/www_yoursite_com.key
     SSLCertificateChainFile /path/to/DigiCertCA.crt

    Hier muss der virt. Webserver auf der UTM auch auf 'www.yoursite.com' lauten und das Zertifikat muss für 'www.yoursite.com' gültig sein.

    edit: Als Background Info: Ein Zertifikat, das für 'test.yourdomain.com' und 'yourdomain.com' ausgestellt ist (klassisches Class1-Zertifikat, wie man es z.B. bei Startcom kostenlos bekommt), ist nicht gültig für 'www.yourdomain.com'!

    ----------
    Sophos user, admin and reseller.
    Private Setup:

    • XG: HPE DL20 Gen9 (Core i3-7300, 8GB RAM, 120GB SSD) | XG 18.0 (Home License) with: Web Protection, Site-to-Site-VPN (IPSec, RED-Tunnel), Remote Access (SSL, HTML5)
    • UTM: 2 vCPUs, 2GB RAM, 50GB vHDD, 2 vNICs on vServer (KVM) | UTM 9.7 (Home License) with: Email Protection, Webserver Protection, RED-Tunnel (server)
  • 0
    scorpionking,

    Mea culpa. Kaum schwänzt man mal das Forum für n Jahr oder so, schon entwickeln sich derartige versteckte Features.

    Ich bin halt noch auf dem Wissensstand von vor 1,5 Jahren und dem, was damals noch so alles auf der (internen) Roadmap geplant war.

    - Christian
    jetzt nicht mehr bei Sophos [:)]
  • 0 in reply to christianlouis
    Macht nix, man kann nicht alles wissen... [:D]
    Ich war auch ganz überrascht, dass es plötzlich ging, ohne dass das kommuniziert wurde...

    ----------
    Sophos user, admin and reseller.
    Private Setup:

    • XG: HPE DL20 Gen9 (Core i3-7300, 8GB RAM, 120GB SSD) | XG 18.0 (Home License) with: Web Protection, Site-to-Site-VPN (IPSec, RED-Tunnel), Remote Access (SSL, HTML5)
    • UTM: 2 vCPUs, 2GB RAM, 50GB vHDD, 2 vNICs on vServer (KVM) | UTM 9.7 (Home License) with: Email Protection, Webserver Protection, RED-Tunnel (server)
Cookie Information Banner