DSM 6.x und darunter HSTS deaktivieren? Kein Zugriff auf verschlüsselte Dienste!

[SoniX]

Hallo,

ich habe seit eben ein Problem auf meine Diskstation per Domain zuzugreifen.

Google Chrome meldet mir bloß "Dies ist keine sichere Verbindung".

Weiters:
"domain.com schützt Ihre Daten in der Regel durch Verschlüsselung. Als Google Chrome dieses Mal versuchte, eine Verbindung zu domain.com herzustellen, gab die Website ungewöhnliche und falsche Anmeldedaten zurück."

Und:
"Sie können domain.com zurzeit nicht aufrufen, da die Website HSTS verwendet."

Woher kommt plötzlich HSTS?
Wieso klappt die verschlüsselte Verbindung nichtmehr wo sie nun doch seit Jahren funktionierte?

Ich nutze ein gültiges Commodo Zertifikat gültig bis 2018.
HSTS Einstellung finde ich bloß unter "Netzwerk, DSM Einstellungen, Domain".
Dort ist es allerdings nicht aktiviert! Domain ist ebenfalls keine eingetragen. Die Option ist als ganzes deaktiviert.

Bitte wie kann ich das schnell beheben? Ich muss in 2 Stunden los und der Zugriff sollte klappen.

Vielen Dank!

PS: Auch auf meiner zweiten Diskstation habe ich plötzlich das gleiche Problem. Kein Zugriff über den Browser und Domain mehr möglich!

PPS: Gestern Abend klappte es noch und seitdem hatte ich nichts geändert!

PPPS: Auf einem zweiten PC klappte ein einmaliger Zugriff, beim zweiten Aufruf aber gleiches Fehlerbild. Auch hier nun kein Zugriff mehr.

PPPPS: Gestern stand ein Photostatio Update an welches ein paar Lücken behob. Ist das das Problem? Wobei auf der zweiten DS keine Photostation läuft.

PPPPPS: Zugriff per Handy Apps klappt. Ebenso per Handybrowser.

 

[SoniX]

So,

Ich glaube das Problem ist gelöst.

In Chrome unter chrome://net-internals/#hsts kann man HSTS Einstellungen zu einer Domain löschen lassen.

Seitdem klappt der Zugriff wieder.

Aber woran lags?

 

[SoniX]

Hat niemand ne Ahnung wie dieser Fehler zustandekommt?

Ich kann mich paarmal einloggen, dann gehts wieder nicht.
Ich muss dann jedesmal die Browsereinstellungen zur Domain löschen und das nervt doch ziemlich.

Woher kommt das?

"Sie können domain.com zurzeit nicht aufrufen, da die Website HSTS verwendet."

"domain.com schützt Ihre Daten in der Regel durch Verschlüsselung. Als Google Chrome dieses Mal versuchte, eine Verbindung zu domain.com herzustellen, gab die Website ungewöhnliche und falsche Anmeldedaten zurück."

Danke!

 

[SoniX]

DS Audio App streikt inzwischen auch. Sagt nur "Keine Verbindung zum Netzwerk", DS File auf der gleichen DS aber klappt. Online ist sie. Per Handybrowser habe ich den gleichen Mist mit HSTS. Aufs DSM mittels Domain zugreifen klappt auch nichtmehr "Es tut uns Leid, die von Ihnen gesuchte Seite konnte nicht gefunden werden.".

Bitte wie bekomme ich das weg??

Scheiss Zertifikatsdreck aber auch!!

 

[Fusion]

Ohne detaillierte Informationen ist die Fehlersuche schwierig.

Domain und DNS Konfiguration beim Provider?
Weiterleitungen / Konfiguration im Router?
Einstellungen in Web Station > vHost?
Einstellungen in Systemsteuerung > Netzwerk > DSM Einstellungen?
Einstellungen in Systemsteuerung > Anwendungsportal > Anwendungen / Reverse proxies?
Einstellungen in Systemsteuerung > Externer Zugriff (Erweitert)?

HSTS steht für den strengen Einsatz von SSL.
Eventuelle Ungereimtheiten bei Zertifikaten und der Aufruf wird verhindert.
Ebenso werden http Anfragen auf https umgesetzt.
Nach dem einmaligen Aufruf merkt sich der Browser dies auch und greift auf eine Domain dann nur noch per https zu.

 

[SoniX]

Werde versuchen alle Infos nachzubringen. Ist ein bisschen komplex wenn der Zugang nicht klappt.

Aber vorab: Wäre es nicht weit einfacher HSTS zu deaktivieren? Ich brauche es nicht, habe es nie aktiviert und es ist auch deaktiviert. Wieso meckert der Browser überhaupt darüber wenn es doch nicht benutzt wird? Ich möchte auch garnicht dass der Browser Details zu meiner verschlüsselten Verbindung aufzeichnet; das ist bloß wieder ne Fehlerquelle; wie man sieht.

Erzwungene Verschlüsselung habe ich mittels Umleitung sowieso.

PS: So, ein paar Infos kann ich schonmal liefern:
Bilder sagen oft mehr als tausend Worte.

Externer Zugriff - Erweitert:


Reverse Proxy (noch nie benutzt und dementsprechend leer):


Virtueller Host (dito):


DSM Einstellungen (HSTS ist hier deaktiviert, war auch noch nie aktiviert):

 

[SoniX]

Liegt es vielleicht daran weil ich mehrere DS mittels gleicher Domain erreichbar habe?

Oder am Synology dyndns Dienst der die Verbindung entsprechend weiterleitet (habe keine fixe IP)?

In allen Fällen wäre eine deaktivierung von HSTS die Lösung.

 

[Fusion]

Im Auslieferungszustand ist HSTS nicht aktiv. Solange man also die Ursache nicht findet kann man auch nicht "mal eben deaktivieren"

Zu den teilweise beantworteten Fragen noch weitere:
Hast du jemals per Konsole/SSH an config Dateien des Webservers Änderungen vorgenommen (nextcloud/owncloud bezüglich, oder andere)?

Der Browser zeichnet keine Details auf, er merkt sich nur welche Domain er unter SSL erreicht hat.
Der nächst schärfere Schritt dazu ist Zertifikat Pinning (webserver config), so dass auch nur ein bestimmtes Zertifikat (mit Fingerabdruck X) zugelassen ist.
Als das dient dazu Angriffe zu erschweren, bei denen jemand versucht einem ein falsches zertifikat bzw einen anderen Server / andere Inhalte unterzujubeln.

Den Port bei Externer Zugriff kannst dir schenken solange der öffentliche Port mit dem Port unter Netzwerk > DSM Einstellungen übereinstimmt geht er eh davon aus, dass dieser von außen erreichbar ist.

https Umleitung meinst du die unter Netzwerk > DSM Einstellungen oder hast du noch woanders was in die Richtung eingestellt?
Diese Umleitung habe ich bei mir nicht gesetzt und nur bei allen Hosts HSTS aktiviert und vom DSM ist sowieso nur ein https Port oder gar kein Port von extern erreichbar gesetzt (damti hatte ich jedenfalls in den letzten jahren weniger Probleme).

Wie genau hast du die mehreren DS unter gleicher Domain erreichbar?
Einfach nur verschiedene Ports für DSM weitergeleitet? 500x > DS1, 500y > DS2 etc?
Wenn ja, dann sollte dies egal sein solange der Aufruf via https://domain:500z erfolgt.

Wenn du hingegen nas1.domain.de oder nas2.domain.de aufrufst so ist dies gleichbedeutend mit "Anfrage auf Port 80, an welches Ziel wird Port 80 weitergeleitet?" für deinen Router. Das ist wie bei Highlander: Es kann nur einen geben bzw. es gibt nur eine DS an die Port 80 weitergeleitet wird.
Genauso bei der Beantragung von LE Zertifikaten. Das geht nur auf der DS an die die Ports 80/443 weitergeleitet sind.

 

[SoniX]

Im Auslieferungszustand ist HSTS nicht aktiv. Solange man also die Ursache nicht findet kann man auch nicht "mal eben deaktivieren"

Zu den teilweise beantworteten Fragen noch weitere:
Hast du jemals per Konsole/SSH an config Dateien des Webservers Änderungen vorgenommen (nextcloud/owncloud bezüglich, oder andere)?

Nop, auf dieser DS nicht. Versuche soweit möglich alles nur über die offiziell zur Verfügung gestellte Oberfläche zu machen damit ich nicht in irgendwelche Probleme laufe.

Der Browser zeichnet keine Details auf, er merkt sich nur welche Domain er unter SSL erreicht hat.
Der nächst schärfere Schritt dazu ist Zertifikat Pinning (webserver config), so dass auch nur ein bestimmtes Zertifikat (mit Fingerabdruck X) zugelassen ist.
Als das dient dazu Angriffe zu erschweren, bei denen jemand versucht einem ein falsches zertifikat bzw einen anderen Server / andere Inhalte unterzujubeln.

Aber irgendwas muss er auch aufzeichnen sonst könnte er nicht sagen dass diesmal irgendwas anders ist und er deswegen die Seite nicht aufruft. Der Aufruf klappt auch wenn man die HSTS Einstellungen im Browser löscht. Für ein paar mal, dann wieder der Fehler.

Den Port bei Externer Zugriff kannst dir schenken solange der öffentliche Port mit dem Port unter Netzwerk > DSM Einstellungen übereinstimmt geht er eh davon aus, dass dieser von außen erreichbar ist.

Den habe ich wegen der Benachrichtigungen drin. Wenn da der Port nicht drinsteht, dann bekomme ich in der Emailbenachrichtigung nicht meine Domain geliefert sondern nur die IP.

https Umleitung meinst du die unter Netzwerk > DSM Einstellungen oder hast du noch woanders was in die Richtung eingestellt?

Ja, das meinte ich. Aber ich habe schon auch weitere Umleitungen. Siehe nächste Antwort.

Wie genau hast du die mehreren DS unter gleicher Domain erreichbar?
Einfach nur verschiedene Ports für DSM weitergeleitet? 500x > DS1, 500y > DS2 etc?
Wenn ja, dann sollte dies egal sein solange der Aufruf via https://domain:500z erfolgt.

Wenn du hingegen nas1.domain.de oder nas2.domain.de aufrufst so ist dies gleichbedeutend mit "Anfrage auf Port 80, an welches Ziel wird Port 80 weitergeleitet?" für deinen Router. Das ist wie bei Highlander: Es kann nur einen geben bzw. es gibt nur eine DS an die Port 80 weitergeleitet wird.
Genauso bei der Beantragung von LE Zertifikaten. Das geht nur auf der DS an die die Ports 80/443 weitergeleitet sind.

Also ich habe für diverse Dienste die auf meinen DS laufen diverse Ports offen. Diese Ports werden vom Router an die jeweilige DS weitergeleitet.

zB:
443 -> 443 DS-116
5001 -> 5001 DS-116
9008 -> 9008 DS-214play

Das meiste läuft auf der DS-116; nur die Videodienste laufen auf der DS-214play. Die meisten Ports werden direkt durchgereicht. SSH, FTP und Co werden aber umgebogen.

Da ich mir die Ports aber nicht wirklich merken kann habe ich mir Subdomains eingerichtet.
Also zB audio.domain.com; video.domain.com; photo.domain.com; etc.
Diese Subdomains werden vom Webserver der DS116 mittels .htaccess umgeleitet.

Sieht dann so in etwa aus:
RewriteCond %{HTTP_HOST} ^audio.domain.com
RewriteRule ^(.*)$ https://domain.com:8801/$1 [L,NC,QSA]

Hier wird auf verschlüsselte Verbindung gewechselt und an den entsprechenden Port weitergeleitet.

Okay, nun glaube ich komme ich der Sache nächer.
Ich habe auf einem fremden PC nun viele male Dienste der DS116 aufrufen können.
Dann habe ich einmalig einen Dienst der DS214play aufgerufen, welches geklappt hat, aber nun kann ich keine Dienste der DS116 mehr aufrufen.

Es scheint als ob die DS214play und die DS116 unterschiedliche... irgendwas... senden und der Browser dann sicherheitshalber sperrt.
Dürfte nur den Webserver (und damit htaccess) betreffen; die Umleitungen, die ja auch der DS116 liegen klappen dann nichtmehr. Bei direktem Aufruf der Ports klappts weiterhin.

Aber wieso hatte es dann bisher geklappt? Das ganze läuft schon... Monate, Jahre... quasi problemlos. Irgendwas ist anders...

 

[mr coffee]

Ich kann dir zwar nicht helfen aber mach doch die Umleitung via reverse proxy und nicht via htaccess - evtl. löst sich dann dein Problem in Rauch auf.

 

[Fusion]

z.B. die Browser haben sich über die Jahre geändert und nehmen es in Sachen SSL heute genauer als früher.
Du hast früher andere Zertifikate mit längerer Laufzeit gehabt (wobei die laufzeit an und für sich nichts machen sollte).
Du hast .... da hat sich denke mehr geändert als einem bewusst ist.

Das heißt deine Umleitungen mit htaccess finden alle auf der 116 statt (also 80/443 auf die 116 geleitet)?
Kopierst du das LE-Zertifikat für domain.com auch von der einen auf die anderen DSen, oder wie machst das?
Oder hast du jeder DS zeitweise die 80/443 hingeleitet und jeweils ein Zertifikat für domain.com ausgestellt?

In diesem Konstrukt.. ich hab eine Gefühl, aber kann den Finger noch nicht drauf legen, was schief geht.
Wenn du willst, kannst du mir per PN mal je eine Domain pro DS verraten, dann würde ich von hier mal die Seiten laden und schauen, wann welche Umleitung greift und welche Zertifikate er lädt oder Fehler wirft.

Ansonsten ist das ein Anwendungs-Szenario für den Reverse Proxy.
Die DS 116 nimmt alle Anfragen an (Endpunkt der SSL Verbindung, einzige DS mit LE-Zertifikaten und Pflege) und leitet sie dann intern weiter. Damit wäre diese Schleife rückwärts auf die Domain mit Port im Router weg.
Der Reverse proxy wäre in dem Beispiel audio.domain.com.
Das Ziel des Proxy ist dann localhost:8801 oder nas-ip:8001 je nachdem ob auf der 116 oder einer anderen NAS.
Man kann auch intern mit weiteren SSL Verbindungen arbeiten wenn man das will (das geht auch mit selbst-signierten zertifikaten).
Einzige Voraussetzung von extern ist, dass alle sub.domain.com per CNAME auf domain.com bzw. die dynDNS zeigen hinter der der Router steckt.
Ports von außen sind dann auch nur noch 80/443.

Edit:
Apropos htaccess rewrite.
Synology hat ja an nginx und Apache gut geschraubt über die Versionen. Vielleicht funzt der rewrite einfach nicht mehr sauber gerade.
Aber das mal nur so hingeworfen ohne Analyse oder durchdacht.

 

[SoniX]

Hallo und guten morgen

Also bisher hatte ich mit dem reverse Proxy nichts am Hut. Hatte ja so auch geklappt.
Habe mich nun aber etwas eingelesen und finde die Idee dahinter ziemlich praktisch.

Es klingt auch alles sehr einfach.

So ganz wie erhofft läuft es aber doch nicht.
Habe mal testweise eine Subdomain audio2 im DNS angelegt und einen Reverse Proxy Eintrag angelegt.

Zum einen fiel mir auf dass hier keine automatische Umleitung von http zu https erfolgt.
Also wenn ich den Reverse Proxy Eintrag mit Quelle https einstelle, dann muss ich auch zwingend https im Browser eingeben.
Wenn ich nur http nutze bzw nur die Subdomain eintippe, dann lande ich auf dem Webserver.
Es wäre schon sehr fein wenn hier automatisch auf https umgeleitet werden würde. Es ist doch ein Tippaufwand jedesmal https:// vorne mit dranzuschreiben.

Zum anderen ist die Verbindung wenn ich https nutze zwar verschlüsselt, aber es wird über das Zertifikat gemeckert.
"There are issues with the site's certificate chain (net::ERR_CERT_COMMON_NAME_INVALID)."
Mein Zertifikat läuft nur auf die Domain mit oder ohne www.
Habe wohl vor Jahren nicht darauf geachtet ein Wildcardzertifikat zu nehmen.

Wenn die Dienste auf der gleichen DS laufen:
Wo liegt der Unterschied zwischen einem Reverse Proxy Eintrag und einer Benutzerdefinierten Domain?
Ich komme im Endeffekt aufs gleiche Ergebnis.

Um ein paar Fragen zu beantworten:
Das Zertifikat hatte ich vor Jahren gekauft und es auf den verschiedenen DS importiert. Da musste kein Webserver laufen; hatte das vom damaligen Hoster so bekommen.
Ja, 443 wird auf die DS-116 geleitet und von dort aus mittels htaccess umgeleitet. Geht schon etwas im Kreis mit den Umleitungen, das stimmt schon.

 

[Fusion]

Für die Dienste die unter Anwendungsportal > Anwendungen zur Verfügung stehen kannst du natürlich dort eine benutzerdefinierte Domain mit HSTS eintragen. (Ports, Alias etc brauchst alles nicht)
Möglich, dass man beim allerersten Aufruf ein https voranstellen muss.
Benutzerdefinierte Domain entspricht technisch glaube ich einem vHost, aber das müßte ich auch wieder nachlesen gehen.

Zertifikatsfehler verständlich, wenn der Name abweicht.
Soll es bei diesem Zertifikat bleiben, bleibt dir nur Alias oder Ports, mit oder ohne Reverse proxy, oder deine htaccess Umleitung.
Bleibt eigentlich mit der rewrite rule die sub.domain.com in der Browser URL stehen oder wechselt das auf domain.com:<port>?

 

[SoniX]

So, nun hatte ich endlich ein wenig Zeit.

Mir hat der Gedanke des reverse Proxies so gefallen dass ich dies nun umgesetzt habe.

Ich habe dazu für die jeweiligen Dienste Subdomains eingerichtet und mir dazu passend ein Lets Encrypt Zertifikat geholt.
Der normale Zugriff (also die Webseite) erfolgt über mein altes gekauftes Zertifikat, der Zugriff auf die Subdomains erfolgt über das von Lets Encrypt.

Die Umleitung der Subdomains auf https habe ich (wieder) mittel htaccess gemacht. Funktioniert soweit.

Als Antwort zur Frage: Bei der Umleitung über htaccess ändert sich die URL auf domain.comort oder in dem jetzigen Fall von http auf https.

Den Fehler mit HSTS hatte ich bisher nicht wieder!
Wahrscheinlich haben da die verschiedenen Diskstations und die Umleitung irgendwie reingefunkt.
Da nun die zweite Diskstation über die erste erreichbar ist tritt da kein Fehler mehr auf.

Ich danke euch allen für eure Hilfe!

Und es freut mich sehr dadurch reverse Proxies kennengelernt zu haben. Ich finde die genial