Dipl.-Inform. Carsten Eilers

Das HTTPS nur sicher ist, wenn alle wichtigen Seiten einer Webanwendung entsprechend geschützt sind, ist seit langem bekannt. Ein klassisches Beispiel sind viele Login-Formulare. Die befinden sich oft auf über HTTP ungeschützt geladenen Seiten, die Eingaben werden dann über HTTPS an den Server geschickt. Ein Angreifer, der sich als Man-in-the-Middle in die Verbindung einschleichen kann, kann dann die Seite mit dem Login-Formular manipulieren, so dass die Login-Daten unverschlüsselt verschickt werden.
Ein weiteres Beispiel sind viele Webshops: Wenn die Shop-Seiten während des Einkaufs unverschlüsselt übertragen werden, kann ein MitM den HTTPS-Links zur Anmeldung oder zur Eingabe der Zahlungsdaten durch einen HTTP-Link ersetzen und danach die unverschlüsselt übertragenen Daten belauschen.

So einen Angriff nennt man SSL-Stripping. Der Angriff wurde 2009 von Moxie Marlinspike auf der Sicherheitskonferenz Black Hat DC vorgestellt, außerdem hat er das Tool sslstrip zur Durchführung solcher Angriffe veröffentlicht.

Sofern der Man-in-the-Middle die Verbindung zum Server ganz normal verschlüsselt aufbaut, kann der Server den Angriff nicht erkennen. Für ihn sieht es aus, als sei der MitM der Benutzer, zu dem eine verschlüsselte Verbindung besteht. Dass der MitM die Daten nur an den eigentlichen Benutzer weiter leitet und dabei alle HTTPS-Links durch entsprechende HTTP-Links ersetzt, kann er nicht erkennen.

Gegenmaßnahme: HTTP Strict Transport Security

Als Gegenmaßnahme für solche Angriffe wurde HTTP Strict Transport Security (HSTS) entwickelt: Der Server kann auf eine HTTP-Anfrage mit einer Antwort mit gesetztem Strict-Transport-Security-Header antworten, um den Browser zur ausschließlichen Nutzung von HTTPS-Links zu zwingen. Der Header enthält den Wert max-age=[Gültigkeitsdauer in Sekunden], außerdem kann durch die Angabe des Schlüsselworts includeSubDomains das Einbeziehen aller Subdomains angeordnet werden. Der Browser ersetzt dann für die Dauer der Gültigkeitsdauer alle HTTP-Links durch HTTPS-Links.

Schutz mit Lücke

Dieser Schutz hat einen Nachteil: Wenn ein Benutzer das erste Mal eine Verbindung zu einem so geschützten Server aufbaut, weiß der Browser nicht, dass er HTTPS nutzen soll, und ein MitM kann die Antwort des Servers manipulieren, so dass der Header den Browser nie erreicht. Die Mozilla Foundation hat deshalb in Firefox eine neue Schutzfunktion implementiert, die dem schon länger verfügbaren entsprechenden Schutz von Googles Chrome gleicht: Der Browser enthält eine Liste mit Hosts, die bekanntermaßen HSTS nutzen, und erzwingen schon beim ersten Verbindungsaufbau die Nutzung von HTTPS.

Wird HSTS überhaupt genutzt?

SecureNet hat untersucht, wie es die Websites auf der "Alexa Top 1.000.000"-Liste mit dem Einsatz von HSTS halten (Paper als PDF). Dabei wurde untersucht, ob der Header überhaupt verwendet wird und wenn ja, wie lang die Gültigkeitsdauer ist. Bis 30 Tage wurde der Schutz als ungenügend eingestuft, bis einem Jahr als schlecht, bei mehr als einem Jahr als ausreichend. Der Hintergrund dafür: Je kürzer die Gültigkeitsdauer, desto größer die Wahrscheinlichkeit dafür, dass der in einer sicheren Umgebung eingeschaltete Schutz beim erneuten Besuch der Website in einer unsicheren Umgebung nicht mehr gültig ist. Der erste Aufruf würde dann über HTTP erfolgen, und der MitM könnte zuschlagen.

Getestet wurde in drei Kategorieren:

1. Alle Domains der "Alexa Top 1.000.000"-Liste
2. Die darin enthaltenen de-Domains
3. Die Login-Seiten deutscher Banken-Websites

Bei der Auswertung nicht berücksichtigt wurden Server, die keinen HTTPS-Zugang anbieten (was nicht vorhanden ist, muss auch nicht besonders geschützt werden), sowie Server mit fehlerhaften Zertifikaten (aufgrund der Annahme, dass die sehr wahrscheinlich nicht wirklich produktiv eingesetzt werden). Ich bin aber auch schon auf Server gestoßen, die produktiv eingesetzt wurden und trotzdem ein fehlerhaftes Zertifikat verwendeten. Aber bei der generell geringen Verbreitung von HSTS nutzenden Servern dürften die mit fehlerhaften Zertifikat und HSTS nicht ins Gewicht fallen.

HSTS wird kaum genutzt

Das Ergebnis der Untersuchung sieht ganz und gar nicht gut aus:

Alle Domains der "Alexa Top 1.000.000"-Liste

Rund 100.000 Websites nutzen HTTPS, aber nur 410 davon auch HSTS.

124 Websites verwenden eine Gültigkeitsdauer von max. 30 Tagen.
8 Websites davon setzen den Wert auf 0 und schalten HSTS damit effektiv aus. Die entscheidenden Frage wäre hier "Ist das Absicht oder ein Fehler", denn der Wert 0 ist extra dafür vorgesehen, einen ggf. vorher gesetzten höheren Wert aufzuheben. Es kann ja auch mal vorkommen, dass eine Website kein HTTPS mehr nutzen möchte.
Das (gültige) Minimum waren 5 Minuten, was nur ein schlechter Scherz, aber kein Schutz ist. Evtl. ist das Problem aber auch die Angabe der Gültigkeitsdauer in Sekunden. Das ist zwar nicht unüblich, aber unübersichtlich, da so auch große Zahlenwerte zu effektiv nur kurzer Gültigkeitsdauer führen.

Bei 46 Websites liegt die Gültigkeitsdauer zwischen 30 Tagen und weniger als 1 Jahr.

238 Websites setzen eine Gültigkeitsdauer von mindestens 1 Jahr ein, 222 davon verwendeten genau 1 Jahr. Das Maximum lag bei 20 Jahren.

2 Websites waren falsch konfiguriert und fielen aus diesem Raster.

Die de-Domains der "Alexa Top 1.000.000"-Liste

Von 39.270 de-Domains setzen 6.206 HTTPS ein, nur 12 davon nutzen HSTS. Nur 5 Websites hatten eine Gültigkeitsdauer von mindestens 30 Tagen, 3 davon hatten zusätzlich das includeSubDomains-Attribut gesetzt.

Deutsche Banken-Websites

Untersucht wurden 424 Bankendomains. Nur 7 Websites setzen HSTS ein, keine nutzte das includeSubDomains-Attribut. Die Gültigkeitsdauer reichte von 1 Stunde bis 365 Tagen.

Browserunterstützung: Mangelhaft

HSTS-Header nutzen natürlich nur etwas, wenn die Browser sie auch auswerten. Und hier patzen zwei wichtige Exemplare: Weder der Internet Explorer noch Safari unterstützen HSTS. Mit anderen Worten: Benutzer von Windows, Mac OS X und iOS, die die jeweiligen Standard-Browser ihrer Systeme benutzen, sind SSL-Stripping-Angriffen auf technischer Ebene schutzlos ausgeliefert.

Schutzmaßnahmen

Im Browser

Auf Client-Seite fällt der Angriff durch die fehlende Kennzeichnung einer sicheren Verbindung auf. Wenn Sie darauf achten, erkennen Sie einen Angriff am fehlenden geschlossenen oder grünen Schloss-Icon oder wie auch immer Ihr Browser eine HTTPS-Verbindung anzeigt. In vielen Fällen, zum Beispiel Login-Formularen in HTTP-Seiten, die erst die eingegebenen Daten über HTTPS senden, ist es dann aber schon zu spät und der Angreifer hat die Daten abgefangen.

Eine Warnung vor einem ungültigen SSL-Zertifikat wie bei MitM-Angriffen auf SSL gibt es bei diesem Angriff nicht, da Ihr Browser gar nicht erst versucht, eine HTTPS-Verbindung aufzubauen.

Zusätzlichen Schutz bieten die Browsererweiterungen HTTPS Everywhere für Firefox und Chrome und NoScript für Firefox, mit denen sich die generelle Nutzung von HTTPS Browser-seitig erzwingen lässt. Natürlich nur bei Servern, die auch HTTPS anbieten. Zum Beispiel hier in meinem Blog könnten Sie HTTPS erzwingen wollen so lange sie wollen, der Server bietet es gar nicht an, da es in diesem Fall nicht nötig ist.

Auf dem Server

Auf der Server-Seite sollten Sie HTTPS immer mit HSTS einsetzen, und zwar mit einer möglichst langen Gültigkeitsdauer und, sofern vorhanden, unter Einbeziehung der Subdomains. Außerdem müssen nicht nur Seiten mit sensitiven Inhalten über HTTPS übertragen werden, sondern auch alle Seiten, die Links auf die nur über HTTPS erreichbaren Seiten enthalten. Besonders gefährlich sind in diesem Zusammenhang Formulare auf HTTP-Seiten, die ihre Daten über HTTPS übertragen (sollen) - der normale Benutzer hat hier keine Möglichkeit, das Fehlen von HTTPS zu erkennen. Theoretisch könnte er den Quelltext der Seite untersuchen, aber wie viele Benutzer sind dazu in der Lage?

Das Aktivieren von HSTS sowie weitere Maßnahmen als "Defence in Depth" wurden von SecureNet in einem Whitepaper zusammengefasst (Download als PDF).

Fazit

Die Nicht-Nutzung von HSTS ist äußerst unschön. Vermutlich ist die Gefahr, die von SSL-Stripping ausgeht, bei den Server-Betreibern nicht oder zumindest nicht ausreichend bekannt. Da fällt mir ein: Wie sieht es denn mit dem Schutz von Session-Cookies etc. aus? Das ist ja auch ein altbekanntes Problem und mit Firesheep gibt es seit mehr als 2 Jahren einen prominenten Proof-of-Concept, der ungeschützt übertragene Cookies abfängt.

Viele Webentwickler und -admins brauchen da wohl noch etwas Nachhilfe. Andererseits kann ich fast diejenigen verstehen, die sich sagen "Wozu soll ich mir mit HTTPS Mühe geben, wenn doch das Zertifizierungssystem sowieso nichts taugt?". Ja, wieso eigentlich? Zum Beispiel um all die Benutzer zu schützen, die nicht mit gefälschten bzw. erbeuteten Zertifikaten angegriffen werden. Die sind vor allem im Iran aufgefallen, aber es gibt sicher noch mehr Staaten, die sich in der Hinsicht als Falschspieler betätigen. Aber ich möchte fast wetten, es gibt weltweit mehr Nutzer unsicherer Netze wie beispielsweise offener WLANs als Internetnutzer im Iran. Warum also alle Nutzer weltweit gefährden, nur weil man die im Iran nicht schützen kann?

Carsten Eilers