VPN verbunden, gemischte Inhalte weiter blockiert: was zu beheben ist
Ordnen Sie die blockierte URL danach, wer sie erzeugt hat, reparieren Sie die Referenz oder geben Sie sie an den Eigentümer des Hosts, und bestätigen Sie den Fix anschließend in der Browserkonsole.
Die halbe Seite wird gerendert, ein Stylesheet steht im Netzwerk-Panel ausgegraut, und der VPN-Client meldet weiterhin einen gesunden Tunnel. Alle drei Beobachtungen stimmen gleichzeitig, denn der Browser hat eine Anfrage der Seite beurteilt, und der Tunnel hatte bei diesem Urteil keine Stimme. Den Fall abschließen lässt sich nur durch eine Entscheidung, nicht durch eine Einstellung: die Referenz reparieren, sie an den Eigentümer des Hosts eskalieren oder die Abhängigkeit entfernen. Jede dieser Optionen hat einen billigen Test, und die falsche Wahl kostet einen Support-Zyklus.
Warum der Tunnel eine Unterressource nicht abdecken kann
Gemischte Inhalte beginnen mit einem HTTPS-Dokument, das eine Unterressource über einfaches HTTP anfordert. Jede URL wird nach ihrem eigenen Schema beurteilt, daher erstreckt sich der Schutz des übergeordneten Dokuments nie auf eine untergeordnete Anfrage. Verschlüsselung, die unterhalb des Browsers hinzugefügt wird, verändert, was über die Leitung geht, nicht das http://, das im Markup stand.
Aktuelle Browser sortieren diese Anfragen in zwei Gruppen und behandeln sie unterschiedlich. Skripte, Stylesheets, iframes und Aufrufe per fetch, XMLHttpRequest oder WebSocket werden rundweg abgelehnt, ohne vorherigen Upgrade-Versuch. Bilder, Audio und Video werden auf https:// umgeschrieben und erneut angefordert, und der Ladevorgang wird abgebrochen, wenn dieser sichere Abruf scheitert. Eine Unterressourcen-URL, deren Host eine reine IP-Adresse ist, ist vom Upgrade ausgenommen, sodass ein HTTP-Bild auf einem IP-Host blockiert bleibt, statt stillschweigend repariert zu werden. Die Aufteilung, einschließlich dieser Ausnahme auf der upgradebaren Seite, ist in Mozillas Leitfaden zu gemischten Inhalten. Chrome wendet eine ähnliche Ablehnung auf unsichere Downloads an, die von einer sicheren Seite gestartet werden, weshalb ein PDF-Link sterben kann, während die umgebende Seite intakt aussieht.
Die ausgegraute Zeile ist daher der Beweis, dass die Kontrolle funktioniert, nicht der Beweis, dass der Tunnel Klartext durchgelassen hat. Behandeln Sie die Zeile als Fund, der auf eine einzelne Referenz zeigt, nicht auf die ganze Seite.
Klärung, wem die unsichere Referenz gehört
Sortieren Sie die beanstandete URL nach ihrer Herkunft, bevor Sie etwas bearbeiten. Diese Antwort entscheidet, ob Sie heute einen Fix ausliefern können, ob ein Anbieter einen veröffentlichen muss oder ob die Abhängigkeit die Seite verlassen muss. Lesen Sie sie aus der Spalte Initiator im Netzwerk-Panel, denn das Markup auf dem Bildschirm wird oft zur Laufzeit zusammengesetzt.
| Woher die URL kommt | Wer sie beheben kann | Erster Schritt |
|---|---|---|
| Hartcodiert in einer Vorlage oder einem Partial, das Sie ausliefern | Sie | Ersetzen Sie sie durch die https://-Form und leeren Sie dann den Cache |
| Von einem Tag-Manager oder einem Anbieter-Bundle eingefügt | Der Anbieter, mit Ihrem Ticket | Senden Sie die genaue URL, den Anfragetyp und die Konsolenzeile |
| Nur auf Port 80 ohne TLS-Listener ausgeliefert | Der Eigentümer des Hosts | TLS verlangen, sie hinter etwas Eigenes stellen oder fallen lassen |
Wenn der Host bereits auf 443 antwortet und nur die Referenz http sagt, ist die Reparatur lokal: Referenz ändern, den Seiten-Cache leeren und prüfen, dass die Zeile auf https wechselt. Ein Host, der nur auf Port 80 lauscht, lässt sich nicht durch Bearbeiten regelkonform machen, also wandert die Ressource, wird hinter etwas gestellt, das Sie kontrollieren, oder fällt weg. Eine von einem Tag-Manager eingefügte URL erscheint weiterhin, selbst wenn Ihre eigene Vorlage sauber ist, und dieser Fall gehört in ein Ticket mit der genauen URL und der Konsolenzeile. Mitarbeitern zu sagen, sie sollen unsichere Inhalte erlauben, ist keine dieser Optionen, denn das schaltet die Prüfung für jede Seite ab, die dieses Browserprofil besucht.
Die Referenz reparieren statt die Browsereinstellung
Laden Sie den fehlschlagenden Ablauf mit erhaltenem Netzwerkprotokoll neu und filtern Sie das Panel nach dem verdächtigen Host. Die Konsole nennt die URL und die Direktive, was klärt, ob eine Anfrage abgelehnt oder hochgestuft wurde, bevor Sie eine Vorlage anfassen.
curl -sSI https://cdn.example.org/vendor.js | head -n 1
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' -L https://cdn.example.org/vendor.jsZwei unterstützende Kontrollen sind wissenswert, und keine ersetzt die Reparatur. Ein Content-Security-Policy-Header mit upgrade-insecure-requests bringt den Browser dazu, http-Unterressourcen-URLs umzuschreiben, bevor sie die Seite verlassen, was alte Referenzen erfasst, die Sie noch nicht gefunden haben. Die umgeschriebene Anfrage scheitert weiterhin, wenn der Zielhost kein HTTPS anbietet, der Header ändert also nur, welche URL der Browser versucht. HSTS gilt pro Host, das heißt, eine Richtlinie auf Ihrer eigenen Domain bewirkt nichts für ein CDN eines Drittanbieters, das den Header nie gesendet hat. Nach einer Vorlagenänderung leeren Sie den Seiten-Cache und suchen im gerenderten HTML nach dem alten Hostnamen, denn dieselbe URL kann auch über ein Partial, einen Übersetzungsstring oder ein Datenbankfeld kommen.
Folgen Sie auch Weiterleitungen, denn eine Kette, die bei https:// beginnt, kann an einem http://-Ziel landen, und der Browser beurteilt den letzten Sprung. Die -L Form des zweiten Befehls oben gibt diese effektive URL für Sie aus. Wenn der letzte Sprung reines http ist, ist die Referenz weiterhin falsch, obwohl der Link, den Sie bearbeitet haben, in Ordnung aussah.
Die Seite mit Konsole und Netzwerk-Panel bestätigen
Laden Sie mit deaktiviertem Cache neu und gehen Sie den Ablauf erneut durch, einschließlich der Schaltflächen, die Inhalte auf Abruf laden. Ein erster Seitenaufruf verbirgt Lazy-Widgets, Kartenkacheln und Player-Skripte, die erst nach einem Klick erscheinen. Die Konsole sollte keine Mixed-Content-Einträge tragen, und jede Zeile, die Sie angefasst haben, sollte https zeigen. Erfassen Sie Konsole und Anfragezeile, bevor Sie das Ticket schließen, denn dieser Zustand ist nach dem nächsten Deploy schwer zu rekonstruieren.
Wenn die Ressource jemand anderem gehört, senden Sie vier Dinge: die genaue URL, den Anfragetyp, den Konsolentext und die Seite, auf der sie erscheint. Schwärzen Sie Sitzungsbezeichner in allem, was Sie in ein Ticket einfügen. Ein Bericht, der nur sagt, Bilder seien kaputt, gibt dem Eigentümer nichts zum Suchen.
Der Tunnel tut weiter seine eigene Arbeit, während der Fix in der Referenz liegt, die die Anfrage erzeugt hat. Suchen Sie nach dem Deploy noch einmal in Vorlage und Anbieter-Bundle nach dem Hostnamen, und schließen Sie den Fall erst, wenn kein blockierter Mixed-Content-Eintrag in der Konsole übrig bleibt.