VPN ansluten men blandat innehåll blockeras fortfarande: det här ska du åtgärda

Halva sidan renderas, en stilmall står gråad i nätverkspanelen, och VPN-klienten rapporterar fortfarande en frisk tunnel. Alla tre observationerna är sanna samtidigt, eftersom webbläsaren bedömde en begäran som sidan gjorde, och tunneln hade ingen röst i den bedömningen. Det som stänger ärendet är ett beslut och inte en inställning: reparera referensen, eskalera den till den som äger värden, eller släpp beroendet. Var och en av de vägarna har ett billigt test, och att välja fel kostar en supportrunda.

Varför tunneln inte kan täcka en underresurs

Blandat innehåll börjar med ett HTTPS-dokument som begär en underresurs över vanlig HTTP. Varje webbadress bedöms efter sitt eget schema, så det överordnade dokumentets skydd sträcker sig aldrig till en underordnad begäran. Kryptering som läggs till under webbläsaren ändrar vad som går över ledningen, inte det http:// som markeringen bad om.

Dagens webbläsare sorterar dessa begäranden i två grupper och behandlar dem olika. Skript, stilmallar, iframes och anrop via fetch, XMLHttpRequest eller WebSocket avvisas direkt, utan ett uppgraderingsförsök först. Bilder, ljud och video skrivs om till https:// och begärs igen, och inläsningen avbryts när den säkra hämtningen misslyckas. En underresursadress vars värd är en bar IP-adress undantas från uppgradering, så en HTTP-bild på en IP-värd förblir blockerad i stället för att tyst repareras. Uppdelningen, inklusive undantaget på den uppgraderingsbara sidan, finns dokumenterad i Mozillas guide om blandat innehåll. Chrome tillämpar en liknande vägran på osäkra nedladdningar som startas från en säker sida, vilket är varför en PDF-länk kan dö medan den omgivande sidan ser intakt ut.

Den gråade raden är alltså beviset på att kontrollen fungerar, inte beviset på att tunneln läckt klartext. Behandla raden som ett fynd som pekar på en enda referens och inte på hela sidan.

Avgör vem som äger den osäkra referensen

Sortera den anstötliga adressen efter var den skapas innan du redigerar något. Det svaret avgör om du kan släppa en åtgärd i dag, om en leverantör måste släppa en, eller om beroendet måste lämna sidan. Läs det i kolumnen Initiator i nätverkspanelen, eftersom markeringen på skärmen ofta sätts ihop vid körning.

När värden redan svarar på 443 och bara referensen säger http, är reparationen lokal: ändra referensen, töm sidcachen och bekräfta att raden blir https. En värd som bara lyssnar på port 80 kan inte redigeras till att följa kravet, så resursen flyttar, får något framför sig som du kontrollerar, eller försvinner. En adress som injiceras av en tagghanterare dyker upp ändå, även när din egen mall är ren, och det fallet hör hemma i ett ärende med den exakta adressen och konsolraden bifogad. Att säga till personalen att de ska tillåta osäkert innehåll är inte något av dessa alternativ, eftersom det stänger av kontrollen för varje webbplats som den webbläsarprofilen besöker.

Reparera referensen i stället för webbläsarinställningen

Ladda om det misslyckade flödet med nätverksloggen bevarad och filtrera panelen på den värd du misstänker. Konsolen namnger adressen och direktivet, vilket avgör om en begäran avvisades eller uppgraderades innan du rör en mall.

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

Två stödjande kontroller är värda att känna till, och ingen av dem ersätter reparationen. En Content-Security-Policy-rubrik med upgrade-insecure-requests får webbläsaren att skriva om http-underresursadresser innan de lämnar sidan, vilket fångar gamla referenser som du ännu inte hittat. Den omskrivna begäran misslyckas fortfarande när målvärden inte erbjuder HTTPS, så rubriken ändrar bara vilken adress webbläsaren försöker med. HSTS gäller per värd, vilket betyder att en policy på din egen domän inte gör något för ett CDN från tredje part som aldrig skickade rubriken. Efter en malländring tömmer du sidcachen och söker i den renderade HTML-koden efter det gamla värdnamnet, eftersom samma adress också kan komma in via en del, en översättningssträng eller ett databasfält.

Följ även omdirigeringar, eftersom en kedja som börjar på https:// kan landa på en http://-plats och webbläsaren bedömer det sista hoppet. Den -L formen av det andra kommandot ovan skriver ut den effektiva adressen åt dig. Om det sista hoppet är ren http är referensen fortfarande fel, även om länken du redigerade såg bra ut.

Bekräfta sidan med konsolen och nätverkspanelen

Ladda om med cachen avstängd och gå igenom flödet igen, inklusive de knappar som laddar innehåll vid behov. En första sidladdning döljer lata widgetar, kartbrickor och spelarskript som först dyker upp efter ett klick. Konsolen bör inte innehålla några poster om blandat innehåll, och varje rad du rörde bör visa https. Fånga konsolen och begärans rad innan du stänger ärendet, eftersom det tillståndet är svårt att återskapa efter nästa driftsättning.

När resursen tillhör någon annan skickar du fyra saker: den exakta adressen, begärantypen, konsoltexten och sidan där den visas. Maskera sessionsidentifierare i allt du klistrar in i ett ärende. En rapport som bara säger att bilder är trasiga ger ägaren inget att söka efter.

Tunneln sköter fortfarande sitt eget arbete medan åtgärden ligger i den referens som skapade begäran. Sök i mallen och leverantörspaketet efter värdnamnet en gång till efter driftsättningen, och stäng ärendet först när ingen blockerad post om blandat innehåll finns kvar i konsolen.