Wann HSTS wirkt
HTTP Strict Transport Security (HSTS) ist eine Browserrichtlinie für einen Host. Der Browser muss sie bereits kennen: aus einem gültigen HTTPS-Response dieses Hosts, über eine geltende includeSubDomains-Richtlinie eines übergeordneten Hosts oder aus seiner Preload-Liste. Dann wandelt er einen HTTP-Aufruf vor dem Netzwerkzugriff in HTTPS um. RFC 6797, Abschnitt 8
Eine HTTP-Weiterleitung arbeitet anders: Der Server beantwortet zunächst eine HTTP-Anfrage und nennt ein HTTPS-Ziel. HSTS kann diesen unverschlüsselten Einstieg für einen bereits erfassten Host vermeiden. Der dynamische Header schützt einen noch unbekannten ersten HTTP-Aufruf nicht rückwirkend. Fehlendes HSTS beweist umgekehrt nicht, dass ein moderner Browser tatsächlich HTTP verwendet; auch direkte HTTPS-Aufrufe und browserseitige HTTPS-Upgrades spielen eine Rolle. RFC 6797, Abschnitt 14.6, HSTS Preload: Einordnung
Für die Einführung sind drei Fragen entscheidend:
- Funktionieren HTTPS und die Zertifikatserneuerung für den erfassten Host zuverlässig?
- Welche Subdomains würden Sie mit
includeSubDomainszusätzlich erfassen? - Können Sie die gewählte Speicherdauer und gegebenenfalls einen Preload-Eintrag langfristig tragen?
Was HSTS gegen SSL-Stripping leistet
Bei SSL-Stripping nutzt ein Angreifer auf dem Netzwerkpfad einen ungeschützten HTTP-Einstieg. Er kann Weiterleitungen oder Links manipulieren und den Browser auf HTTP halten, während er selbst HTTPS zum eigentlichen Server verwendet. Dabei wird eine bereits korrekt aufgebaute und validierte TLS-Verbindung nicht einfach entschlüsselt.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Situation | Möglicher Ablauf | Grenze der Aussage |
|---|---|---|
| HTTP-Aufruf ohne wirksame HSTS-Richtlinie und ohne andere HTTPS-Aufwertung | Die erste Anfrage kann unverschlüsselt beginnen. Ein Angreifer auf dem Netzwerkpfad kann diesen Einstieg manipulieren; über HTTP gesendete Daten können offenliegen. | Fehlendes HSTS allein belegt weder einen gelungenen Angriff noch, dass der Browser HTTP verwendet hat. |
| HTTP-Aufruf mit wirksamer HSTS-Richtlinie | Der Browser verwendet vor dem Netzwerkzugriff HTTPS. Der unverschlüsselte HTTP-Einstieg zum erfassten Host entfällt. | Die Richtlinie muss diesem Browser bereits bekannt sein. Sie schützt nicht vor allen Netzwerk- oder Anwendungsangriffen. |
Die erste Situation ist das Angriffsszenario, auf das die Erklärung zielt. Browserwarnungen, HTTPS-Upgrades und sichere Cookieattribute beeinflussen zusätzlich, welche Daten im konkreten Fall gefährdet sind. HSTS ersetzt weder eine korrekte TLS-Konfiguration noch sichere Cookies oder Anwendungsschutz. RFC 6797, Bedrohungsmodell
Der HSTS-Header im Detail
Der Server übermittelt die Richtlinie mit dem Antwortheader Strict-Transport-Security. Ein Browser verarbeitet ihn nur nach Empfang über eine fehlerfreie HTTPS-Verbindung. Ein HSTS-Header über unverschlüsseltes HTTP wird ignoriert. RFC 6797, Abschnitt 8.1
Ein kurzer Einstieg für diesen Host, ohne Subdomain-Erweiterung und ohne Preload-Opt-in:
Strict-Transport-Security: max-age=300Das ist ein Headerbeispiel, keine vollständige Serverkonfiguration. Für die konkrete Ausgabestelle wählen Sie eine Stackanleitung.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Bestandteil | Bedeutung | Entscheidung vor dem Einsatz |
|---|---|---|
max-age=300 | Der Browser speichert die Richtlinie für 300 Sekunden, also 5 Minuten, ab dem Empfang. Ein späterer gültiger HSTS-Header aktualisiert den gespeicherten Ablaufzeitpunkt. | Eine kurze Dauer begrenzt die Bindung einer neu gelernten Richtlinie. Sie verkürzt nicht automatisch ältere Einträge bei Browsern, die den neuen Header noch nicht empfangen haben. |
includeSubDomains | Die Richtlinie gilt zusätzlich für untergeordnete Hosts. Bei example.com sind das etwa www.example.com und shop.example.com; bei www.example.com ist example.com nicht eingeschlossen. | Betroffene Subdomains einschließlich verschachtelter und intern genutzter Webangebote erfassen und auf HTTPS prüfen. |
preload | Zusätzliche Opt-in-Direktive für das Preload-Programm, keine HSTS-Direktive aus RFC 6797. | Der Header allein belegt keine Aufnahme oder Verteilung. Preload hat weitere Voraussetzungen und Folgen. |
max-age ist erforderlich; includeSubDomains und preload sind keine Pflicht für einen gewöhnlichen HSTS-Einsatz. Lange Werte wie 31536000 (365 Tage) oder 63072000 (730 Tage) gehören an das Ende einer bewussten Betriebsentscheidung. Sie sind kein allgemeiner Startwert. RFC 6797, Abschnitte 6.1 und 8.1, Preload-Anforderungen
HSTS schrittweise einführen
Prüfen Sie zuerst HTTPS, Zertifikate, Weiterleitungen und die Antwortpfade Ihrer Anwendung. Stellen Sie sicher, dass Sie die aktive Konfiguration ändern und Zertifikate erneuern können. Legen Sie fest, wer bei einem Ausfall handelt.
Die folgende Staffel ist ein Planungsbeispiel. Sie gibt keine festen Projektwochen, Erfolgskriterien unter Last oder automatische Freigabe vor. Prüfen Sie in jeder Stufe betroffene Webangebote und lassen Sie mindestens die bisherige Speicherdauer verstreichen, bevor Sie erhöhen. HSTS Preload: Empfehlungen zur Einführung
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Stufe | Beispielwert | Was vor der nächsten Stufe feststehen sollte |
|---|---|---|
| Kurzer Funktionstest | max-age=300 | Der Header kommt über gültiges HTTPS an. Wichtige Seiten und benötigte Antwortpfade funktionieren. |
| Beobachtung im Betrieb | max-age=604800 | Eine Woche Speicherdauer ist vertretbar; Zertifikatserneuerung, Fehlerbehandlung und Zuständigkeiten sind geklärt. |
| Längere Beobachtung | max-age=2592000 | 30 Tage Speicherdauer passen zum Betrieb. Aufgetretene Probleme sind behoben. |
| Langfristige Richtlinie | max-age=31536000 | Der Betreiber kann HTTPS über die lange Bindung zuverlässig bereitstellen. |
| Optional: Subdomains einbeziehen | Zum bewusst gewählten Wert includeSubDomains ergänzen | Alle betroffenen Webangebote sind erfasst und HTTPS-fähig. Die Erweiterung selbst wird bewusst eingeführt. |
| Optional: Preload | Beispielsweise max-age=63072000; includeSubDomains; preload | Gesonderte Preload-Entscheidung, erfüllte Aufnahmebedingungen und langfristiger HTTPS-Betrieb. Kein obligatorischer letzter Schritt. |
Preload als eigene langfristige Entscheidung
Ein tatsächlich im verwendeten Browser vorhandener Preload-Eintrag kann HTTPS bereits vor dem ersten Besuch erzwingen. Chrome führt eine solche Liste; weitere Browser verwenden daraus abgeleitete Listen. Daraus folgt keine Zusage, dass jeder Eintrag zu einem bestimmten Zeitpunkt in jedem Browser angekommen ist.
Die Betreiber von hstspreload.org empfehlen HSTS, sprechen aber keine allgemeine Empfehlung für Preload aus. Setzen Sie preload deshalb nicht beiläufig aus einer kopierten Konfiguration.
Wer sich bewusst für eine Einreichung entscheidet, muss die aktuellen Bedingungen erfüllen:
- Ein gültiges Zertifikat bereitstellen.
- Falls Port 80 offen ist, HTTP zunächst zu HTTPS auf demselben Host weiterleiten.
- Alle betroffenen Subdomains über HTTPS betreiben, auch verschachtelte und interne Webangebote. Dazu gehört
www, wenn dafür ein DNS-Eintrag existiert. - Auf der Basisdomain über HTTPS einen HSTS-Header mit mindestens
max-age=31536000,includeSubDomainsundpreloadsenden. - Falls diese HTTPS-Antwort nochmals weiterleitet, bereits auf dieser Weiterleitung den Header senden.
Die Einreichung und Statusabfrage sind ein gesonderter Vorgang. Der Header zeigt ein Opt-in, aber noch keinen ausgelieferten Listeneintrag. Die Bedingungen müssen auch nach der Aufnahme erfüllt bleiben. Preload-Anforderungen
Was ein HSTS-Befund zeigt
Eine aktuelle HTTPS-Antwort zeigt, welchen Header der untersuchte Host auf diesem Antwortpfad ausliefert. Bei einer Weiterleitung auf einen anderen Host gehört der dort empfangene Header zu diesem Zielhost. Aus der Zielantwort lässt sich kein HSTS-Header des ursprünglichen Hosts ableiten.
Davon getrennt sind der gespeicherte Zustand eines bestimmten Browsers, die Richtlinie eines übergeordneten Hosts und ein vorhandener Preload-Eintrag. Ein fehlender Header löscht eine zuvor gespeicherte Richtlinie nicht: Sie kann bis zu ihrem Ablauf weiter gelten. RFC 6797, Abschnitte 8.1 und 8.6
Prüfen Sie deshalb Host, Protokoll, Antwortstatus und relevante Pfade gemeinsam. Die vorhandene Nginx-Anleitung zum Setzen und Prüfen von HSTS bietet dafür einen konkreten Einstieg. Wenn der Header auffällig ist, kann der Befund bereits genügen, um eine konkrete Konfigurationsfrage an den zuständigen Betreiber zu geben.
HSTS dokumentieren: Reichweite und Grenzen
Ein HSTS-Header ist ein technischer Einzelbefund zur HTTPS-Nutzung in unterstützenden Browsern. Dokumentieren Sie den geprüften Host, die URL, den Messzeitpunkt, den empfangenen Header und die Grenzen der Prüfung.
Der Befund belegt nicht, dass sämtliche Verbindungen oder personenbezogenen Daten geschützt sind. Er ersetzt weder ein TLS-Audit noch eine Prüfung regulatorischer Anforderungen. Aus einem vorhandenen Header oder einer Punktzahl folgt insbesondere keine NIS2-, DSGVO- oder IT-Grundschutz-Konformität. Diese Anleitung bewertet keine rechtlichen Pflichten einzelner Länder.
Passende Anleitungen und nächste Schritte
Die Nginx-Anleitung zeigt das Setzen des Headers und grundlegende Prüfschritte. Der Abschnitt zu Preload erläutert die Reichweite und Voraussetzungen.
Der Web Security Check untersucht öffentlich erreichbare Konfigurationsmerkmale und zeigt Einzelbefunde mit Messgrenzen. Ein solcher Befund ersetzt keine Prüfung aller Hosts, Pfade oder Browserzustände. Die Web-Security-Übersicht ordnet HSTS neben weitere Themen ein.
Häufige Fragen zu HSTS
Was ist HSTS?
HSTS steht für HTTP Strict Transport Security. Ein unterstützender Browser verwendet für einen von der Richtlinie erfassten Host nur HTTPS. Die Richtlinie muss ihm aus einem gültigen HTTPS-Response, über einen übergeordneten Host oder aus einer Preload-Liste bereits bekannt sein.
Schützt HSTS vor allen Man-in-the-Middle-Angriffen?
Nein. Eine wirksame HSTS-Richtlinie verhindert den unverschlüsselten HTTP-Einstieg zum erfassten Host. Ein dynamischer Header schützt einen noch unbekannten Erstkontakt nicht rückwirkend. HSTS ist kein Schutz vor sämtlichen Netzwerk- oder Anwendungsangriffen.
Was passiert, wenn das Zertifikat abläuft?
Ein Browser, der HSTS für den Host anwendet, muss die Verbindung bei TLS-Fehlern abbrechen und darf keine gewöhnliche Ausnahme anbieten. Verlässliche Zertifikatserneuerung und betriebliche Überwachung sind deshalb wichtig. Ein Headerfund belegt nicht, dass diese Prozesse funktionieren. RFC 6797, Abschnitt 8.4
Kann ich HSTS rückgängig machen?
Ein über gültiges HTTPS empfangenes max-age=0 löscht den dynamischen Eintrag für diesen Host. Eine übergeordnete includeSubDomains-Richtlinie oder ein Preload-Eintrag kann weiter gelten. Ohne erneuten Empfang der Änderung bleibt eine zuvor gelernte Richtlinie bis zu ihrem Ablauf wirksam.
Was bedeutet includeSubDomains?
Die Direktive erweitert die Richtlinie auf untergeordnete Hosts. Sie gilt nicht nach oben oder seitwärts: Eine Richtlinie von www.example.com erfasst weder example.com noch shop.example.com. Aktivieren Sie die Erweiterung erst nach Prüfung der betroffenen Webangebote.
Beweist HSTS NIS2-Konformität?
Nein. Der Header dokumentiert eine begrenzte Browseranweisung zur HTTPS-Nutzung. Er ist kein Nachweis für die Erfüllung regulatorischer Anforderungen. Diese Anleitung trifft keine Aussage dazu, welche rechtlichen Pflichten für eine bestimmte Einrichtung gelten.
Quellen
- RFC 6797: HTTP Strict Transport Security, November 2012; insbesondere Abschnitte 2.3, 6.1, 8.1–8.6, 11.4 und 14.6.
- HSTS Preload: Einführung, Aufnahmebedingungen und Entfernung, am 12. September 2026 konsultiert; ein veränderliches Browserprogramm, keine allgemeine Preload-Empfehlung.
Die beschriebenen Beispiele erklären den Mechanismus. Sie sind keine Messung einer Kundenwebsite.