Die HTTPS-Verschlüsselung löst viele Probleme, aber ein Element bleibt seit Jahren ein kritischer Verwundbarkeitspunkt: der Moment, in dem der Browser noch nicht weiß, ob er HTTPS verwenden soll. Diese Phase geht der eigentlichen TLS-Verbindung voraus. Sie findet statt, bevor der Handshake durchgeführt wird, bevor das Zertifikat überprüft wird und bevor der Server überhaupt die Möglichkeit erhält, irgendwelche Richtlinien durchzusetzen. Genau in diesem Zeitfenster entsteht Raum für SSL-Stripping, Manipulation des Verkehrs in öffentlichen Netzwerken sowie für Angriffe, die darauf beruhen, die erste Anfrage abzufangen und die Antwort so zu verändern, dass der Benutzer niemals die verschlüsselte Version erreicht.

HSTS und HSTS Preload: wie entscheidet der Browser über Vertrauen, bevor eine Verbindung entsteht?

Der HSTS-Mechanismus wurde als Element entwickelt, das dem Browser ermöglicht, sich zu merken, dass eine bestimmte Domain ausschließlich über HTTPS bedient werden soll. Diese Information erreicht den Browser jedoch erst in dem Moment, in dem der Server den entsprechenden Header zurückgibt, also nach der ersten Verbindung. Wenn diese erste Verbindung kompromittiert ist, kann die HSTS-Richtlinie möglicherweise nie zugestellt werden, da ein Angreifer sie leicht entfernen oder ersetzen kann. Dies führt dazu, dass das grundlegende HSTS-Modell hervorragend funktioniert, aber nur dann, wenn der Benutzer die Website bereits einmal unter sicheren Bedingungen besucht hat. HSTS Preload beseitigt dieses Problem vollständig. Die Preload-Liste ist im Browsercode eingetragen – sie befindet sich buchstäblich in der Chrome-Build-Struktur und wird auf andere Browser synchronisiert. Wenn der Benutzer die Adresse einer preload-fähigen Domain eingibt, stellt der Browser keine Fragen: er verbindet sich nicht über HTTP, erlaubt keine Verbindung auf Port 80 und wartet nicht auf einen Server-Header. Er leitet den Verkehr einfach von Anfang an ausschließlich über HTTPS. In der Praxis wirkt es so, als wäre die gesamte Domain in ein anderes, strengeres Vertrauensmodell verschoben worden – das einzige, in dem es unmöglich ist, den Browser durch Manipulation des ersten Pakets zu täuschen.

Dies lässt sich leicht beobachten, wenn man das Verhalten des Browsers mit und ohne Preload vergleicht. In einer Domain ohne Preload führt der Browser eine tatsächliche HTTP-Anfrage durch, bevor er den 301-Redirect erhält:

GET / HTTP/1.1
Host: example.pl

In einer preload-fähigen Domain entsteht hingegen nicht einmal eine TCP-Verbindung zu Port 80 – der Browser überschreibt die Adresse intern noch vor der Netzwerkschicht:

https://example.pl

Dieser Schritt ist für den Benutzer unsichtbar, hat aber grundlegende Bedeutung. Die gesamte erste Phase der Kommunikation, die am anfälligsten für Manipulation war, hört auf zu existieren. Genau deshalb wird Preload als eine ernsthafte technologische Deklaration betrachtet: man kann es nicht sofort zurückziehen, man kann es nicht umgehen und seine Auswirkungen sind global. Die technischen Anforderungen ergeben sich direkt aus diesem Vertrauensmodell. Browser dürfen keine Situation zulassen, in der eine preload-fähige Domain auch nur eine einzige Subdomain hat, die über HTTP funktioniert, oder einen einzigen Endpoint, der kein Zertifikat unterstützt. Daher sind drei Elemente zwingend erforderlich: max-age von mindestens einem Jahr, includeSubDomains sowie das Schlüsselwort preload. Die Header-Konstruktion muss folgendermaßen aussehen:

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

Wenn eine Domain Cloudflare verwendet, kann der Header sogar gesetzt werden, ohne den Origin zu berühren – direkt in den Transformationsregeln oder im SSL → HSTS-Panel. Bei Servern wie NGINX oder OpenLiteSpeed ist die Konfiguration ebenfalls trivial:

NGINX:

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

OpenLiteSpeed (Regel auf vhost-Ebene):

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

Der größte Fehler von Administratoren besteht in der Annahme, dass HSTS lediglich eine Frage eines einzigen Headers sei. Tatsächlich handelt es sich um eine Entscheidung, die die gesamte Domainarchitektur betrifft. Wenn sich in der Struktur eine ungenutzte Subdomain, eine Testumgebung über HTTP, ein altes Administrationspanel oder irgendetwas anderes befindet, das nicht die HTTPS-Anforderungen erfüllt, disqualifiziert Preload die Domain. Deshalb verzichten viele Unternehmen bewusst darauf, obwohl sie wissen, dass die Lösung sicherheitstechnisch ideal ist. Preload toleriert keine organisatorischen Versäumnisse. Es ist auch erwähnenswert, dass Preload perfekt zum modernen Modell des Verkehrs über ein CDN passt. Wenn TLS am Edge terminiert wird, zum Beispiel in Cloudflare, wird das CDN zum „Server“ für den Browser. Wenn Preload aktiv ist, ist das gesamte Kommunikationsmodell deterministisch und einheitlich – unabhängig davon, an welchem POP der Browser das Routing beendet. Das ist einer der Gründe, warum preload-fähige Domains häufiger eine stabile A+-Bewertung in SSL Labs an allen Verfügbarkeitsstandorten erzielen.

Die Einführung von Preload ist daher eine Entscheidung, die den Charakter der Domain von „HTTPS optional“ zu „HTTPS erforderlich“ verändert. Es ist kein gewöhnliches Einschalten eines Headers. In der Praxis bedeutet es das Schließen aller möglichen Rückwege und eine eindeutige Erklärung: „Diese Domain wird niemals wieder über HTTP funktionieren.“ Für Unternehmen, die Sicherheitsprodukte entwickeln – wie HEXSSL – ist dies ein natürlicher Schritt, da Preload die Konsistenz und Konsequenz in der Gestaltung der Transportarchitektur unterstreicht.

Was passiert, wenn etwas schiefgeht? Preload als schwer rückgängig zu machende Entscheidung.

Preload ist einer der wenigen Sicherheitsmechanismen, der nicht in Echtzeit funktioniert, sondern auf dem Lebenszyklus der Software basiert. Wenn eine Domain in die Preload-Liste aufgenommen wird, laden Browser diese Information im Rahmen von Updates herunter und speichern sie über die gesamte Lebensdauer der installierten Version. Das bedeutet, dass selbst wenn du später den preload-Header entfernst, die Clients deine Domain weiterhin als HTTPS-only behandeln, bis sie eine neue Browserversion installieren. Wenn ein Benutzer ein System verwendet, dessen Updates selten sind (z. B. Android aus dem Jahr 2018), kann die Änderung ihn viele Jahre lang nicht erreichen.

Deshalb ist der Prozess der Entfernung einer Domain aus Preload langsam, und die Propagationszeit hängt von Millionen individueller Faktoren ab. Google verlangt, dass Administratoren die Entfernung einer Domain aus Preload nur in gerechtfertigten Situationen beantragen – in solchen, in denen die Sicherheitskonfiguration ernsthaft und dauerhaft beeinträchtigt wurde. In der Praxis bedeutet dies die Veröffentlichung eines temporären Headers, der die Richtlinie deaktiviert und Browsern erlaubt, wieder HTTP zu verwenden. Browser, die jedoch eine alte Version der Preload-Liste besitzen, werden weiterhin HTTPS erzwingen. Dadurch entsteht eine Situation, in der Preload weniger eine Konfigurationseinstellung ist und mehr eine architektonische Erklärung. Domains, die aus der Preload-Liste entfernt wurden, gibt es nur sehr wenige, gerade weil das Verfahren weder schnell noch schmerzlos ist. Jede Organisation sollte sich vor der Einreichung vollständig darüber im Klaren sein, dass Preload das Kommunikationsmodell auf Jahre hinaus festigt und dass ein sofortiger Rollback unmöglich ist.

Die häufigsten Administratorfehler: wenn die Domain ihre eigene Sicherheitsrichtlinie verletzt.

Obwohl Preload technisch einfach erscheint, sind die Fehler der Administratoren oft subtil und ohne entsprechende Werkzeuge schwer zu erkennen. Das häufigste Problem sind Subdomains, die außerhalb des Bewusstseins des Teams existieren – Staging-Instanzen, die in der Cloud zurückgelassen wurden, Test-Developer-Panels, ungenutzte Wildcards oder Integrationen, die längst ihre Bedeutung verloren haben, aber immer noch in DNS existieren. Wenn auch nur ein solcher Endpoint ausschließlich über HTTP betrieben wird, wird die Preload-Richtlinie verletzt, auch wenn der Domaininhaber nichts davon weiß.

Ein weiterer typischer Fehler ist die Verwendung temporärer Testumgebungen, die öffentlich exponiert und später vergessen werden. Tools wie CertSpotter, crt.sh oder DNS-Scanner zeigen manchmal Hunderte Zertifikate für Subdomains an, an die sich Administratoren nicht mehr erinnern. Wenn die includeSubDomains-Richtlinie aktiv ist, wird jede solche Subdomain als Sicherheitsverpflichtung betrachtet. Viele Probleme ergeben sich auch aus uneinheitlichem Verhalten zwischen Origin und CDN. Wenn das CDN einen korrekten HSTS-Header zurückgibt, der Origin jedoch nicht, entsteht eine Inkonsistenz. Der Browser sieht den Datenverkehr nur über das CDN, aber automatische Mechanismen – wie Compliance-Scanner – können Unterschiede zwischen den Infrastruktur-Ebenen erkennen. In extremen Fällen werden fehlerhafte Header auf dem Origin als Versuch gewertet, das Sicherheitsniveau zu senken, was zur Ablehnung des Preload-Antrags führen kann.

Diese Probleme entstehen nicht aus böser Absicht, sondern aus der natürlichen Komplexität großer DNS-Strukturen und hunderter Zugangspunkte. Genau deshalb sind Subdomain-Audits und vollständige Beobachtbarkeit der Transportschicht unerlässlich, bevor eine Entscheidung über Preload getroffen wird. Tools wie curl, openssl s_client sowie dedizierte Audit-Skripte ermöglichen das Erkennen von Inkonsistenzen, die normalerweise unsichtbar bleiben.

Wie erzwingt der Browser die HSTS-Preload-Richtlinie? Der interne Mechanismus von Chrome.

Obwohl HSTS Preload von außen wie eine einfache Liste von Domains aussieht, ist seine Implementierung im Browser komplexer. Chrome kompiliert eine statische JSON-Datei in eine C++-Struktur, die beim Start der Anwendung geladen wird. Jeder Eintrag enthält einen Datenbereich, in dem Sicherheitsattribute, Richtlinien-Flags und Informationen über die Notwendigkeit der HTTPS-Erzwingung markiert sind. Wenn der Benutzer eine Domain eingibt, führt Chrome noch keine Netzwerkabfrage durch. Die erste Phase findet in der URLLoader-Schicht statt: bevor ein TCP-Socket initialisiert wird, prüft Chrome die lokale HSTS-Richtlinie. Wenn sich die Domain in der Preload-Liste befindet, ändert der Browser das Protokollschema zu https:// und startet den TLS-Handshake, wobei der gesamte HTTP-Prozess übersprungen wird. Im Quellcode sieht dies ungefähr so aus:

if (IsPreloadedHSTS(host)) {
    scheme = "https";
}

Erst nach dem Wechsel in den HTTPS-Zweig wechselt Chrome zur net/socket-Schicht und versucht, eine Verbindung zu Port 443 herzustellen. Wenn der Server HTTPS nicht unterstützt, endet die Kommunikation sofort mit einem Fehler und der Benutzer sieht eine Meldung, dass die Verbindung nicht hergestellt werden kann – selbst wenn der Server technisch über HTTP erreichbar wäre. Dieses Verhalten ist vollständig beabsichtigt: Preload blockiert jede Möglichkeit einer Rückfalloption auf unverschlüsselte Kommunikation. Der gesamte Prozess funktioniert lokal, deterministisch und unabhängig von der Netzwerkkonfiguration. Ein Angreifer hat keinen Angriffspunkt in diesem Mechanismus, da er die vom Browser vor Verbindungsaufbau verwendeten Daten nicht beeinflussen kann. Genau deshalb ist Preload einer der effektivsten Schutzmechanismen in der Geschichte der Web-Sicherheit.

Der vollständige Migrationspfad einer Organisation zu Preload – ein Prozess, der die gesamte Domain umfassen muss.

Die Migration zu HSTS Preload erfordert einen Ansatz, der eher der Einführung einer Architektur ähnelt als dem Setzen eines einzelnen Headers. Preload verzeiht keine halben Maßnahmen. Es erzwingt vollständige Transportdisziplin. Der erste Schritt besteht darin, vollständige Sichtbarkeit über den DNS-Raum zu erhalten, da Preload absolut alle Subdomains umfasst und viele Organisationen historische DNS-Einträge haben, an die sich niemand mehr erinnert. In dieser Phase werden breite Enumerationen, Zertifikats-Scanner und Zugriffswerkzeuge eingesetzt, um eine vollständige Karte der Punkte zu identifizieren, die von der Richtlinie betroffen sein werden.

Eine typische Kontrolle beginnt mit einem Zertifikatsdump von crt.sh:

curl -s "https://crt.sh/?q=%.example.com&output=json"

Dies ist keine Liste von Zertifikaten, sondern eine Liste realer, aktiver Spuren von Subdomains, von denen viele aufgegeben wurden. Preload erzwingt ihre HTTPS-only-Bedienung, daher müssen sie bereinigt werden.

Der zweite wichtige Schritt ist konsistentes Verhalten der gesamten Infrastruktur. Origin, CDN, Load Balancer und Reverse Proxy – alle diese Schichten müssen eine einheitliche Richtlinie zurückgeben. In der Praxis bedeutet dies Anpassungen an Headers, Redirects und TLS-Konfigurationen auf jeder Ebene. Wenn das CDN zum Beispiel einen korrekten Header sendet, der Origin jedoch nicht, entsteht eine Inkonsistenz, die den Preload-Antrag ungültig machen oder zu falschen Interpretationen durch Audit-Tools führen kann.

Auch die HSTS-Konfiguration selbst muss der zukünftigen Richtlinie entsprechen. Während der Übergangsphase verwenden Organisationen am häufigsten folgende Version des Headers:

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

Das preload-Schlüsselwort wird erst hinzugefügt, wenn die Stabilität der gesamten Umgebung außer Zweifel steht. Diese Beobachtungszeit dauert in der Regel einige Wochen – es ist die einzige Möglichkeit sicherzustellen, dass Anwendungen, Integrationen, alte APIs und Partnersysteme unter erzwungenem HTTPS korrekt funktionieren.

Erst nach Abschluss von:

• vollständiger Subdomain-Enumerierung,
• Harmonisierung des Verhaltens aller Netzwerkschichten,
• einer Phase operativer Stabilität,

kann eine Domain für HSTS Preload eingereicht werden.

Dies ist keine Konfigurationsmaßnahme – es ist eine architektonische Entscheidung, die gesamte Domain dauerhaft in ein Kommunikationsmodell ohne Transportlücken zu überführen.

Wie beeinflusst Preload HTTP/3 und QUIC? Neuer Transport erfordert neue Sicherheitslogik.

HTTP/3 und QUIC verändern die Art und Weise, wie der Browser mit dem Server kommuniziert. QUIC arbeitet ausschließlich über UDP und kombiniert den Transport-Handshake mit dem kryptografischen Handshake. Es gibt darin keinen Platz für unverschlüsselte Verbindungen, daher wird Preload auf natürliche Weise Teil des Mechanismus, der entscheidet, ob der Browser überhaupt versuchen darf, QUIC zu verwenden.

Bei preload-fähigen Domains ist das Verhalten eindeutig: der Browser erwägt HTTP nicht als Alternative. Er initiiert sofort den QUIC-Handshake – und wenn dieser fehlschlägt, wechselt er zu TLS 1.3 über TCP, aber weiterhin ohne HTTP-Verkehr zuzulassen. Der Protokollauswahlmechanismus hört auf, heuristisch zu sein, und wird deterministisch. Chrome versucht nicht zu „erraten“, ob der Server QUIC unterstützt – es führt den Versuch sofort aus, da die Preload-Richtlinie keinen Raum für unverschlüsselte Schichten lässt.

Dies zeigt sich in der Struktur des ersten QUIC-Pakets, das die ClientHello-Funktion mit dem Transportteil kombiniert:

QUIC Initial Packet:
  - TLS ClientHello
  - Supported Versions: h3, h3-29, h3-27
  - ALPN: h3

Wenn eine Domain preload-fähig ist, führt der Browser diesen Schritt unabhängig von den Netzbedingungen aus. Ein Angreifer kann keine vorzeitige HTTP-Verbindung erzwingen, da Preload den Versuch, Port 80 zu öffnen, noch vor der Netzwerkschicht blockiert. Dies wirkt sich auch auf die Leistung aus. Im klassischen Modell ohne Preload musste der Browser eine Reihe heuristischer Informationen analysieren – Besuchshistorie, vorherige Protokolle, frühere QUIC-Fehler, Netzcharakteristik -, um zu entscheiden, ob sich ein HTTP/3-Versuch lohnt. Bei Preload ist die Logik vereinfacht: QUIC ist die erste Wahl, und ein Fallback wird nur angewendet, wenn der Server HTTP/3 tatsächlich nicht anbietet.

Preload und QUIC verstärken sich gegenseitig. QUIC eliminiert die Kosten von TCP plus TLS, Preload entfernt die gesamte Kategorie unverschlüsselten Transports. Zusammen schaffen sie ein Modell, in dem es keinen Raum für Manipulation der ersten Pakete gibt und der gesamte Verbindungsaufbau sowohl sicherer als auch schneller verläuft. Für global operierende Domains wie HEXSSL ist diese Synergie besonders wichtig: jeder CDN-POP arbeitet im gleichen Sicherheitsmodell, und der Benutzer auf jedem Kontinent erhält ein vorhersehbares Transportverhalten ohne Downgrade-Risiko oder Netzwerkmanipulation.

HEXSSL – HSTS & Preload Checklist.

1. Zertifikate und Domains.

❑ Die Hauptdomain hat ein gültiges Zertifikat
❑ Alle Subdomains haben gültige Zertifikate
❑ Keine Subdomains ohne HTTPS
❑ Das Wildcard deckt ab, was es abdecken soll (und der Rest hat einzelne Zertifikate)
❑ Keine DEV/OLD-Umgebung ist öffentlich über HTTP erreichbar

2. HTTPS-Erzwingung.

❑ HTTP → immer 301 zu HTTPS
❑ 301 auf Serverebene gesetzt, nicht in PHP
❑ Keine HTTP-Antworten 200/403/404
❑ HTTP 301 gibt ebenfalls den HSTS-Header zurück (gemäß RFC)

3. HSTS-Header – Korrektheit.

❑ Der Header wird für jede HTTPS-Antwort zurückgegeben
❑ Der Header hat genau diesen Wert: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload


❑ max-age ≥ 31536000
❑ includeSubDomains ist vorhanden
❑ preload ist vorhanden
❑ „always“/“set“ erzwingt den Header auch bei 3xx/4xx/5xx

4. Validierungstests.

❑ curl -I https://domain | grep -i strict gibt den Header zurück
❑ curl -I http://domain → 301 + HSTS
❑ curl -I https://www.domain → HSTS
❑ curl -I https://sub.domain → HSTS
❑ Keine HTTP-Antworten (ohne 301)
❑ Cloudflare (oder andere) überschreibt den Header nicht mit falschen Werten

5. Subdomains – vollständige Validierung.

❑ Liste der Subdomains aus CT-Logs:

curl -s "https://crt.sh/?q=%.domain.com&output=json" | jq '.[].name_value' | sort -u

❑ Jede Subdomain hat ein Zertifikat
❑ Jede Subdomain gibt HSTS zurück
❑ Jede Subdomain erzwingt HTTPS mit 301
❑ Keine „toten“ Subdomains mit Zertifikat, aber ohne Server

6. Cloudflare / CDN.

❑ SSL-Modus: Full (strict)
❑ Minimale TLS-Version: 1.2 oder 1.3
❑ HSTS im Cloudflare-Panel aktiviert (falls genutzt)
❑ Transform-Rule überschreibt HSTS nicht mit falschen Werten
❑ Keine Page Rules, die HTTP bedienen könnten

7. Preload – notwendige Bedingungen.

❑ HSTS aktiviert mit max-age ≥ 31536000
❑ includeSubDomains vorhanden
❑ preload vorhanden
❑ Alle Subdomains antworten über HTTPS
❑ Keine 403/404-Fehler bei kritischen Ressourcen
❑ HTTP liefert niemals Inhalte

8. Preload – Einreichung.

❑ Aufrufen von: https://hstspreload.org
❑ Test besteht zu 100 %
❑ Domain eingereicht
❑ Überwachung des Status in der Chrome-Preload-Liste
❑ Interne Kommunikation: „Vorgang kurzfristig NICHT UMKEHRBAR“

9. Monitoring nach der Einführung.

❑ curl-Tests täglich für 7 Tage
❑ SSL-Labs-Test nach der Einführung
❑ Alerts auf HTTP-Fehler → 301 → HTTPS
❑ Alert bei fehlendem HSTS-Header
❑ Alert bei Zertifikatsänderung (CT Monitoring)
❑ Überprüfung, dass QUIC/H3 korrekt funktionieren

10. Risikopunkte (was Preload beschädigen kann).

❑ Vergessene Subdomain mit ausgeschaltetem Server
❑ DEV/OLD-Subdomain in DNS
❑ Produktumzug auf neuen Server ohne Zertifikat
❑ Cloudflare im DNS-only-Modus
❑ HTTPS versehentlich deaktiviert
❑ Fehlerhaftes Wildcard (z. B. *.example.com deckt example.com nicht ab)

11. Minimale Testliste vor der Einreichung.

❑ Hauptdomain – HSTS
❑ www – HSTS
❑ Wildcard – HSTS
❑ alle A/CNAME-Einträge aus DNS – nur HTTPS
❑ 100 % gültige Zertifikate
❑ 0 HTTP-Seiten
❑ 0 Mixed-Content-Fehler
❑ 0 Fehler im Preload-Validator