HTTP Strict Transport Security
Geschichte
Der Standard wurde 2012 von der IETF als RFC 6797 veröffentlicht[1] und wird unter anderem von den jüngsten Versionen der gängigen Webbrowser unterstützt.[2] 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.[1]
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 die 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 ist. Diese Zeitspanne wird in Sekunden angegeben. So weist der Header
Strict-Transport-Security: max-age=31536000
den Browser den Anwenders an, im nächsten Jahr nur verschlüsselte Verbindungen zu dieser Seite aufzubauen.
Browser
Wenn ein Browser einen HSTS-Header erhält muss er sich folgendermaßen verhalten[3]:
- Alle unverschlüsselten Links zu dieser Seite werden automatisch in verschlüsselte umgewandelt:
http://example.org/bild.jpgwird zuhttps://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.
HSTS wird nur für verschlüsselte HTTPS-Verbindungen unterstützt, denn unverschlüsselte HTTP-Verbindungen können von einem Angreifer manipuliert werden, so dass der Anwender den Informationen nicht vollständig vertrauen kann.
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 übernimmt.[4] Webserver sollten HSTS dennoch aktivieren, da, unabhängig vom Datenschutzrisiko auf der Browserseite, die Kommunikation durch HSTS sicherer wird. Die Gefahr für einen Man-in-the-Middle-Angriff wird deutlich reduziert.
Weblinks
- Eintrag im Mozilla Developer Network (englisch)
- Eintrag im Open Web Application Security Project (OWASP) (englisch)
Einzelnachweise
- ↑ a b Reiko Kaps: HTTP Strict Transport Security als Internet-Standard – heise Netze. In: Heise Online. 21. November 2012, abgerufen am 25. Oktober 2015.
- ↑ Vgl. Übersicht im Abschnitt Browser compatibility des Eintrags HTTP Strict Transport Security im Mozilla Developer Forum.
- ↑ Jeff Hodges, Jackson, Collin, Barth, Adam: Section 5. HSTS Mechanism Overview. In: RFC 6797. IETF, November 2012, abgerufen am 21. November 2012.
- ↑ Ronald Eikenberg: Security-Funktion HSTS als Supercookie – heise Security. In: Heise. 6. Januar 2015, abgerufen am 25. Oktober 2015.