Wie Sie HSTS einrichten, ohne sich auszusperren

HSTS ist einfach, bis es das nicht mehr ist

HTTP Strict Transport Security, meist zu HSTS verkürzt, sagt Browsern: „Für diese Website immer HTTPS verwenden.“ Sobald ein Browser den Header über eine gültige HTTPS-Verbindung erhält, merkt er sich die Regel für die von Ihnen angegebene Dauer.

Das ist nützlich. Es verhindert Protocol-Downgrade-Angriffe, reduziert unbeabsichtigte unsichere Anfragen und vermeidet den unangenehmen Moment, in dem ein Benutzer example.com eingibt und kurz normales HTTP berührt, bevor er weitergeleitet wird.

Es ist aber auch hartnäckig. Wenn Sie die falsche HSTS-Richtlinie veröffentlichen, können Browser sie noch lange durchsetzen, nachdem Sie den Header von Ihrem Server entfernt haben. So sperren sich Teams aus: nicht unbedingt aus ihrem eigenen Admin-Panel, sondern aus den Browsern der Nutzer, aus Subdomains, Staging-Systemen, Legacy-Endpunkten und vergessenen Diensten, die noch nicht für erzwungenes HTTPS bereit sind.

Das Ziel ist nicht, HSTS zu vermeiden. Das Ziel ist, es wie eine Migration bereitzustellen, nicht wie einen Schalter.

Was der HSTS-Header tatsächlich tut

Ein typischer HSTS-Header sieht so aus:

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

Er hat drei wichtige Teile:

• max-age: wie lange der Browser HTTPS für diesen Host erzwingen soll, in Sekunden.
• includeSubDomains: ob die Regel auch für jede Subdomain gilt.
• preload: ein Signal, dass Sie die Domain in Browser-Preload-Listen aufnehmen lassen möchten.

Der Browser vertraut diesem Header nur, wenn er ihn über gültiges HTTPS erhält. Wenn das Zertifikat ungültig, abgelaufen oder nicht passend ist, sollte der Browser aus dieser Antwort keine neue HSTS-Richtlinie akzeptieren.

Sobald die Richtlinie gespeichert ist, werden künftige Versuche, http://example.com aufzurufen, vom Browser auf https://example.com hochgestuft, bevor die Anfrage gesendet wird. Das ist der Gewinn für die Privatsphäre: Die unsichere Anfrage verlässt das Gerät nie.

Lockout-Szenarien, die Sie vermeiden sollten

Die meisten HSTS-Fehler werden nicht durch die Hauptwebsite verursacht. Sie passieren an den Rändern.

1. Eine vergessene Subdomain ist nicht HTTPS-bereit

includeSubDomains klingt aufgeräumt, ist aber absolut. Wenn Sie es auf example.com setzen, gilt es für:

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• alles andere unter dieser Domain

Wenn einer dieser Hosts kein gültiges HTTPS ausliefern kann, können Benutzer mit zwischengespeicherter HSTS-Richtlinie ihn nicht mehr über HTTP erreichen.

2. Ein Zertifikat läuft ab

Ohne HSTS klicken Benutzer manchmal durch Zertifikatswarnungen hindurch. Das ist keine gute Sicherheitspraxis, kommt aber vor.

Mit HSTS erlauben moderne Browser für diesen Host kein einfaches Umgehen von Zertifikatsfehlern. Genau das ist der Zweck. Es bedeutet aber auch, dass Zertifikatserneuerung langweilig, überwacht und getestet sein muss.

3. Staging- oder interne Tools liegen unter der Produktionsdomain

Interne Tools unter *.example.com zu platzieren, kann schmerzhaft werden, sobald die übergeordnete Domain includeSubDomains verwendet. Wenn diese Tools selbstsignierte Zertifikate, private Zertifizierungsstellen, alte TLS-Konfigurationen oder gar kein HTTPS verwenden, legt HSTS diese Abkürzung offen.

Das ist ein Grund, warum viele Teams interne und experimentelle Systeme unter einer separaten Domain halten, die ihre eigene Sicherheitsrichtlinie hat.

4. Preload wird wie eine normale Checkbox behandelt

HSTS preload ist nicht einfach eine weitere Direktive. Es bedeutet, dass Ihre Domain in Browsern als HTTPS-only ausgeliefert werden kann, bevor irgendein Benutzer Ihre Website besucht hat.

Das schließt die Lücke beim „ersten Besuch“, lässt sich aber deutlich schwerer rückgängig machen. Die Entfernung aus Preload-Listen kann je nach Release-Zyklen der Browser Wochen oder Monate brauchen, bis sie bei Nutzern ankommt. Preload eignet sich für stabile, reife Domains. Es eignet sich nicht für eine Website, die ihre Subdomain-Landschaft noch entdeckt.

Ein sicherer Rollout-Plan

Schritt 1: Prüfen Sie jeden Hostnamen, den Sie kontrollieren

Bevor Sie includeSubDomains setzen, listen Sie jeden Hostnamen unter der Domain auf. DNS-Einträge sind ein Anfang, aber nicht die ganze Geschichte. Prüfen Sie CDN-Konfigurationen, Hosting-Dashboards, E-Mail-bezogene Hostnamen, alte Marketing-Tools, Storage-Buckets und interne Dokumentation.

Beantworten Sie für jeden Hostnamen:

• Liefert er HTTP, HTTPS oder beides aus?
• Ist das HTTPS-Zertifikat gültig und wird es automatisch erneuert?
• Leitet er HTTP sauber auf HTTPS um?
• Soll er öffentlich sein?
• Wird er noch benötigt?

Wenn Ihr Team bereits Routinen zum Debuggen von Produktions-Headern hat, passt das natürlich neben Redirect- und Header-Prüfungen. Diesen Workflow haben wir in einem kleinen Toolkit zum Debuggen von Redirects und HTTP-Headern in der Produktion beschrieben.

Schritt 2: Reparieren Sie HTTPS, bevor Sie HSTS hinzufügen

HSTS macht ein kaputtes HTTPS-Setup nicht sicher. Es macht HTTPS nur verpflichtend.

Prüfen Sie vor der Aktivierung:

• TLS-Zertifikate decken die richtigen Hostnamen ab.
• Zertifikate werden automatisch erneuert.
• HTTP leitet möglichst mit einem einzigen sauberen Sprung auf HTTPS um.
• Weiterleitungen zum kanonischen Host sind konsistent, zum Beispiel von non-www zu www oder umgekehrt.
• Anwendungs-Assets hängen nicht von unsicheren http://-URLs ab.

Mixed Content ist seltener als früher, taucht aber weiterhin in alten CMS-Themes, Analytics-Snippets, eingebetteten Medien und hartcodierten Bildpfaden auf.

Schritt 3: Beginnen Sie mit einem sehr kurzen max-age

Beginnen Sie nicht mit einem Jahr. Beginnen Sie mit fünf Minuten:

Strict-Transport-Security: max-age=300

Stellen Sie das nur auf dem Hostnamen bereit, den Sie testen, üblicherweise der kanonischen Produktionswebsite. Lassen Sie includeSubDomains vorerst weg.

Testen Sie dann in echten Browsern und mit Kommandozeilenanfragen:

curl -I https://example.com

Sie sollten genau einen Strict-Transport-Security-Header sehen. Doppelte HSTS-Header von einem App-Server und einem CDN sind eine häufige Quelle von Verwirrung. Browser wenden im Allgemeinen die wirksame Richtlinie an, aber Menschen, die einen Vorfall debuggen, brauchen keine Mehrdeutigkeit.

Schritt 4: Erhöhen Sie schrittweise

Wenn nichts kaputtgeht, erhöhen Sie die Dauer stufenweise:

Strict-Transport-Security: max-age=86400

Dann:

Strict-Transport-Security: max-age=604800

Dann vielleicht:

Strict-Transport-Security: max-age=2592000

Ein praktischer Zeitplan ist:

• 5 Minuten
• 1 Tag
• 1 Woche
• 1 Monat
• 6 Monate oder 1 Jahr

Es gibt keinen Preis fürs Eilen. Der ganze Zweck eines gestuften Rollouts besteht darin, Ihrem Monitoring, dem Support-Postfach und Randfällen Zeit zu geben, Ihnen zu zeigen, was Ihre Checkliste übersehen hat.

Schritt 5: Fügen Sie includeSubDomains erst hinzu, wenn das Audit wirklich belastbar ist

Sobald jede öffentliche Subdomain HTTPS-bereit ist, können Sie Folgendes in Betracht ziehen:

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

Das ist der Moment, konservativ zu sein. Wenn ein Legacy-Dienst noch HTTP benötigt, fügen Sie includeSubDomains nicht zur übergeordneten Domain hinzu. Migrieren Sie entweder diesen Dienst, verschieben Sie ihn auf eine andere Domain, oder akzeptieren Sie, dass Ihre HSTS-Richtlinie vorerst enger bleiben muss.

Security-Header sollten die Realität abbilden. Sie sollten nicht als Motivationsposter für Infrastruktur verwendet werden, die Sie später einmal haben möchten.

Schritt 6: Behandeln Sie preload als eigenes Projekt

Ziehen Sie preload nur in Betracht, wenn alle folgenden Punkte zutreffen:

• Die Domain und alle Subdomains unterstützen gültiges HTTPS.
• HTTP leitet auf HTTPS um.
• Der HSTS-Header verwendet max-age von mindestens 31536000 Sekunden.
• Der Header enthält includeSubDomains.
• Der Header enthält preload.
• Sie sind sicher, dass Sie nirgends unter der Domain normales HTTP benötigen werden.

Ein preload-bereiter Header sieht so aus:

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

Die Einreichung bei der Preload-Liste ist eine langfristige Verpflichtung. Wenn die Website eine Kampagnen-Microsite, eine temporäre Produktdomain oder eine Domain mit unklaren Zuständigkeitsgrenzen ist, lassen Sie es bleiben.

Konfigurationsbeispiele

Nginx

Verwenden Sie always, damit der Header auch bei Fehlerantworten gesendet wird:

add_header Strict-Transport-Security "max-age=300" always;

Nachdem der Rollout stabil ist:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Apache

Mit aktiviertem mod_headers:

Header always set Strict-Transport-Security "max-age=300"

Später:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

CDN- oder Edge-Plattform

Wenn Ihr CDN Response-Header setzt, sollten Sie HSTS möglichst an einer einzigen Stelle verwalten. Setzen Sie nicht eine Richtlinie am Origin und eine andere an der Edge, außer Sie haben einen sehr klaren Grund.

Prüfen Sie außerdem, ob das CDN Header auf Redirects, zwischengespeicherte Fehler und benutzerdefinierte Fehlerseiten anwendet. Eine Produktionswebsite besteht nicht nur aus ihrer 200 OK-Antwort.

Wie Sie HSTS sicher rückgängig machen

Wenn Sie HSTS deaktivieren müssen, senden Sie:

Strict-Transport-Security: max-age=0

Es gibt aber einen Haken: Der Browser muss die Website erfolgreich über gültiges HTTPS erreichen, um diesen Header zu erhalten. Wenn HTTPS selbst kaputt ist, können Benutzer mit zwischengespeicherter HSTS-Richtlinie die Anweisung, die sie löschen würde, nicht abrufen.

Die übliche Reihenfolge zur Wiederherstellung ist daher:

1. Gültiges HTTPS wiederherstellen.
2. Strict-Transport-Security: max-age=0 ausliefern.
3. Lange genug beibehalten, damit wiederkehrende Benutzer es erhalten.
4. Den Header entfernen oder ersetzen, nachdem der Vorfall behoben ist.

Wenn die Domain preloaded ist, reicht max-age=0 für neue Browserprofile nicht aus. Sie müssen außerdem die Entfernung aus der Preload-Liste beantragen und warten, bis diese Änderung über Browser-Updates ausgeliefert wird.

Test-Checkliste vor dem Ausrollen

Verwenden Sie diese Checkliste, bevor Sie max-age erhöhen oder includeSubDomains hinzufügen:

• Die kanonische HTTPS-URL liefert ein gültiges Zertifikat zurück.
• HTTP leitet auf HTTPS um.
• Es gibt nur einen HSTS-Header.
• Der Header erscheint auf Redirects und Fehlerantworten, wo es angemessen ist.
• Alle öffentlichen Subdomains haben gültiges HTTPS.
• Die Zertifikatserneuerung wird überwacht.
• Kein kritisches internes System hängt unter derselben übergeordneten Domain von HTTP ab.
• Preload wurde ausdrücklich besprochen, nicht aus Gewohnheit hinzugefügt.

Lighthouse kann in manchen Kontexten ebenfalls fehlende oder schwache Security-Header melden, sollte aber nicht Ihre einzige Verifikationsmethode sein. Wenn Sie es als Teil einer umfassenderen Prüfung verwenden, lesen Sie die Befunde als Signale statt als Urteile; dieselbe Haltung hilft, wenn Sie einen Lighthouse-Bericht lesen, ohne in Panik zu geraten.

<!-- tool-cta:start -->

💡 Probieren Sie dies aus: Prüfen Sie vor und nach jeder HSTS-Änderung die Strict-Transport-Security-Antwort mit Get Headers, um zu bestätigen, dass max-age, includeSubDomains und preload Ihren Erwartungen entsprechen.

<!-- tool-cta:end -->

Der Datenschutzaspekt von HSTS

HSTS wird oft als Security-Header beschrieben, und das ist es auch. Es hat aber auch einen Datenschutzvorteil: Es reduziert die Wahrscheinlichkeit, dass die erste Anfrage eines Benutzers über normales HTTP in einem nicht vertrauenswürdigen Netzwerk durchsickert.

Das ist relevant in Flughafen-WLANs, Hotelnetzwerken, Unternehmens-Gastnetzwerken und überall dort, wo der Traffic eines Benutzers beobachtet oder verändert werden könnte. Eine normale HTTP-Anfrage kann den Hostnamen, den Pfad, Cookies ohne Secure-Flag und andere Anfragedetails offenlegen. HTTPS ist keine Magie, aber es konsequent zu erzwingen, entfernt eine ganze Klasse vermeidbarer Lecks.

Die besten HSTS-Bereitstellungen sind unauffällig. Sie werden langsam ausgerollt, von zuverlässigen Zertifikaten getragen und sind langweilig genug, dass niemand sie bemerkt. Genau das wollen Sie von einem Header, dessen Fehlermodus dramatisch sein kann.