VPN on ühendatud, kuid segasisu on endiselt blokeeritud: mida parandada
Sorteerige blokeeritud URL selle järgi, kes selle lõi, parandage viide või andke see hosti omanikule, ja kinnitage parandus seejärel brauseri konsoolis.
Pool lehekülge renderdatakse, üks stiilileht seisab võrgu paneelil hallina ja VPN-klient teatab endiselt tervest tunnelist. Kõik kolm tähelepanekut on korraga tõesed, sest brauser hindas lehekülje tehtud päringut ja tunnelil ei olnud selles hinnangus sõnaõigust. Asja sulgeb otsus, mitte säte: parandage viide, eskaleerige see hosti omanikule või loobuge sõltuvusest. Igal neist valikutest on odav test ja vale valimine maksab ühe tugitsükli.
Miks tunnel ei saa alamressurssi katta
Segasisu algab HTTPS-dokumendist, mis küsib alamressurssi lihtsa HTTP kaudu. Iga URL-i hinnatakse selle enda skeemi järgi, seega ülemdokumendi kaitse ei laiene kunagi tütarpäringule. Brauseri alla lisatud krüpteerimine muudab seda, mis liigub mööda juhet, mitte http://, mida märgistus küsis.
Praegused brauserid jagavad need päringud kahte rühma ja kohtlevad neid erinevalt. Skriptid, stiililehed, iframe'id ja kutsed fetchi, XMLHttpRequesti või WebSocketi kaudu lükatakse kohe tagasi, ilma eelneva uuendamiskatseta. Pilte, heli ja videot kirjutatakse ümber https:// kujule ja küsitakse uuesti, ning laadimine katkestatakse, kui see turvaline hankimine ebaõnnestub. Alamressursi URL, mille host on paljas IP-aadress, on uuendamisest vabastatud, seega HTTP-pilt IP-hostil jääb blokeerituks, selle asemel et vaikselt parandatud saada. See jagunemine, sealhulgas nimetatud erand uuendataval poolel, on dokumenteeritud Mozilla segasisu juhendis. Chrome rakendab sarnast keeldumist turvaliselt lehelt algatatud ebaturvalistele allalaadimistele, mistõttu PDF-link võib surra, samal ajal kui ümbritsev lehekülg näib terve.
Hall rida on seega tõestus, et kontroll töötab, mitte tõestus, et tunnel lasi läbi avateksti. Käsitlege rida leiuna, mis osutab ühele viitele, mitte kogu lehele.
Tehke kindlaks, kellele ebaturvaline viide kuulub
Sorteerige probleemne URL selle järgi, kus see tekib, enne kui midagi muudate. See vastus otsustab, kas saate täna paranduse välja anda, kas tarnija peab selle avaldama või kas sõltuvus peab lehelt lahkuma. Lugege seda võrgu paneeli veerus Initiator, sest ekraanil olev märgistus pannakse sageli kokku käitusajal.
| Kust URL pärineb | Kes saab selle parandada | Esimene samm |
|---|---|---|
| Kõvasti kodeeritud mallis või osas, mille te juurutate | Teie | Asendage see https:// kujuga ja tühjendage seejärel vahemälu |
| Sisestatud sildihalduri või tarnija paketi poolt | Tarnija, teie piletiga | Saatke täpne URL, päringu tüüp ja konsooli rida |
| Pakutakse ainult pordil 80 ilma TLS-kuulajata | Hosti omanik | Küsige TLS-i, asetage selle ette midagi, mida te kontrollite, või loobuge sellest |
Kui host vastab juba pordil 443 ja ainult viide ütleb http, on parandus kohalik: muutke viidet, tühjendage lehe vahemälu ja kinnitage, et rida muutub https-iks. Hosti, mis kuulab ainult pordil 80, ei saa redigeerimisega vastavusse viia, seega ressurss kolib, selle ette pannakse midagi, mida te kontrollite, või see kaob. Sildihalduri sisestatud URL ilmub jätkuvalt ka siis, kui teie enda mall on puhas, ja see juhtum kuulub pileti alla, millele on lisatud täpne URL ja konsooli rida. Personalile öelda, et lubataks ebaturvalist sisu, ei ole ükski neist valikutest, sest see lülitab kontrolli välja igal saidil, mida see brauseri profiil külastab.
Parandage viide, mitte brauseri säte
Laadige ebaõnnestuv voog uuesti, hoides võrgulogi alles, ja filtreerige paneeli kahtlase hosti järgi. Konsool nimetab URL-i ja direktiivi, mis otsustab, kas päring lükati tagasi või uuendati, enne kui malle puudutate.
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.jsKaks toetavat kontrolli on väärt teadmist ja kumbki ei asenda parandust. Content-Security-Policy päis koos upgrade-insecure-requests paneb brauseri http alamressursside URL-id ümber kirjutama enne, kui need lehelt lahkuvad, mis püüab vanad viited, mida te veel leidnud pole. Ümber kirjutatud päring ebaõnnestub endiselt, kui sihthost ei teeninda HTTPS-i, seega päis muudab ainult seda, millist URL-i brauser proovib. HSTS kehtib hosti kohta, mis tähendab, et poliitika teie enda domeenil ei tee midagi kolmanda osapoole CDN-ile, mis ei saatnud päist kunagi. Pärast malli muutmist tühjendage lehe vahemälu ja otsige renderdatud HTML-ist vana hostinime, sest sama URL võib tulla ka osa, tõlke-stringi või andmebaasivälja kaudu.
Jälgige ka ümbersuunamisi, sest ahel, mis algab https://-ga, võib maanduda http:// asukohas ja brauser hindab viimast hüpet. Teise käsu -L kuju trükib selle tegeliku URL-i teie eest välja. Kui viimane hüpe on puhas http, on viide endiselt vale, kuigi redigeeritud link nägi hea välja.
Kinnitage lehekülg konsooli ja võrgu paneeliga
Laadige uuesti väljalülitatud vahemäluga ja käige voog uuesti läbi, sealhulgas nupud, mis laadivad sisu nõudmisel. Lehe esimene laadimine peidab laisad vidinad, kaardipaani ja pleieri skriptid, mis ilmuvad alles pärast klõpsu. Konsoolis ei tohiks olla segasisu kirjeid ja iga puudutatud rida peaks näitama https-i. Jäädvustage konsool ja päringu rida enne pileti sulgemist, sest seda olekut on pärast järgmist juurutust raske taastada.
Kui ressurss kuulub kellelegi teisele, saatke neli asja: täpne URL, päringu tüüp, konsooli tekst ja lehekülg, kus see ilmub. Peitke seansi identifikaatorid kõiges, mille piletile kleepite. Aruanne, mis ainult ütleb, et pildid on katki, ei anna omanikule midagi otsida.
Tunnel teeb endiselt oma tööd, samal ajal kui parandus asub viites, mis päringu lõi. Pärast juurutust otsige hostinime veel kord mallist ja tarnija paketist ning sulgege asi alles siis, kui konsooli ei jää ühtki blokeeritud segasisu kirjet.