HTTP Strict Transport Security

HTTP Strict Transport Security (kurz HSTS) ist ein Sicherheitsmechanismus für HTTPS-Verbindungen, der sowohl vor Aushebelung der Verbindungsverschlüsselung durch einen Downgrade-Angriff als auch vor Session Hijacking schützen soll. Hierzu kann ein Server mittels des Strict-Transport-Security dem Browser des Anwenders mitteilen, in Zukunft für eine definierte Zeit (max-age) ausschließlich verschlüsselte Verbindungen für diese Domain zu nutzen. Optional lässt sich dieses über den Parameter includeSubDomains auf alle Subdomains ausweiten, also nicht nur auf https://example.org, sondern auch auf https://subdomain.example.org.

Ein grundsätzliches Problem des Standards ist, dass beim Erstaufruf einer Domain zunächst ein Request vom Client zum Server abgeschickt werden muss, um zu prüfen, ob dieser Verschlüsselung fordert. Bei dieser initialen Abfrage könnte ein Angreifer ansetzen, bevor die zukünftige Kommunikation zu der aufgerufenen Domain verschlüsselt wird. Um diesem Problem entgegenzuwirken, wird eine von Google Chrome betreute und den anderen großen Webbrowsern genutzte HSTS preload list gepflegt. Steht eine Domain auf dieser Liste, überspringt der Browser die Erstanfrage und verschlüsselt sämtliche Kommunikation sofort.<ref name="preloading_hsts_mozillla">Preloading HSTS. Mozilla Security Blog, 1. November 2012.</ref> Die Eintragung zusätzlicher Domains ist kostenlos möglich.<ref>HSTS preload submission.</ref>

Geschichte

Der Standard wurde 2012 von der IETF als RFC 6797<ref>Vorlage:RFC-Internet</ref> veröffentlicht<ref name="heise2012">Reiko Kaps: HTTP Strict Transport Security als Internet-Standard. In: Heise Online. 21. November 2012, abgerufen am 25. Oktober 2015. </ref> und wird unter anderem von den jüngsten Versionen der gängigen Webbrowser unterstützt.<ref>Vgl. Übersicht im Abschnitt Browser compatibility des Eintrags HTTP Strict Transport Security im Mozilla Developer Forum.</ref> Anlass für die Entwicklung waren von Moxie Marlinspike 2009 demonstrierte Attacken auf verschlüsselte Verbindungen durch Man-in-the-Middle-Angriffe, die sich bereits vor Zustandekommen einer verschlüsselten Verbindung dazwischen schalten.<ref name="heise2012" />

Funktionsweise

Um HSTS anzuwenden, müssen sich sowohl der Server als auch die Browser der Anwender entsprechend der Vorgabe verhalten.

Server

Der Server versendet bei HTTPS-Verbindungen einen zusätzlichen Header mit der Information, dass die angeforderte Seite in der Zukunft nur über eine verschlüsselte Verbindung verfügbar ist. Dieser Header muss dann vom Browser des Anwenders entsprechend interpretiert werden. Der Header ist Strict-Transport-Security. Außerdem wird angegeben, wie lange die Seite in Zukunft verschlüsselt erreichbar sein wird. Diese Zeitspanne wird in Sekunden angegeben. So weist der Header

Strict-Transport-Security: max-age=31536000

den Browser des Anwenders an, für die Dauer eines Jahres nur verschlüsselte Verbindungen zu dieser Seite aufzubauen.

Browser

Wenn ein Browser einen HSTS-Header erhält, muss er sich für alle zukünftigen Verbindungen zu dieser Domain bis zum Ablauf der angegebenen Gültigkeit folgendermaßen verhalten:<ref name="RFC6797-5">Vorlage:RFC-Internet</ref>

• Alle unverschlüsselten Links zu dieser Seite werden automatisch in verschlüsselte umgewandelt: http://example.org/bild.jpg wird zu https://example.org/bild.jpg
• Wenn die Sicherheit der Verbindung nicht gewährleistet werden kann, z. B. wenn dem Zertifikat des Servers nicht getraut werden kann, wird eine Fehlermeldung angezeigt und die Verbindung abgebrochen. Der Nutzer hat dann keine Möglichkeit mehr, die Seite mit dem Browser aufzurufen.

Wird ein HSTS-Header über eine unverschlüsselte Verbindung übertragen oder ist das Zertifikat der Verbindung nicht gültig, muss der Browser diesen ignorieren.

Browser-Unterstützung

Folgende Browser unterstützen seit der angegebenen Versionsnummer den HSTS-Standard (in Reihenfolge der Erstveröffentlichung):<ref name="mdn-security">Strict-Transport-Security. MDN, November 2012, abgerufen am 26. März 2023 (). </ref>

• Chromium und Google Chrome ab Version 4 – veröffentlicht: 25. Januar 2010
• Firefox ab Version 4 – veröffentlicht: 22. März 2011<ref name="firefox-4-release-notes">Firefox 4 Release Notes. Mozilla, März 2011, abgerufen am 26. März 2023 (). </ref>
• Opera ab Version 12 – veröffentlicht: 14. Juni 2012<ref name="opera_presto">Web specifications support in Opera Presto 2.10. Opera Software ASA, 23. April 2012, archiviert vom Vorlage:IconExternal (nicht mehr online verfügbar) am 20. Juni 2018; abgerufen am 8. Mai 2012 (). </ref>
• Safari ab Version 7 auf OS X Mavericks – veröffentlicht: 22. Oktober 2013
• Internet Explorer 11 auf Windows 8.1 und Windows 7 mit dem Update-Paket KB3058515 – veröffentlicht: 9. Juli 2015<ref>HTTP Strict Transport Security comes to Internet Explorer 11 on Windows 8.1 and Windows 7. In: windows.com. Archiviert vom Vorlage:IconExternal (nicht mehr online verfügbar) am 27. November 2019; abgerufen am 12. Juni 2015 (). </ref>
• Microsoft Edge ab Version 12 auf Windows 10 – veröffentlicht: 28. Juli 2015

Kritik

Die Speicherung der HSTS-Informationen durch den Client lässt sich für ein Tracking von Benutzern ausnutzen. Besonders kritisch wurde in diesem Zusammenhang diskutiert, dass Google Chrome die HSTS-Informationen auch in den für besonderen Datenschutz ausgelegten Inkognito-Modus übernahm.<ref>Ronald Eikenberg: Security-Funktion HSTS als Supercookie. In: Heise – Security. 6. Januar 2015, abgerufen am 25. Oktober 2015. </ref> Stand 2018 war das Problem für gängige Browser nicht mehr gegeben.<ref>Varun Patil: HSTS-SuperCookie. github</ref>

Verwandte Protokolle

Was HSTS für HTTP(S)-Verbindungen leistet, soll MTA-STS (SMTP MTA Strict Transport Security)<ref>Vorlage:RFC-Internet</ref> für Mailserver bzw. SMTP bieten.<ref>Jürgen Schmidt: Zwangsverschlüsselung für E-Mail-Transport. In: heise online. 28. September 2018, abgerufen am 3. September 2021. </ref>

Weblinks

• HTTP Strict Transport Security. MDN Web Docs (englisch)
• HTTP Strict Transport Security. OWASP – Open Web Application Security Project (englisch)
• Vorlage:RFC-Internet

Einzelnachweise

<references />