Google hat HSTS für seine TLDs aktiviert und gibt HPKP auf

02.02.2018 | Petra Alm

Vor Kurzem hat Google bekanntgegeben, die HSTS Absicherung für alle TLD Domains einzuschalten, die von ihm besessen und verwaltet werden. In diesem Artikel erklären wir Ihnen, wie HSTS und sein „Partner“ HPKP funktionieren und was Googles Entscheidung für die Internetwelt bedeutet. Sie erfahren unter anderem, dass uns HPKP in vieler Hinsicht gut dienen kann - in unbefugten Händen kann das Tool aber auch äußerst gefährlich werden. Deshalb erwägt Google sogar, HPKP kurz nach der Einführung wieder abzuschalten!

HSTS bedeutet ein nur über HTTPS erreichbares Web

HSTS (HTTP Strict Transport Security) dient zur Absicherung des Webs vor Angriffen und Verbindungsdiebstählen (Session-Diebstählen). Einfach gesagt teilt ein Web mit HSTS dem Browser mit, dass es nur über das verschlüsselte Protokoll HTTPS erreichbar ist. Mit einer auf diese Art und Weise geschützten Website kann sich der Besucher nicht über HTTP verbinden, denn alle Anfragen werden automatisch auf HTTPS umgeleitet. Dies gilt für alle Ports, nicht nur für 80.

HSTS wird in den Webserver-Einstellungen eingeschaltet und funktioniert dank einem speziellen HTTP Header, in welchem Informationen für Clients aufgeführt sind. Aufgrund dieses gelieferten Köpfchens erfährt der Browser des Clients, dass die gegebene Domain nur über HTTPS zugänglich ist. In dem Header kann auch der Schlüsselabdruck (Hash des Zertifikats) spezifiziert werden, welchen der Browser auf dem Web erwarten soll. Dieses Header heißt HPKP (HTTP Public Key Pinning) und wird vor allem bei wertvollen Domains genutzt, die oft den Versuchen gegenüberstehen müssen, ein Zertifikat für Phishing auszustellen – also vor allem bei den Google Domains und Diensten.

Die Nutzer schützt HSTS zwar gegen absichtliches Umgehen von HTTP, für die Serververwalter kann dieses Tool jedoch eine Gefahr darstellen. In dem Header, welcher dem Browser über HTTPS geliefert wird, ist die Zeit aufgeführt, während welcher das Web nur mit HTTPS aufrufbar ist. Dieses Intervall kann zum Beispiel ein Jahr sein und sollte es zu einer Änderung kommen, wird sie der Browser nicht einlesen können, denn die Einstellung wird in Cache gespeichert. Bei einer falschen Konfiguration von HSTS und HPKP können Sie somit Ihr Web unzugänglich machen. Falls Sie den im HPKP Header aufgeführten Schlüssel verlieren, wird der Server den Besucher aussperren und die Session wird unterbrochen. Aus diesem Grund muss auch ein Speicherungsschlüssel spezifiziert werden und in dem Header müssen mindestens zwei Fingerabdrücke aufgeführt sein.

Browser gehen von einer eigenen Domainliste aus, von der sog. HSTS preload list. Dank dieser Liste kennen sie Domains mit eingeschaltetem HSTS – welche also die Verschlüsselung erfordern – noch bevor diese abgerufen werden. Der Schutz ist somit effektiver. Der Google-Browser Chrome ist mit dieser Domainliste ebenfalls ausgestattet und außerdem steht ihm eine Liste von HPKP Schlüsseln zur Verfügung, in welcher die wichtigsten Domains wie Google.com, Facebook.com, Twitter.com oder GitHub.com aufgeführt sind. Die Eintragung in diese Liste können Sie hier beantragen. Es ist aber nicht möglich, in diese Liste alle Domains der Welt aufzunehmen – deshalb werden vor allem solche ergänzt, die für die Sicherheit der Besucher außerordentlich wichtig sind – wie zum Beispiel eben Google.com.

Ausgewählte TLD Domains mit HSTS

Nun wissen wir schon, was HSTS bedeutet und was passiert, wenn die 45 Haupt-TLDs von Google (Domains der ersten Ordnung) im Browser in der „preload list“ aufgeführt sind. Jedwede Domain der zweiten oder niedrigeren Ordnung in den Zonen der erwähnten 45 TLDs wird nur über HTTPS erreichbar sein und wird ein eigenes TLS-Zertifikat besitzen müssen, denn HSTS wird schon von der Domainendung an sich erfordert. Auf diesen Domains hat Google HTTP absichtlich begraben – es kann hier nicht genutzt werden. Diesen mutigen Schritt konnte sich der Internetgigant auch deshalb erlauben, weil er für die Domains die TLS-Zertifikate selbst sicherstellen wird.

Vielleicht fällt Ihnen ein, ob in Zukunft auch weitere Domains ergänzt werden. Diese Vorgehensweise ist jedoch nur bei solchen Domains möglich, die der Verwalter für konkrete Zwecke ausgegliedert hat und welche für Endkunden nicht bestimmt sind. Erstens würde der Inhaber einer solchen Domain nämlich um seine Entscheidungsfreiheit kommen und zweitens ist HSTS, obwohl sich die ganze Interwelt dem flächendeckenden Einsetzen von HTTPS nähert, für eine ganze Domain der ersten Ordnung wie zum Beispiel für .de nicht durchführbar. Im Fall der von Google verwalteten Domains handelt es sich um Endungen wie google, how, soy, foo oder dev. Eine komplette Liste von Googles TLDs finden Sie hier.

Suchen Sie in HSTS und HPKP kein Sicherheitsheil

Ähnlich wie andere Sicherheitsfunktionen kann uns auch HSTS keinen vollkommenen Schutz vor allen potentiellen Angriffen garantieren. Bei der Webabsicherung müssen die Sicherheitsmaßnahmen kombiniert werden – HSTS ist nur ein Tropfen in dem Meer der Sicherheitstools. Es hilft uns ein bestimmtes Ziel zu erreichen, aber seine Nutzung allein kann das Ergebnis nicht sicherstellen – ähnlich funktioniert auch die Serversicherheit. Der Einsatz eines TLS-Zertifikats kann nicht gewährleisten, dass sich das Web nicht durchbrechen lässt - der Server kann fehlerhaft konfiguriert oder die Verschlüsselung veraltet sein.

HSTS muss auch skeptisch angesehen werden – hinter der Absicherung können sich ein Zeitaufwand und einige Risiken verbergen. Zum Beispiel der Sicherheitsexperte Scott Helme hat in seinem Artikel  I'm giving up on HPKP Gründe beschrieben, warum er die Arbeit mit diesem Tool aufgegeben hat. HSTS in Kombination mit HPKP und ungeschickten Händen kann die Websites für eine lange Zeit außer Betrieb setzen. Dies ist auch dem Web Smashing Magazine passiert, das wegen HSTS fünf Tage nicht erreichbar war. Die ganze Geschichte und die Beschreibung der Fehler finden Sie in dem Artikel Be Afraid Of HTTP Public Key Pinning.

Ivan Ristic hat dem Public Pinning den Artikel Is HTTP Public Key Pinning Dead gewidmet. Er weist auf hohe Risiken von diesem Sicherheitstool hin, die sich in der Statistik der Nutzung von HPKP im Internet widerspiegeln. Er geht von der Untersuchung der 1 Million bekanntesten Domains, die der bereits erwähnte Scott Helme durchgeführt hat und bei welcher nur 375 Webs mit HPKP gefunden wurden, also 0,0375%.

Erwägen Sie, HSTS oder HPKP einzusetzen?

Falls Sie die Nutzung der beschriebenen Techniken in Betracht ziehen, empfehlen wir Ihnen, sich zuerst deren Funktionsprinzipien detailliert durchzulesen – vor allem die Warnung vor den Problemen, die auftauchen können. Eine von den Voraussetzungen für HSTS ist automatisierte Zertifikatsinstallation und Rotation. Bei der Nutzung von HPKP ist dann ausdrücklich notwendig über einen Speicherungsschlüssel zu verfügen – also über das Zertifikat – und diesen in dem Header aufzuführen, denn sonst könnte es zu dem fatalen Fall kommen, dass das Web nicht erreichbar sein wird. Mögliche Probleme lassen sich nicht voraussehen und das Web kann nicht nur auf ein TLS Zertifikat angewiesen sein. Googles Plan, HPKP wieder aufzugeben, lässt sich durchaus nachvollziehen…

Ob Sie HSTS erfolgreich eingestellt haben können Sie zum Beispiel imm SSLlabs-Test überprüfen – in den Ergebnissen der Analyse werden Ihnen Details der Einstellung von HSTS, eventuell von HPKP, angezeigt. Ein weiteres Tool, mit welchem Sie HSTS überprüfen können, ist Securityheaders.io. Falls Sie auch den Einsatz von HPKP Headern erwägen, kann Ihnen der Online Hash-Generator für HPKP gelegen kommen, der für Ihr Zertifikat Abdrücke der richtigen Schlüssel bereitstellen wird.

Quellen:

1. HTTP Strict Transport Security for Apache, NGINX and Lighttpd. Aufrufbar auf raymii.org
2. HSTS-Anleitung für Wordpress und Drupal - Require HTTPS with the HSTS Header. Aufrufbar auf pantheon.in
3. Broadening HSTS to secure more of the Web. Aufrufbar auf security.googleblog.com