VPN tersambung tetapi konten campuran masih diblokir: apa yang perlu diperbaiki

Separuh halaman dirender, satu lembar gaya tampak abu-abu di panel Jaringan, dan klien VPN masih melaporkan terowongan yang sehat. Ketiga pengamatan itu benar sekaligus, karena browser menilai permintaan yang dibuat halaman dan terowongan tidak punya suara dalam penilaian itu. Yang menutup kasus adalah keputusan, bukan pengaturan: memperbaiki referensi, mengeskalasinya ke pemilik host, atau melepas ketergantungan itu. Setiap opsi punya uji murah, dan memilih yang salah menghabiskan satu siklus dukungan.

Mengapa terowongan tidak bisa menutupi subresource

Konten campuran dimulai dengan dokumen HTTPS yang meminta subresource lewat HTTP biasa. Setiap URL dinilai menurut skemanya sendiri, jadi perlindungan dokumen induk tidak pernah meluas ke permintaan anak. Enkripsi yang ditambahkan di bawah browser mengubah apa yang melintas di kabel, bukan http:// yang diminta markup.

Browser saat ini membagi permintaan ini ke dalam dua kelompok dan memperlakukannya berbeda. Skrip, lembar gaya, iframe, dan panggilan lewat fetch, XMLHttpRequest, atau WebSocket ditolak mentah-mentah, tanpa upaya peningkatan lebih dulu. Gambar, audio, dan video ditulis ulang ke https:// dan diminta lagi, dan pemuatan dibatalkan ketika pengambilan aman itu gagal. URL subresource yang host-nya berupa alamat IP telanjang dikecualikan dari peningkatan, sehingga gambar HTTP pada host IP tetap diblokir alih-alih diperbaiki diam-diam. Pembagian ini, termasuk pengecualian di sisi yang dapat ditingkatkan, didokumentasikan dalam panduan konten campuran Mozilla. Chrome menerapkan penolakan serupa pada unduhan tidak aman yang dimulai dari halaman aman, karena itu tautan PDF bisa mati sementara halaman di sekitarnya tampak utuh.

Baris abu-abu itu karena itu adalah bukti kontrol bekerja, bukan bukti terowongan membocorkan teks polos. Perlakukan baris itu sebagai temuan yang menunjuk satu referensi, bukan seluruh halaman.

Tentukan siapa pemilik referensi tidak aman itu

Urutkan URL bermasalah menurut tempat ia dihasilkan sebelum mengubah apa pun. Jawaban itu menentukan apakah Anda bisa merilis perbaikan hari ini, apakah vendor harus merilisnya, atau apakah ketergantungan itu harus meninggalkan halaman. Bacalah dari kolom Initiator di panel Jaringan, karena markup di layar sering dirakit saat runtime.

Ketika host sudah menjawab pada 443 dan hanya referensinya yang mengatakan http, perbaikannya lokal: ubah referensi, kosongkan cache halaman, dan pastikan barisnya berubah menjadi https. Host yang hanya mendengarkan pada port 80 tidak bisa dibuat patuh lewat penyuntingan, jadi sumber daya itu pindah, diberi sesuatu yang Anda kendalikan di depannya, atau hilang. URL yang disuntikkan pengelola tag tetap muncul bahkan ketika templat Anda sendiri bersih, dan kasus itu masuk ke tiket dengan URL persis dan baris konsol terlampir. Menyuruh staf mengizinkan konten tidak aman bukan salah satu opsi ini, karena itu mematikan pemeriksaan bagi setiap situs yang dikunjungi profil browser tersebut.

Perbaiki referensinya, bukan pengaturan browser

Muat ulang alur yang gagal dengan log jaringan dipertahankan dan saring panel menurut host yang Anda curigai. Konsol menyebut URL dan direktifnya, yang memutuskan apakah permintaan ditolak atau ditingkatkan sebelum Anda menyentuh templat.

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

Dua kontrol pendukung layak diketahui, dan keduanya tidak menggantikan perbaikan. Header Content-Security-Policy dengan upgrade-insecure-requests membuat browser menulis ulang URL subresource http sebelum meninggalkan halaman, yang menangkap referensi lama yang belum Anda temukan. Permintaan yang ditulis ulang tetap gagal ketika host tujuan tidak menyajikan HTTPS, jadi header hanya mengubah URL mana yang dicoba browser. HSTS berlaku per host, yang berarti kebijakan di domain Anda sendiri tidak melakukan apa pun untuk CDN pihak ketiga yang tidak pernah mengirim header itu. Setelah mengubah templat, kosongkan cache halaman dan cari nama host lama di HTML yang dirender, karena URL yang sama juga bisa datang lewat parsial, string terjemahan, atau bidang basis data.

Ikuti juga pengalihan, karena rantai yang dimulai pada https:// bisa mendarat di lokasi http:// dan browser menilai lompatan terakhir. Bentuk -L perintah kedua di atas mencetak URL efektif itu untuk Anda. Jika lompatan terakhir adalah http murni, referensinya tetap salah meskipun tautan yang Anda sunting tampak baik.

Konfirmasi halaman dengan konsol dan panel jaringan

Muat ulang dengan cache dimatikan dan jalani alurnya lagi, termasuk tombol yang memuat konten sesuai permintaan. Pemuatan pertama halaman menyembunyikan widget lambat, ubin peta, dan skrip pemutar yang baru muncul setelah klik. Konsol seharusnya tidak memuat entri konten campuran dan setiap baris yang Anda sentuh seharusnya menampilkan https. Tangkap konsol dan baris permintaan sebelum menutup tiket, karena keadaan itu sulit direkonstruksi setelah penerapan berikutnya.

Ketika sumber daya itu milik orang lain, kirim empat hal: URL persis, jenis permintaan, teks konsol, dan halaman tempat ia muncul. Sembunyikan pengenal sesi dari semua yang Anda tempelkan ke tiket. Laporan yang hanya mengatakan gambar rusak tidak memberi pemiliknya apa pun untuk dicari.

Terowongan tetap menjalankan tugasnya sendiri sementara perbaikannya berada di referensi yang menghasilkan permintaan itu. Setelah penerapan, cari nama host sekali lagi di templat dan bundel vendor, dan tutup kasus hanya ketika tidak ada entri konten campuran yang diblokir tersisa di konsol.