Technic Blog

Technik BlogHTTP Security Extensions - HSTS

04. Mai 2017 Tobias Maier

HTTP Strict Transport Security

Bei HTTP Strict Transport Security (HSTS) handelt es sich um einen Sicherheitsmechanismus für das HTTP-Protokoll. Durch HSTS werden Clients angewiesen, dass die Kommunikation ausschließlich über eine sichere Verbindung erfolgen soll.

Um höheren Ansprüchen an Sicherheit und Datenschutz zu gewährleisten, ist die Anzahl der Websites, deren Inhalte ausschließlich über HTTPS angeboten werden, in der Vergangenheit stark gestiegen. Typischerweise leiten diese Websites unverschlüsselte HTTP-Anfragen umgehend an die entsprechende HTTPS-Adressen weiter. Dieses etablierte Verfahren weist dennoch Schwachpunkte auf, deren Beseitigung ist die Zielsetzung von HSTS.

Mit der HSTS Erweiterung wird für eine Domain die Vorgabe erteilt, dass Anfragen ausschließlich über HTTPS gestellt werden und gänzlich auf die Übertragung mit unverschlüsseltem HTTP verzichtet wird. Dabei wird auch festgelegt wie lange der Client diese Vorgabe umsetzten soll und ob dies auch auf Subdomains anzuwenden ist. Zudem sind die Clients angewiesen, dem Benutzer nicht das Akzeptieren von Fehlern im Aufbau der verschlüsselten Verbindung anzubieten.

Die HSTS Policy einer Website wird dem Client durch das Antwort-Headerfeld Strict-Transport-Security vom Webservers mitgeteilt, kann aber auch über andere Methoden an den Client übermittelt werden. Dies kann beispielsweise über sogenannte Preload-Listen erfolgen, diese werden direkt mit der Browser Software ausgeliefert. Auch das Hinzufügen einer HSTS Policy durch den Benutzer wird in der HSTS Spezifikation vorgeschlagen.

HSTS ist in der RFC 6797 spezifiziert.

HSTS Headerfeld und Direktiven

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

max-age
Diese Direktive gibt an, wie lange ein Client nach Erhalt des Headers die betroffene Seite als HSTS Webseite behandeln soll. Die Zeitangabe erfolgt in Sekunden, die Angabe dieser Direktive ist verpflichtend. Durch Setzen des Werts auf null ("max-age=0") werden Clients angewiesen, die entsprechende HSTS Einstufung zu verwerfen.
includeSubDomains
Das Flag includeSubDomains gibt an, dass die HSTS Policy für den Domainnamen des Hosts sowie all dessen Subdomains gültig ist.
preload
Diese Direktive ist nicht in der RFC 6797 definiert. Das setzen dieses Flags wird aber als notwendiges Kriterium für die Aufnahme in die Preload-Liste von Google verwendet, diese wird inzwischen Browserübergreifend verwendet.

Adressierte Schwachstellen

Unverschlüsselter Kommunikationsbeginn

Sollen Websites nur verschlüsselt genutzt werden, leiten diese üblicherweise auf HTTPS-Adressen weiter, wenn Inhalte über unverschlüsseltes HTTP angefragt werden. Die initiale HTTP-Verbindung ist dabei jedoch ein verbliebener Schwachpunkt.

Serverseitig kann dieses Problem nicht beseitigt werden, da die Kommunikation naturgemäß vom Client begonnen wird und diesem somit auch die Wahl des initialen Protokolls obliegt. Es ist zwar durchaus möglich, dass ein Großteil der Kommunikation direkt über HTTPS begonnen wird, dies ist beispielsweise durch eine entsprechende Indizierung in den Suchmaschinen zu erklären. Dennoch, gibt ein Anwender die gewünschte URL manuell in die Adresszeile des Browsers ein, ohne explizit ein Protokoll anzugeben, wird die initiale Verbindung per Default über HTTP aufgebaut. Gleiches gilt für den Aufruf von Bookmarks, die zu einem früheren Zeitpunkt angelegt wurden und noch auf die HTTP Version verweisen. Dies gilt im Allgemeinen beim Aufruf aller Links die HTTP als Protokoll angeben ("http://").

Da eine gesicherte Verbindung erst nach Aufforderung des Servers erfolgt und diese Anweisung selbst unsicher übertragen wird, stellt dies eine erhebliche Schwachstelle im etablierten Verfahren dar. HSTS wirkt dieser Schwachstelle entgegen, hat ein Browser eine gültige HSTS Policy vorliegen, startet und führt der Browser die Kommunikation ausschließlich über HTTPS. Dennoch ist diese Schwachstelle auch mit HSTS nicht gänzlich beseitigt, für den allerersten Aufruf einer Seite und nach Ablauf der gespeicherter HSTS-Einträge ist das Problem nach wie vor vorhanden. Dies kann durch die Aufnahme der entsprechenden Domain in die Preload-Liste der Browser beseitigt werden. Durch diese ist dem Browser die HSTS Umsetzung der darin gespeicherten Domains bekannt, ohne dass dies eine Kommunikation mit der entsprechenden Website erfordert.

"Durchklicken" von Sicherheitsmeldungen

Ein weiterer kritischer Faktor auf den Applikationsbetreiber bisher keinen Einfluss nehmen konnten, ist der clientseitige Umgang mit Fehlern die beim Aufbau einer gesicherten Verbindung auftreten. Dies betrifft insbesondere Fehler bei der Zertifikatsverifikation. Browser geben diese Fehler durch eine Sicherheitsmeldung an den Anwender weiter. Das Laden der Website wird vorerst gestoppt, der Anwender kann das Risiko aber akzeptieren und somit den Ladevorgang fortsetzen. Eine sicherheitsrelevante Entscheidung für die folgende Client-Server-Kommunikation wird also dem Client bzw. dessen Anwender überlassen. Durch HSTS sind Clients angewiesen, keine Ausnahme durch den Anwender zu akzeptieren.

Quittierung von Sicherheitsmeldungen
Bei Fehlern im Verbindungsaufbau mit Webseiten ohne HSTS kann der Anwender diese durch klicken auf die Schaltfläche "Ausnahme hinzufügen" akzeptieren.
Keine Wahlmöglichkeit bei HSTS
Kommt es bei einer Webseite mit HSTS zu Fehlern beim Verbindungsaufbau, wird dem Anwender keine Möglichkeit zum Hinzufügen einer Ausnahme angeboten.

Fehler in der Anwendungsentwicklung und Content-Bereitstellung

Zudem verhindert die forcierte Verwendung von HTTPS auch, dass ein Fehler in der Erstellung und Bearbeitung von Webseiten direkte Auswirkungen auf das verwendete Übertragungsprotokoll haben kann, folglich die Verschlüsselung in Teilen außer Kraft gesetzt wird. Auch Session Cookies die vom Anwendungsentwickler fälschlicherweise nicht für die ausschließlich verschlüsselte Übertragung markiert wurden, sind durch die strikte Verwendung von HTTPS dennoch geschützt.

Angriffsszenario: SSL-Stripping

Kommunikationsverlauf mit Redirect auf HTTPS
Regulärer Kommunikationsverlauf eines Login-Vorgangs nach typischem Redirect auf HTTPS
Man-in-the-Middle und SSL-Stripping
Redirect auf HTTPS wird durch einen Man-in-the-Middle mittels SSL-Stripping ausgehebelt

Viele User verwenden unter anderem freie WLAN Hot Spots um unterwegs eine Verbindung mit dem Internet herzustellen. Da der Anbieter die vollständige Kontrolle über den Datenverkehr in seinem Netzwerk hat, ist es arglistigen Betreibern problemlos möglich den Datenverkehr mitzulesen und zu modifizieren. Dies kann ausgenutzt werden, um für HTTPS bestimmte Kommunikation offenzulegen.

Voraussetzung für den nachfolgend geschilderten Angriff ist, dass der Client die Kommunikation über eine einfache HTTP Anfrage beginnt (1), also nicht direkt eine HTTPS Verbindung aufbaut und das dafür erforderliche Zertifikat validiert. Besteht der Server auf gesicherte Übertragung, fordert dieser den Client mittels Redirect auf, die entsprechende Anfrage über HTTPS zu senden (2). Der Client folgt dieser Anweisung (3), fordert jetzt ein gültiges Zertifikat des Servers und kann die erhaltenen Antwort (4) dadurch als vertrauenswürdig betrachten. Dabei handelt es sich beispielsweise um eine Seite mit Login-Formular. Der Client übermittelt die vom Benutzer eingegebenen Daten an den Server (5), nach erfolgreicher Prüfung ist der Benutzer an der Applikation angemeldet und der Server leitet den Browser (6) an die Startseite des geschützten Bereichs weiter.

Zwei wesentliche Punkte sind es, die im geschilderten Ablauf letztlich zu einer gesicherten Übertragung mit dem gewünschten Kommunikationspartner führen:

  • der Server fordert den Client auf, die Anfrage über HTTPS zu stellen
  • der Client püft das Server-Zertifikat im Rahmen des TLS Handshakes der gestellten HTTPS Anfrage

Bei letzterem Punkt, verhindert der Einsatz von Zertifikaten, dass sich ein Angreifer als der gewünschte Kommunikationspartner ausgeben kann, somit kann der Angreifer die vom Client aufgebaute TLS Verbindung nicht terminieren und sich als Server ausgeben. Allenfalls kann er dem Client ein unzureichendes Zertifikat präsentieren und auf die Akzeptanz durch den Benutzer hoffen. Dies setzt aber eine Fehleinschätzung durch den Benutzer voraus, der die entsprechende Sicherheitsmeldung bestätigen und explizit eine Ausnahme hinzufügen muss. Bei der Verwendung von Kommandozeilen-Tools, wie z.B. curl oder wget, muss beim Aufruf eine Option gesetzt werden.

Ein Angriff der weitaus weniger auf die Fehleinschätzung des Nutzers angewiesen ist, zielt jedoch auf den erstgenannten Punkt. Hierbei nutzt der Angreifer seine Position als Man-in-the-Middle (MITM) um gesendete Pakete zu modifizieren oder auch zu unterdrücken. Eine HTTP Anfrage des Clients (7), wird durch den Angreifer an den angefragten Server weitergereicht (8). Fordert dieser per Redirect (9) eine HTTPS Verbindung an, wird diese Aufforderung nicht an den Client zurückgegeben. Stattdessen setzt der Angreifer selbst eine entsprechende HTTPS Anfrage ab (10), auf diese liefert der Server den angefragten Inhalt (11). Dieser wird nun vom Angreifer modifiziert und über die HTTP Verbindung an den Client gereicht (12). Dabei werden jegliche Inhalte modifiziert, die den Browser veranlassen würden eine HTTPS-Verbindung aufzubauen, insbseondere die Protokollangabe HTTPS in URLs. Der Client fährt somit mit der Kommunikation über HTTP fort (13). Die Anfragen werden vom Angreifer über HTTPS an den Server weitergegeben (14), die Antwort des Servers (15) wird dem Client durch den Angreifer über HTTP zugestellt (16). Dabei kann der Angreifer den kompletten Datenverkehr zwischen Client und Server einsehen, nach Wunsch modifizieren und somit auch Daten und Code einschleusen.

Wird ein Nutzer Opfer dieses Angriffs, erhält dieser keine fenstergroße Sicherheitswarnung. Da der Browser zu keinem Zeitpunkt, weder durch den Nutzer noch durch den Server, zur Verwendung von HTTPS aufgefordert wurde. Ein Unterschied zu einem regulären Seitenaufruf zeigt sich nur in den kleinen Symbolen der Adressleiste. Dabei entfällt die Anzeige des grünen Schlosses, welches eine sichere Verbindung kennzeichnet, unter Umständen wird stattdessen ein durchgestrichenes Schloss dargestellt (nachfolgend sind die Darstellungen in Firefox 53 gegenübergestellt).

Sicherheits-Info bei HTTPS-Verbindungen
Bei einer HTTPS-Verbindung wird neben dem Info-Symbol ein kleines grünes Schloss angezeigt. Im Info-Popup wird in grüner Schrift "Verbindung ist sicher" angezeigt. Dort können auch weitere Details des Zertifikats eingesehen werden.
Sicherheits-Info bei HTTPS-Verbindungen
Bei einer herkömmlichen HTTP-Verbindung wird kein Schloss oder ein Warnsymbol angezeit. Durch Anklicken des Info-Symbols, sind über ein Popup weitere Details einsehbar. Hier wird zudem die Meldung "unsichere Verbindung" ausgegeben.
Sicherheits-Warnung bei Passwortfelder
Wird eine Seite mit Passwortfeld über HTTP aufgerufen, zeigen aktuelle Browser zusätzlich ein durchgestrichenes Schloss an. Im Popup erfolgt der Hinweis: "Ihre Zugangsdaten könnten auf dieser Seite in falsche Hände geraten".

HSTS kann diesen Angriff unterbinden, wenn die Seite bereits einmal aufgerufen wurde und die übermittelte Policy noch gültig ist, oder aber die Domain auf der Preload-Liste des Browsers hinterlegt ist. Konsequenterweise unterbindet HSTS auch das Akzeptieren unzulänglicher Zertifikate, andernfalls würde dem Angreifer, wie oben bereits angeführt, ein alternatives Vorgehen offenstehen.

Browser Kompatibilität

Desktop

HSTS wird in der aktuellen Version aller gängiger Browser unterstützt.

  • Chrome 4.0
  • Edge 12
  • Firefox 4
  • Internet Explorer 11
  • Opera 12
  • Safari 7

Mobile

Ebenso unter mobilen Endgeräten hat HSTS bereits breite Unterstützung gefunden.

  • Android 4.4
  • Chrome for Android 18
  • Edge Mobile
  • Firefox for Android
  • Safari Mobile 8.4
  • Firefox for iOS

Kommandozeilen-Tools

Das Kommandozeilen-Tool wget setzt HSTS bereits um, für das Tool curl wurde die Umsetzung von HSTS in die TODO-Liste aufgenommen.

  • wget 1.17

Fazit

Für Webseiten, die bereits ausschließlich über HTTPS bereitgestellt werden, stellt HSTS ein leicht umzusetzendes Verfahren dar, um den Schutz vor Ausnutzung der geschilderten Schwachstellen erheblich zu verbessern.

Voraussetzung ist eine ausreichend hoch gewählte Gültigkeit, so dass ein einmal gesetzter HSTS Eintrag bei üblicher Nutzungshäufigkeit im Regelfall nicht abläuft. Für Seiten die bisher auch über HTTP bereitgestellt wurden, kann die Zeitangabe vorerst gering gewählt werden. Im Falle eines Lastproblems kann so ein schneller Rückbau erfolgen.

Ohne den Preload-Machanismus können die aufgeführten Angriffe aber nicht gänzlich ausgeschlossen werden. Dies liegt daran, dass auch HSTS der Trust On First Use (TOFU) Problematik unterliegt, da zumindest einmal eine sichere Verbindung zum gewünschten Kommunikationspartner zustande kommen muss, damit dieser seine HSTS Policy an den Client übertragen kann. HSTS schützt einen Nutzer somit nicht beim allerersten Zugriff auf eine Website oder bei einem erneuten Zugriff nach Ablauf der Gültigkeit bereits gespeicherter HSTS Einträge.

Vollständigen Schutz gegen die adressierten Schwachstellen liefert also nur HSTS in Verbindung mit der Aufnahme in die Preload-Listen der Browser. Dies sollte ein wohlüberlegter Schritt sein, da nur gesamte Domains inklusive Subdomains in die Liste von Google aufgenommen werden. Zugelassen für die Aufnahme sind nur Second-Level bzw. Third-Level-Domains, wenn die öffentliche Vergabe erst auf dieser Ebene erfolgt (z.B.: .co.uk). Dies wird unter anderem gefordert, um die Größe der Preload-Liste nicht zu groß werden zu lassen. Ob diese Forderung langfristig ausreichend ist oder ob die Aufnahme künftig noch durch zusätzliche Kriterien eingeschränkt wird, bleibt abzuwarten.