Die Verbindung zu Webseiten mittels HTTPS zu verschlüsseln ist eine extrem potente Variante, die gebotene Sicherheit für einen Besucher zu erhöhen. Dadurch wird verhindert, dass Verkehr mitgeschnitten, modifiziert oder umgeleitet wird. Geboten wird ein gewisses Mass an Authentisierung, sowie der Schutz der Integrität und der Vertraulichkeit der Daten, die durch die Seite angeboten werden.

Als zusätzlicher Vorteil gilt es festzustellen, dass Transportsicherheit selten einen direkten Zusammenhang mit den inneren Abläufen einer Applikation hat. Während es sicherlich Fälle gibt, in denen der Wechsel von HTTP zu HTTPS Herausforderungen birgt, ist das in der Regel nicht der Fall. Sogar Anwendungen, die über Jahre hinweg keine Updates mehr erhalten haben, können oftmals mit keinen oder sehr marginalen Änderungen via HTTPS angeboten werden. Es ist dabei selbstverständlich, dass dies den übrigen Sicherheitsproblemen in diesem Szenario keinen Abbruch tut: Die Verschlüsselung via SSL hat keinerei abschwächenden Effekt auf die Gefahren mangelnder Eingabevalidierung. Aber der Wechsel auf HTTPS stellt einen vergleichsweise einfach Weg dar, diverse Risiken, denen Benutzer üblicherweise gegenüber stehen, zu adressieren. Das beinhaltet zum Beispiel unvertrauenswürdige öffentliche Netzwerke, Internetprovider mit ambivalenten Gefühlen gegenüber der Thematik der Netzneutralität oder auch Arbeitgeber, die gerne den Internetverkehr ihrer Mitarbeiter im Detail überwachen.

Zumal die Nutzung von HTTPS eine ziemlich solide Kosten/Nutzen Bilanz aufweist, werden starke Anreize geschaffen, um die Verbreitung weiter zu fördern. Google gibt sicheren Seiten seit 2014 einen Ranking-Vorteil. Let’s Encrypt ist eine gemeinnützige Organisation, die von verschiedenen Schwergewichten wie der Electronic Frontier Foundation und der Mozilla Foundation gegründet wurde und die SSL-Zertifikate – einst ein ziemlich kostspieliges Privileg – zum Nulltarif anbietet und die Nutzung von HTTPS damit einer weitaus grösseren Zielgruppe zugänglich gemacht hat. Es wird damit zunehmend schwieriger, Gründe zu finden keine Verschlüsselung anzubieten. In der Tat wird das Anbieten von Inhalten über ungeschützte Verbindungen sogar bestraft, in dem Browser wie Chrome die entsprechenden Seiten visuell prominent als unsicher deklarieren.

Angriffe auf den Eintrittspunkt

Aufgrund dieser Aspekte im letzten Abschnitt hat die Verbreitung von HTTPS über die vergangenen Jahre massiv zugenommen. Das ist nicht in erster Linie ein Verdient der jeweiligen Seitenbetreiber, sondern eine Folge der einfacheren Abläufe und Hilfsmittel, die es auch technisch weniger versierten Personen erlauben, mit wenigen Mausklicks eine Seite auf HTTPS zu migrieren.

Trotzdem ist HTTP nach wie vor prominent vertreten. Einzelne Webseiten bieten weiterhin ihren gesamten Inhalt ausschliesslich via HTTP an. Für Seiten mit statischem, wenig sensitivem Inhalt ist das unschön, weil es das Risiko birgt, dass Angreifer Malware oder andere Inhalte injizieren. Grobfahrlässig wird dies aber dann, wenn Seiten via HTTP Loginmasken oder ähnliche Mechanismen anbieten. Leider ist dies nach wie vor eine gängige Praxis, wenn auch in reduziertem Masse als noch vor einigen Jahren.

Die nächste Variante, die HTTP/HTTPS Hybridseite verschwindet langsam. Diese Seiten nutzen HTTP für die Teile, die als unproblematisch betrachtet werden, wechseln aber für heiklere Teile, wie zum Beispiel Login-Formulare, auf HTTPS. Eine sehr übliche Schwachstelle bei Seiten, die dieses Vorgehen wählen, ist die Auslieferung des Login-Formulars via HTTP. Ein Angreifer kann in einem Man-in-the-Middle (MITM) Szenario problemlos das action Attribut des Formulars verändern und die eingegebenen Credentials an eine Stelle seiner Wahl schicken lassen. Während dieser Ansatz der gemischten Kanäle sicherlich in vereinzelten, exotischen Szenarien seine Berechtigung haben dürften, kann gesamthaft davon abgeraten werden. Der Aufwand und die Fehleranfälligkeit stehen in keinem Verhältnis zu einem allfälligen Ertrag, schon gar nicht im Hinblick auf die oftmals weitaus weniger komplizierte Variante, einfach die gesamte Seite via HTTPS auszuliefern.

Aber sogar Seiten, die an sich vollständig auf HTTPS (tcp/443) ausgeliefert werden, betreiben in der Regel nach wie vor einen HTTP Dienst (tcp/80) an, um Benutzer die via HTTP ankommen auf die sichere Seite weiterzuleiten. HTTP bleibt uns noch eine gute Weile erhalten und die derzeitige Situation bringt einige nennenswerte Risiken.

Gehen wir zur Illustration selbiger davon aus, dass ein Benutzer die Seite https://www.example.com besuchen möchte. Davon ausgehen, dass der Benutzer nicht über eine Suchmaschine auf diese Seite gelangt, wird er auf die Adressleiste seines Browsers klicken und “www.example.com” eingeben. Standardmässig fügt der Browser daraufhin das Schema “http://” hinzu und versucht auf den Webserver von www.example.com auf Port 80, also HTTP zu. Dieses Verhalten ist gewollt und normal, es sei denn der Browser weiss bereits, dass er zu dieser Seite via HTTPS verbinden soll. Dazu mehr später.

Dies stellt einen verwundbaren Moment im Prozess dar. Wenn ein Angreifer die Verbindung in diesem Moment kontrolliert, hindert ihn nichts daran die Verbindung nach https://www.example.net, einem Duplikat der Seite unter seiner Kontrolle, umzuleiten. Es ist nennenswert, dass der Angreifer in diesem Beispiel selber HTTPS benutzt, um die gefälschte Webseite zu betreiben und auch ein valides Zertifikat dafür nutzen kann. Die Verantwortung einer Certicate Authority (CA) in solchen Fällen wurde bereits ausführlich diskutiert. Die kurze Version lautet dahingehend, dass ein Domain Validation Zertifikat nicht mehr bedeutet, als eine assoziative Verbindung zwischen einem Public Key und einer Domäne. Im Gegensatz zu einem Extended Validation Zertifikat, hat das Domain Validation Zertifikat keinen Anspruch, die Instituion, die eine Seite betreibt zu überprüfen und zu authentisieren. Extended Validation Zertifikate dagegen, haben genau dieses Ziel – wobei eine Studie mit dem Titel An Evaluation of Extended Validation and Picture-in-Picture Phishing Attacks von Microsoft Research und der Universität Stanford zu Tage gefördert haben, dass Benutzer ohne spezielles Training nur sehr eingeschränkt von diesen Zertifikaten profitieren.

Participants who received no training in browser security features did not notice the extended validation indicator and did not outperform the control group.

In diesem Szenario einer bösartigen Webseite example.net besteht die einzige, realistische Chance für den Benutzer darin, dass diese durch Google’s Safe Browsing API als Bedrohung erkannt und mit einer Warnung versehen wird. Weiterhin besteht eine geringe Chance, dass der Benutzer die veränderte URL erkannt. Durch das Anbieten eines SSL Zertifikates, gepaart mit dem Fakt, dass die Adresse manuell eingegeben wurde, ist es unwahrscheinlich dass ein durchschnittlicher Benutzer diesem Umstand übermässige Beachtung schenken wird.

Der vermutlich wichtigste Security Header

Die Möglichkeiten von Security Headern wurde schon wiederholt diskutiert. Die verfügbaren Header variieren im Hinblick auf deren simple Konfiguration und Implementierung, sowie auch im Hinblick auf deren Effektivität. Aber kaum ein Header ist so effektiv und simpel zugleich wie HTTP Strict Transport Security (HSTS).

Was tut HSTS? Schauen wir uns einen Beispiel-Header an:

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

Sobald dieser Header einmal erhalten wurde, errinert sich der Browser daran, dass diese Seite ausschliesslich via HTTPS zu kontaktieren ist. Zukünftige Versuche, via HTTP auf diese Ressource zuzugreifen reagieren in einer unmittelbaren, client-seitigen Umleitung auf HTTPS. Zusätzlich gibt RFC6797 die nachdrückliche Empfehlung, dass Benutzer bei Seiten mit aktivem HSTS Header nicht in der Lage sein sollen, sich durch Warnmeldungen im Hinblick auf ungültige Zertifikate “durchzuklicken”. Konrket heisst dass, dass ein Benutzer im Falle eines MITM Angriffs mit gefälschtem Zertifikat keine Möglichkeit hat, sich mangels technischen Wissens inkorrekt zu verhalten und Opfer eines Angriffs zu werden.

Im obenstehenden Beispiel enthält der Header die drei verfügbaren Direktiven: max-age, includeSubDomains und preload.

• max-age=<delta seconds>: definiert die Lebensdauer der HSTS Einstellungen in Sekunden
• includeSubDomains: erweitert die Gültigkeit von HSTS auf alle Subdomänen der selben Domäne. Im Beispiel von example.com würde das heisst, dass zum Beispiel die Subdomäne my.example.com ebenfalls via HTTPS angefragt werden müsste.
• preload: ist ein Spezialfall und nicht in RFC6797 definiert. Es definiert die Absicht der Seite, in einer Liste von Webseiten die HSTS nutzen aufgeführt zu werden, so dass sogar für Erstbesucher HSTS erzwungen werden könnte. Dies erfordert, dass die Seite manuell für die Einbindung in die HSTS Preload Liste angemeldet wird.

Sofern der Header korrekt eingesetzt wird, schliesst HSTS eine Lücke, bei der ein Benutzer ungewollterweise via HTTP auf eine Seite zugreift und dabei durch einen Angreifer abgefangen wird. Sogar wenn preload nicht genutzt wird, werden regelmässige Besucher durch eine ausreichend hoch gesetzte max-age Direktive effektiv geschützt. Auf der Basis dieser Umstände sollte klar werden, dass der Strict-Transport-Security Header auf jeder Webseite, die via HTTPS ausgeliefert wird, gesetzt werden sollte. Die Vorteile überwiegen den benötigten Aufwand um ein Vielfaches und die Implementierung bietet überschaubare Risiken und Herausforderungen.

Häufige Fehler

Einmal eingerichtet ist der Strict-Transport-Security Header wartungsarm. Allerdings gibt es einige Fehler, die häufig vorkommen. Hier sind die fünf häufigsten Fehlkonfigurationen:

Strict-Transport-Security Header via HTTP

Der HSTS Header verändert dauerhaft die Verbindungsart, auf die der Browser beim Aufruf der Seite zurückgreift. Dadurch muss er über eine vertrauenswürdige Verbindung gesetzt werden. Wenn eine Anfrage via HTTP an den Host gerichtet wird, sollte dieser mit einem 301 Status reagieren und mittels eines Location: Headers auf die sichere Seite verweisen. Dort sollte, über die sichere HTTPS-Verbindung, auch der HSTS Header gesetzt werden. RFC6797 gibt klar vor, dass ein Browser einen HSTS Header via HTTP ignorieren muss. Ihn trotzdem zu senden, dürfte im Regelfall keinen Schaden anrichten, ist aber sinnlos.

max-age zu tief

Eine übliche Empfehlung für Seiten in Produktion ist es, die max-age Direktive auf 31536000 zu setzen, was ungefähr einem regulären Jahr (Schaltjahre ausgenommen) entspricht. Tiefere Werte können zu Testzwecken nützlich sein, erhöhen aber die Frequenz mit der Angriffsfenster auftreten. Ohne viel Aufwand können Beispiele gefunden werden, die Werte im Bereich von 1-10 Minuten nutzen. Das ist sinnlos und lässt den Effekt von HSTS fast komplett verpuffen. Im schlimmsten Fall kommt ein falsches Gefühl der Sicherheit erschwerend dazu, zumal die Seite – an und für sich – über einen gültigen HSTS Header verfügt.

max-age auf 0

Wird max-age auf 0 gesetzt, so wird der Browser angewiesen ist gecachete HSTS Policy für den Host unmittelbar zu löschen, inklusive der includeSubDomains Direktive, sofern zutreffend. Aus Sicht der Sicherheit ist das nicht zu empfehlen, daher ist dieses Vorgehen hier als Konfigurationsfehler gelistet. Als Randnotiz sei aber erwähnt, dass das Setzen von max-age auf 0 darauf hindeuten kann, dass eine Seite HSTS missbraucht, um Benutzer zu tracken.

includeSubDomains

Es ist ratsam, sämtliche Inhalte via HTTPS anzubieten, auch auf allfälligen Subdomänen. Aber das ist nicht der einzige Grund, warum dieses Setting von Nutzen ist: Subdomänen können Cookies manipulieren, was in einer Vielzahl von Angriffsszenarien von Relevanz sein kann. Wann immer möglich, sollte includeSubDomains genutzt werden.

preload nicht (korrekt) genutzt

preload ist keine offizielle Direktive. Gleichzeitig ist es die einzige Direktive, die effektiv negative Konsequenzen mit sich bringen kann. Sollte jemals der Bedarf aufkommen, via HTTP Inhalte anzubieten oder auf ein ungültiges, eigens signiertes Zertifikat zurückzugreifen, wird es hier zu Problemen kommen. Da die preload-Liste gebundlet mit Browsern ausgeliefert wird, ist davon auszugehen dass die Entfernung von der Liste einiges an Zeit in Anspruch nehmen wird. Offiziell ist von 6-12 Wochen die Rede, bis “die meisten Chrome User” eine aktualisierte Liste erhalten haben. Für Besucher mit anderen Browsern, kann die Zeit deutlich länger ausfallen.

Sofern die möglichen Konsequenzen aber klar sind und auch klar ist, wie diese adressiert werden können, so ist preload eine gute Option. Allerdings wird dabei oftmals übersehen, dass eine aktive Anmeldung via hstspreload.org von Nöten ist und dass gewisse Kriterien dafür erfüllt werden müssen. Auch für die Einbindung in die Liste ist mit einer Wartezeit von mehreren Wochen – oder länger – zu rechnen.

Fazit

Es ist heute simpler denn je, HTTPS zu nutzen und Besuchern damit einen Weg anzubieten, auf sichere Art und Weise mit einer Webseite zu kommunizieren. Die Nutzung von HSTS benötigt einen geringfügig höheren Aufwand, kann aber Restrisiken weiter reduzieren. Mittels der Links und Kommentare im vorliegenden Artikel sollte es ein Leichtes sein, HSTS zu konfigurieren, derzeitige Schwächen zu adressieren und Dritte darin zu beraten, gleichermassen die richtigen Massnahmen zu ergreifen.

Über den Autor

Stefan Friedli gehört zu den bekannten Gesichtern der Infosec Community. Als Referent an internationalen Konferenzen, Mitbegründer des Penetration Testing Execution Standard (PTES) und Vorstandsmitglied des Schweizer DEFCON Group Chapters trägt er aktiv zum Fortschritt des Segmentes bei.

Links

• http://www.usablesecurity.org/papers/jackson.pdf
• https://hstspreload.org/
• https://letsencrypt.org/
• https://letsencrypt.org/2015/10/29/phishing-and-malware.html
• https://testsafebrowsing.appspot.com/
• https://tools.ietf.org/html/rfc6797
• https://webmasters.googleblog.com/2014/08/https-as-ranking-signal.html
• https://www.leviathansecurity.com/blog/the-double-edged-sword-of-hsts-persistence-and-privacy