HSTS funktioniert nicht

[maschbauer]

Hallo zusammen,

ich betreibe jetzt schon seit einiger Zeit meine Diskstation und bin mittlerweile mit der Konfiguration soweit zufrieden. Insbesondere nutze ich Nextcloud und Plex. Bei mir läuft das alles gedockert und alle Verbindungen über den Reverse Proxy aus der DSM. Alles ist mit einem Zertifikat abgesichert und - so meine Überzeugung - sollte auch nur als https erreichbar sein.
Für jede Subdomain wie cloud.bla.de und plex.bla.de wird zuerst Port 80 auf 443 weitergeleitet und von 443 aus auf die entsprechenden Containerports. Bei letzterer Weiterleitung habe ich das HSTS-Kästchen aktiviert, aber trotzdem kann ich die verschiedenen Dinger auch über http://plex.bla.de erreichen und bekomme von Chrome die Meldung, dass dies nicht sicher sei. Ich habe hier mal noch die Konfigurationsseiten angehängt. Bin ich blöd? Übersehe ich irgendwas ganz offensichtliches? Ich krieg es echt nicht hin. Sollte ja auch nicht so dramatisch sein, da ich die Webseiten nur über die https-Variante aufrufe, aber ich würde gerne auch alles so haben, dass es ganz egal ist, weil die Weiterleitung korrekt funktioniert.

Danke schonmal im Vorhinein
Andreas

 

[King3R]

Hallo,

warum leitest du denn erst von Port 80 auf Port 443 weiter? Das ist meiner Meinung nach völlig unnötig.

Bei mir werden in meiner Fritzbox die Ports 80/443 auf die Port 80/443 der Diskstation weitergeleitet. So habe ich nur diese Ports nach außen hin offen.



Die Auflösung auf meine Docker-Container erfolgt über die Subdomain und den internen Dockerport.



Für meine Diskstation direkt, habe ich das auch in Anwendung. Dazu wird die Subdomain als CNAME auf meine DDNS-Adresse umgeleitet. Das funktioniert bis jetzt ohne Probleme.



Falls du noch Fragen hast, meld dich einfach.

 

[Benares]

@maschbauer
Also bei mir funktioniert der Zugriff, und auch die Umlenkung von http auf https, mit den Einstellungen, wie du sie gemacht hast, einwandfrei - zumindest auf nextcloud. Was mault bei dir denn der Browser beim Zugriff über http? Welches Zertifikat ist dabei im Spiel/wird genutzt/angezeigt?

@King3R
Ich vermisse bei dir die Umleitung von http auf https für andere Anwendungen. https funktioniert ja bei @maschbauer scheinbar. Gelten die Einstellungen im letzten Screenshot nicht nur für den DSM selbst ?

 

[TeXniXo]

Das ist diese Funktion gemeint:
Systemsteuerung - Netzwerk - DSM-Einstellungen (dort dann http zu https umleiten aktivieren)

 

[maschbauer]

Bei der Nextcloud funktioniert es, bei allen anderen Subdomains funktioniert es seltsamerweise nicht. Die kann ich mit auch ohne https:// erreichen und bekomme wie geschrieben die Sicherheitswarnungen.
@TexniXo: Mit der Einstellung leite ich aber nur den DSM-Zugriff um, aber selbst das funktioniert nicht.
nas.bla.de leitet um auf localhost:5001 und in den DSM-Einstellungen ist die Weiterleitung von http auf https aktiviert, aber es passiert nichts.
@King3R: Ich leite 80 auf 443 weiter, weil ich ja https-Verbindungen haben will. Wenn ich nur die 443 auf irgendwelche Container-Ports weiterleite, dann muss ich im Browser auch wirklich https://nas.bla.de eingeben. Tue ich das nicht und leite 80 nicht auf 443 weiter, dann kommt eine Fehlermeldung, weil Synology keinen Seiteninhalt findet.
Irgendwie glaube ich, dass in meinem NAS die Reverse-Proxy Regeln nicht richtig geschrieben werden von DSM.

 

[King3R]

@Benares
Da in Betrag #1 die Weiterleitung von Port 80 > Port 443 > Port 5000 erfolgt, bin ich erstmal von der HTTPS-Verbindung der Diskstation ausgegangen. Die Umleitung von Port 80 > Port 443 siehst du bei mir im 2. Bild. Wenn HSTS eingestellt ist, sollten normalerweise alle Anfragen, die auf baikal.example.org:80 eingehen, auf baikal.example.org:443 umgeleitet werden.

@maschbauer
Sind alle deine Weiterleitungen wie in Beitrag #1 aufgebaut? Falls ja, habe ich da eine Vermutung. Vielleicht interpretiert der Browser die Weiterleitung Port 80 (unverschlüsselt) > Port 443 (verschlüsselt) > Port 5000 (unverschlüsselt) halt generell als unverschlüsselt. Ungeachtet dessen, versuch mal das localhost durch die IP der Diskstation zu ersetzen.

Deine Intension mit der Umleitung habe ich verstanden, aber wie schon im vorangegangenen Absatz geschrieben, sollte es unnötig sein extra eine Weiterleitung von Port 80 > Port 443 zu erstellen, da HSTS das ja bewerkstelligen soll.

Wenn du dir im Beitrag #2 mein letztes Bild anschaust, dient die obere Umleitungsoption dazu den interen Port 5000 > 5001 für die Diskstation umzuleiten. Das ist aber nur relevant im interen Netzwerk. Möchte man von außen auf die Diskstation nur über HTTPS zugreifen, dann muss man die untere Umleitungsoption wählen. Ich habe es gerade noch einmal probiert, ist die untere Option ausgeschaltet kann ich über dsm.example.org:80 auf meine Diskstation, ist sie aktiviert wird dsm.example.org:80 automatisch auf dsm.example.org:443 umgeleitet.

Probier bitte mal die Einstellungen, wie ich Sie für die Diskstation gesetzt habe bei dir aus. Deaktiviere gleichzeitig deine Weiterleitungen für die Diskstation im Reverse Proxy und berichte dann mal.

 

[Benares]

So, ich hab jetzt auch nochmal ein paar Versuche unternommen.

Ziel ist es ja wohl, verschiedene Docker-Anwendungen (nennen wir sie mal app1, app2, ...) nach außen zu öffnen und http-Zugriffe darauf auf https umzuleiten.
http://app1.example.com und https://app1.example.com sollen also bei https://app1.example.com landen, bei app2 usw. ebenso.

Der Ansatz von King3R hat mich da nicht wirklich weiter gebracht. Das mag zwar alles für den DSM selbst passen, aber für andere Anwendungen nicht. Von daher war der Ansatz von @maschenbauer völlig richtig. Einen https-Reverse-Proxy pro APP, und dann noch einen für http, falls unbedingt gewünscht.

Die Falle dabei ist, dass man ein oder mehrere Zertifikate braucht, die die verwendeten Namen abdecken und dies der entsprechenden https-Revers-Proxy-Einstellung zuordnet (Systemsteuerung->Sicherheit->Zertifikat->Konfigurieren). Zum Glück hatte ich kürzlich mit Wildcard-LE-Zertifikaten experimentiert und auch eines für *.example.com erstellt. Dazu noch ein paar CNAMEs für die jeweilige APP und schon flutscht es.

Mit http://dsm.example.com komme ich nun gesichert auf den DSM (DSM-Einstellungen lt. King3R) und mit http://app[n].example.com (doppelter Reverse-Proxy lt. @maschenbauer) gesichert auf die jeweilige APP.

 

[maschbauer]

@King3R:
Ich hatte die DSM-Seite bislang auch über die Reverse Proxys im Anwendungsportal weitergeleitet. Ich bin jetzt mal den von die vorgeschlagenen Weg gegangen und habe den eigens konfigurierten Reverse Proxy abgeschaltet. Siehe da, das funktioniert jetzt. Leider löst es mein Problem ja lediglich für die DSM-Oberfläche. Aber es ist auf jeden Fall schonmal ein Schritt in die richtige Richtung, vielen Dank dafür!
Wenn ich bei den anderen Subdomains die 80/443 Regel weglasse, dann reicht ein Aufruf von plex.domain.de in einem komplett neuen Browser nicht aus, um die Seite aufzurufen, weil der ja erstmal auf Port 80 geschieht und die Diskstation dann nicht weiß, wohin damit. Für mich ist das nicht relevant, ich weiß ja woran es liegt, aber das ist mir nicht narrensicher genug, um die Domain auch anderen Leuten weiterzugeben.
Hast du vielleicht neben der DSM-Oberfläche noch weitere Subdomains, mit denen du das mal testen kannst, ob du meine Probleme da auch hast, oder ob bei dir immer auf irgendeine Art und Weise auf Port 443 weitergeleitet wird.

@Benares: Ich habe zwei Zertifikate. Nr. 1 lautet auf dyndns.domain.de und hat noch einige Alias-Namen, u.a. plex,nas,cloud, die hierüber laufen. Dann habe ich noch eins für jupyter.domain.de. Die jeweiligen Subdomains sind immer einem dieser Zertifikate zugeordnet, aber die Weiterleitung funktioniert nicht, unabhängig davon, ob der eigentliche Zertifikatsname und die Domain übereinstimmen (bei jupyter.domain.de) oder nicht (bei allen anderen). Ein Wildcard-Zertifikat habe ich nicht probiert, da mein Domainregistrar da nix unterstützt und ich mir einen neuen suchen muss, damit ich nicht die TXT-Einträge manuell setzen muss. Kann es wirklich daran liegen, dass ich hier ohne Wildcard-Zertifikat arbeite? Das wäre unschön, aber immerhin lösbar, wenn ich meinen Hoster wechsel. Andererseits kann ich mir nicht so ganz vorstellen, dass man unbedingt ein Wildcard-Zertifikat braucht, denn bei den Einstellungen, die ich mit Kin3Rs Lösung gesetzt habe, funktioniert ja alles. Genau wie bei meiner Nextcloud, aus Gründen, die ich nicht nachvollziehen kann. Ich versuch mal die von DSM angelegten Configs zu verstehen, vielleicht bringt mich das auf eine Idee.
So aus Interesse, bei welchem Anbieter hast du deinen DNS-Server?

Ich hatte als alternative Lösung auch mal einen komplett selbst konfigurierten Reverse-Proxy auf einem Raspberry, dort wird das Protokoll geändert, aber damit wollte die Kombi Nextcloud/Onlyoffice nicht arbeiten, irgendwie ist das die Wahl zwischen Pest und Cholera.
Auch eine Lösung, bei der ich Port80 erstmal auf einen vHost umleite, in dem dann das Protokollrewrite über eine .htaccess-Datei stattfinden soll, funktioniert nicht. https://blog.golimb.com/2017/07/14/synology-reverse-proxy/

 

[Fusion]

Nur mal ein Einwurf zu einem anscheinend grundsätzlichen Missverständnis. HSTS ist keine automatische https Umleitung!
HSTS dient dazu ein Gerät welches per https zugreift anzuwenden die aufgerufene Domain innerhalb der nächsten 90/180 oder anderer Anzahl im Header definierter Tage NICHT per http zu besuchen, oder die Verschlüsselung herunter zu stufen.
Also ja, WENN ich einmalig (trust on first use Prinzip) per https auf der Seite war wird der Client auch die nächsten 180 Tage https benutzen, auch wenn ich es per http versuche.
In diesem Sinne findet eine http > https Umleitung statt, aber nur wenn eben ein einmaliger https Zugriff voraus ging.

Zusätzlich verschleiernd kann hier wirken, wenn die Browser selbst entweder über Erweiterungen wie 'https-first' oder anderen Maßnahmen schon von sich aus probieren ob eine Seite nicht vielleicht per https erreichbar ist. Ist also nicht immer offensichtlich welche Ursache (Browser Einstellung, Erweiterung, Webserver config etc) einem Symptom (augenscheinlich Umleitung zu https) zugrunde liegt.

 

[Benares]

Der Beitrag von Fusion hat mich jetzt stutzig gemacht. Vielen Dank dafür.

Ja, es scheint wirklich so zu sein, dass der http->https-Reverse-Proxy gar nicht wirkt. Erst wenn man mal auf der https-Seite war, landet man auch beim http-Zugriff dort. Dafür sorgt wohl aber HSTS und nicht der Proxy. Wenn man den Browser-Cache leert, landet man beim http-Zugriff wieder auf der ungesicherten Seite. Keine Ahnung, warum das so ist.

Ich bin bei Strato. Man braucht nicht unbedingt ein Wildcard-Zertifikat, es ist nur bequemer, wenn man ständig mit anderen Namen experimentiert. Hauptsache die verwendeten Namen sind in der Liste "Alternative Antragstellername" mit dabei. Bei mir steht da halt nur *.example.com und nicht jeder Name einzeln.

 

[Penthys]

Ich hab dafür in /usr/local/etc/nginx/sites-enabled eine redirect.conf angelegt - name ist beliebig - und für jeden host einen redirect auf https dort drin stehen:

server {
listen 80;
server_name meine.sub.domain;

return 301 https://$host$request_uri;
}

Da ist es etwas eleganter und aufgeräumter und übersteht config changes, reboots und normale DSM updates.

 

[Benares]

Vielen Dank - das war die Lösung - funktioniert einwandfrei

Ich habe für jede APP so eine Datei unter /usr/local/etc/nginx/sites-enabled angelegt (www-redirect.conf, app1-redirect.conf, app2-redirect.conf...) und die http->https-Reverse-Proxies gelöscht.
Jetzt lande ich auch nach dem Löschen des Browser-Caches beim http-Zugriff auf den zugehörigen https-Seiten.

 

[maschbauer]

Danke in die Runde, jetzt funktioniert es wunderbar!
@Fusion, dann hat HSTS in diesem Sinne bei mir also doch funktioniert. Weil das von dir beschriebene Verhalten habe ich schon vorher gesehen. Ich hatte nur gedacht, dass es zusätzlich auch sicherstellt, dass ein nicht https-Zugriff verhindert wird, aber das war beim ersten Aufruf nicht der Fall.
@Penthys: Das war die Lösung! Ich hatte gestern auch noch in den config-Files gesucht und gesehen, wo der große Unterschied ist, zwischen der Zwangsumeleitung, die man für die DSM-Oberfläche setzen kann und die 80/443-Weiterleitung im Anwendungsportal.
So sieht eine manuell gesetzte Weiterleitung aus:

server {
    listen 80;
    listen [::]:80;
    resolver 192.168.178.1 [ipv6];
    set $backend "https://cloud.domain.de:443";
    server_name cloud.domain.de;
    location / {
        proxy_connect_timeout 60;
        proxy_read_timeout 60;
        proxy_send_timeout 60;
        proxy_intercept_errors off;
        proxy_http_version 1.1;
        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_pass $backend;
    }
    location ^~ /.well-known/acme-challenge {
        root /var/lib/letsencrypt;
        default_type text/plain;
    }
    error_page 403 404 500 502 503 504 @error_page;
    location @error_page {
        root /usr/syno/share/nginx;
        rewrite (.*) /error.html break;
        allow all;
    }
}

und so die von DSM selbst gesetzte entsprechend der Lösung von King3R:

    server {
        listen 80;
        listen [::]:80;
        server_name nas.domain.de;
        set $fqdn nas.domain.de;
        location ^~ /.well-known/acme-challenge {
            root /var/lib/letsencrypt;
            default_type text/plain;
        }
        location / {
            return 301 https://$server_name$request_uri;
        }
    }

Sprich, wer wirklich eine Zwangsumleitung auf https haben will, der muss wohl config-Dateien schreiben und kann sich auf die DSM-Oberfläche nicht verlassen, was ich schade finde. Danke nochmal an alle, die bei der Lösung des Problems geholfen haben!

 

[King3R]

Hast du vielleicht neben der DSM-Oberfläche noch weitere Subdomains, mit denen du das mal testen kannst, ob du meine Probleme da auch hast, oder ob bei dir immer auf irgendeine Art und Weise auf Port 443 weitergeleitet wird.

Dass es für die DSM-Oberfläche funktioniert, ist doch super. Leider habe gerade nicht so viel Zeit um das Testen zu können. Da es aber jetzt die funktioniernde Lösung von Penthys gibt, ist das ja nicht so schlimm. Ich werde mir das aber nochmal anschauen, sobald ich wieder mehr Zeit habe. Es muss doch auch über die GUI zu lösen sein, sonst hätte sich ja Synology damit einen Bock geschossen. Mir ist aber aufgefallen, dass die HSTS-Checkbox in den DSM-Einstellungen gar nicht ausgewählt sein muss, solange die HTTPS-Umleitung für den DSM-Desktop weiter oben ausgewählt ist. Muss man nicht verstehen.

Normalerweise sollten die Zertifikate für die Subdomains ausreichen, Ein Wildcard-Zertifikat ist halt komfortabler, wenn man des öfteren mit den Subdomains rumspielt bzw. die ändert/hinzufügt. Ich bin z. B. mit meinen Domains bei hosting.de, da kostet eine .de-Domain 2,90€/Jahr exkl. des DDNS-Services (zusätzl. 6€/Jahr). Ich finde das unschlagbar. Ich nutze aber nsupdate.info als DDNS-Service und leite dann die Subdomains als CNAME um. Die Zertifikate hole ich mir über den acme.sh Docker-Container. In acme.sh ist eine API für hosting.de und ein Deployhook für die Synology enthalten. Funktioniert bis jetzt alles reibungslos.

Nur mal ein Einwurf zu einem anscheinend grundsätzlichen Missverständnis. HSTS ist keine automatische https Umleitung!

Ich habe mal einen älteren Beitrag von dir rausgesucht, da ging es um die gleiche Frage. Ich habe das gerade nochmal probiert, wenn ich das für den DSM-Desktop einstelle, funktioniert die sofortige automatische Umleitung auf HTTPS, ohne das ich das Ganze vorher per HTTP aufrufe. Irgendwie scheint das Synology nicht einheitlich hinzubekommen.

Ich hab dafür in /usr/local/etc/nginx/sites-enabled eine redirect.conf angelegt ...

Danke, das werde ich demnächst auch mal ausprobieren.

Sprich, wer wirklich eine Zwangsumleitung auf https haben will, der muss wohl config-Dateien schreiben und kann sich auf die DSM-Oberfläche nicht verlassen, was ich schade finde.

Ist halt die Frage, warum das Synology das über die GUI nicht hinbekommt. Für welche, die sich nicht so tief in der Materie befinden, sollte es doch eigentlich auch eine funktionierende Lösung über die GUI geben. Vielleicht ja mit DSM 7 ...

@alle
Nutzt ihr nun generell den Reverse Proxy der Diskstation nicht mehr, macht ihr das ganze immer über die Konsole oder verwendet ihr einen anderen Proxy?

 

[synfor]

Mir ist aber aufgefallen, dass die HSTS-Checkbox in den DSM-Einstellungen gar nicht ausgewählt sein muss, solange die HTTPS-Umleitung für den DSM-Desktop weiter oben ausgewählt ist. Muss man nicht verstehen.

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.

 

[Fusion]

@king3R - ja, meine Aussage in dem alten Thread dazu ist leider nicht korrekt gewesen. Das lässt sich leider nicht mehr korrigieren.
Von daher nochmal :
- 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. Dies hat nichts zu tun mit
- https Umleitungen die sich an diversen Stellen im DSM tummeln. Dass diese (in der Gui) nicht für sämtliche Dienste die ich mir auf der Syno realisieren kann gelten / möglich sind ist Fakt. Das greift nur für den DSM und die meisten syno eigenen Anwendungen.
- reverse proxy, natürlich nutzt man die, aber das hat ebenfalls nichts mit https Umleitung zu tun.

Will man in allen Lagen eine https Umleitung, muss man dies selbst in die Hand nehmen, sei des erweiterte nginx config, oder htaccess für Apache.
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.

Persönlich habe ich manche Dienste überhaupt nicht als http Variante geöffnet. Dann fällt halt für den Benutzer der Komfort weg, dass er mit sub.example.com arbeiten könnte, sondern er muss halt direkt https://sub.example.com verwenden bzw eingeben, falls sein gewählter Browser nicht eh https-first oder ähnliches benutzt.
In den Syno Apps wie DS Audio, Drive etc muss man ja eh ein https Häkchen setzen wenn man es nutzen will.
Dann braucht es auch keine https-Umleitung.

 

[synfor]

Außerdem sollte sich so langsam herumgesprochen haben, dass viele Seiten gar nicht mehr unverschlüsselt aufgerufen werden können.

 

[maschbauer]

Ich hatte zwischenzeitlich auch mal den Synology-Support kontaktiert. Heute kam eine Antwort, ich solle mich an Docker wenden, man könne mir nicht weiterhelfen. Ich habe nochmal versucht die Situation mit all den Erkenntinssen aus dem Forum zu schildern, um hier eine Aussage zu bekommen, ob wir alle etwas übersehen, oder ob das nur über Config-Files realisiert werden kann. Ich bin gespannt und werde euch auf dem Laufenden halten.

 

[Penthys]

@alle
Nutzt ihr nun generell den Reverse Proxy der Diskstation nicht mehr, macht ihr das ganze immer über die Konsole oder verwendet ihr einen anderen Proxy?

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.

 

[Penthys]

... ob wir alle etwas übersehen, oder ob das nur über Config-Files realisiert werden kann. ...

Die Option, bei Reverse Proxy http auf https weiterzuleiten, ist in der GUI nicht drin, wir übersehen die nicht. So viele wie da inzwischen drauf geschaut haben... Es wäre jemanden aufgefallen. Solange Synology das nicht einbaut gibt's nur die zusätzliche Config.