Zugriff von extern / WSS

[saegefisch]

wenn der ReverseProxy in einer DMZ zwischen zwei FW steht und erst die 2.= innere FW diese Möglichkeiten hat (MIrkoTik, pfsense,...), dann ist es vermutlich schon positiv,Anfragen möglichst früh zu verwerfen. Ansonsten geb' ich Dir recht, das gehört eigentlich besser in den Router, aber mit der FritzBox als äußerer Router wohl schwierig...

[saegefisch]

Mein WebSocket scheint nicht zu funktionieren, weil da wohl SSL-Daten ankommen. Im access.log stehen EInträge, die mit ""\x16\x03\x01\x00"... beginnen. Auf welchen Konfigurationsfehler könnte das hindeuten? Ich habe bei dem 8080-Server es bereits mit "listen 8080;", "listen 8080 ssl;" und auch "listen 8080 ssl http2" (wie bei 433 bei mir) versucht... ansonsten galt wie im PDF oder auch nginx beschrieben: MAP.... und UPSTREAM... und eigener Server für Websocket...

Wie gesagt: admin geht, roter Kreis kommt auch, aber eben kein grüner... vom LAN aus geht alles prima, deomi geht also.

Anmerkung: Derzeit noch WWW -- https --> RevProxy -- http --> edomi, d.h. von extern ausschließlich SSL, intern derzeit noch ohne. Könnte es daran liegen; einige Anleitungen sind ja mit "Achtung, ohne SSL" markiert, d.h. auch extern ohne SSL - zumindest verstehe ich das so

[starwarsfan]

Hi

Derzeit noch WWW -- https --> RevProxy -- http --> edomi, d.h. von extern ausschließlich SSL, intern derzeit noch ohne. Könnte es daran liegen; einige Anleitungen sind ja mit "Achtung, ohne SSL" markiert, d.h. auch extern ohne SSL - zumindest verstehe ich das so

Das könnte durchaus das Problem sein, da die https-Verbindung vom nginx terminiert wird und nicht direkt von Edomi. Mach doch versuchsweise mal http von draussen auf und versuch's. Wenn's dann geht ist klar wo es klemmt. Und wenn Du's ganz sicher haben willt, könntest Du ja danach ein neues Passwort für den Visu-Account setzen...

[saegefisch]

Vielen Dank, gute Idee! Irgendwie hätt' ich da ja auch selber drauf kommen können...

Aber rein kommt eh' keiner mehr, seit heute Nacht habe ich Client Zertifikate obligatorisch aktiviert. Die Gemengelage auf dem ReverseProxy mit nginx, WebSocket, Let's enrypt, edomi, SSL, client certificates ist durchaus eine Herausforderung - für jedes Teilstück gibt es schon Anleitungen, aber kombiniert...ist es ein harter Weg für jemanden, der das nicht täglich macht, aber mit Perfektionsismus auch keine Löcher oder unschöne Lösungen will

[saegefisch]

Ich war (recht) erfolgreich...das meiste geht jetzt - mit fast exakt der conf, die ich vorher schon hatte. Das Vorgehen - für alle, die auch mal verzweifeln: Eigenen conf kopieren, die wirklich minimale aus dem obigen PDF 1:1 nehmen (nur IPs und PEM anpassen) und anfangen. Damit geht Websocket und SSL...definitiv. Danach kann man sich sich Stück für Stück seine weiteren Parameter aus "seiner" conf zurück kopieren, speichern und sudo service nginx reload und im parallel offenen Chrome die Visu refreshen... "...ob es geht oder nicht...das zeigt Dir gleich das Licht..."

So konnte ich den - für mich dazu unerwarteten - "Übeltäter" finden, der trotz einem ganzen Sack weiterer Parameter letztlich nachweislich und reporduzierbar Websocket behindert: Client Certifiactes (CC). Ich nehme mal an, dass es eine Lösung dafür gibt, dies auch zusammen zum Laufen zu bringen, aber mit den folgenden Parametern konnte ich Websocket per auskommentieren an und ausschalten:

ssl_client_certificate /etc/nginx/ssl/ca/certs/ca.crt;
# ssl_crl /etc/nginx/ssl/ca/private/ca.crl;   # CRL-Datei muss noch erzeugt werden, wenn man das nutzen möchte --> siehe meine Frage gestern...
ssl_verify_client on;    # on | off | optional | optional_no_ca

Ich find's gerade arg doof: Denn ohne Client Certifiactes ist mir der Reverse Proxy eigentlich ein zu heißes Eisen - und würde eher darauf verzichten und VPN nutzen, als mir so eine (vielleicht nur gefühlt) offene Tür zu akzeptieren. Ohne CC gehe ich schlicht von einer größeren Angriffsfläche aus, die ein RevProxy ins WWW stellt.

Frage: In Bezug zu meinem Post gestern und meiner Frage dazu: Wofür brauche ich die CRL-Datei, welches Risiko habe, wenn nich sie nicht erzeuge (einige Tuorials zum Thema CC machen es nicht) und könnte sie helfen, Websocket UND Client Certifiactes (CC) gleichzeitig nutzen zu können? Könnte es mit den selbst signierten CC zu tun haben (im Browser als p12 importiert). Oder kann das nur funktionieren, wenn beide Strecken WWW -> RevProxy -> edomi per https laufen, weil dann edomi auch Zertifikate hat und wir ja vielleicht ein Problem damit haben, dass der Upstream im RevProxy nicht/falsch verschlüsselt wird und daher im Browser nicht korrekt ankommt und den websocket verhindert.

Hat das schon jemand geschafft, mit WebSocket UND Client Certifiactes unter NGINX?

[saegefisch]

Es geht doch!

Mein Fehler war, dass ich ganzen SSL-Paramter vor den Servern (und damit übergreifend) definiert habe - das macht m.E. vieles übersichtlicher und weniger redundant. Wenn ich (nur) die Client Certificates in den Server zu Port 443 ziehe, dann geht es nun wunderbar, da die CC nicht mehr auf den UPSTREAM bzw. Port 8080 wirken.

Frage gelöst!
Frage zur CRL-Datei bleibt aber interessant...

Gleich die nächste - eher praktische Frage: Die p12-Zertifikate muss man ja eigentlich auf dem Reverse Proxy erstellen, um die ca.crt aktuell zu haben (und ggf. auch die ca.crl). Aber wie bekommt man die Zertifikate sicher und einfach vom RevProxy ins LAN hinter die interne FW? Versuchsweise habe ich ein EXCHANGE-Verezichnis angelegt und sie dort kurz abgelegt und im LAN per Browser dort abgeholt und wieder gelöscht. Da ich ja nur noch per CC drauf komme, schient mir das Verzeichnis auch gut geschützt. Wie löst Ihr das?

[EinAnfaenger]

Du kannst auch nur die für die Visu benötigten Verzeichnisse zugreifbar machen in der Edomi-Reverse-Proxy-Config:

        location /data/ {
                                proxy_pass http://192.168.x.y/data/;
        }
        location /remote/ {
                                proxy_pass http://192.168.x.y/remote/;
        }
        location /shared/ {
                                proxy_pass http://192.168.x.y/shared/;
        }
        location /visu/ {
                                proxy_pass http://192.168.x.y/visu/;
        }

Für die Verwaltung muss dann eben noch

        location /admin/ {
                                proxy_pass http://192.168.x.y/admin/;
        }

dazu.

Für interne Zwecke einfach noch einen weiteren virtuellen Host einrichten, der dann als Root-Verzeichnis irgendein lokales Verzeichnis hat, da kannst Du dann beliebige Dateien reinlegen und nur im LAN drauf zugreifen.

Authentifizierung des WebSockets mit Client-Zertifikat funktioniert wohl leider nicht (zumindest nicht im Reverse-Proxy bzw. habe ich es nicht ans Laufen bekommen). Sollte aber kein Problem sein, evt. den Port von 8080 verlegen, dann landen da weniger HTTP Port-Scans darauf.

Die CRL brauchst Du eigentlich nur wenn Du vorhast Client-Zertifikate zu sperren. Hängt halt davon ab wieviele Zertifikate Du so ausstellen und unters Volk bringen willst. Im Zweifel kann sich ja auch einfach eine komplett neue CA mit neuen Zertifikaten einrichten.

[saegefisch]

Danke für Deine Rückmeldung:
* Wegen der Unterverzeichnisse nur für die Visu: Da sehe ich keinen Vorteil, nur Nachteile/Aufwand. Ich sehe eher eine Umstellung des Zugriffs vom RevProxy zu Edomi via https statt http als ein Sicherheitsplus. Mal schauen.
* Für Die Übergabe habe ich ja bereits ein solches Austauschverzeichnis angelegt. Ich hatte gehofft, es gibt noch andere Ideen, dies zu lösen und dann zwschen den Lösungen entschieden zu können. Aber es geht genau wie Du sagst auch schon
* Wenn Du meinen letzten Post liest, dann halte ich entgegen: Klar geht Websocket und Client Certificate, die entsprechenden SSL-Parameter müssen dem virtuellen Host 443 zugeordnet werden und nicht übergeordnet. --> So sollte das auch bei Dir gehen, Änderung der conf dauert nur 2 Minuten + nginx reload...
* CRL: Okay, da ich darüber auch andere Serverdienste für Freunde und weitere Familie plane, sollte ich dann wohl CRL nutzen, denn das Zurückziehen eines Zertifikats halte ich durchaus für sinnvoll. Danke für diese wichtige Info für mich.

Neue Frage: Kann es sein, dass wenn Port 443 in der Fritzbox für das Portforwading zum Reverse Proxy nutzt, dann kann man per VPN in die FritzBox im LAN nur nur http-Seiten aufrufen, aber keine https-Seiten. Kann das sein?

[EinAnfaenger]

Wenn Du Windows nutzt kannst Du z.B. auch Samba auf der nginx-Machine installieren.

Wenn Du nur dem vHost auf Port 443 das Client Zertifkat zuweist wird das nicht für die WS-Verbindung genutzt. Die WS-Verbindung ist für den Browser aufgrund des abweichenden Ports eine neue Verbindung. Die ist zwar verschlüsselt aber nicht authentifiziert! Das ist allerdings ein Browser Problem (zumindest Chrome kann für ein WS-Verbindung kein Client-Zertifikat senden, auch wenn eins vom Server angefordert wird. Andere WS-Anwendungen nutzen daher ein Unterverzeichnis für die WS Kommunikation und keine zusätzliche Verbindung über einen anderen Port).

Zur Fritzbox: Ja, das tut die (und ist auch gut so). Für den Zugriff von extern musst Du einen anderen Port weiterleiten und dann beim Zugriff sowohl das Protokoll als auch den Port angeben (https://meinhost.ddns.org:1234/)

[benji]

Hi ich muss das Thema nochmal aufgreifen,


ich habe mich jetzt eben nochmal mit dem ReverseProxy beschäftigt. Eigentlich nutze ich VPN für den Zugriff zuhause, seit dem letzten OpenVPN update der iOS App funktioniert aber OnDemand nicht mehr. Da ich keine Lust habe nach jedem Update wieder irgendetwas zu basteln oder sonstiges wollte ich mir ein ReverseProxy für den Zugriff auf die Visu anlegen. In erster Linie auch für meine bessere Hälfte, da es für Sie ohne großen Aufwand wie z.B VPN manuell aufbauen usw. funktionieren soll.

Jetzt bin ich mir nicht sicher, ob ich die Funktion eines ReverseProxy richtig verstanden habe

Der ReverseProxy baut doch lediglich eine https:// Verbindung zu meinem EDOMI auf und ist somit gesichert. Der Zugriff auf den Server wird doch nicht wirklich beschränkt oder? Zudem kann jeder, sofern er meine dyndns kennt, auch auf die Startseite meiner Visu bzw. den Server gelangen. Sehe ich das richtig??

Ich habe bereits einen ReverseProxy für Alexa installiert und dieser läuft auch wunderbar. Jetzt habe ich diesen um folgendes erweitert um eine Weiterleitung auf den EDOMI zu erreichen.

location /{

proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_pass https://<EDOMI_IP>/;
proxy_buffering off;
proxy_connect_timeout 5; # more than http_server
proxy_read_timeout 350; # 60 default, 300s is GNUnet's idle timeout
proxy_http_version 1.1;
proxy_next_upstream error timeout invalid_header http_500 http_503 http_502 http_504;

}

Mit dieser Erweiterung funktioniert auch der Zugriff zu EDOMI Adminseite, Visu logischerweise noch nicht da kein WS Verbindung hergestellt werden kann. Allerdings kann ich ja auch mit dieser Variante auf alle Dateien im EDOMi /www Verzeichnis zugreifen.


Wenn ich anstatt

proxy_pass https://<EDOMI_IP>/;

folgende Zeile angebe:

proxy_pass https://<EDOMI_IP>:80/;

bekomme ich beim zugriff einen Fehler 502 BadGateway.

[jonofe]

folgende Zeile angebe:

proxy_pass https://<EDOMI_IP>:80/;

bekomme ich beim zugriff einen Fehler 502 BadGateway.

:80 und https passt ja auch irgendwie nicht zusammen ...

[benji]

Ja stimmt auch mal wieder

[saegefisch]

Um das Thema SSL und externe Zugriff per Reverse Proxy für mich sauber abzuschließen, habe ich nun noch zwei offene Punkte, der Rest ist millerweile gelöst (z.B. CRL - das Entziehen von Zertifikaten geht wunderbar):Ich halte weiterhin auch im LAN eine SSL-Nutzung für abslut sinnvoll, da in einer Familie jeder (inkl mir) sich einen sniffenden Sonstwas in LAN holen kann und bis man den bemerkt, möchte ich doch gerne, dass keine PW und Daten im Klartext durch die Leitung geflossen sind. Daher möchte ich edomi auch im LAN per SSL nutzen, um auf der letzten Strecke
WWW -- https --> RevProxy -- http --> edomi auch ein "s" hinter das http setzen zu können.

Der Alexa-Anleitung (Kapitel 8) folgend hatte ich rasch admin-Zugang zu edomi per https, aber die visu per websocket will nicht, es braucht also wohl mehr dafür, um im LAN per SSL auf die Visu zugreifen zu können. Bestimmt stand es irgendwo schon, aber ich habe es nicht mehr gefunden. Was ist (vermutlich im Apache) auf edomi-Seite zu tun, damit websocket auch mit https geht?
Anmerkung: Per ReverseProxy geht alles wunderbar (Wie oben beschrieben), aber da läuft die "innere Strecke" ja auch noch per http.

Und: Mit eine eigenen CA fürs ganze LAN und sauber signierten Zertifikaten für jeden Server und dem Import des einen CA-Zertifikats liefert mir edge/IE und Firefox für alle meine Server inkl edomi (der mangels webkit dort natürlich nicht geht) per https ein grünes Schloss. Aber Chrome bleibt bei seinem "Nicht sicher" (ERR_CERT_COMMON_NAME_INVALID), klickt man darauf, zeigt es "Zertifikat ungültig", in den Details hingegen zeigt Chrome mir meine CA und mein Server-Zertifikat als "gültig"...?!? Kennt jemand eine Grund dafür und Mittel dagegen?
Anmerkung auch hier: Per ReverseProxy ist alles grün, da dann ja die LE-Zertifikate greifen.

Danke!

[jonofe]

Hi Carsten,

EDOMI unterstützt keine secure websockets. Siehe auch HIER. Daher geht es nur bis zum Reverseproxy und intern bei direktem Zugriff gar nicht.
Das Problem ist die Änderung, die damals in der app0.php gemacht wurde, damit von außen Secure Websockets verwendet werden können. Dadurch wird nun versucht, wenn man EDOMI per https aufruft auch eine wss Verbindung zur Visu aufzubauen. Das geht nur, wenn diese dann beim Reverse Proxy landet und nicht direkt beim EDOMI Server.

Wenn man in der /usr/local/edomi/www/visu/apps/app0.php wieder das "wss" in "ws" ändert, dann sollte eigentlich auch das Login per SSL im internen Netz funktionieren, aber dann natürlich nicht mehr das https von außen. Das ist zumindest meine Prognose.

Testen kannst du es mit folgender Änderung in /usr/local/edomi/www/visu/apps/app0.php: (das rote "s" löschen)

visu_socket.open(((window.location.protocol=='https:')?'ws[B][COLOR=#FF0000]s[/COLOR][/B]':'ws'),window.location.hostname,<?echo global_visuWebsocketPort;?>);

ändern in:

visu_socket.open(((window.location.protocol=='https:')?'[B][COLOR=#006400]ws[/COLOR][/B]':'ws'),window.location.hostname,<?echo global_visuWebsocketPort;?>);

Bzgl. der Zertifikatswarnung musst du dein root und intermediate Zertifikat deiner CA in Chrome importieren:

=> Settings -> Advanced -> Manage Certificates

Screenshot from 2018-02-12 09-20-13.png


Danach sollte ein grünes Schloss bei allen internen Servern auftauchen, die SSL Zertifikate von deiner CA verwenden.

[EinAnfaenger]

Wenn nur Chrome meckert könnte es an fehlenden Subject Alternative Name Feldern in den Zertifikaten liegen (sowohl der Server- als auch das Root/Intermediate-Zertifikat).