VPN povezan, a mešana vsebina je še vedno blokirana: kaj popraviti
Razvrstite blokirani URL po tem, kdo ga je ustvaril, popravite sklic ali ga predajte lastniku gostitelja, nato pa popravek potrdite v konzoli brskalnika.
Polovica strani se izriše, ena slogovna datoteka ostane siva v plošči Omrežje, odjemalec VPN pa še vedno poroča o zdravem tunelu. Vsa tri opažanja veljajo hkrati, ker je brskalnik presodil zahtevo, ki jo je ustvarila stran, tunel pa pri tej presoji ni imel besede. Zadevo zapre odločitev, ne nastavitev: popraviti sklic, ga poslati lastniku gostitelja ali opustiti odvisnost. Vsaka od teh možnosti ima poceni preizkus, izbira napačne pa stane en cikel podpore.
Zakaj tunel ne more pokriti podrejenega vira
Mešana vsebina se začne z dokumentom HTTPS, ki zahteva podrejeni vir po navadnem HTTP. Vsak URL se presoja po lastni shemi, zato se zaščita nadrejenega dokumenta nikoli ne razširi na podrejeno zahtevo. Šifriranje, dodano pod brskalnikom, spremeni, kaj gre po žici, ne pa http://, ki ga je zahtevala oznaka.
Sodobni brskalniki te zahteve razdelijo v dve skupini in z njimi ravnajo različno. Skripti, slogovne datoteke, iframe-i in klici prek fetch, XMLHttpRequest ali WebSocket so zavrnjeni takoj, brez predhodnega poskusa nadgradnje. Slike, zvok in video se prepišejo v https:// in zahtevajo znova, nalaganje pa se opusti, ko to varno pridobivanje spodleti. URL podrejenega vira, katerega gostitelj je goli naslov IP, je izvzet iz nadgradnje, zato slika HTTP na gostitelju IP ostane blokirana, namesto da bi bila tiho popravljena. Razdelitev, vključno s to izjemo na nadgradljivi strani, je dokumentirana v vodniku Mozille o mešani vsebini. Chrome uporabi podobno zavrnitev za nezanesljive prenose, začete z varne strani, zato lahko povezava do PDF umre, medtem ko je stran okoli nje videti nedotaknjena.
Siva vrstica je torej dokaz, da kontrola deluje, ne dokaz, da je tunel spustil čisto besedilo. Obravnavajte vrstico kot ugotovitev, ki kaže na en sklic in ne na celo stran.
Ugotovite, komu pripada nezanesljivi sklic
Razvrstite sporni URL po tem, kje nastane, preden kar koli spremenite. Ta odgovor odloči, ali lahko popravek objavite danes, ali ga mora izdati dobavitelj, ali mora odvisnost zapustiti stran. Preberite ga v stolpcu Initiator v plošči Omrežje, ker je oznaka na zaslonu pogosto sestavljena ob izvajanju.
| Od kod prihaja URL | Kdo ga lahko popravi | Prvi korak |
|---|---|---|
| Trdo kodiran v predlogi ali delu, ki ga uvajate | Vi | Zamenjajte ga z obliko https:// in nato izpraznite predpomnilnik |
| Vstavljeno s strani upravitelja oznak ali paketa dobavitelja | Dobavitelj, z vašo prijavo | Pošljite točen URL, vrsto zahteve in vrstico konzole |
| Streženo samo na vratih 80 brez poslušalca TLS | Lastnik gostitelja | Zaprosite za TLS, pred njim postavite nekaj, kar nadzorujete, ali ga opustite |
Ko gostitelj že odgovarja na 443 in samo sklic pravi http, je popravek lokalen: spremenite sklic, izpraznite predpomnilnik strani in potrdite, da se vrstica spremeni v https. Gostitelja, ki posluša samo na vratih 80, ni mogoče spraviti v skladnost z urejanjem, zato se vir premakne, pred njim se postavi nekaj, kar nadzorujete, ali izgine. URL, ki ga vstavi upravitelj oznak, se še vedno pojavlja, tudi ko je vaša predloga čista, in ta primer sodi v prijavo s točnim URL-jem in vrstico konzole v prilogi. Reči osebju, naj dovoli nezanesljivo vsebino, ni nobena od teh možnosti, ker izklopi preverjanje za vsako spletno mesto, ki ga obišče ta profil brskalnika.
Popravite sklic, ne nastavitve brskalnika
Ponovno naložite tok, ki spodleti, z ohranjenim omrežnim dnevnikom in filtrirajte ploščo po gostitelju, ki ga sumite. Konzola navede URL in direktivo, kar razreši, ali je bila zahteva zavrnjena ali nadgrajena, preden se dotaknete predloge.
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.jsDve podporni kontroli sta vredni poznavanja in nobena ne nadomesti popravka. Glava Content-Security-Policy z upgrade-insecure-requests povzroči, da brskalnik prepiše URL-je podrejenih virov http, preden zapustijo stran, kar ujame stare sklice, ki jih še niste našli. Prepisana zahteva še vedno spodleti, ko ciljni gostitelj ne streže HTTPS, zato glava spremeni le, kateri URL brskalnik poskusi. HSTS velja za posameznega gostitelja, kar pomeni, da pravilo na vaši lastni domeni ne naredi ničesar za CDN tretje strani, ki glave ni nikoli poslal. Po spremembi predloge izpraznite predpomnilnik strani in v izrisanem HTML poiščite staro ime gostitelja, ker lahko isti URL pride tudi prek dela, prevodnega niza ali polja zbirke podatkov.
Sledite tudi preusmeritvam, ker lahko veriga, ki se začne na https://, pristane na lokaciji http:// in brskalnik presodi zadnji skok. Oblika -L drugega ukaza zgoraj natisne ta dejanski URL namesto vas. Če je zadnji skok čisti http, je sklic še vedno napačen, tudi če je bila povezava, ki ste jo uredili, videti v redu.
Potrdite stran s konzolo in ploščo omrežja
Ponovno naložite z onemogočenim predpomnilnikom in znova prehodite tok, vključno z gumbi, ki nalagajo vsebino na zahtevo. Prvo nalaganje strani skrije lene pripomočke, ploščice zemljevida in skripte predvajalnika, ki se pojavijo šele po kliku. Konzola ne bi smela vsebovati vnosov o mešani vsebini in vsaka vrstica, ki ste se je dotaknili, bi morala kazati https. Zajemite konzolo in vrstico zahteve, preden zaprete prijavo, ker je to stanje po naslednji objavi težko obnoviti.
Ko vir pripada nekomu drugemu, pošljite štiri stvari: točen URL, vrsto zahteve, besedilo konzole in stran, kjer se pojavi. Skrijte identifikatorje seje v vsem, kar prilepite v prijavo. Poročilo, ki samo pravi, da so slike zlomljene, lastniku ne da ničesar za iskanje.
Tunel še naprej opravlja svoje delo, medtem ko popravek leži v sklicu, ki je ustvaril zahtevo. Po objavi še enkrat poiščite ime gostitelja v predlogi in paketu dobavitelja ter zadevo zaprite šele, ko v konzoli ne ostane noben blokiran vnos o mešani vsebini.