HTTPS reicht nicht: HSTS, Certificate Transparency und HTTP/3

Ein grünes Schloss in der Adresszeile wird oft mit vollständiger Sicherheit verwechselt. HTTPS verschlüsselt eine Verbindung, sobald sie steht - es verhindert aber nicht, dass ein Angreifer einen Nutzer im ersten Moment auf eine unverschlüsselte Version derselben Seite umleitet, bevor die Weiterleitung überhaupt greifen kann. Wer HTTPS einrichtet und dabei stehen bleibt, hat die halbe Aufgabe gelöst.

Warum HTTPS allein nicht reicht

Der Angriff, vor dem ein reines HTTPS-Zertifikat nicht schützt, heißt SSL-Stripping: Ein Angreifer im selben Netzwerk - etwa in einem offenen WLAN - fängt den allerersten Verbindungsversuch ab, bevor eine Weiterleitung auf https:// greift, und hält den Nutzer unbemerkt auf einer unverschlüsselten Verbindung. Für den Nutzer sieht die Seite normal aus, tatsächlich läuft der gesamte Datenverkehr unverschlüsselt über den Angreifer. HTTPS-Zertifikat und Weiterleitung lösen dieses Problem nicht, weil beide erst greifen, nachdem die erste Verbindung schon unverschlüsselt zustande gekommen ist.

Was HSTS technisch tut

HTTP Strict Transport Security (HSTS) schließt genau diese Lücke, indem der Browser angewiesen wird, eine Domain für einen festgelegten Zeitraum ausschließlich über HTTPS anzusprechen - ganz ohne den ersten unverschlüsselten Versuch. Das Signal kommt als HTTP-Header von der Website selbst:

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

max-age legt in Sekunden fest, wie lange der Browser sich das Verbot merkt, includeSubDomains weitet es auf alle Subdomains aus, und preload ist die Bewerbung für die im nächsten Abschnitt beschriebene Preload-Liste. Wichtig: Dieser Header wirkt erst, nachdem der Browser eine Seite mindestens einmal über HTTPS besucht hat - beim allerersten Kontakt einer neuen Domain hilft er allein noch nicht.

Preload: der Schritt, der sich praktisch nicht zurücknehmen lässt

Genau diese Lücke beim allerersten Besuch schließt die HSTS-Preload-Liste. Statt auf den ersten Besuch zu warten, ist die Domain bereits fest im Quellcode der großen Browser hinterlegt - Chrome, Firefox, Safari und Edge liefern diese Liste mit jeder neuen Version aus. Ein Nutzer, der eine gelistete Domain zum allerersten Mal ansteuert, wird schon vor dem ersten Request auf HTTPS umgeleitet, weil der Browser es selbst weiß, ohne die Website je gefragt zu haben.

Genau diese feste Verankerung macht die Aufnahme in der Praxis irreversibel. Die Liste wird über hstspreload.org gepflegt, aber eine Domain wieder zu entfernen bedeutet nicht, dass die Änderung sofort wirkt: Sie muss zunächst aus der Quellliste entfernt werden, und die Entfernung erreicht Nutzer erst mit der nächsten Browser-Version, die sie installieren - über alle vier Browser-Hersteller hinweg, und ohne dass die Website selbst darauf Einfluss hat, wann das geschieht. Wer eine Domain preloaded, obwohl später doch eine Subdomain ohne HTTPS betrieben werden muss, sitzt diese Entscheidung über Monate aus, nicht über Minuten. Preload gehört deshalb erst gesetzt, wenn HTTPS auf der gesamten Domain inklusive aller Subdomains dauerhaft und zuverlässig läuft, nicht als Standardhäkchen beim ersten Setup.

Certificate Transparency: das öffentliche Logbuch Ihrer Zertifikate

Certificate Transparency (CT) ist ein öffentliches, unveränderliches Protokoll aller ausgestellten SSL-Zertifikate. Jede Zertifizierungsstelle meldet ein neu ausgestelltes Zertifikat in dieses Log, und moderne Browser akzeptieren ein Zertifikat nur noch, wenn es dort nachweislich verzeichnet ist. Der praktische Nutzen: Wird für Ihre Domain irgendwo ein Zertifikat ausgestellt, das Sie nicht selbst beantragt haben, taucht es im selben öffentlichen Log auf. Werkzeuge wie crt.sh erlauben eine gezielte Suche nach der eigenen Domain in diesen Logs. Bei modernen Zertifizierungsstellen wie Let's Encrypt läuft die CT-Meldung automatisch mit jeder Ausstellung, ein manuelles Zutun ist dafür nicht nötig - regelmäßiges Prüfen der eigenen Domain in den Logs bleibt trotzdem sinnvoll, weil die Meldung selbst nichts daran ändert, ob ein Zertifikat berechtigt beantragt wurde.

HTTP/3: schneller ohne TCP-Overhead

HTTP/3 verwendet für die Übertragung QUIC statt des klassischen TCP. Der wichtigste praktische Unterschied betrifft Verbindungen mit Paketverlust: Bei TCP blockiert ein einzelnes verlorenes Datenpaket alle nachfolgenden Pakete auf derselben Verbindung, bis es erneut übertragen wurde. QUIC überträgt Datenströme unabhängig voneinander, sodass ein verlorenes Paket nur den betroffenen Stream verzögert statt die gesamte Verbindung. Zusätzlich verbindet sich QUIC schneller neu, wenn ein Gerät das Netzwerk wechselt - etwa von WLAN zu Mobilfunk. Auf einer stabilen Glasfaserverbindung fällt dieser Unterschied kaum auf; auf einem Smartphone im mobilen Netz mit wechselnder Signalstärke ist er spürbar. Moderne CDN- und Edge-Anbieter aktivieren HTTP/3 heute meist automatisch, klassisches Shared Hosting oft nicht.

Konkrete Maßnahmen für die nächsten 90 Tage

• Tag 1-30: HSTS-Header ohne preload setzen und beobachten, ob HTTPS auf allen Subdomains dauerhaft stabil läuft
• Tag 31-60: Certificate-Transparency-Logs der eigenen Domain über crt.sh prüfen, HTTP/3-Verfügbarkeit beim eigenen Hosting- oder CDN-Anbieter klären
• Tag 61-90: erst nach stabilem Betrieb aller Subdomains die Preload-Option ergänzen und bei hstspreload.org einreichen

Fazit

Von den Schritten in diesem Artikel sind drei folgenlos, wenn Sie sie später zurücknehmen: HSTS ohne Preload, Certificate Transparency überwachen, HTTP/3 aktivieren. Einer ist es nicht. Die Preload-Liste nimmt eine Domain in Wochen auf und gibt sie erst in Monaten wieder frei - tragen Sie sie deshalb erst ein, wenn wirklich jede Subdomain dauerhaft per HTTPS erreichbar ist, einschließlich der einen, an die gerade niemand denkt. Wie sich eine saubere technische Basis auf Ladegeschwindigkeit auswirkt, zeigen wir im Artikel Core Web Vitals 2026. Welche Rolle die Crawler-Steuerung für die Sichtbarkeit spielt, die auf dieser Basis aufbaut, beschreiben wir im Artikel robots.txt und KI-Crawler. Was ein technisches SEO-Audit inklusive HTTPS-Prüfung kostet, sehen Sie im Artikel zu SEO-Kosten. Für eine unverbindliche Prüfung Ihrer aktuellen HTTPS-Konfiguration nehmen Sie gerne Kontakt mit uns auf.