Cloudflare will Schluss machen mit dem unverschlüsselten Internet. Aber das Web hat beim Wechsel zu HTTPS ein Henne-Ei-Problem.
Vor langer Zeit war es schwierig, teuer und langsam, eine HTTPS-fähige Website einzurichten. Dann kamen Dienste wie Cloudflares Universal SSL, die den Wechsel von http:// auf https:// quasi auf Knopfdruck ermöglichten. Mit einem Klick wurde eine Seite über HTTPS bereitgestellt, mit einem frisch ausgestellten, kostenlosen SSL-Zertifikat.
Bumm!
Plötzlich ist die Website über HTTPS verfügbar, und, noch besser, die Website ist schneller, weil sie die Vorteile des neuesten Webprotokolls HTTP/2 nutzen kann.
Leider ist das nicht das Ende der Geschichte. Viele ansonsten sichere Websites leiden unter dem Problem gemischter Inhalte. Und gemischte Inhalte bedeuten, dass das grüne Schloss-Symbol für eine https://-Website nicht angezeigt wird, da sie in der Tat nicht wirklich sicher ist.
Hier liegt das Problem: Wenn eine https://-Website Inhalte von einer Website (auch ihrer eigenen) enthält, die über http:// bereitgestellt wird, kann das grüne Vorhängeschloss nicht angezeigt werden. Das liegt daran, dass Ressourcen wie Bilder, JavaScript, Audio, Video usw., die über http:// eingebunden sind, eine Sicherheitslücke in der sicheren Website öffnen. Eine Hintertür für Schwierigkeiten.
Webbrowser wissen seit langem, dass dies ein Problem ist. Bereits 1997 warnte der Internet Explorer 3.0.2 mit dem folgenden Dialogfeld die Nutzer von Websites mit gemischten Inhalten.
Heute zeigt Google Chrome ein eingekreistes i bei jeder https:// an, die unsichere Inhalte hat.
Und Firefox zeigt ein Vorhängeschloss mit einem Warnsymbol. Um ein grünes Vorhängeschloss von einem dieser Browser zu erhalten, muss jede einzelne Subressource (eine von einer Seite geladene Ressource) über HTTPS bereitgestellt werden.
Wenn Sie 1997 auf „Ja“ geklickt hätten, hätte der Internet Explorer die Gefahren von gemischten Inhalten ignoriert und die Subressourcen über Klartext-HTTP geladen. Das Anklicken von „Nein“ verhinderte, dass sie geladen wurden (was oft zu einer fehlerhaften, aber sicheren Webseite führte).
Umstellung auf vollständig sichere Inhalte
Es ist verlockend, aber naiv, zu denken, dass es eine einfache Lösung für gemischte Inhalte gibt: „Laden Sie einfach alles über https:// und reparieren Sie Ihre Website.“ Leider macht es das Sammelsurium von Inhalten, die von Erst- und Drittanbieter-Websites in moderne Websites geladen werden, sehr schwierig, „einfach“ diese Änderung vorzunehmen.
CC BY 2.0 Foto von Mike Mozart
Wired hat seinen Übergang zu https:// in einer Reihe von Blogbeiträgen dokumentiert, die zeigen, wie schwer es sein kann, alles auf HTTPS umzustellen. Sie begannen im April und verbrachten fünf Monate mit dem Prozess (nachdem sie sich bereits monatelang nur für die Umstellung der zentralen Homepage auf https:// vorbereitet hatten). Im Mai schrieben sie über eine größere Schwierigkeit:
„[…] eine der größten Herausforderungen bei der Umstellung auf HTTPS ist die Vorbereitung aller unserer Inhalte für die Bereitstellung über sichere Verbindungen. Wenn eine Seite über HTTPS geladen wird, müssen auch alle anderen Ressourcen (wie Bilder und Javascript-Dateien) über HTTPS geladen werden. Wir erhalten eine hohe Anzahl von Meldungen wegen dieser „Gemischte Inhalte“-Probleme oder Ereignissen, bei denen eine unsichere HTTP-Ressource im Rahmen einer sicheren HTTPS-Seite geladen wird. Um unsere Einführung richtig zu gestalten, müssen wir sicherstellen, dass wir weniger Probleme mit gemischten Inhalten haben – dass wir so viele Inhalte von WIRED.com so sicher wie möglich bereitstellen.“
Im Jahr 2014 identifizierte die New York Times gemischte Inhalte als eine große Hürde für die Sicherheit:
_„_Um erfolgreich zu HTTPS zu wechseln, müssen alle Anfragen an Seiteninhalte über einen sicheren Kanal gestellt werden. Es ist eine gewaltige Herausforderung, und es gibt viele bewegliche Teile. Wir müssen Ressourcen berücksichtigen, die derzeit aus unsicheren Domains geladen werden – von JavaScript bis hin zu Werbeinhalten."
Und das W3C erkannte dies als ein großes Problem an: „Vor allem die Prüfung gemischter Inhalte kann Administratoren, die mit der Übertragung großer Mengen an Altinhalten auf HTTPS beauftragt sind, echte Kopfschmerzen bereiten. Insbesondere stellt das Durchsuchen alter Inhalte und manuelle Umschreiben von Ressourcen-URLs eine große Herausforderung dar.“ Als ein schwieriges Beispiel wurde das riesige Archiv der BBC angeführt.
Aber es sind nicht nur Medienseiten, die ein Problem mit gemischten Inhalten haben. Viele CMS-Benutzer finden es schwierig oder unmöglich, alle Links, die ihr CMS erzeugt, zu aktualisieren, da sie in Konfigurationsdateien, Quellcode oder Datenbanken verborgen sein können. Darüber hinaus haben auch Websites, die sich mit benutzergenerierten Inhalten befassen müssen, ein Problem mit http://-URIs.
Die Gefahren gemischter Inhalte
Gemischte Inhalte gibt es in zwei Varianten: aktiv und passiv. Moderne Webbrowser gehen die Gefahren dieser verschiedenen Arten gemischter Inhalte so an: Aktive gemischte Inhalte (die gefährlichsten) werden automatisch und vollständig blockiert, passive gemischte Inhalte werden durchgelassen, führen aber zu einer Warnung.
Aktiver Inhalt ist alles, was das DOM (die Webseite selbst) verändern kann. Ressourcen, die über die Tags <script>, <link>, <iframe> oder <object> eingebunden sind, CSS-Werte, die url verwenden, und alles, was mittels XMLHTTPRequest angefordert wird, kann eine Seite ändern, Cookies lesen und auf Benutzerdaten zugreifen.
Passiver Inhalt ist alles andere: Bilder, Audio, Videos, die in die Seite geschrieben werden, aber selbst nicht auf die Seite zugreifen können.
Aktive Inhalte sind eine wirkliche Bedrohung, denn wenn es einem Angreifer gelingt, die Anfrage nach einem http://-URI abzufangen, kann er den Inhalt durch seinen eigenen ersetzen. Dabei handelt es sich nicht um ein theoretisches Problem. Im Jahr 2015 wurde Github von einem System namens Great Cannon angegriffen, das Anfragen nach gängigen JavaScript-Dateien über HTTP abfing und durch ein JavaScript-Angriffsskript ersetzte. Die „Große Kanone“ nutzte die Computer unschuldiger Benutzer als Waffe, indem sie TCP abfing und die inhärente Schwachstelle aktiver Inhalte ausnutzte, die von den http://-URIs geladen wurden.
Passive Inhalte stellen eine andere Art von Bedrohung dar: Da Anfragen für passive Inhalte im Klartext gesendet werden, kann ein Lauscher die Anfragen überwachen und Informationen extrahieren. So könnte beispielsweise ein gut positionierter Lauscher Cookies, besuchte Webseiten und möglicherweise auch Authentifizierungsinformationen überwachen.
Das Firefox-Add-on Firesheep kann verwendet werden, um ein lokales Netzwerk (z. B. in einem Café) auf über HTTP gesendete Anfragen zu überwachen und automatisch Cookies zu stehlen, mit denen ein Benutzer die Identität einer Person mit einem einzigen Klick übernehmen kann.
Moderne Browser blockieren heute aktive Inhalte, die nicht sicher geladen werden, lassen aber passive Inhalte passieren. Dennoch ist der Wechsel zu ausschließlichem https:// der einzige Weg, um alle Sicherheitsbedenken für gemischte Inhalte zu beseitigen.
Automatische Behebung des Problems mit gemischten Inhalten
Wir wollten schon lange helfen, das Problem mit gemischten Inhalten zu beheben, denn unser Ziel ist es, ein vollständig verschlüsseltes Web zu bekommen. Und wie bei anderen Cloudflare-Diensten wollten wir dies zu einer „Ein-Klick“-Erfahrung machen.
CC BY 2.0 Foto von Anthony Easton
Wir haben eine Reihe von Ansätzen erwogen:
Automatisches Einfügen der CSP-Anweisung upgrade-insecure-requests
Die Anweisung upgrade-insecure-requests kann wie folgt in einem Content Security Policy-Header eingefügt werden:
Content-Security-Policy: upgrade-insecure-requestsDadurch wird der Browser angewiesen, jede HTTP-Anfrage automatisch auf HTTPS zu aktualisieren. Dies kann nützlich sein, wenn der Website-Besitzer weiß, dass jede Subressource über HTTPS verfügbar ist. Die Website muss die in sie eingebetteten http://-URIs nicht wirklich in https:// ändern, der Browser kümmert sich automatisch darum.
Leider gibt es einen großen Nachteil mit upgrade-insecure-requests. Da der Browser blind jeden URI auf https:// aktualisiert, unabhängig davon, ob der resultierende URI tatsächlich funktioniert, kann es zur fehlerhaften Darstellung von Seiten kommen.
Änderung aller Links in https://
Da nicht alle Browser, die von Besuchern von Cloudflare-Websites verwendet werden, upgrade-insecure-requests unterstützen, haben wir erwogen, alle URIs von http:// auf https:// zu aktualisieren, wenn die Seiten unseren Dienst durchlaufen. Da wir Webseiten in Echtzeit analysieren und modifizieren können, hätten wir einen „upgrade-insecure-requests“-Dienst erstellen können, der nicht auf Browserunterstützung angewiesen gewesen wäre.
Leider tritt dabei aber immer noch das gleiche Problem von defekten Links auf, wenn ein http://-URI in https:// umgewandelt wird, die Ressource aber nicht tatsächlich mit HTTPS geladen werden kann.
Änderung von Links, die auf andere Cloudflare-Websites verweisen
Da Cloudflare allen seinen vier Millionen Kunden kostenlos Universal SSL bietet und wir einen großen Prozentsatz der Webzugriffe abdecken, haben wir darüber nachgedacht, nur bei URIs, von denen wir wissen, dass sie funktionieren werden (weil sie unseren Dienst nutzen), http:// zu https:// zu aktualisieren.
Dies löst einen Teil des Problems, ist aber keine gute Lösung für das allgemeine Problem des Upgrades von HTTP auf HTTPS.
Schaffung eines Systems, das bekannte HTTPS-fähige URIs umschreibt
Schließlich haben wir uns entschieden, es schlau anzustellen: URIs von http:// zu https:// zu aktualisieren, wenn wir wissen, dass die Ressource über HTTPS bereitgestellt werden kann. Um herauszufinden, welche Links aktualisiert werden können, haben wir die ausgezeichnete Erweiterung HTTPS Everywhere der EFF und die Liste HSTS preload von Google Chrome genutzt, um unser Wissen über Cloudflare-Sites mit aktiviertem SSL zu erweitern.
Wir sind sehr dankbar, dass die EFF freundlicherweise bereit war, uns bei diesem Projekt zu unterstützen.
Der HTTPS-Everywhere-Regelsatz geht weit über den einfachen Wechsel von http:// zu https://: hinaus und enthält Regeln (und Ausschlüsse), mit denen es (und wir) sehr spezifische URIs ansprechen können. Hier ist zum Beispiel eine echte HTTPS-Everywhere-Regel für gstatic.com:
<rule from="^http://(csi|encrypted-tbn\d|fonts|g0|[\w-]+\.metric|ssl|t\d)\.
gstatic\.com/" to="https://$1.gstatic.com/"/>Sie verwendet einen regulären Ausdruck, um spezifische Subdomains von gstatic.com zu identifizieren, die sicher für die Verwendung von HTTPS aktualisiert werden können. Den kompletten Regelsatz können Sie hier einsehen.
Da wir eine große Anzahl von URIs, die in Webseiten eingebettet sind, aktualisieren müssen (wir schätzen etwa fünf Millionen pro Sekunde), haben wir bestehende HTML-Parser (einschließlich unserer eigenen) verglichen und beschlossen, einen neuen für diese Art von Umschreibe-Aufgabe zu entwickeln. Wir werden in einem späteren Beitrag mehr über Design, Test und Leistung des Parsers berichten.
Automatische HTTPS-Rewrites
Automatische HTTPS-Rewrites sind nun im Kunden-Dashboard für alle Cloudflare-Kunden verfügbar. Derzeit ist diese Funktion standardmäßig deaktiviert und kann mit einem Klick aktiviert werden:
Wir werden die Leistung und Effektivität dieser Funktion überwachen und sie im Laufe des Jahres standardmäßig für Kunden mit kostenlosen und Pro-Tarifen aktivieren. Wir planen auch, die Berichtsfunktionen der Content Security Policy zu nutzen, um unseren Kunden eine automatische Übersicht zu geben, welche URIs noch aktualisiert werden müssen, damit ihr Übergang zu ausschließlichem https:// so einfach wie möglich wird: Manchmal kann es sehr schwierig sein, einfach nur herauszufinden, welche URIs geändert werden müssen, wie Wired feststellen musste.
Wir würden uns freuen, von Ihnen zu hören, welche Erfahrungen Sie mit dieser Funktion machen.