Welche Risiken birgt das Preloading von HSTS?

Obwohl HTTP Strict Transport Security (HSTS) entwickelt wurde, um die Sicherheit im Web zu verbessern, warnen einige Sicherheitsexperten doch seit einiger Zeit davor, ein Preloading des Protokolls zu nutzen. Was sind die Gründe dafür und welche Risiken bestehen beim Preloading von HSTS?

Wenn eine im Vorfeld geladene Direktive zum Security Header von HTTP hinzugefügt wird, werden dabei alle Subdomains mit in die Liste kopiert. Das folgende Beispiel aus einer HSTS-Policy zeigt dieses Verhalten:

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

Wenn ein Nutzer eine Webadresse besucht, dann wird der Browser durch die HSTS Policy angewiesen, HTTPS auch für alle Subdomains zu nutzen. Der Wert max-age sorgt dafür, dass die im Vorfeld geladene Liste für 31.536.000 Sekunden – das entspricht genau einem Jahr – genutzt werden muss. Die Richtlinie sorgt also dafür, dass der Browser für alle enthaltenen Subdomains rund ein Jahr lang HTTPS verwenden muss. Das bedeutet jedoch auch, dass alle über das Web erreichbaren Ressourcen der Webseite über HTTPS erreichbar sein müssen.

Das Preloading der Liste stellt aber aus den drei folgenden Gründen ein Risiko dar. Erstens lassen sich versehentlich zu dieser Liste hinzugefügte Subdomains nicht mehr sofort entfernen, auch nicht, wenn dazu https://hstspreload.org/removal genutzt wird. Manchmal dauert es einen längeren Zeitraum, bis die angeforderte Löschung alle relevanten Stellen erreicht hat.

Zweitens ist es nachträglich nicht möglich, den ursprünglich angegebenen Zeitraum zu ändern, wenn etwa neue Subdomains hinzugekommen sind. So lässt sich die Zeit beispielsweise nicht „mal eben“ von einem Jahr auf 90 Tage verkürzen. Das geht erst, nachdem die ursprüngliche Direktive abgelaufen ist.

Drittens sind manche Intranets und verteilte Hosts nur über HTTP erreichbar, so dass hier HSTS gar nicht greift.

Einige Webseiten verwenden unter derselben Domain zudem je eine aus dem Intranet und eine aus dem öffentlichen Internet erreichbare Seite, die sich jeweils nur durch eine eigene Subdomain voneinander unterscheiden. Manche Webseiten-Anbieter vergeben den Auftrag, sich um ihre Subdomains zu kümmern, auch an externe Dritte. Dieses Vorgehen wird gerne etwa für Werbe-, Analyse- oder Backup-Dienste genutzt. Falls die Server dieser Partner HTTPS nicht unterstützen, wenn die Hauptseite bereits auf diese Technik umgestellt wurde, dann kommt es zu Fehlermeldungen, wenn die Seite besucht werden soll.

Eine Möglichkeit, dieses Problem zu umgehen, ist auf das Preloading komplett zu verzichten. Eine andere Variante ist, beim Nutzen der Direktive auf einen kürzeren Zeitraum wie zum Beispiel nur 30 Tage zu setzen. So kann schneller sichergestellt werden, dass auch wirklich alle Subdomains durch HTTPS geschützt werden. Eine Alternative ist der Einsatz eines HTTPS-Frontends für einen reinen HTTP-Server. Das sollte aber erledigt werden, bevor der Backend-Server gesichert wird.

Folgen Sie SearchSecurity.de auch auf Twitter, Google+, Xing und Facebook!