Archiv für die Kategorie: Tipps

Was ist HSTS?

HTTP Strict Transport Security (HSTS) ist eine Anweisung des Webservers, das den Web-Browser (oder ein anderes Programm) darüber informiert, wie die Verbindung zwischen Server und Web-Browser gehandhabt werden soll. Diese Information wird gleich am Anfang im sogenannten „Response Header“ gesendet.

Eine einfache Umleitung von HTTP auf HTTPS kann immer noch umgangen werden. Der „Strict-Transport-Security“ Parameter zwingt den Web-Browser, die Verbindung verschlüsselt über HTTPS aufzubauen und ignoriert dabei jedes Skript, das Ressourcen der Domain über HTTP laden will. Damit können z.B. weder Cookies oder Session IDs der Webseite gesammelt noch die Webseite auf eine Phishing-Seite umgeleitet werden.

Warum HSTS?

• HSTS ist eine Möglichkeit, die Sicherheit der Verbindung zu Deiner Webseite zu erhöhen.
• Die erhöhte Sicherheit kann sich auch positive auf das Ranking von Google auswirken.

Welche Voraussetzungen müssen für HSTS erfüllt sein?

• gültiges SSL-Zertifikat für die Webseite und alle weiteren Subdomains
• Umleitung aller Anfragen von HTTP auf HTTPS
• HSTS max-age muss mindestens 1 Jahr betragen
• HSTS includeSubDomains muss aktiviert sein
• HSTS preload muss aktiviert sein

Was bedeuten die einzelnen Werte für HSTS?

HSTS max-age

Zeit in Sekunden, während der der Web-Browser die Webseite als Known HSTS Host betrachtet und keine Verbindungen über HTTP aufbaut.

HSTS includeSubDomains

Stellt sicher, dass die HSTS-Richtlinie nicht nur für die Domain, sondern auch für alle Sub-Domains angewendet wird, z. B. example.de und www.example.de.

HSTS preload

Ob die Webseite in die von Chrome geführte (und von Firefox und Safari, IE 11 und Edge verwendete) HSTS-Preload-Liste aufgenommen werden soll. Wenn HSTS preload aktiv ist, wird der Web-Browser gezwungen, die Seite über HTTPS aufzurufen, da dem Web-Browser schon im Vorfeld bekannt ist, dass diese Seite nur über HTTPS zu erreichen ist.
Das Senden der Preload-Direktive kann Probleme verursachen und Benutzer daran hindern, auf die Webseite und ihre Subdomains zuzugreifen, wenn Du die Seite auf HTTP zurückstellst.
Wenn HSTS preload aktiv ist, kannst Du Deine Webseite unter https://hstspreload.org zu der von Chrome geführten Liste hinzufügen.

HSTS mit einer Webseite testen

Ehe Du HSTS für Deine Webseite „scharf schaltest“, solltest Du Deine Seite erst einmal mit HSTS testen. Für einen Test müssen folgende Voraussetzungen erfüllt sein:

• gültiges SSL-Zertifikat für die Webseite und alle weiteren Subdomains
• Umleitung aller Anfragen von HTTP auf HTTPS

Auf unseren Managed Servern kannst Du HSTS nur aktivieren, wenn Du für die Webseite auch ein gültiges SSL-Zertifikat eingerichtet hast. Andere Voraussetzungen werden automatisch mit angepasst, sobald Du HSTS aktivierst.

Wenn Du HSTS aktiviert hast, setzt Du zu Testzwecken zunächst „HSTS max-age“ auf eine Woche, um etwaige Probleme erkennen zu können. Wenn die Testphase erfolgreich und ohne Probleme verlaufen ist, kannst Du „HSTS max-age“ auf einen Monat setzen und Deine Tests verlängern, oder Du aktivierst HSTS gleich vollständig.

HSTS für eine Webseite aktivieren

Wenn Deine Webseite ein gültiges SSL-Zertifikat hat, kannst Du HSTS aktivieren. Melde Dich in ISPConfig an und öffne die entsprechende Webseite. Unter „Erweitert“ findest Du die passenden Optionen:

Diese Anleitung gilt nicht für eine Nextcloud-Installation, die Du über den Wizard angelegt hast – der Wizard erstellt die entsprechende Datei automatisch.

Wenn Du als „limitierter“ Shell-User (Chrooted Shell = Jailkit) den Befehel ‚php occ …‘ ausführen willst, musst Du zwei Änderungen an der Nextcloud-Konfiguration vornehmen. Wir verwenden dafür eine eigene Konfiguration, die bei einem Update nicht überschrieben wird und automatisch erkennt, ob ein Aufruf über die Shell oder die Webseite erfolgt.

Auf unseren Managed-Servern kannst Du Dir die custom.config.php direkt in ISPConfig für die jeweilige Webseite anzeigen lassen und kannst diese direkt in den config-Ordner per FTP hochladen.

In dieser Anleitung steht zwar nur Shell, das gilt aber auch alles für Cron-Jobs, die ‚Chrooted‘ ausgeführt werden.

Um den Modus zu finden, in dem ein Cron-Job ausgeführt wird, öffnest Du in ISPConfig den entsprechenden Cron-Job:

Im folgenden Beispiel ist unsere Webseite mit der Nextcloud-Installation im Verzeichnis /var/www/clients/client3/web1602/web installiert. Das Verzeichnis findest Du übrigens in ISPConfig bei einer Webseite im ersten Teil von „Abweichendes Document Root“, wenn Du den Bereich „Erweitert“ aufklappst.

Werte in der Nextcloud-Konfiguration anpassen

1. datadirectory
   Ein Chrooted Shell-User kann nicht auf den kompletten Pfad der Webseite /var/www/clients/client3/web1602/web zugreifen. Daher muss das datadirectory „umgeschrieben“ werden, wenn Du über die Shell „php occ“ ausführen willst. Wir verwenden dazu einfach eine custom.config.php.
2. dbhost
   Beim dbhost kannst Du nicht localhost verwenden. PHP verwendet bei localhost eine Verbindung über das Socket-File, da eine solche Verbindung am schnellsten ist. In einer Chrooted-Shell steht das Socket-File aber nicht zur Verfügung und Du bekommst den Fehler „Doctrine\DBAL\Exception: Failed to connect to the database“. Entweder stellst Du in der config.php den ‚dbhost‘ von ‚localhost‘ auf ‚127.0.0.1‘ um (dann erfolgt die Verbindung immer über TCP/IP ist langsamer) oder Du verwendest einfach unsere custom.config.php.

custom.config.php anlegen

Im config-Verzeichnis der Nextcloud-Installation legst Du die Datei custom.config.php an bzw. erstellst diese auf Deinem PC und lädst die erstellte Datei dann per FTP in das config-Verzeichnis.

Du musst in der custom.config.php nur zwei Stellen für Deine Nextcloud-Installation anpassen:

• $basedir – hier trägst Du den Pfad zu Deiner Webseite an, wie sie in ISPConfig angezeigt wird und lässt nur ‚/web‘ am Ende weg.
• $dir – darüber wird das data-Verzeichnis von Nextcloud gesetzt. Bei den meisten Installation liegt das data-Verzeichnis mit im Document-Root der Webseite. Wenn Du Dich per FTP anmeldest, kannst Du das Verzeichnis leicht finden:

Die custom.config.php sieht in unserem Beispiel so aus:

<?php
$basedir = '/var/www/clients/client3/web1601';
$dbhost = null;
if(php_sapi_name() != 'cli') {
  $dir = $basedir;
} else {
  $dbhost = '127.0.0.1';
  $dir = (!is_dir($basedir)) ? '' : $basedir;
}
$dir .= '/web/data';
$CONFIG['datadirectory'] = $dir;
if($dbhost !== null) $CONFIG['dbhost'] = $dbhost;

Wenn Du einen unserer Managed Server mit nginx verwendest, kannst Du Deine Webseiten auch mit HTTP/3 ausliefern lassen.

Das Prinzip von HTTP/3

Bei HTTP/3 handelt es nicht um eine Weiterentwicklung von HTTP/2 (SPDY). HTTP/3 unterscheidet sich deutlich von den anderen HTTP-Verfahren und kombiniert die Eigenschaften von HTTP/2 mit User Datagram Protocol (UDP). UDP wird z.B. für die Abfragen des DNS eingesetzt. Die übrigen Funktionen von HTTP/2 bleiben dabei vollständig erhalten (z.B. paralleles Streamen von Daten verschiedener Herkunft).

Unterschiede zwischen HTTP/2 und HTTP/3

Im Gegensatz zu HTTP/2 nutzt das neue Protokoll HTTP/3 zur Auslieferung der Webseiten nicht das TCP, sondern das UDP Protokoll und ist damit wesentlich schneller.

Bei TCP erfolgen immer mehrstufige Handshakes zwischen Server und Browser. UDP und das darauf basierende QUIC agieren hingegen verbindungslos. An Stelle der Kontrolle einer erfolgreiche Zustellung wird bei Bedarf lediglich die Integrität des Pakets und der Übertragung durch eine Checksumme validiert. Dadurch entfällt das sogenannte Head-of-line-Blocking (Datenstau) und dadurch das erneute Anfordern fehlender Pakete. Die Auslieferung Deiner Seite wird erheblich schneller.

Die Übertragung erfolgt nicht mehr über die IP-Adresse, sondern durch eine individuelle ID. Wenn der Besucher auf seinem Gerät eine neue IP-Adresse erhält (z.B. beim Wechsel von mobilen Daten ins WLAN) kann HTTP/3 den Download ohne Unterbrechung oder eine erneute Verbindung fortsetzen.

HTTP/3 aktivieren

Öffne die entsprechende Webseite in ISPConfig. Unter „Erweitert“ kannst Du dann direkt HTTP/3 aktivieren:

QUIC und HTTP/3 verlangen zwingenden HTTPS über TLS 1.3. Wenn Du bei „Minimum TLS-Version“ eine kleinere Version eingestellt hast, bedeutet das übrigens nicht, dass HTTP/3 dann nicht funktioniert (das nennt sich ja auch nicht max. TLS-Version). Wird die Seite über HTTP/3 angefordert, wird die Verschlüsselung automatisch auf TLS v1.3 hochgesetzt.

Clientseitige Voraussetzungen

Der Browser muss HTTP/3 unterstützen, damit der Besucher Deiner Seite von den Vorteilen profitieren kann. Unterstützt der Browser HTTP/3 nicht oder nicht vollständig, wird Deine Seite ganz normal über HTTP/2 ausgeliefert.

Die gängigen (aktuellen) Browser unterstützen übrigens HTTP/3 schon jetzt. Sporadisch kommt es aber zu einem seltsamen Problem: der Browser beschließen, QUIC und HTTP/3 zu ignorieren.

aktueller Status

Momentan befindet sich HTTP/3 noch in der Entwicklung und nicht zu 100% stabil. Es kann bei einzelnen Webseiten durchaus vorkommen, dass diese mit HTTP/3 nicht richtig funktioniern. Alle aktuellen CMS laufen nach unseren Beobachtungen aber komplett problemlos.

Wenn Du Deinen Webmailer von Roundcube auf RainLoop umstellen möchtest, musst Du lediglich von Deinem Postfach einmal die gespeicherten Adressen sichern und importieren.

Kontakte exportieren

Um die Kontakte zu exportieren, melde Dich in Roundcube an, wähle links „Kontakte“ und klicke dann auf „Exportieren“.

Kontakte importieren

Um die Kontakte zu importieren, melde Dich in RainLoop an, gehe links auf Kontakte und wähle „Import (csv, vcf, vCard)“ aus und lade dann die exportierten Kontakte hoch.