HSTS steht für HTTP Strict Transport Security. Hierbei handelt es sich um einen Security Policy Mechanismus, der durch das IETF in RFC 6797 spezifiziert wurde. Webserver können diesen einsetzen, um einen Webbrowser anzuweisen, wie er zu kommunizieren hat. Dank ihm sieht sich aber ein Webmaster für öffentliche Webseiten in der Lage, die Kommunikation von internen Diensten zu beeinflussen.

Vor Jahren hat sich das Internet in Bewegung gesetzt und es wurde von nun an durch Security Professionals vorausgesetzt, dass sämtliche Webseiten nur noch über verschlüsseltes HTTPS angesprochen werden können sollten. Die Einbussen in Bezug auf Komplexität, Performance und Caching wurden im religiösen Eifer ignoriert. Und doch gerade diesem Vorpreschen haben wir es zu verdanken, dass das Web – mindestens ein bisschen – sicherer geworden ist.

Aus Kompatibilitätsgründen bieten viele Seiten nach wie vor einen unverschlüsselten Zugriff über HTTP an. Schliesslich gibt es auch heute noch Leute oder Firmen mit alten Browsern, die nicht mit den hohen SSL-/TLS-Anforderungen umgehen können. Oder Anbieter von freien Internetzugängen unterbinden eine sichere Kommunikation, so dass man halt auch eine Alternative anbieten möchte. Denn diese Benutzer will man nicht verlieren – Vor allem, wenn beim eigenen Angebot Privatsphäre keine Priorität hat.

Moderne Browser pflegen das Verhalten ihrer Nutzer zu adaptieren und speichern zum Beispiel, ob nun die HTTPS-Version einer Webseite bevorzugt aufgerufen wird. Die Autocomplete-Funktion in der Adresszeile wird dann stets eben diese vorschlagen. Das Risiko ist, dass – mindestens beim ersten Zugriff – sensitive Login- oder Session-Informationen im Klartext übertragen werden, falls mal eben ein Zugriff nur über HTTP stattfindet. Da nützt es dann auch nicht mehr viel, dass da HTTPS vorhanden gewesen wäre oder in einem nächsten Schritt – zum Beispiel mittels Redirect – durchgesetzt wird.

Das bringt HSTS

Webmaster haben mit HSTS die Möglichkeit, dieses Verhalten einzuschränken. Indem der entsprechende Header Strict-Transport-Security in einer HTTP-Rückantwort gesetzt wird, wird der Browser dazu bewegt, sein Verhalten anzupassen.

Strict-Transport-Security: max-age=31536000

In diesem Beispiel wird dem Webbrowser mitgeteilt, dass für die kommenden 31’536’000 Sekunden, dies entspricht 365 Tagen, die Webseite immer zuerst mit HTTPS aufgerufen werden soll.

Dieser Header darf eigentlich nur über HTTPS ausgeliefert werden und hat unter HTTP theoretisch keine Gültigkeit. Dadurch wird gewährleistet, dass nur Benutzer an HTTPS gebunden werden, die mindestens einmal erfolgreich eben eine solche Verbindung herstellen konnten.

Und selbst wenn dies geschehen ist, kann der Benutzer manuell auf HTTP zurückwechseln – Sofern der Webserver dies natürlich unterstützt. Sicherheit wird vorbildlich mit Flexibilität kombiniert.

Das passiert mit der Direktive preload

Der HSTS-Header kann erweitert werden, um das Mass an Sicherheit noch zu erhöhen. Das folgende Beispiel nutzt die Direktive includeSubDomains, um auch die Subdomains des Webservers in die Anforderung miteinzuschliessen. Wird HSTS über www.example.com ausgeliefert, gilt sie also fortan für *.www.example.com.

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

Diese Direktive ist erforderlich, damit schlussendlich auch die Direktive preload eingesetzt werden kann. HSTS ohne preload erfordert, dass der Benutzer mindestens einmal absichtlich oder halt unabsichtlich die Webseite über HTTPS aufgerufen hat. Nur so kann sich die Anforderung im Browser etablieren.

Mit preload wird dieser Schritt übersprungen. Dadurch wird es möglich, dass eine Seite in die HSTS Preload List der sie unterstützenden Browser aufgenommen wird. Hat man seine Webseite entsprechend wie soeben gezeigt vorbereitet, kann sie auf hstspreload.org angemeldet werden. Nach einer Prüfung durch Google wird diese Liste dann an bekannte Webbrowser-Hersteller verbreitet. Diese verteilen die Liste dann über ein Software-Update an die bestehenden Browser-Installationen, wodurch sie lokal auf den Client-Systemen abgelegt wird.

Will nun ein Nutzer auf eine Webseite zugreifen, die HSTS Preload voraussetzt, wird der Browser automatisch und in jedem Fall den Zugriff über HTTPS durchsetzen. Selbst wenn der Benutzer http://example.com eingibt, wird nie ein Zugriff über http:// stattfinden sondern noch vor dem Netzzugriff auf https:// gewechselt werden. Grundsätzlich eine gute Sache.

Das können böswillige Webmaster damit machen

Die Konstellation von HSTS Preload ist explosiv: Ein Webmaster, Webserver-Admin oder Proxy-Admin kann in der Regel Einfluss auf die HTTP-Header nehmen. Jeder von Ihnen kann unabhängig voneinander einen funktionalen Preload-Header generieren: Ablauf, Subdomains inkludieren und Preload-Anweisung festlegen.

Und jeder von Ihnen kann eine Submission an die HSTS Preload List vornehmen. Das Problem dabei ist, dass die Direktive für das Inkludieren der Subdomains halt eben Einfluss auf Services und Server haben kann, die nicht unter der zugewiesenen Befugnis sind. Wer auf https://example.com eine entsprechende Konfiguration vornimmt, kann auch Einfluss auf webmail.example.com, intranet.example.com oder root.directory.srv2.example.com ausüben.

Es dauert gegenwärtig rund zwei Wochen, bis eine gültige Submission in die HSTS Preload List aufgenommen wird. Rund eine Woche später wird sie durch die ersten Browser-Hersteller verteilt. Von da an sind die betroffenen Nutzer gezwungen, nur noch über HTTPS auf die spezifizierten Ressourcen zuzugreifen.

Dies wird ein Problem, wenn zum Beispiel gar kein HTTPS angeboten wird. Aber auch dann, wenn kein valides Zertifikat (z.B. abgelaufen oder self-signed) zum Einsatz kommt – Eine Tatsache, die in internen Netzen noch immer zu Hauf angetroffen wird.

In diesem Fall hat der Benutzer nur wenige Möglichkeiten, um dennoch auf den Dienst zugreifen zu können. Denn der Browser verweigert das Umstellen auf HTTP oder das Akzeptieren von nicht gültigen Zertifikaten. Einige Browser erlauben das manuelle Löschen oder Ändern der lokalen HSTS Preload List. Bei Google Chrome funktioniert dies einwandfrei über chrome://net-internals/#hsts – Auch Mozilla Firefox liesse den Eingriff in die entsprechende Text-Datei zu. Im Rahmen unserer Tests konnten wir jedoch keine Lösung etablieren – Es blieb nichts anderes übrig, als auf einen anderen Browser auszuweichen.

Falls die eigenen Services nun ungewollt in der HSTS Preload List gelandet sind, kann man wiederum auf hstspreload.org ein Removal beantragen. Auf der Seite wird angegeben, dass dies 6-12 Wochen dauern kann. Und dann gilt es natürlich noch darauf zu hoffen, dass die Liste wieder zeitnah durch die Browser-Hersteller verteilt wird. Webbrowser, die keine Aktualisierung über das Internet erfahren, könnten die überarbeitete Liste gar nie erhalten.

Empfehlungen

HSTS Preload ist meines Erachtens ein Fehldesign. Hierbei wird ein klassisches Prinzip der Informationssicherheit, nämlich Separation of Duties, grundlegend verletzt. Wieso soll jemand, der für eine öffentliche Ressource zuständig ist und diese Rechtmässigkeit auch nur in isolierter Weise öffentlich validiert werden kann, Einfluss auf interne Ressourcen nehmen können?

HSTS per Definition als übergeordnete Instanz zu verhindern, ist nicht möglich. Grundsätzlich gilt es also zu hinterfragen, wem man Einflussmöglichkeiten auf HTTP-Header geben will. Nicht selten werden Webmaster-Aufgaben an externe Firmen übertragen. Dies birgt ein zusätzliches Risiko, dass hier jemand absichtlich oder unabsichtlich einen problematischen Zustand erzeugt.

Es ist mancherorts ein bisschen aus der Mode gekommen, jedoch könnte man dieses Problem – mindestens für interne Dienste – mit einer lokalen Domain verhindern: Das zwar für öffentliche Dienste example.com verwendet wird, im internen Netz jedoch ausschliesslich example-internal.com zum Tragen kommt (die Domain sollte dementsprechend auch im eigenen Besitz sein). Eine nachträgliche Umstellung dieser Art kann sich jedenfalls als Sisyphusarbeit herausstellen.

Falls man sich plötzlich mit einem solchen Angriff konfrontiert sieht und nicht auf das Ausrollen des Removals warten kann, kann man versuchen kurzfristig HTTPS mit entsprechend validen Zertifikaten zu etablieren. In vielen Fällen wird dies mit entsprechendem Aufwand möglich sein. Und hat man es einmal gemacht, hat man sowieso einen langfristigen Sicherheitsgewinn. HTTP und invalide Zertifikate haben nämlich genau genommen auch im internen Netzwerk nichts zu suchen.

Über den Autor

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Links

• https://hstspreload.org
• https://hstspreload.org/removal/
• https://tools.ietf.org/html/rfc6797