Gemischte Inhalte hinter einem VPN: Repariere die Ressource, nicht den Tunnel

Eine HTTPS-Seite, die Skripte über HTTP lädt, stellt zwei Anfragen mit zwei unterschiedlichen Schutzstufen, und das Vorhängeschloss beschreibt nur die erste. Ein Tunnel ändert daran nichts, weil er den Träger schützt und nicht das eigene Schema der Ressource. Der Browser sagt dir bereits, welche Anfrage fehlgeschlagen ist, wenn du die Konsole statt die Adressleiste liest. Drei Prüfungen führen dich von einer teilweise funktionierenden Seite zu einer tatsächlichen Reparatur.

Lies die Anfrage, nicht die Adressleiste

Ein über HTTPS abgerufenes Dokument kann ein Skript, ein Stylesheet, eine Schriftart oder einen Frame über einfaches HTTP referenzieren. Dieser Verweis ist eine eigene Anfrage, und genau über sie beschwert sich der Browser. Der Schutz des Hauptdokuments wandert nicht in sie zurück, und der Tunnel, der beide Ströme trägt, ändert keines der beiden Schemata. Die Seite kann daher zugleich wirklich sicher und wirklich kaputt sein.

Die Ressource bloß eine eingebundene Datei zu nennen macht ihren Austausch nicht harmlos.

Wenn unsicherer Skriptinhalt unterwegs verändert und dann ausgeführt werden kann, kann er das Verhalten der Seite verändern, was ein größeres Problem ist als ein kosmetischer Fehler. Bilder tragen ein kleineres, aber reales Risiko, wenn sie unterwegs verändert werden. Das Vorhängeschloss lügt über nichts. Es beantwortet eine engere Frage als die, die du ihm gestellt hast.

Wisse, welche Ressourcen blockiert und welche hochgestuft werden

Browser behandeln nicht jeden Ressourcentyp gleich. die Hinweise zu gemischten Inhalten trennen Anfragen, die auf HTTPS hochgestuft werden, von Anfragen, die vollständig blockiert werden, wobei Skripte, Stylesheets und programmatische Anfragen auf der blockierten Seite liegen, während Bilder und Medien stattdessen hochgestuft oder markiert werden können.

Dieser Unterschied erklärt die verwirrenden Berichte. Eine Seite mit einem blockierten Skript verliert eine Funktion vollständig, während eine Seite mit einem hochgestuften Bild gut aussieht und ihre Anfrage still verändert hat. Die dokumentierten Kategorien haben auch Ausnahmen, also gehe nicht davon aus, dass jede URL eines bestimmten Typs erfolgreich hochgestuft wird. Lies, was die Konsole über die konkrete Anfrage sagt, statt aus einer Dateiendung zu schließen.

Ein blockiertes Widget ist kein Beweis dafür, dass der Tunnel versagt hat. Es ist ein Beweis dafür, dass der Browser seine Aufgabe erfüllt hat.

Repariere den Verweis an seiner Quelle

Für einen Seitenbetreiber gehört die Reparatur dorthin, wo die unsichere URL geschrieben wurde: eine Vorlage, ein Stylesheet, ein Skript, das URLs zusammensetzt, oder eine Komponente eines Drittanbieters. Das Ändern der sichtbaren Seitenadresse lässt all das unberührt. Suche die Quelle nach dem Host ab und repariere jeden Verweis statt nur den einen, den die Konsole zufällig genannt hat.

Bestätige dann, dass die Ressource tatsächlich über HTTPS mit gültiger Identität ausgeliefert wird, denn ein Schemawechsel kann keinen Dienst herbeizaubern, der dort nie veröffentlicht wurde.

grep -rn "http://assets.example" ./templates
curl -sSI https://assets.example/widget.js | head -n 1

Folge auch Weiterleitungen, denn ein Verweis, der mit HTTPS beginnt, kann trotzdem auf einem Klartext-Auslieferungspfad landen. Wo eine Abhängigkeit schlicht keine sichere Auslieferung hat, entferne oder ersetze sie über den normalen Änderungsprozess, statt einen Workaround auszuliefern. Für einen Nutzer lass die Browserschutzfunktionen aktiviert und melde dem Betreiber der Seite die URL der Ressource, ihren Typ und die Konsolenmeldung. Verbreite niemals Anweisungen, die Mitarbeitern sagen, sie sollen unsichere Inhalte für eine Seite zulassen, denn diese Ausnahme überlebt den Vorfall, der sie ausgelöst hat.

Teste die Seite erneut so, wie Nutzer sie anfassen

Übe die Vorgänge, die Ressourcen bei Bedarf laden, nicht nur das erste Dokument. Seiten holen nach einem Knopfdruck zusätzlichen Code, Daten und Downloads, und diese Anfragen sind oft die unsicheren. Bestätige die konkreten Anfragen und das sichtbare Verhalten bei weiterhin aktivem Schutz. Ein Test, der mit einem gelockerten Browserprofil beginnt, kann dir nicht zeigen, was ein normaler Nutzer sieht.

Der Tunnel hat weiterhin seine eigene Aufgabe, und diese Aufgabe ist Netzzugang statt Seitenintegrität.

Sobald der Verkehr den Endpunkt des Tunnels verlässt, hat jeder verbleibende HTTP-Abruf vom Träger nichts gewonnen. Repariere den Ressourcenpfad und lass die Durchsetzung im Browser bestehen. Eine weitere Transportschicht als Reparatur für eine unsichere Abhängigkeit zu behandeln, ist der Weg, auf dem ein Team bei einem Helpdesk-Skript landet, das die Kontrolle abschaltet, die korrekt funktioniert hat.