Pada 4 Agustus 2026, peneliti Mysk menerbitkan analisis tentang tiga mekanisme WebKit yang mengirimkan lalu lintas melewati proxy yang telah diatur — langsung dari perangkat. Semua browser iOS dengan mode proxy, termasuk browser Tor, serta layanan Apple sendiri — iCloud Private Relay, terkena dampak. Proxy diaktifkan, antarmuka menunjukkan negara lain, tetapi situs tersebut dapat melihat IP asli Anda dan resolver DNS rumah Anda.
Ini bukan kerentanan eksotis untuk para paranoid. Ini adalah demonstrasi nyata dari aturan arsitektur yang harus dipahami oleh semua orang yang bekerja melalui proxy: proxy di tingkat aplikasi hanya melindungi lalu lintas yang melewati tumpukan jaringan aplikasi tersebut. Segala sesuatu yang dihasilkan oleh sistem operasi atau layanan sistem tertentu akan melewati.
Apa yang sebenarnya bocor
Penelitian dimulai dari situasi sehari-hari: pengguna browser proxy Psylo mengeluh kepada pengembang tentang kebocoran DNS. Analisis keluhan tersebut mengungkap tiga saluran kebocoran independen — semuanya berasal dari WebKit itu sendiri, bukan dari aplikasi tertentu.
1. DNS prefetching — yang paling sederhana dan paling tidak menyenangkan
Mekanisme: tag <link rel="dns-prefetch"> meminta browser untuk terlebih dahulu menyelesaikan nama host, untuk mempercepat pemuatan di masa depan. Masalahnya adalah bahwa WebKit di iOS menyelesaikan nama-nama tersebut melalui jalur DNS biasa perangkat, bukan melalui proxy.
Safari desktop telah mendukung dns-prefetch sejak Safari 5, tetapi iOS mengabaikan tag ini — hingga iOS 26.0 (September 2025). Saat itu, WebKit mengaktifkannya sebagai bagian dari perubahan yang sama yang menghapus DNS prefetching spekulatif yang tidak jelas (bug 285744).
Bagaimana ini dieksploitasi: halaman menyematkan nama host unik untuk setiap pengunjung dalam tag tersebut, dan kemudian hanya melihat bagaimana permintaan datang ke server DNS otoritatifnya sendiri — dari alamat jaringan pengunjung yang sebenarnya. Tidak ada JavaScript, tidak ada interaksi dengan pengguna. Cukup buka halaman.
2. Permintaan Asal Terkait WebAuthn — kebocoran melalui paspor dari passkey
Saluran ini muncul sejak iOS 18.0. Ketika situs meminta kredensial WebAuthn (yaitu passkey), sistem memeriksa file https://<rpId>/.well-known/webauthn — untuk memastikan bahwa domain benar-benar terkait dengan pihak yang mengandalkan yang ditentukan.
Detail kunci: permintaan verifikasi ini tidak berasal dari tumpukan jaringan browser. Ini dilakukan oleh layanan kredensial sistem operasi, yang sendiri mengirimkan permintaan HTTPS langsung dari perangkat. Proxy yang diatur di dalam browser tidak mengetahuinya (bug 268426).
Artinya, cukup bagi halaman untuk memulai permintaan passkey — dan server penyerang mendapatkan koneksi dari IP asli Anda.
3. WebTransport — QUIC langsung dari perangkat
Saluran terbaru. Panggilan new WebTransport(url) membuka koneksi QUIC langsung dari perangkat, melewati konfigurasi proxy. WebTransport di WebKit telah lama dinonaktifkan dan secara publik diperkenalkan di iOS 26.4 pada Maret 2026 (bug 260810 dan 303453).
Siapa yang terpengaruh
Apple mengharuskan semua browser di iPhone menggunakan WebKit. Oleh karena itu, setiap browser iOS yang bergantung pada proxy-API WebKit akan terpengaruh — termasuk semua versi iOS dari browser Tor dan Psylo itu sendiri, yang memulai penyelidikan. Ditambah Safari dan iCloud Private Relay.
Apa yang tidak terpengaruh — aplikasi VPN. Mereka beroperasi di tingkat sistem dan membungkus seluruh lalu lintas perangkat secara keseluruhan, termasuk yang dihasilkan oleh layanan sistem. Inilah perbedaan utamanya: terowongan sistem tidak memiliki "melewati". Pengecualian terpisah — Onion Browser di tingkat keamanan Silver dengan Mode Lockdown yang diaktifkan: ia kebal terhadap kebocoran melalui WebTransport.
Dari sisi pengembang, reaksi sudah ada. Di Psylo 1.3.1, semua tiga saluran ditutup: aplikasi memblokir petunjuk dns-prefetch (halaman tidak dapat lagi memaksa perangkat untuk menyelesaikan nama yang dikendalikan oleh penyerang), dan WebTransport serta WebAuthn dinonaktifkan secara default — mereka dapat diaktifkan secara selektif, dengan saklar terpisah. Apple, pada saat publikasi, diharapkan akan memperbaiki masalah ini dalam pembaruan mendatang; perusahaan tidak memberikan tenggat waktu tertentu.
Mengapa ini muncul hanya sekarang
Kronologi di sini sangat menunjukkan, dan perlu dibahas secara terpisah — ini menjelaskan mengapa masalah ini tidak terdeteksi sebelumnya.
- September 2024, iOS 18.0 — muncul mekanisme Permintaan Asal Terkait WebAuthn. Saluran kebocoran telah ada selama hampir dua tahun dan selama ini tidak dibahas oleh siapa pun: verifikasi domain untuk passkey terlihat sebagai elemen keamanan, bukan sebagai cara untuk mengungkap alamat.
- September 2025, iOS 26.0 — WebKit mengaktifkan dukungan dns-prefetch di perangkat seluler. Secara formal ini adalah optimasi kecepatan pemuatan; secara faktual — halaman mendapatkan kemampuan untuk memaksa perangkat untuk mengakses nama DNS sembarangan melewati proxy.
- Maret 2026, iOS 26.4 — WebTransport diaktifkan secara publik. Saluran ketiga.
- Agustus 2026 — keluhan dari satu pengguna tentang kebocoran DNS mengarah pada analisis yang mengungkap semua tiga sekaligus.
Kesamaan umum: tidak ada dari fungsi ini yang dirancang sebagai saluran de-anonimisasi. Ketiga-tiganya adalah kemampuan biasa dari platform: percepatan resolusi, verifikasi passkey, transportasi modern. Mereka menjadi kebocoran hanya ketika dikombinasikan dengan mode proxy tingkat aplikasi, dan itulah mengapa tidak ada yang memeriksa mereka dalam kapasitas ini selama bertahun-tahun.
Kesimpulan untuk praktiknya sederhana dan tidak menyenangkan: ketiadaan berita tentang kebocoran tidak berarti tidak ada kebocoran. Anda harus memeriksa sendiri dan secara teratur, bukan menunggu seseorang menerbitkan analisis.
Bagaimana cara memeriksa diri sendiri
Para peneliti telah menyediakan stand publik — leaks.psylo.app. Ini memeriksa tiga hal: lalu lintas HTTPS biasa (IP apa dan resolver DNS apa yang dilihat server), WebTransport, dan kombinasi WebAuthn + dns-prefetch. Buka dengan proxy diaktifkan dan bandingkan hasilnya dengan alamat yang Anda harapkan untuk dilihat.
Secara terpisah, penting untuk memeriksa kebersihan dasar — apakah IP, DNS, dan alamat WebRTC Anda cocok dalam kombinasi kerja Anda. Jika sebelumnya Anda tidak melakukannya secara sistematis, mulailah dengan analisis kami: cara memeriksa proxy untuk kebocoran DNS.
Kesimpulan praktis: lapisan itu penting
Kisah tentang WebKit adalah kasus khusus dari aturan umum yang perlu diingat saat bekerja melalui proxy, di platform mana pun.
- Proxy di browser ≠ proxy di perangkat. Pengaturan di dalam aplikasi hanya mencakup lalu lintas yang dikirimkan oleh aplikasi itu sendiri. Layanan sistem, proses latar belakang, pembaruan, koneksi push, dan, seperti yang telah terbukti, layanan passkey yang terintegrasi — semuanya berjalan di jalurnya sendiri.
- Kebocoran tidak hanya terjadi di tempat "terkenal". WebRTC sudah lama menjadi perhatian, dan orang telah belajar untuk menutupnya. Sementara itu, dns-prefetching dan verifikasi WebAuthn adalah fungsi kinerja dan keamanan yang tidak pernah dianggap sebagai saluran de-anonimisasi. Fitur baru di browser secara teratur menciptakan jalur bypass baru.
- Pembaruan platform dapat merusak perlindungan Anda secara diam-diam. Di sini, ini terlihat secara harfiah dari tanggal: dns-prefetching "diaktifkan" di iOS 26.0, WebTransport — di iOS 26.4. Pengguna tidak mengubah apa pun, tetapi permukaan kebocoran meningkat dengan sendirinya.
Apa artinya ini untuk multi-akuntansi dan otomatisasi
Bagi mereka yang mengelola beberapa akun atau mengumpulkan data, risikonya tidak bersifat abstrak-pribadi, tetapi cukup finansial. Sistem anti-fraud platform membandingkan sinyal: jika sesi mengklaim satu IP, tetapi permintaan terkait datang dari alamat lain dan dari resolver rumah, itu adalah alasan yang jelas untuk menghubungkan akun satu sama lain atau menandai sesi sebagai mencurigakan.
Konsekuensi praktis:
- Jangan jalankan sesi multi-akun kerja di browser seluler dengan mode proxy. Selama platform belum menutup celah, lapisan aplikasi di iOS tidak dapat diandalkan secara definisi.
- Bundel lalu lintas secara sistematis. Jika tugasnya adalah lingkungan seluler, lebih bijaksana untuk mengatur proxy di tingkat perangkat atau merutekan melalui gateway terpisah, bukan mengandalkan pengaturan di dalam browser.
- Periksa kombinasi setelah setiap pembaruan besar OS dan browser. Setidaknya sekali setiap kuartal. Jadikan ini bagian dari daftar periksa Anda, bukan "ketika sesuatu berjalan tidak semestinya".
- Nonaktifkan apa yang tidak Anda gunakan. WebTransport dan WebAuthn dalam profil kerja untuk parsing atau SMM hampir pasti tidak diperlukan — menonaktifkannya menghilangkan dua saluran kebocoran dari tiga.
Kualitas IP itu sendiri tetap menjadi variabel terpisah: bahkan dengan konfigurasi yang rapat, alamat pusat data mengungkapkan dirinya melalui ASN. Untuk skenario di mana penting untuk terlihat seperti pengguna biasa, proxy residensial berfungsi, dan untuk aplikasi seluler dan platform dengan anti-fraud yang paling ketat — proxy seluler dengan IP dari operator seluler yang nyata. Namun, tidak ada kelas proxy yang dapat menyelamatkan jika sebagian lalu lintas secara fisik melewati proxy — pertama-tama kedap udara, kemudian kualitas alamat.
Kesimpulan
Tiga bug WebKit — dns prefetching, Permintaan Asal Terkait WebAuthn, dan WebTransport — menunjukkan bahwa "proxy diaktifkan" dan "semua lalu lintas melewati proxy" adalah dua pernyataan yang berbeda. Di iOS, celah antara keduanya cukup lebar sehingga halaman web biasa tanpa satu baris JavaScript pun dapat mengetahui alamat asli pengunjung browser Tor.
Sementara Apple menyiapkan perbaikan, satu-satunya strategi yang bekerja adalah memeriksa, bukan berasumsi. Buka stand pengujian, bandingkan alamat, nonaktifkan API yang tidak perlu. Dan anggap setiap pembaruan besar OS sebagai peristiwa di mana konfigurasi perlu diperiksa ulang. Perbedaan antara privasi dan ilusi privasi sering kali terletak pada satu pertanyaan yang tidak diajukan tepat waktu: "apakah semua lalu lintas benar-benar?" Juga berguna untuk memahami sinyal lain apa yang mengungkapkan Anda selain alamat — tentang ini kami telah menulis dalam materi tentang perlindungan terhadap fingerprinting browser.