HSTS funktioniert nicht

[King3R]

Das ist doch ganz einfach, HSTS sorgt dafür, das der Browser nur noch HTTPS benutzt, wenn er einmal die Seite per HTTPS aufgerufen hat.

Mir ist bewusst was HSTS für eine Funktion hat. Ich hatte bei meinem Test die HSTS-Checkbox ausgeschaltet und die Cookies gelöscht, damit HSTS nicht greift. Meine Annahme war, dass die Checkbox "HTTP-Verbindung des DSM-Desktop auf HTTPS umleiten" nur intern funktioniert und die benutzerdefinierte Domain außen vor lässt. Dem war aber nicht der Fall. Somit brauch man in diesem Fall die HSTS-Funktion eigentlich gar nicht.

hsts soll ein downgrade der Verbindung eines Besuchs ohne https für eine gewisse Zeit verhindern, wenn ein erstmaliger Besuch per https stattgefunden hat. Das kann ausgehebelt werden wenn man einen neuen Client benutzt oder alle website-daten/cookies löscht etc.

Ich habe das Ganze gerade nochmal getestet, einmal mit gelöschten Cookies und das andere Mal im Private-Mode vom Firefox. Ich habe die HSTS-Checkbox aktiviert, danach habe ich die Seite jeweils mehrmals über die HTTP-Verbindung aufgerufen, ohne vorher die HTTPS-Verbindung zu nutzen. Bei jedem Versuch wurde ich trotzdem automatisch auf die HTTPS-Verbindung umgeleitet. Aus meiner Sicht ist deine damalige Aussage also korrekt. Dass das nur für die Diskstation-Dienste gilt ist mir nun klar. Ungeachtet dessen, werde ich die HSTS nicht weiter nutzen, sondern auf die manuelle Lösung umsteigen. Ich hab da gern was Einheitliches und kein Stückwerk.

Natürlich könnte man das in die Gui einbauen, wäre am Ende ja nichts anderes als das was wir mit den configs machen. Nur ist ein Haken in der Gui 'http > https' eben unter der Haube bei webstation vhosts, reverse proxy, nginx/apache Benutzer-Webserver, etc immer anders umzusetzen.

Wenn Synology was an seinen Nutzern liegen würde, würden Sie das noch irgendwann einbauen. Vielleicht ja mit DSM 7, ich glaub aber nicht so recht dran.

Bei mir ist der Synology Reverse Proxy nach wie vor zuständig um Subdomains an Dienste zu vermitteln. Die Zusatzkonfiguration ist nur für die http-zu-https Weiterleitung und eine weitere ist eingerichtet um zusätzlich zu subdomains auch subfolder zu erlauben. Subfolder macht die Reverse-Proxy-GUI von Synology nämlich auch nicht, aber möglich ist es sowas einzurichten. Bei Diensten die damit kein Problem haben kann ich so entweder app.domain oder domain/app verwenden, wie man es bei den Synology-internen Diensten ja auch machen kann.

Kannst du das mit den Subfolders vielleicht näher ausführen?

 

[Fusion]

@King3R - das Symptom mag zur damaligen Aussage passen, aber von der technischen Spezifikation dürfte das nicht an HSTS liegen. Firefox hat ja auch z.B. ein https_only_mode, der ist zwar in der aktuellen v77 noch nicht auf Automatik, aber in dieser Richtung würde ich eher den Verursacher vermuten. Wie dem auch sei, bin bei dir, wenn man eher nach Lösungen schaut die über alle Browser, mit/ohne Erstbesuch etc funktionieren, oder gleich nur die https Dienste anbietet.
Dass Synology nichts an seinen Benutzern liegt glaube ich nicht. Was ich glaube ist, dass die Prioritäten bzw. die Marschrichtung in die sie Weiterentwicklung betreiben nicht unbedingt mit unseren Prios übereinstimmt.

 

[King3R]

Ich habe mir auch gerade nochmal die Spezifikation angeschaut, du hast natürlich recht, sollte eigentlich so nicht funktionieren. Dann ist wohl eher die Frage, warum die Spezifikation nicht eingehalten wird. Ab es an der Diskstation liegt, lässt sich wahrscheinlich leider nicht ohne größeren Aufwand herausfinden. Da es auch auf andere Art funktioniert, sollten wir es dabei belassen. Du hast vermutlich recht, war ein bisschen überspitzt dargestellt. Der Nutzer möchte halt immer als erstes das haben, was zu seinem eigenen Workflow passt. Das kann man im Normalfall aber leider nicht auf die gesamte Nutzerschaft bzw. den betriebswirtschaftliches Aspekt des Herstellers übertragen.

 

[Penthys]

HSTS als zusätzliches Sicherheitsmerkmal halte ich schon für sinnvoll. Es erzwingt zum Beispiel auch, dass eine Domain über ein passendes Zertifikat abgesichert wird. Insgesamt einfach ein weiteres Plus an Sicherheit.

Da der Reverse Proxy nur entweder HTTPS oder HTTP erlaubt, aber nicht beides, ist es nicht so ganz trivial ein Redirect http->https per Haken einzurichten. Die GUI müsste immer auch prüfen, ob es nicht bereits ein HTTP Proxy für die Domain gibt. Der nginx merkt das auf jeden Fall und ignoriert einen der beiden Einträge im besten Fall oder läuft nicht mehr richtig im schlechten Fall.

Bezüglich der Subfolder wollte ich einfach eine weitgehend konsistente Konfiguration der Dienste haben. Zum Beispiel aktiviere ich im Anwendungsportal bei der Videostation den Alias und kann per domain/video darauf zugreifen. Zusätzlich ein Häkchen bei 'Benutzerdefinierte Domain' und video.domain ist auch möglich.
Da es nicht für alle gewünschten Systemen einen Video Station Client gibt, z.B. Kodi, habe ich einen Emby-Server laufen. Per Reverse Proxy über emby.domain erreichbar aber domain/emby lässt sich über die GUI nicht einrichten. Das habe ich dann halt auch über manuelle Konfiguration gemacht. Das funktioniert allerdings nicht mit allen Diensten. Sobald absolute und kein relativen Pfade verwendet werden, bekommt man nur Kraut und Rüben statt der gewünschten Oberfläche, z.B. bei mir mit Bitwarden.

Letztlich ist es das, was die Proxy GUI baut, angepasst für Subfolder. Hier als Beispiel für Emby und Calibre Content Server:

server {
    listen 443 ssl http2;
    server_name my.main.domain;

    location /emby/ {
       proxy_set_header        Host                $http_host;
       proxy_set_header        X-Real-IP           $remote_addr;
       proxy_set_header        X-Forwarded-For     $proxy_add_x_forwarded_for;
       proxy_set_header        X-Forwarded-Proto   $scheme;
       proxy_set_header        Upgrade             $http_upgrade;
       proxy_set_header        Connection          $connection_upgrade;
       proxy_intercept_errors  on;
       proxy_http_version      1.1;

       proxy_pass http://localhost:8096/;
    }

    location /ebooks/ {
       proxy_set_header        Host                $http_host;
       proxy_set_header        X-Real-IP           $remote_addr;
       proxy_set_header        X-Forwarded-For     $proxy_add_x_forwarded_for;
       proxy_set_header        X-Forwarded-Proto   $scheme;
       proxy_set_header        Upgrade             $http_upgrade;
       proxy_set_header        Connection          $connection_upgrade;
       proxy_intercept_errors  on;
       proxy_http_version      1.1;

       proxy_pass http://localhost:8081/;
    }
}

Die Konfiguration am besten immer mit sudo nginx -t testen und wenn erfolgreich mit sudo nginx -s reload aktivieren. Im Fehlerfall sagt nginx recht genau wo es hakt.

 

[King3R]

Danke, werde ich mal testen.