VPN forbundet, men blandet indhold stadig blokeret: det skal du rette

Halvdelen af siden vises, ét stylesheet står gråtonet i netværkspanelet, og VPN-klienten rapporterer stadig en sund tunnel. Alle tre observationer er sande på samme tid, fordi browseren bedømte en anmodning, som siden lavede, og tunnelen havde ingen stemme i den bedømmelse. Det, der lukker sagen, er en beslutning og ikke en indstilling: reparér referencen, eskalér den til den, der ejer værten, eller slip afhængigheden. Hver af disse muligheder har en billig test, og at vælge den forkerte koster en supportrunde.

Hvorfor tunnelen ikke kan dække en underressource

Blandet indhold begynder med et HTTPS-dokument, der anmoder om en underressource over almindelig HTTP. Hver URL bedømmes efter sit eget skema, så det overordnede dokuments beskyttelse strækker sig aldrig til en underordnet anmodning. Kryptering, der tilføjes under browseren, ændrer, hvad der går over ledningen, ikke det http://, som markupen bad om.

Nutidige browsere sorterer disse anmodninger i to grupper og behandler dem forskelligt. Scripts, stylesheets, iframes og kald via fetch, XMLHttpRequest eller WebSocket afvises blankt, uden et opgraderingsforsøg først. Billeder, lyd og video skrives om til https:// og anmodes igen, og indlæsningen opgives, når den sikre hentning fejler. En underressource-URL, hvis vært er en bar IP-adresse, er fritaget for opgradering, så et HTTP-billede på en IP-vært forbliver blokeret i stedet for stille at blive repareret. Opdelingen, inklusive den fritagelse på den opgraderbare side, er dokumenteret i Mozillas guide til blandet indhold. Chrome anvender en lignende afvisning på usikre downloads, der startes fra en sikker side, hvilket er grunden til, at et PDF-link kan dø, mens den omkringliggende side ser intakt ud.

Den gråtonede række er altså beviset på, at kontrollen virker, ikke beviset på, at tunnelen har lækket klartekst. Behandl rækken som et fund, der peger på én reference og ikke på hele siden.

Afgør, hvem der ejer den usikre reference

Sortér den anstødelige URL efter, hvor den opstår, før du redigerer noget. Det svar afgør, om du kan udrulle en rettelse i dag, om en leverandør skal udgive en, eller om afhængigheden skal forlade siden. Læs det i kolonnen Initiator i netværkspanelet, fordi markupen på skærmen ofte sammensættes ved kørsel.

Når værten allerede svarer på 443, og kun referencen siger http, er reparationen lokal: ændr referencen, tøm sidecachen og bekræft, at rækken bliver https. En vært, der kun lytter på port 80, kan ikke redigeres til at overholde kravet, så ressourcen flytter, får noget foran, som du kontrollerer, eller forsvinder. En URL, der injiceres af en tagmanager, dukker fortsat op, selv når din egen skabelon er ren, og det tilfælde hører i en sag med den præcise URL og konsollinjen vedhæftet. At fortælle personalet, at de skal tillade usikkert indhold, er ikke en af disse muligheder, fordi det slår kontrollen fra for hvert websted, som den browserprofil besøger.

Reparér referencen i stedet for browserindstillingen

Genindlæs det fejlende flow med netværksloggen bevaret, og filtrer panelet efter den vært, du mistænker. Konsollen nævner URL'en og direktivet, hvilket afgør, om en anmodning blev afvist eller opgraderet, før du rører en skabelon.

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.js

To understøttende kontroller er værd at kende, og ingen af dem erstatter reparationen. En Content-Security-Policy-header med upgrade-insecure-requests får browseren til at omskrive http-underressource-URL'er, før de forlader siden, hvilket fanger gamle referencer, som du endnu ikke har fundet. Den omskrevne anmodning fejler stadig, når målværten ikke udbyder HTTPS, så headeren ændrer kun, hvilken URL browseren forsøger. HSTS virker for hver vært, hvilket betyder, at en politik på dit eget domæne intet gør for et tredjeparts-CDN, der aldrig sendte headeren. Efter en skabelonændring tømmer du sidecachen og søger i den renderede HTML efter det gamle værtsnavn, fordi den samme URL også kan komme via en partial, en oversættelsesstreng eller et databasefelt.

Følg også omdirigeringer, fordi en kæde, der starter ved https://, kan lande på en http://-placering, og browseren bedømmer det sidste hop. Den -L form af den anden kommando ovenfor udskriver den effektive URL for dig. Hvis det sidste hop er ren http, er referencen stadig forkert, selv om linket, du redigerede, så fint ud.

Bekræft siden med konsollen og netværkspanelet

Genindlæs med cachen deaktiveret, og gå flowet igennem igen, inklusive de knapper, der indlæser indhold efter behov. En første sideindlæsning skjuler lazy widgets, kortfliser og afspillerscripts, som først vises efter et klik. Konsollen bør ikke indeholde blandet-indhold-poster, og hver række, du har rørt, bør vise https. Tag et billede af konsollen og anmodningsrækken, før du lukker sagen, fordi den tilstand er svær at genskabe efter den næste udrulning.

Når ressourcen tilhører en anden, skal du sende fire ting: den præcise URL, anmodningstypen, konsolteksten og den side, hvor den vises. Slør sessionsidentifikatorer i alt, hvad du indsætter i en sag. En rapport, der kun siger, at billeder er ødelagte, giver ejeren intet at søge efter.

Tunnelen gør fortsat sit eget arbejde, mens rettelsen ligger i den reference, der skabte anmodningen. Søg i skabelonen og leverandørbundlen efter værtsnavnet én gang mere efter udrulningen, og luk først sagen, når ingen blokeret blandet-indhold-post er tilbage i konsollen.