Installation schlägt fehl bei SSL verschlüsselung [Workaround]

1st Official Post
    Affected App
    WoltLab Suite Core

    Systeminfo:
    Webserver nginx 1.4.6 php-fpm 5.4.24 mysql 5.5.35
    Reverse SSL proxy: nginx 1.4.4


    Die Installation schlägt immer nach erstellen des Adminkonots fehl: Die Seite wird fehlerhaft dargestellt (ohne css/bilder etc.) Javascripts werden nicht ausgeführt, der Browser meldet unsichere Ressourcen. Ein erneutes Laden der Seite mit der Erlaubnis unsichere Inhalte anzuzeigen funktioniert, die Installation schlägt dann jedoch fehl. (wegen dem reload) Ich hab vertrödelt genau nachzuschauen welche Dateien solche Probleme machen, ich vermute jedoch das die Standardeinstellung jQuery-Quelle: "Google Hosted Libraries CDN" schuld ist.


    Mein Workaround: den SSL Proxy umgehen und das ganze dann über die IP Adresse des Webserver installieren. Nicht schön die Lösung, der der Server normalerweise nicht direkt erreichbar ist sondern nur dem proxy antwortet. IM APC dann bei allen installierten Paketen in der richtigen Reihenfolge die Domain nachträglich ändern und fertig.


    Ich weiß HTTPS wird normalerweise kaum eingesetzt schon gar nicht für Forensoftware. Aber ich will auf SPDY nicht verzichten und sehe es auch nciht ein das alle Seiten verschlüsselt übertragen werden und beim Forum eine Ausnahme machen. Da bin ich Prinzipienreiter. Ich verschlüssel alles ;)


    Da sich inzwischen immer mehr Menschen Gedanken um Sicherheit machen und SPDY stark im kommen ist, wird es also in Zukunft evtl. auch andere geben die vor diesem Problem stehen, daher hoffe ich das mein Workaround im der Forensuche gefunden wird^^


    Noch schöner wäre es jedoch wenn Woltlab die Installation anpasst und SSL/SPDY berücksichtigt: Während der Installation darf dann einfach keine externe und somit "unsicherer" Ressource verwendet werden.

    • Official Post

    jQuery wird pauschal via SSL eingebunden, da spielt das keine wirkliche Rolle. Das Problem wird eher die Konfiguration des SSL-Proxies sein, ich gehe mal davon aus du hast folgendes Setup:


    Client <-(via HTTPS)-> SSL Proxy <-(via HTTP)-> Webserver


    In dem Falle kommt es zu eine Diskrepanz, die Software reagiert automatisch auf das verwendete Protokoll (etwa HTTPS) und erzeugt alle Verweise auf Seiten und statischen Ressourcen unter Beibehaltung des Protokolls. In deinem Fall ist das Problem, dass der Reverse Proxy die Request via HTTP macht und dementsprechend die Software annimmt, dass kein TLS im Einsatz ist.


    Als Lösungsansatz gäbe es für dich zwei Möglichkeiten:

    • Den Zielwebserver mit HTTP via Port 443 betreiben (kannst eh jeden Port nehmen den du möchtest)
    • In nginx via FastCGI-Parameter: fastcgi_param HTTPS on; (das kannst du spezifisch für die Location der Software setzten, empfohlen)

    Die Option fastcgi_param HTTPS on; habe ich inzwischen für das WBB aktiviert, es lief nicht ohne. (Alle Inhalte vom Browser geblockt). Hätte ich das mal vor der Installation gewusst, hätt ich mir viel gram erspart. Aber man kann ja eigentlich auch erwarten, dass jemand der einen Reverse SSL proxy einsetzt, schneller auf diese Lösung kommt *unschuldig pfeif* .


    Trotzdem super, dass dieser etwas exotischere Fall in Zukunft direkt abgefangen wird. Für mich ist das irgendwie so selbstverständlich Verschlüsselung und Appliactionserver zu trennen, das ich da gar nicht weiter über evtl. Probleme nachgedacht hab.


    Vielen Dank, 1a Kundensupport!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login