So implementieren Sie HTTP Strict Transport Security

Was HSTS bewirkt und warum es wichtig ist

HTTP Strict Transport Security (HSTS) ist eine in RFC 6797 definierte Sicherheitsrichtlinie. Eine Website sendet sie als Response-Header über HTTPS, und der Browser merkt sie sich. Für die von der Website festgelegte Dauer schreibt der Browser jeden http://-Link vor dem Senden automatisch in https:// um und verhindert, dass der Nutzer Zertifikatsfehler für diesen Host übergeht.

Ohne HSTS stellt ein Besucher, der example.com in die Adresszeile tippt, meist zuerst eine Anfrage über unverschlüsseltes HTTP und wird dann auf HTTPS umgeleitet. Diese erste unverschlüsselte Anfrage ist ein Einfallstor für Angreifer im selben Netzwerk, etwa an einem manipulierten WLAN-Hotspot: Sie können die Verbindung abfangen und den Nutzer auf HTTP halten (eine Technik, die oft SSL-Stripping genannt wird). HSTS schließt diese Lücke für jeden Besuch, nachdem der Browser den Header einmal gesehen hat, und die Preload-Liste schließt sie sogar beim allerersten Besuch.

HSTS ersetzt HTTPS nicht. Es ist eine zusätzliche Schicht auf einer korrekt konfigurierten TLS-Umgebung, die Browsern sagt, niemals auf HTTP zurückzufallen.

Die Header-Syntax erklärt

Der Header hat eine Pflicht- und zwei optionale Direktiven:

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

Einige Regeln werden leicht übersehen:

• Browser ignorieren den Header, wenn er über unverschlüsseltes HTTP ankommt. Er zählt nur über eine gültige HTTPS-Verbindung.
• Bei jedem Empfang des Headers beginnt der Countdown neu, eine regelmäßig besuchte Website bleibt also faktisch dauerhaft geschützt.
• Senden Sie nur einen einzigen Strict-Transport-Security-Header. Duplikate, oft entstanden durch Setzen in Anwendung und Webserver zugleich, können dazu führen, dass die Richtlinie ignoriert wird.

Voraussetzungen vor dem Aktivieren

Da HSTS den Rückfall auf HTTP unmöglich macht, sollten Sie sich gründlich vorbereiten. Arbeiten Sie zuerst diese Checkliste ab:

1. Überall gültige Zertifikate. Jeder abgedeckte Hostname muss ein vertrauenswürdiges, nicht abgelaufenes und zum Namen passendes Zertifikat ausliefern.
2. Eine funktionierende Weiterleitung von HTTP auf HTTPS. Anfragen auf Port 80 sollten mit 301 auf die HTTPS-Version derselben URL verweisen.
3. Kein Mixed Content. Skripte, Bilder, Schriften und API-Aufrufe sollten per HTTPS geladen werden. HSTS stuft Links zu Ihrem eigenen Host hoch, Drittanbieter-Ressourcen über HTTP werden aber weiterhin blockiert oder markiert.
4. Eine Subdomain-Inventur. Listen Sie jede Subdomain Ihrer DNS-Zone auf, einschließlich alter Staging-Hosts, Webmail-Portale, interner Tools und per CNAME eingebundener Seiten von Dienstleistern. Jede, die kein HTTPS beherrscht, fällt aus, sobald Sie includeSubDomains hinzufügen.
5. Eine verlässliche Zertifikatsverlängerung. Automatische Verlängerung (zum Beispiel per ACME) plus unabhängige Ablaufüberwachung.

Für Inventur und Überwachung hilft ein Verlängerungs-Tracker: Sie können jedes Zertifikat und jede Domain im TLDix-Domain-Tracking erfassen und erhalten Warnungen lange vor dem Ablauf.

Eine sichere, schrittweise Einführung

Der größte HSTS-Fehler ist der direkte Sprung auf eine einjährige Richtlinie mit includeSubDomains. Geht etwas schief, bleiben Besucher, die den Header bereits erhalten haben, bis zum Ablauf von max-age auf HTTPS festgelegt, und Sie können ihn nicht aus ihren Browsern zurückholen. Ein gestuftes Vorgehen begrenzt den Schaden:

Die Zeiträume sind Richtwerte, keine Regeln. Gehen Sie erst zur nächsten Stufe über, wenn Logs und Nutzerrückmeldungen zeigen, dass nichts ausgefallen ist.

HSTS auf gängigen Servern konfigurieren

Nginx

Fügen Sie den Header im HTTPS-Serverblock hinzu. Der Parameter always sorgt dafür, dass Nginx ihn auch bei Fehlerantworten sendet.

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    # ssl_certificate und weitere Direktiven hier
}

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

Beachten Sie, dass in Nginx ein add_header in einem verschachtelten location-Block die von der Serverebene geerbten Header ersetzt. Wiederholen Sie ihn also, wo nötig, oder nutzen Sie eine Include-Datei.

Apache

Aktivieren Sie mod_headers und fügen Sie die Direktive im SSL-VirtualHost hinzu:

<VirtualHost *:443>
    ServerName example.com
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</VirtualHost>

<VirtualHost *:80>
    ServerName example.com
    Redirect permanent / https://example.com/
</VirtualHost>

CDNs und Anwendungs-Frameworks

Viele CDNs und Reverse Proxys bieten im Dashboard einen HSTS-Schalter, und die meisten Web-Frameworks haben eine passende Middleware. Wählen Sie einen einzigen Ort, an dem der Header gesetzt wird. Fügen ihn CDN und Ursprungsserver gleichzeitig hinzu, entstehen womöglich doppelte oder widersprüchliche Werte.

Die HSTS-Preload-Liste

Die großen Browser enthalten eine eingebaute Liste von Domains, die schon ab der allerersten Anfrage nur per HTTPS erreichbar sind. Ein Eintrag beseitigt die Lücke beim ersten Besuch (Trust on First Use). Die Liste wird über die Einreichungsseite hstspreload.org verwaltet; zu ihren Anforderungen (die aktuelle Fassung finden Sie dort) gehören in der Regel:

• Ein gültiges Zertifikat und eine Weiterleitung von HTTP auf HTTPS auf demselben Host.
• Alle Subdomains werden per HTTPS ausgeliefert.
• Der Header auf der Basisdomain mit langem max-age (zum Zeitpunkt des Schreibens mindestens ein Jahr), includeSubDomains und preload.

Preloading ist eine langfristige Verpflichtung. Eine Entfernung ist möglich, erreicht Nutzer aber erst, wenn Browser-Updates ausgeliefert werden, was Monate dauern kann. Einige TLDs sind komplett vorab geladen, das heißt, jede Domain darunter ist in unterstützenden Browsern standardmäßig nur per HTTPS erreichbar. Wenn Sie einen neuen Namen suchen, können Sie Optionen mit der Domainsuche prüfen und diesen Punkt berücksichtigen.

HSTS und verwandte Sicherheits-Header

HSTS wird oft zusammen mit anderen Response-Headern eingesetzt, und es lohnt sich, die Unterschiede zu kennen. Eine Content-Security-Policy mit der Direktive upgrade-insecure-requests weist Browser an, Unterressourcen Ihrer Seiten per HTTPS zu laden – eine gute Ergänzung zu HSTS, wenn alte Inhalte noch HTTP-Links zu Dritten enthalten. HSTS regelt dagegen, wie der Browser sich mit Ihrem Host selbst verbindet. Keiner ersetzt den anderen, und auf ausgereiften Websites sind meist beide gesetzt. Prüfen Sie sie gemeinsam, wann immer Sie CDN oder Reverse Proxy ändern, denn bei einem Neuaufbau der Konfiguration können mehrere Header gleichzeitig verloren gehen.

Die Richtlinie testen und überprüfen

Prüfen Sie den Header auf der Kommandozeile:

curl -sI https://example.com | grep -i strict-transport-security

Testen Sie anschließend das Verhalten, nicht nur das Vorhandensein:

• Rufen Sie http://example.com auf und prüfen Sie, ob mit 301 auf HTTPS umgeleitet wird.
• In Chromium-basierten Browsern können Sie auf der internen Seite net-internals/#hsts abfragen, ob für eine Domain eine Richtlinie gespeichert ist, und sie während der Tests löschen.
• Testen Sie jede Subdomain per HTTPS, bevor Sie includeSubDomains hinzufügen – auch selten genutzte.
• Testen Sie nach Deployments, CDN-Änderungen oder Servermigrationen erneut, da Header beim Neuaufbau der Konfiguration oft verloren gehen.

Häufige Fallstricke und wie Sie sie vermeiden

• Vergessene Subdomains. Ein alter Intranet-Host oder eine Dienstleisterseite per CNAME ohne Zertifikat fällt aus, sobald includeSubDomains greift. Prüfen Sie zuerst das DNS.
• Abgelaufene Zertifikate. Mit HSTS sperren Browser den Zugriff vollständig, wenn ein Zertifikat ungültig ist. Aus einer Warnung wird ein kompletter Ausfall. Überwachen Sie Ablaufdaten unabhängig von Ihrer Verlängerungsautomatik.
• Header in HTTP-Antworten. Dort wird er ignoriert, bietet also keinen Schutz und kann Audits verwirren.
• Entwicklungsdomains. Senden Sie HSTS nicht von lokalen oder Test-Hosts, die eine übergeordnete Domain mit der Produktion teilen, sofern diese nicht ebenfalls HTTPS unterstützen.
• Zurückrollen. Um eine Richtlinie zurückzuziehen, liefern Sie max-age=0 per HTTPS aus. Browser, die das sehen, vergessen die Regel; wer die Website nie wieder besucht, behält sie bis zum Ablauf.

HSTS wirkt am besten als Teil eines umfassenderen Härtungsplans. Kombinieren Sie es mit CAA-Einträgen, um festzulegen, welche Stellen Zertifikate ausstellen dürfen, und lesen Sie die übergreifenden Best Practices zur Domain-Sicherheit für die Konto- und DNS-Seite.

HSTS dauerhaft gesund halten

Einmal eingerichtet, braucht HSTS wenig Aufmerksamkeit, solange HTTPS funktioniert. Verankern Sie ein paar Gewohnheiten im Betrieb: Halten Sie die Subdomain-Inventur aktuell, nehmen Sie die Header-Prüfung in Ihre Deployment-Tests auf und verfolgen Sie jedes Verlängerungsdatum für Zertifikate und Domains. Bei der Prüfung älterer Websites können Sie mit der Hosting-Abfrage nachsehen, wo eine Website liegt, und Details bestätigen. Die Richtlinie ist nur so verlässlich wie die Zertifikate und Domainregistrierungen darunter – behandeln Sie Verlängerungen daher als Teil derselben Sicherheitsmaßnahme.

Kurze Betriebs-Checkliste

• Neue Subdomain angelegt? Zuerst Zertifikat einrichten, dann DNS-Eintrag veröffentlichen.
• CDN oder Proxy gewechselt? Header und Weiterleitung sofort erneut prüfen.
• Dienst abgeschaltet? Den zugehörigen DNS-Eintrag entfernen, statt ihn ins Leere zeigen zu lassen.