HSTS Preload: Voraussetzungen für die Preload-Liste, Risiken und wie Sie Header und Status prüfen

1. Was die HSTS-Preload-Liste ist

HTTP Strict Transport Security ist in RFC 6797 definiert. Der Server sendet Strict-Transport-Security: max-age=… über HTTPS, und der Browser merkt sich für max-age Sekunden, dass der Host nur per HTTPS erreichbar sein darf. Solange der Browser eines Besuchers den Header nicht mindestens einmal empfangen hat, schützt nichts die erste unverschlüsselte http://-Anfrage; ein Angreifer im selben Netz kann sie abfangen. Der RFC beschreibt diese Schwäche beim ersten Kontakt und nennt vorkonfigurierte Richtlinien als mögliche Antwort.

Die Preload-Liste ist diese Antwort in der Praxis. Das Chromium-Projekt pflegt sie, neue Einträge werden direkt in den Quellcode von Chrome geschrieben. Laut der HSTS-Seite des Chromium-Projekts und hstspreload.org führen Firefox, Safari und Edge eigene Listen auf Basis der Chrome-Liste. In jeder Browserversion, die den Eintrag enthält, ist eine vorgeladene Domain ab dem ersten Start nur per HTTPS erreichbar, und weil Einreichungen includeSubDomains enthalten müssen, gilt das auch für jeden Namen darunter.

Drei Punkte werden oft missverstanden:

• Die Direktive preload bewirkt im Browser nichts. Sie gehört nicht zu RFC 6797, und Browser ignorieren Direktiven, die sie nicht kennen. Sie signalisiert den Betreuern der Liste, dass der Domaininhaber mit der Aufnahme einverstanden ist. Sobald Ihr Header sie enthält, kann jeder Ihre Domain über das Formular einreichen.
• Nur ganze registrierbare Domains kommen auf die Liste. Eingereicht wird example.com, nicht www.example.com oder shop.example.com, und der Eintrag umfasst jede Subdomain, auch interne, die öffentlich gar nicht erreichbar sind.
• Manche Top-Level-Domains sind komplett vorgeladen. Jede Domain unter .app oder .dev zum Beispiel ist in Browsern, die die Liste nutzen, bereits nur per HTTPS erreichbar, ob ihr Inhaber etwas eingereicht hat oder nicht.

2. Brauchen Sie Preloading überhaupt noch?

Für die meisten Websites lautet die Antwort: eher nicht. Die Einreichungsseite selbst schreibt inzwischen, dass HSTS empfohlen wird, HSTS-Preloading aber nicht. Chrome und Safari versuchen bei Navigationen, die mit http:// beginnen, automatisch HTTPS, unabhängig von einer HSTS-Richtlinie. Die Lücke beim ersten Besuch, für die Preloading gedacht war, ist dadurch deutlich kleiner geworden. Laut hstspreload.org bringt Preloading nur dann zusätzlichen Schutz, wenn diese automatischen Upgrades wegen eines aktiven Angreifers scheitern, und der Nutzen ist im Vergleich zu HSTS selbst minimal.

Sinnvoll sein kann Preloading trotzdem, wenn alle drei Punkte zutreffen:

• Ein Downgrade schon beim allerersten Besuch ist für Sie relevant, etwa weil sich Nutzer aus öffentlichen WLANs anmelden oder bezahlen.
• Jede heutige und künftige Subdomain, auch interne und von Dienstleistern betriebene, kann HTTPS mit gültigem Zertifikat ausliefern.
• Sie wollen die Domain und HTTPS darauf über Jahre behalten.

Verzichten Sie darauf oder verschieben Sie es, wenn Teams oder Dienstleister Subdomains betreiben, die Sie nicht vollständig kontrollieren, wenn interne Hosts unter der öffentlichen Domain liegen, wenn die Domain zu einer kurzlebigen Kampagne gehört oder wenn Sie sie verkaufen oder abgeben könnten: Der Eintrag geht mit der Domain an den nächsten Inhaber über, bis jemand die Entfernung beantragt. Ein sauber konfigurierter HSTS-Header ohne preload schützt bereits jeden wiederkehrenden Besucher.

3. Die genauen Voraussetzungen für die Einreichung

hstspreload.org prüft diese Bedingungen bei der Einreichung, und Sie müssen sie auch danach dauerhaft erfüllen: Domains, die das nicht mehr tun, können entfernt werden, und sobald preload aus dem Header verschwindet, ist die Domain sofort für das Entfernungsformular zugelassen.

An der Weiterleitungsregel scheitern viele Websites. Leitet https://example.com/ auf https://www.example.com/ weiter, muss genau diese Weiterleitungsantwort den vollständigen Header tragen. Der Header der www-Seite zählt nicht, denn eine von www.example.com gesetzte Richtlinie gilt nie für die Basisdomain. Ein Header, der die Prüfung besteht, sieht so aus:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

4. Die Risiken: warum Preloading schwer rückgängig zu machen ist

• Die Entfernung dauert Monate. Eine Entfernung ist eine Quellcodeänderung, die Nutzer erst mit Browser-Updates erreicht. Laut der Entfernungsseite kann es 6 bis 12 Wochen dauern, bis sie bei den meisten Chrome-Nutzern ankommt, in anderen Browsern womöglich länger. Ein Browser, der nie aktualisiert wird, behält den alten Eintrag.
• Subdomains ohne HTTPS fallen aus. Typische Fälle sind Intranet-Hosts, die nur im internen DNS auflösen, Verwaltungsseiten von Druckern, Routern und Speichersystemen mit selbstsignierten Zertifikaten, vergessene Staging-Server und Dienste von Anbietern per CNAME, etwa ein Helpdesk, eine Statusseite oder Klick-Tracking-Links aus E-Mails, die nur per HTTP antworten. In einem Browser, in dem Ihre Domain vorgeladen ist, scheitern sie, ohne dass sich die Fehlermeldung umgehen lässt.
• Zertifikatsfehler werden zur Sperre. Auf einem HSTS-Host verlangt RFC 6797, dass der Browser die Verbindung bei jedem Zertifikatsfehler abbricht, ohne dem Besucher ein Weiterklicken zu erlauben. Ein abgelaufenes Zertifikat auf irgendeiner Subdomain sperrt alle aus, bis es ersetzt ist. Automatisieren Sie deshalb die Verlängerung und überwachen Sie Ablaufdaten, bevor Sie einreichen.
• Wiederkehrende Besucher behalten ihre gespeicherte Richtlinie. Der Austritt aus der Liste löscht nicht, was Browser aus Ihrem Header gelernt haben. Bei einem max-age von zwei Jahren hält diese Kopie zwei Jahre, es sei denn, der Besucher kommt wieder und erhält max-age=0 über HTTPS.
• Versehentliche Einreichung. Ein aus einer Vorlage kopierter Header, in dem preload schon steht, genügt, damit jeder Ihre Domain einreichen kann. Lassen Sie die Direktive weg, bis der Plan im nächsten Abschnitt abgeschlossen ist.

5. Ein Stufenplan für max-age vor der Einreichung

hstspreload.org empfiehlt, max-age schrittweise zu erhöhen, mit includeSubDomains ab der ersten Stufe. Suchen Sie in jeder Stufe nach defekten Seiten, beobachten Sie Kennzahlen wie Traffic, Anmeldungen und Umsatz, beheben Sie auftretende Probleme und warten Sie mindestens das volle max-age der Stufe ab, bevor Sie weitergehen. Sie können die Stufen zuerst mit einer Testgruppe durchlaufen, danach aber für alle Nutzer.

Senden Sie den Header unter nginx aus dem HTTPS-Serverblock mit dem Parameter always, damit auch Fehlerseiten ihn tragen, und behalten Sie die HTTP-Weiterleitung auf demselben Host. Eine add_header-Zeile in einem location-Block ersetzt dort die Header der Serverebene (nginx-Modul für Header).

server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # Stufe 1: Wert in jeder Stufe anpassen
    add_header Strict-Transport-Security "max-age=300; includeSubDomains" always;
}

Allein der stufenweise Anstieg dauert mehr als fünf Wochen. Nach der Einreichung kann es laut hstspreload.org mehrere Monate dauern, bis ein neuer Eintrag die stabile Chrome-Version erreicht. Für einen festen Launch-Termin ist Preloading deshalb nie eine schnelle Lösung.

6. So prüfen Sie Ihren HSTS-Header

Prüfen Sie im Terminal die drei entscheidenden Antworten:

curl -sS -D - -o /dev/null http://example.com/
curl -sS -D - -o /dev/null https://example.com/
curl -sS -D - -o /dev/null https://www.example.com/

Die erste sollte 301 oder 308 mit Location: https://example.com/ liefern; einen HSTS-Header braucht sie nicht, denn Browser ignorieren HSTS, das über unverschlüsseltes HTTP ankommt. Die zweite muss strict-transport-security mit allen drei Direktiven tragen, auch wenn sie selbst auf www weiterleitet. Die dritte sollte den Header ebenfalls senden, denn wer nur www aufruft, erhält die Richtlinie der Basisdomain nie. Unter Windows rufen Sie curl.exe auf und verwenden -o NUL.

Achten Sie auf diese Fehler:

• Zwei HSTS-Header. Fügen CDN und Ursprungsserver jeweils einen hinzu, verarbeiten Browser laut RFC 6797 nur den ersten, und die Prüfung auf hstspreload.org meldet „Multiple HSTS headers“ als Fehler. Legen Sie fest, welche Schicht den Header verantwortet.
• Eine falsch geschriebene Direktive. Browser verwerfen unbekannte Direktiven ohne Warnung. Ein includeSubdomain ohne das abschließende s lässt die Subdomains also stillschweigend ungeschützt.
• Fehlt bei manchen Antworten. Die Startseite hat den Header, Fehlerseiten, die API oder statische Dateien aus einer anderen Schicht aber nicht.

Öffnen Sie in den Chrome DevTools das Network-Panel und geben Sie http://example.com/ in die Adresszeile ein, nachdem der Browser die Richtlinie gespeichert hat. Der erste Eintrag zeigt 307 Internal Redirect mit Non-Authoritative-Reason: HSTS: Der Browser hat selbst auf HTTPS umgestellt, bevor eine Anfrage den Server erreichte. Die Syntax des Headers finden Sie in der MDN-Referenz.

7. So prüfen Sie den Status auf der Preload-Liste

• hstspreload.org. Geben Sie die Domain im Formular ein. Es zeigt, ob die Domain vorgeladen, ausstehend oder nicht gelistet ist, und nennt Fehler und Warnungen gemessen an den aktuellen Voraussetzungen. Eine ausstehende Domain ist noch nicht geschützt: Sie muss erst mit einer Browserversion ausgeliefert werden.
• chrome://net-internals/#hsts. Geben Sie in Chrome die Domain unter „Query HSTS/PKP domain“ ein. Felder, die mit static_ beginnen, stammen aus der in diese Browserversion eingebauten Liste; Felder mit dynamic_ stammen aus Headern, die der Browser empfangen hat. „Delete domain security policies“ löscht nur den dynamischen Teil, ein vorgeladener Eintrag bleibt also, bis ein Browser-Update ihn entfernt.
• Andere Browser. Firefox, Safari und Edge liefern eigene, von der Chrome-Liste abgeleitete Kopien nach eigenem Zeitplan aus. Eine Aufnahme oder Entfernung kann sie daher zu unterschiedlichen Zeitpunkten erreichen.

Wiederholen Sie die Prüfung nach Änderungen an DNS, CDN oder Zertifikaten. hstspreload.org weist darauf hin, dass Domains, die die Voraussetzungen nicht mehr erfüllen, künftig automatisch entfernt werden können.

8. Austritt aus der Liste: Schritte und Dauer

1. Liefern Sie auf der Basisdomain weiter HTTPS mit gültigem Zertifikat aus; das Entfernungsformular prüft das.
2. Senden Sie einen HSTS-Header ohne preload. hstspreload.org wertet diesen Header als Antrag auf Entfernung. Behalten Sie includeSubDomains und ein langes max-age, wenn Sie HSTS weiter nutzen wollen, oder senden Sie max-age=0, um HSTS ganz abzuschalten.
3. Reichen Sie die Domain über das Entfernungsformular ein.
4. Geben Sie in der Wartezeit der Subdomain, die den Ausschlag gab, ein gültiges Zertifikat oder ziehen Sie sie auf eine andere Domain um: Die Entfernung kann 6 bis 12 Wochen brauchen, bis sie die meisten Chrome-Nutzer erreicht, in anderen Browsern länger.
5. Senden Sie preload nicht erneut, es sei denn, Sie wollen wieder auf die Liste.

max-age=0 wirkt nur über HTTPS und nur bei Besuchern, die wiederkommen und es empfangen. Planen Sie mit dem langsamsten Fall: Ein veralteter Browser mit dem eingebauten Eintrag oder eine gespeicherte Zwei-Jahres-Richtlinie kann HTTPS noch lange erzwingen, nachdem Sie Ihre Entscheidung geändert haben.

9. Was der kostenlose Snapshot von Sitelemetry zeigt

Der kostenlose Snapshot von Sitelemetry (Launch Readiness Snapshot) führt ohne Registrierung acht passive Prüfungen für eine öffentliche Domain aus und liefert einen Score mit dem Ergebnis jeder Prüfung. Zwei davon betreffen HSTS:

• Die Prüfung der HTTP-Sicherheitsheader liest die Startseite der eingegebenen Domain nach bis zu fünf Weiterleitungen. Fehlt Strict-Transport-Security bei einem HTTPS-Ziel, bewertet sie das als mittel und zeigt den beobachteten Wert.
• Die Prüfung der HTTPS-Weiterleitung markiert ein max-age unter 180 Tagen (15.552.000 Sekunden) als niedrig, wenn Sie eine reine Domain oder eine https://-Adresse eingeben. In den Stufen 1 bis 3 des Plans ist dieses Ergebnis zu erwarten.

Nicht geprüft werden includeSubDomains, die Direktive preload, Ihre Subdomains und Ihr Listenstatus; dafür nutzen Sie hstspreload.org und die curl-Befehle oben. Wenn Sie das Header-Ergebnis zuerst sehen möchten, nutzen Sie den kostenlosen Security Headers Checker, der denselben Snapshot ausführt. Die Zertifikatsseite behandelt der Leitfaden zu SSL/TLS-Zertifikat und HSTS, und die Website-Launch-Checkliste stellt HSTS neben Weiterleitungen, DNS und die übrigen Prüfungen vor dem Go-live.