Nextcloud - "Strict-Transport-Security" / Aktivieren von HSTS

Hallo,

ich erhalte in der Nextcloud die folgende Fehlermeldung.

Der “Strict-Transport-Security” HTTP-Header ist nicht auf mindestens “15552000” Sekunden eingestellt. Um die Sicherheit zu erhöhen, empfehlen wir das Aktivieren von HSTS

Was muss ich tun um den Fehler zu beseitigen?

Danke Frank

Hallo zurueck,

sofern das Modul mod_headers aktiviert ist, wird in der Apache-Konfiguration im Container der Domain der STS-Header ergaenzt:

<VirtualHost <ip>:443>
   ServerAdmin support@TLD.com
   ServerName www.TLD.com
   # HSTS einrichten -- erfordert mod_headers!
   Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
   [...]
</VirtualHost>

Die Security Headers koennen hier getestet werden: https://securityheaders.io/ :wink:

Dafür gibt m.E. UCR-Variablen.

root@ucs-8762:~# ucr search hsts
apache2/hsts/includeSubDomains: <empty>
 Applies HSTS policy also to subdomains if set to 'yes'.

apache2/hsts/max-age: <empty>
 Time in seconds of how long web browsers will cache and enforce the HSTS policy on the host. Defaults to '10886400' - which are 18 weeks.

apache2/hsts: <empty>
 Enable HTTP Strict Transport Security (HSTS) by setting this variable to 'yes'. 'apache2/force_https' should be enabled additionally to take full advantage of HSTS.


5 Likes

Danke das war der gute Tipp

wenn ich “ucr search” eingebe erhalte ich diesen Fehler:

root@nextc-81739309:/# ucr search hsts
bash: ucr: command not found

ist “ucr” ein Programm das ich erst noch mit apt-get installieren muss?

ucr ist eine Executable das nur auf Univention Systemen existiert. Das Kommando wird daher auf dem Univention System ausgeführt werden müssen, nicht im Docker Container von Nextcloud.

Es ist auch aus rein funktionalen Aspekten nötig, HSTS auf dem System, mit dem die Clients reden, zu konfigurieren. Also dem UCS.

wo finde ich die datei mit diesem Inhalt. Irgendwie ist in UCS alles etwas anders und ich finde nicht einmal diese Datei mit den VirtualHost Einträgen:

<VirtualHost <ip>:443>
   ServerAdmin support@TLD.com
   ServerName www.TLD.com

etc…
wenn ich auf diese Datei zugreifen kann dann käme ich vermutlich etwas weiter mit diesem Problemchen?
Andernfalls bin ich völlig verloren. :frowning:
vielen Dank

Die Konfiguration erfolgt in der default-ssl.conf (unter sites-available bzw. sites-enabled). Dort landen dann auch nach dem Setzen der oben genannten UCR-Variablen die HSTS-Einstellungen. Docker-Gäste müssen normalerweise nicht extra dafür konfiguriert werden.

sorry, aber irgendwie bin ich zu blöd dazu. :blush:

wenn ich folgende schritte mache:

Administrator@ucs-nexcloud:~$ sudo univention-app shell nextcloud
root@nextc-81739309:/# vim /etc/apache2/sites-enabled/000-default.conf

Inhalt der 000-default.conf:
Screenshot%20from%202018-09-12%2009-10-52

und bei: /etc/apache2/sites-available/default-ssl.conf
sieht es nicht viel besser aus???

Screenshot%20from%202018-09-12%2009-12-12
Screenshot%20from%202018-09-12%2009-12-32

Soll ich die nachfolgenden Angaben zu HSTS manuell unter <VirtualHost… eintragen oder ist HSTS bei mir gar nicht aktiv oder???
Was mache ich falsch, wo ist der Denkfehler?

<VirtualHost <ip>:443>
   ServerAdmin support@TLD.com
   ServerName www.TLD.com
   # HSTS einrichten -- erfordert mod_headers!
   Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
   [...]
</VirtualHost>

Scheinbar haben wir dich irgendwo total verwirrt. Innerhalb von Univention erfolgt die Konfiguration in der Regel über die Univention Web IU oder mittels UCR Variablen (die wiederum über die UI oder über die Kommandozeile gesetzt werden können). Wenn HSTS verwendet werden soll, dann muss dies nicht innerhalb des Nextcloud Containers konfiguriert werden, sondern auf dem Univention Host. Hierfür reicht per CLI ein “einfaches” ucr set apache2/force_https=yes apache2/hsts=yes.

Um es nochmal zu verdeutlichen. Konfigurationsdateien müssen hierfür nicht händisch verändert werden. Im Gegenteil sogar, dies zu tun ist in den meisten fällen sogar kontraproduktiv, da Änderungen dann durch Univention im späteren Verlauf überschrieben werden könnten.

1 Like

Hallo ich hoffe, ich darf den Thread noch einmal pushen. Ich bin immer noch recht verwirrt wegen dem Strict-Transport-Security.

Wenn ich das richtig verstanden habe, dann ist HSTS ein Sicherheitsmechanismus, um für eine definierte Zeit (max-age) ausschließlich verschlüsselte Vernindungen zuzulassen.

Diese Zeitspanne setze ich mit

Strict-Transport-Security: max-age=……

Aber wo setzte ich diese Seit also in welcher Datei und wo finde ich die Datei?

Oder ist es ein Befehl, den ich in die Konsole eingebe, so wie „fbartels“ es geschrieben hat.

Gebe ich dann einfach

ucr set apache2/force_https=yes apache2/hsts=yes

In die Konsole ein und fertig oder muss ich in einem bestimmten Pfad sein und es eingeben?

Entschuldigt, meine Fragerei und vielen lieben Dank für eure Hilfe.

Thomas

Hallo @deggit,

vereinfacht gesprochen (auch weil ich mir das Thema bisher noch in keinem grösseren Detail angesehen habe, die folgende Aussage kann also technische Fehler enthalten):

Es geht bei hsts nicht vorwiegend darum, dass eine Verbindung verschlüsselt ist, sondern mit welchem Schlüssel dies passiert ist.
Wenn hsts aktiviert ist, merkt sich nicht der selbst Server den Schlüssel, sondern der Browser.

Das hier geschützte Scenario ist also:

  • ich spreche regelmäßig mit Server X, Server X hat aber nun ein (valides) SSL Zertifikat aus einer anderen CA.
  • wenn hsts genutzt wird hat der Admin dies hoffentlich vorher bedacht und hsts deaktiviert. Falls nicht dann ist von einem Angriff auszugehen.

Ich glaub, dass ist nicht ganz korrekt.
Wenn ein HSTS verstehender Client (z.B. Browser) sich einmal zu einem Server, der einen HSTS-Header sendet, verbunden hat, wird er sich innerhalb der angegebenen Zeitspanne nicht ohne weiteres mehr mit http zufrieden geben. Das soll Downgrade-Attacken verhindern, bei denen sich ein “Man in the Middle” z.B. mit dem Angebot eines “Free-WiFi here” einklinkt, einfach mal sagt “heute kein https, nehmt http” und dann fleissig mitliest.
Der Wechsel von Zertifikaten bei aktiven HSTS ist nach meiner Erfahrung unkritisch, solange man nicht auf selbst signierte gehen will.
Siehe auch Nextcloud Hardening and security guidance und Wikipedia: HSTS

Das wäre m.E. eher ein mit HPKP adressierbares Problem. Nachbarbaustelle.

1 Like

Hallo,
vielen lieben Dank für die Antworten. Leider helfen mir diese nicht wirklich weiter. Könntet ihr mir etwas genauer beschreiben, was ich zu machen hätte?
vielen lieben Dank für die Hilfe
Thomas

Hi

It would be helpful to know how you access nextcloud ?
direct or through proxy ?

if direct than on the nextcloud host you’ll have to set HSTS and forceHTTPS in UCR
if through proxy than you’ll have to set this on the proxy (if also UCS then in UCR - else in the proxy configuration files (apache nginx, whatever you use)

for UCS:
Auswahl_006

rg
Christian

Hallo zusammen,

ich muss den Beitrag auch mal ausgraben. Ich habe Nextcloud (19.0.3) auf einem UCS-Member (4.4.6) am laufen und erhalte diese Meldung auch.
Ich habe auf dem UCS-Host ausgeführt:

ucr set apache2/force_https=yes
ucr set apache2/hsts/includeSubDomains=yes
ucr set apache2/hsts/max-age=15552000

und den UCS anschließend neu gestartet. Die Meldung ist jedoch geblieben. Was mache ich falsch?

Habe den wichtigsten vergessen:
ucr set apache2/hsts=yes

Meldung verschwunden. Sorry

Mastodon