Gemengde inhoud achter een VPN: repareer de bron, niet de tunnel

Een HTTPS-pagina die scripts via HTTP laadt, doet twee verzoeken met twee verschillende beschermingsniveaus, en het hangslot beschrijft alleen het eerste. Een tunnel verandert dat niet, want hij beschermt de transportlaag en niet het eigen schema van de bron. De browser vertelt je al welk verzoek is mislukt, als je de console leest in plaats van de adresbalk. Drie controles brengen je van een half werkende pagina naar een echte reparatie.

Lees het verzoek, niet de adresbalk

Een document dat via HTTPS is opgehaald, kan via gewone HTTP verwijzen naar een script, stylesheet, lettertype of frame. Die verwijzing is een apart verzoek, en daar klaagt de browser over. De bescherming van het hoofddocument reist niet terug naar binnen, en de tunnel die beide stromen draagt, verandert geen van beide schema's. De pagina kan dus tegelijk echt veilig en echt kapot zijn.

De bron simpelweg een ingesloten bestand noemen maakt het vervangen ervan niet ongevaarlijk.

Als onveilige scriptinhoud onderweg kan worden gewijzigd en daarna uitgevoerd, kan die het gedrag van de pagina veranderen, wat een groter probleem is dan een cosmetisch defect. Afbeeldingen dragen een kleiner maar reëel risico wanneer ze onderweg worden gewijzigd. Het hangslot liegt over niets. Het beantwoordt een smallere vraag dan degene die je het stelde.

Weet welke bronnen worden geblokkeerd en welke worden opgewaardeerd

Browsers behandelen niet elk type bron hetzelfde. de richtlijnen over gemengde inhoud scheiden verzoeken die naar HTTPS worden opgewaardeerd van verzoeken die volledig worden geblokkeerd, waarbij scripts, stylesheets en programmatische verzoeken aan de geblokkeerde kant staan, terwijl afbeeldingen en media in plaats daarvan kunnen worden opgewaardeerd of gemarkeerd.

Dat verschil verklaart de verwarrende rapporten. Een pagina met een geblokkeerd script verliest een functie volledig, terwijl een pagina met een opgewaardeerde afbeelding er goed uitziet en stilletjes zijn verzoek heeft gewijzigd. De gedocumenteerde categorieën hebben ook uitzonderingen, dus ga er niet van uit dat elke URL van een bepaald type met succes wordt opgewaardeerd. Lees wat de console over het specifieke verzoek zegt in plaats van te redeneren vanuit een bestandsextensie.

Een geblokkeerde widget is geen bewijs dat de tunnel heeft gefaald. Het is bewijs dat de browser zijn werk heeft gedaan.

Repareer de verwijzing bij de bron

Voor een eigenaar van een site hoort de reparatie waar de onveilige URL is geschreven: een sjabloon, een stylesheet, een script dat URL's samenstelt, of een component van een derde partij. Het zichtbare pagina-adres wijzigen laat dat allemaal ongemoeid. Zoek de bron af naar de host en repareer elke verwijzing, niet alleen degene die de console toevallig noemde.

Bevestig daarna dat de bron werkelijk via HTTPS met geldige identiteit wordt geleverd, want een schemawissel kan geen dienst tevoorschijn toveren die daar nooit is gepubliceerd.

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

Volg ook doorverwijzingen, want een verwijzing die met HTTPS begint, kan alsnog op een leverpad met platte tekst belanden. Waar een afhankelijkheid simpelweg geen veilige levering heeft, verwijder of vervang je hem via het normale wijzigingsproces in plaats van een omweg te leveren. Voor een gebruiker laat je de browserbeschermingen aan staan en meld je de URL van de bron, het type en het consolebericht aan de eigenaar van de site. Verspreid nooit instructies die medewerkers vragen om onveilige inhoud voor één pagina toe te staan, want die uitzondering overleeft het incident dat haar veroorzaakte.

Test de pagina opnieuw zoals gebruikers haar aanraken

Oefen de handelingen die bronnen op verzoek laden, niet alleen het eerste document. Pagina's halen na een knopdruk extra code, gegevens en downloads op, en die verzoeken zijn vaak de onveilige. Bevestig de specifieke verzoeken en het zichtbare gedrag terwijl de bescherming nog aan staat. Een test die met een versoepeld browserprofiel begint, kan je niet laten zien wat een normale gebruiker ziet.

De tunnel heeft nog steeds zijn eigen taak, en die taak is netwerktoegang en niet pagina-integriteit.

Zodra het verkeer het eindpunt van de tunnel verlaat, heeft elke resterende HTTP-ophaling niets gewonnen van de transportlaag. Repareer het bronpad en houd de handhaving in de browser op zijn plaats. Nog een transportlaag behandelen als reparatie van een onveilige afhankelijkheid is hoe een team uiteindelijk een helpdeskscript krijgt dat de controle uitschakelt die correct werkte.