Was ist HSTS?

Einfach erklärt

HSTS ist eine Anweisung Ihrer Website an den Browser: „Rufe mich ab jetzt nur noch verschlüsselt auf.“ Der Browser merkt sich das für eine Zeit, die Ihre Website festlegt, zum Beispiel ein Jahr. Tippt ein Besucher danach „ihre-firma.de“ ohne „https://“ ein oder klickt er einen alten Link an, fragt der Browser gar nicht erst unverschlüsselt an. Er geht direkt zur sicheren Adresse. Man kann es sich wie einen Vermerk im Adressbuch vorstellen: „Post an diese Firma nur per Einschreiben.“

Warum das zusätzlich zur Weiterleitung nötig ist

Die Weiterleitung von „http://“ auf „https://“ hat eine Schwachstelle: Die allererste Anfrage geht unverschlüsselt hinaus. Wer in einem offenen WLAN mithört, kann genau diese Anfrage abfangen und den Besucher auf eine gefälschte Seite lenken. Mit HSTS entfällt dieser Moment ab dem zweiten Besuch.

Außerdem lässt der Browser bei einem Zertifikatsfehler kein „Trotzdem fortfahren“ mehr zu. Besucher können eine Warnung dann nicht einfach wegklicken.

Was Sie tun können

HSTS ist eine Zeile in der Konfiguration des Webservers. Bitten Sie die Firma, die Ihre Website betreut, sie zu setzen. Vorher muss alles per HTTPS funktionieren. Sollen Subdomains wie „shop.ihre-firma.de“ einbezogen werden, gilt das auch für sie.

Achtung: Browser, die die Anweisung kennen, erfahren von einer Rücknahme erst beim nächsten erfolgreichen verschlüsselten Besuch. Fällt in der Zwischenzeit das Zertifikat aus, ist die Seite für sie gar nicht erreichbar.

Was HSTS nicht kann

Beim allerersten Besuch kennt der Browser die Anweisung noch nicht. Diese Lücke schließt nur eine Liste, die Chrome und andere Browser fest eingebaut haben, die sogenannte Preload-Liste. Und HSTS schützt nur die Verbindung, nicht die Inhalte der Website.

Header und Wirkung

HSTS ist in RFC 6797 (2012) definiert. Der Server sendet den Header in HTTPS-Antworten:

Strict-Transport-Security: max-age=31536000; includeSubDomains

• max-age: Sekunden, die der Browser die Regel behält. Jede Antwort mit dem Header setzt die Frist neu.
• includeSubDomains: Die Regel gilt auch für alle Subdomains.
• max-age=0: Der Browser löscht die Regel.
• preload: kein Teil des RFC, sondern die Zustimmung zur Aufnahme in die Preload-Liste.

Für einen bekannten HSTS-Host schreibt der Browser http://-Adressen intern auf https:// um (Abschnitt 8.3). Bei jedem Fehler im TLS-Aufbau bricht er die Verbindung ab, ohne dass der Nutzer die Warnung übergehen kann (Abschnitte 8.4 und 12.1). Über HTTP empfangene HSTS-Header ignoriert er (Abschnitt 8.1).

Preload-Liste

Die Liste unter hstspreload.org ist fest in Chrome eingebaut, andere Browser nutzen sie ebenfalls. Voraussetzungen für die Aufnahme:

• gültiges Zertifikat,
• Umleitung von HTTP auf HTTPS desselben Hosts, falls Port 80 offen ist,
• alle Subdomains per HTTPS erreichbar, auch www und interne Namen,
• Header auf der Hauptdomain mit max-age von mindestens 31536000 Sekunden (ein Jahr), includeSubDomains und preload, auch an Weiterleitungen.

Bis ein neuer Eintrag in der stabilen Chrome-Version ankommt, vergehen mehrere Monate. Eine Entfernung dauert ebenso lange. Andere Browser übernehmen sie nicht zwingend.

Typische Fehler

• Zu kurze Laufzeit. max-age=300 schützt nur fünf Minuten nach dem letzten Besuch.
• includeSubDomains zu früh. Ein internes System wie intranet.ihre-firma.de ohne gültiges Zertifikat ist danach im Browser nicht mehr erreichbar.
• Header nur über HTTP oder nur auf der Startseite, nicht auf Weiterleitungen.
• preload ohne Plan. Wer aufgenommen wird, legt sich für Monate fest.

Prüfen

curl -sI https://ihre-firma.de/ | grep -i '^strict-transport-security'

Den Stand in der Preload-Liste zeigt hstspreload.org. In Chrome zeigt chrome://net-internals/#hsts die gespeicherte Regel für eine Domain.