Strict-Transport-Security

Verwendung

Der Header Strict-Transport-Security ist der Mechanismus hinter HTTP Strict Transport Security (HSTS). Empfängt ein Browser diesen Header über eine gesicherte Verbindung, merkt sich der Browser die Direktive und stuft alle künftigen HTTP-Anfragen an die angegebene Domain automatisch auf HTTPS hoch. Ist die gesicherte Verbindung nicht verfügbar, verweigert der Browser den Zugriff vollständig, anstatt auf einfaches HTTP zurückzufallen.

Dieser Header wird nur beachtet, wenn er über HTTPS ausgeliefert wird. Eine über einfaches HTTP ausgelieferte Antwort mit Strict-Transport-Security wird ignoriert, da ein Angreifer auf dem Netzwerkpfad den Header einschleusen oder verändern kann.

Der Header akzeptiert drei Direktiven: max-age, includeSubDomains und preload.

max-age

Die Direktive max-age ist erforderlich. Der Wert gibt die Anzahl der Sekunden an, für die sich der Browser merkt, HTTPS für die Domain zu erzwingen. Ein gängiger Produktionswert ist 63072000 (zwei Jahre). Mit max-age=0 wird der HSTS-Eintrag sofort aus dem Browser-Cache gelöscht.

includeSubDomains

Die Direktive includeSubDomains dehnt die HTTPS-Erzwingung auf jede Subdomain des Hosts aus. Ohne diese Direktive gilt HSTS nur für die exakte Domain in der Antwort. Das Hinzufügen von includeSubDomains verhindert, dass ein Angreifer eine über einfaches HTTP erreichbare Subdomain ausnutzt, um Cookies zu setzen oder Datenverkehr umzuleiten.

preload

Die Direktive preload ist nicht Teil der HSTS-Spezifikation. Browser-Hersteller pflegen HSTS-Preload-Listen, und die Direktive preload signalisiert die Absicht des Domain-Inhabers, aufgenommen zu werden. Sobald eine Domain auf einer Preload-Liste steht, erzwingen Browser HTTPS ab der ersten Verbindung und beseitigen damit das Zeitfenster der Verwundbarkeit vor dem Empfang des ersten Strict-Transport-Security-Headers. Für die Einreichung einer Domain zur Preload-Liste sind ein max-age von mindestens einem Jahr (31536000 Sekunden) sowie die Direktive includeSubDomains erforderlich.

Beispiel

Ein Server, der HTTPS zwei Jahre lang über alle Subdomains hinweg erzwingt, mit Preload-Berechtigung:

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

Eine minimale Konfiguration, die HSTS für sechs Monate nur auf der primären Domain setzt:

Strict-Transport-Security: max-age=15768000

Löschen des HSTS-Eintrags durch Zurücksetzen von max-age auf null – nützlich bei Migrationen oder Tests:

Strict-Transport-Security: max-age=0

Fehlersuche

HSTS-Probleme zeigen sich meist als Verbindungsfehler oder Weiterleitungsschleifen, die selbst nach Serveränderungen bestehen bleiben, weil der Browser die Richtlinie lokal zwischenspeichert.

Aussperrung nach Aktivierung von HSTS mit langem max-age. Sobald ein Browser die HSTS-Richtlinie erfasst hat, werden alle Anfragen automatisch auf HTTPS hochgestuft. Eine Rückkehr zu HTTP ist nicht möglich, bis das max-age abläuft oder der Benutzer den HSTS-Eintrag manuell löscht. Öffnen Sie in Chrome chrome://net-internals/#hsts, geben Sie die Domain unter „Delete domain security policies“ ein und löschen Sie den Eintrag. Schließen Sie in Firefox den Browser, bearbeiten Sie SiteSecurityServiceState.txt im Profilordner und entfernen Sie die Zeile mit der Domain.

Defekte Subdomains durch includeSubDomains. Das Hinzufügen von includeSubDomains erzwingt HTTPS auf jeder Subdomain, einschließlich interner Werkzeuge, Staging-Server und Altsysteme ohne gültiges Zertifikat. Vergewissern Sie sich vor der Aktivierung dieser Direktive, dass jede Subdomain ein vertrauenswürdiges TLS-Zertifikat ausliefert. Entfernen Sie includeSubDomains und liefern Sie den Header erneut mit max-age=0 aus, um zwischengespeicherte Einträge zu löschen, falls eine Subdomain ausfällt.

Entfernung aus der Preload-Liste dauert Monate. Die HSTS-Preload-Liste wird mit den Browser-Releases ausgeliefert. Eine Entfernung erfordert daher, eine Anfrage auf hstspreload.org einzureichen, auf die nächste Aktualisierung der Liste zu warten und darauf zu warten, dass diese Aktualisierung die Benutzer über Browser-Versionsupgrades erreicht. Dieser Vorgang dauert mehrere Monate. Betrachten Sie preload als langfristige Verpflichtung und stellen Sie vor der Einreichung die vollständige HTTPS-Bereitschaft sicher.

Über einfaches HTTP gesendeter HSTS-Header wird ignoriert. Browser verwerfen den Header Strict-Transport-Security, wenn die Antwort über eine unverschlüsselte Verbindung eintrifft. Der Header wirkt nur bei HTTPS-Antworten. Bestätigen Sie, dass der Header in der HTTPS-Antwort vorhanden ist, indem Sie prüfen mit: curl -sI https://example.re | grep -i strict.

Mixed-Content-Fehler nach Aktivierung von HSTS. HSTS stuft die Seite auf HTTPS hoch, doch eingebettete Ressourcen, die weiterhin auf http://-URLs verweisen, lösen Mixed-Content-Warnungen oder -Blockierungen aus. Prüfen Sie alle Ressourcen-URLs (Bilder, Skripte, Stylesheets, API-Endpunkte) und aktualisieren Sie die Verweise auf https:// oder auf protokollrelative Pfade. Die CSP-Direktive upgrade-insecure-requests erledigt dies für verbleibende fest codierte HTTP-URLs automatisch.

Fehlgeschlagene Zertifikatserneuerung führt zur vollständigen Aussperrung von der Website. Ein abgelaufenes oder ungültiges Zertifikat auf einer HSTS-geschützten Domain führt zu einem harten Fehler ohne Umgehungsmöglichkeit für den Benutzer. Browser weigern sich, die Website anzuzeigen oder eine Option „trotzdem fortfahren“ anzubieten. Automatisieren Sie die Zertifikatserneuerung (der certbot von Let’s Encrypt erledigt dies per Cronjob) und überwachen Sie die Ablaufdaten der Zertifikate. Richten Sie Warnmeldungen für mindestens 14 Tage vor Ablauf ein.