HSTS-Test und Preload-Check

Warum HSTS testen?

Der HSTS-Header ist eine der wirksamsten HTTPS-Sicherheitsmaßnahmen, wird aber häufig falsch konfiguriert: zu kurze max-age, vergessene includeSubDomains, oder eine für die Preload-List geeignete Domain, die nie eingereicht wurde. Wer seine Konfiguration regelmäßig testet, erkennt diese Lücken, bevor sie ausgenutzt werden.

Nach diesem einmaligen Test kann die Sicherheitsnote HSTS für eine URL mit bezahlter Uptime (3 €), einem Pack oder dem Agentur-Angebot fortlaufend überwachen.

Drei zentrale Anwendungsfälle:

• Sicherheitsaudit vor dem Go-live: prüfen, dass die HTTPS-Kette, die HTTP-zu-HTTPS-Umleitung und der Strict-Transport-Security-Header zusammenpassen, bevor eine neue Domain öffentlich freigegeben wird.
• Vorbereitung auf die Preload-List: die vier Anforderungen prüfen (max-age größer oder gleich 31536000, includeSubDomains, preload, HTTP-zu-HTTPS-Umleitung), bevor die Domain auf hstspreload.org eingereicht wird.
• Verifizierung nach einer Migration: nach einer Infrastruktur-Änderung (Wechsel zu Cloudflare, Migration auf einen neuen Nginx-Cluster) bestätigen, dass der HSTS-Header weiterhin mit den richtigen Direktiven auf der Apex-Domain und den Subdomains gesendet wird.

So nutzen Sie den HSTS-Test in 3 Schritten

Schritt 1: Domain eingeben

Tippen Sie die Root-Domain ohne https:// und ohne Pfad (z. B. captaindns.com). Das Tool zielt automatisch auf die HTTPS-Version der Website und folgt der initialen Umleitung, falls vorhanden. Vermeiden Sie Subdomains bei der ersten Analyse, außer Sie wollen gezielt einen bestimmten Dienst prüfen (z. B. api.captaindns.com).

Schritt 2: HSTS-Test starten

Klicken Sie auf Testen. CaptainDNS führt drei Aktionen parallel aus: Abfrage des Strict-Transport-Security-Headers, den der Server zurückgibt, Anfrage an die Preload-List von Chrome zur Statusbestätigung und Analyse der Direktiven max-age, includeSubDomains und preload. Das vollständige Ergebnis erscheint in unter 3 Sekunden.

Schritt 3: Empfehlungen umsetzen

Lesen Sie Ihr Rating (missing, weak, good, preload-ready oder preloaded) und die Liste der vorgeschlagenen Fixes. Kopieren Sie das passende Snippet für Nginx, Apache oder Cloudflare zu Ihrem Stack, deployen Sie es und starten Sie den Test erneut, um den Sprung zur höheren Stufe zu bestätigen. Iterieren Sie so lange, bis Sie preloaded erreichen, falls die Preload-List Ihr Ziel ist.

Was ist HSTS?

HSTS (HTTP Strict Transport Security) ist ein HTTP-Response-Header, der 2012 durch RFC 6797 standardisiert wurde. Wenn ein Browser diesen Header über eine gültige HTTPS-Verbindung empfängt, merkt er sich die Domain und lehnt für die festgelegte Dauer jede Klartext-Verbindung zu ihr ab. Die Umwandlung von http:// zu https:// erfolgt lokal im Browser, vor dem ersten Netzwerkpaket, und schließt damit das Zeitfenster für eine Interception bei der ersten Umleitung.

Der Header besteht aus drei Direktiven:

• max-age: Dauer in Sekunden, während der der Browser HSTS erzwingt. Empfohlener Wert für stabilen Produktivbetrieb: 31536000 (1 Jahr). Für die Preload-List: mindestens 31536000.
• includeSubDomains: erweitert den Schutz auf alle Subdomains (www, api, mail usw.). Pflicht für die Preload-List.
• preload: signalisiert die Zustimmung des Eigentümers zur Einreichung der Domain in die Preload-List von Chrome. Ohne diese Direktive lehnt hstspreload.org die Einreichung ab.

Beispiel eines vollständigen Headers:

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

Ohne HSTS sendet ein Nutzer, der captaindns.com in die Adressleiste tippt, zuerst eine HTTP-Anfrage im Klartext. Ein Angreifer im selben Wi-Fi-Netz kann diese Anfrage abfangen und eine manipulierte Version der Website ausliefern (SSL-Stripping-Angriff). HSTS macht diesen Angriff nach dem ersten legitimen Besuch unmöglich, und die Preload-List macht ihn schon beim ersten Besuch unmöglich, für Domains, die im Browser vorab geladen sind.

Die 5 Stufen erklärt

CaptainDNS vergibt eine Stufe basierend auf den erkannten Direktiven und dem Preload-Status. Hier die Bewertungsskala:

Die Stufe preload-ready bedeutet nicht, dass die Domain in der Preload-List ist: Sie zeigt, dass sie die technischen Bedingungen erfüllt, um eingereicht zu werden, oder dass eine Einreichung bereits auf die Aufnahme wartet. Die Einreichung selbst läuft über hstspreload.org, und die Aufnahme in Chrome dauert in der Regel 6 bis 12 Wochen.

So korrigieren Sie Ihre HSTS-Konfiguration

Hier die einsatzbereiten Snippets für die drei häufigsten Plattformen. Alle aktivieren ein HSTS, das den Anforderungen der Preload-List entspricht.

Nginx

# /etc/nginx/sites-available/captaindns.com
server {
    listen 443 ssl http2;
    server_name captaindns.com;

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

Das Schlüsselwort always sorgt dafür, dass der Header auch bei Fehlerantworten (4xx, 5xx) gesendet wird. Ohne dieses Schlüsselwort würde eine 404-Seite den HSTS-Header nicht tragen.

Apache (mod_headers)

# /etc/apache2/sites-available/captaindns.com.conf
<VirtualHost *:443>
    ServerName captaindns.com
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</VirtualHost>

Aktivieren Sie das Modul mit a2enmod headers, falls noch nicht geschehen, und laden Sie Apache dann neu.

Cloudflare Workers

addEventListener('fetch', event => {
    event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
    const response = await fetch(request);
    const newHeaders = new Headers(response.headers);
    newHeaders.set(
        'Strict-Transport-Security',
        'max-age=31536000; includeSubDomains; preload'
    );
    return new Response(response.body, {
        status: response.status,
        statusText: response.statusText,
        headers: newHeaders,
    });
}

Bei Cloudflare können Sie HSTS auch direkt im Dashboard aktivieren (SSL/TLS, Edge Certificates, HTTP Strict Transport Security), ohne einen Worker zu deployen.

Starten Sie nach jeder Änderung den HSTS-Test erneut, um die Übernahme auf der CDN- oder Reverse-Proxy-Seite zu bestätigen.

Eintragung in die HSTS-Preload-List

Die Preload-List ist eine Liste von Domains, die fest in Chrome verdrahtet ist (und von Firefox, Safari, Edge und Opera übernommen wird). Jede Domain in der Liste wird von den Browsern schon beim allerersten Besuch als HTTPS-only behandelt, ohne dass der HSTS-Header zuvor empfangen werden muss.

Um eine Domain auf hstspreload.org einzureichen, muss sie vier Bedingungen erfüllen:

• max-age größer oder gleich 31536000 (1 Jahr).
• Direktive includeSubDomains im Header vorhanden.
• Direktive preload im Header vorhanden.
• HTTP-zu-HTTPS-Umleitung aktiv auf der Apex-Domain und allen Subdomains.

Auch das Zertifikat muss gültig sein (vollständige Kette, nicht selbst signiert, nicht abgelaufen). Sobald die Einreichung akzeptiert ist, dauert die Aufnahme in Chrome im Schnitt 6 bis 12 Wochen, bis die Änderung in einer neuen stabilen Browser-Version ausgeliefert wird.

Warnung zur Unumkehrbarkeit. Die Entfernung einer Domain aus der Preload-List ist technisch möglich (Entfernungsformular auf hstspreload.org), aber sie dauert mehrere Monate und wirkt nur auf zukünftige Versionen von Chrome. Nutzer mit älteren Versionen erzwingen weiterhin HTTPS, jahrelang. Prüfen Sie vor der Einreichung, dass jede Produktions-, Staging- und interne Admin-Subdomain über HTTPS erreichbar ist und dass kurzfristig kein Wechsel auf einen anderen Domainnamen geplant ist.

Konkrete Anwendungsfälle

Vorfall 1: Stufe weak nach einem externen Sicherheitsaudit

Symptom: Ein externes Sicherheitsaudit meldet, dass captaindns.com zwar einen HSTS-Header sendet, der max-age-Wert (3600) aber zu niedrig ist, um echten Schutz zu bieten.

Diagnose: Der HSTS-Test bestätigt das Vorhandensein von Strict-Transport-Security: max-age=3600. Keine Direktive includeSubDomains oder preload. Die zugewiesene Stufe ist weak.

Maßnahme: Die Nginx-Konfiguration auf max-age=31536000; includeSubDomains; preload umstellen, nachdem geprüft wurde, dass alle Subdomains (api, mail, status) über HTTPS antworten. Den Test erneut starten: Die Stufe steigt auf preload-ready.

Vorfall 2: Subdomain nach Aktivierung von includeSubDomains kaputt

Symptom: Nach der Aktivierung von includeSubDomains auf captaindns.com wird das interne Tool metrics.captaindns.com für die Teams unerreichbar. Fehler "ERR_SSL_PROTOCOL_ERROR" in Chrome.

Diagnose: Die Subdomain metrics besitzt nur einen HTTP-Endpoint. Die Direktive includeSubDomains, die in den Browsern der Teams gespeichert ist, erzwingt jetzt HTTPS, aber kein Zertifikat wird auf dieser Subdomain ausgeliefert.

Maßnahme: Dringend ein Let's Encrypt-Zertifikat auf metrics ausrollen oder die Direktive includeSubDomains vorübergehend entfernen und den lokalen HSTS-Cache der Teams leeren (chrome://net-internals/#hsts), bis die Subdomain wieder konform ist.

Vorfall 3: preload-ready Domain nie eingereicht

Symptom: Bei einem internen Sicherheitsaudit zeigt der Test, dass captaindns.com seit über einem Jahr preload-ready ist, aber nicht in der Preload-List von Chrome steht. Neue Besucher bleiben beim allerersten Besuch anfällig für SSL-Stripping.

Diagnose: Die Server-Konfiguration ist korrekt (max-age=31536000, includeSubDomains, preload, HTTP-zu-HTTPS-Umleitung). Der von Chrome zurückgegebene Preload-Status lautet "Not in preload list".

Maßnahme: Die Domain auf hstspreload.org einreichen. Die Bestätigung verfolgen und dann 6 bis 12 Wochen auf die Verbreitung in der stabilen Chrome-Version warten. Die Entscheidung und ihre Unumkehrbarkeit im internen Sicherheitsregister dokumentieren.

FAQ - Häufig gestellte Fragen

F: Was ist HSTS?

A: HSTS (HTTP Strict Transport Security) ist ein HTTP-Response-Header, der durch RFC 6797 definiert ist. Er weist den Browser an, die Domain nur über HTTPS zu kontaktieren, für die in max-age festgelegte Dauer. Sobald der Header gespeichert ist, wandelt der Browser jede http://-Anfrage in https:// um, bevor sie gesendet wird, was Downgrade- und SSL-Stripping-Angriffe in nicht vertrauenswürdigen Netzwerken verhindert.

F: Welchen max-age-Wert sollen Sie für HSTS wählen?

A: Für eine vorsichtige Inbetriebnahme starten Sie mit max-age=300 (5 Minuten), um ohne Risiko zu testen. Sobald die HTTPS-Kette validiert ist, steigern Sie schrittweise auf 86400 (1 Tag), dann 604800 (1 Woche). Für die Preload-List ist der Mindestwert 31536000 (1 Jahr), was auch der empfohlene Wert für stabilen Produktivbetrieb ist. Ein höherer Wert bringt keinen zusätzlichen Gewinn.

F: Ist HSTS-Preload reversibel?

A: Ja, aber in der Praxis sehr langsam. Sie können die Entfernung über hstspreload.org beantragen, aber der Vorgang dauert mehrere Monate und wirkt nur auf zukünftige Versionen von Chrome. Nutzer mit älteren Versionen erzwingen weiterhin HTTPS, jahrelang. Stellen Sie vor der Einreichung sicher, dass alle Ressourcen, einschließlich interner Subdomains, über HTTPS erreichbar sind.

F: Funktioniert HSTS ohne HTTPS?

A: Nein. RFC 6797 verlangt, dass der Strict-Transport-Security-Header ignoriert wird, wenn er über HTTP empfangen wird. Nur Antworten, die über eine gültige TLS-Verbindung ausgeliefert werden, können HSTS im Browser aktivieren. Sie müssen also zuerst ein gültiges Zertifikat (z. B. Let's Encrypt) ausrollen und den gesamten HTTP-Traffic auf HTTPS umleiten, bevor Sie den Header senden.

F: HSTS und HTTPS-Redirect, was ist der Unterschied?

A: Ein 301-Redirect von HTTP auf HTTPS wird vom Server ausgeführt, nachdem die Klartext-Anfrage das Gerät bereits verlassen hat. Ein Angreifer in einer Man-in-the-Middle-Position kann diese erste Anfrage abfangen. HSTS löst dieses Problem: Nach dem ersten Besuch wandelt der Browser http:// selbst in https:// um, bevor irgendetwas ins Netz geht. Der Redirect bleibt für den allerersten Besuch und für Clients nötig, die den Header nie empfangen haben.

F: Sollen Sie includeSubDomains aktivieren?

A: Ja, sobald alle Subdomains (www, api, mail, admin, intranet usw.) über HTTPS erreichbar sind. Die Direktive includeSubDomains weitet den HSTS-Schutz auf die gesamte Domain aus und ist für die Preload-List Pflicht. Bevor Sie sie aktivieren, prüfen Sie jede aktive Subdomain: Eine interne Subdomain auf HTTP (z. B. ein Monitoring-Tool) wird unerreichbar, sobald die Browser den Header gespeichert haben.

Ergänzende Tools

Der HSTS-Test kombiniert sich mit anderen CaptainDNS-Tools, um die HTTP-, DNS- und Mail-Sicherheit abzudecken:

Nützliche Ressourcen

• Vollständiger HSTS- und Preload-List-Leitfaden von CaptainDNS (Referenzleitfaden zur schrittweisen Aktivierung von Strict-Transport-Security: Direktiven, Konfigurationen für Nginx, Apache, Cloudflare, AWS, Caddy, Preload-Einreichung)
• hstspreload.org (offizielles Einreichungsformular für die Preload-List von Chrome)
• MDN: Strict-Transport-Security (Referenzdokumentation zum HSTS-Header und seinen Direktiven)
• RFC 6797 (Originalspezifikation von HTTP Strict Transport Security)
• OWASP HSTS Cheat Sheet (Best Practices für die HSTS-Bereitstellung)
• content-security-policy.com (Praxisleitfaden zu HSTS mit Konfigurationsbeispielen)