Kebocoran WebRTC: mengapa alamat asli Anda bisa terlihat meski di balik proxy
WebRTC ada agar browser dapat berkomunikasi langsung satu sama lain untuk panggilan dan berbagi layar. Untuk itu, browser perlu menemukan alamat tempat ia dapat dihubungi, dan proses penemuan itulah yang dimaksud dengan "kebocoran WebRTC".
Kandidat ICE dalam satu paragraf
Saat sebuah halaman membuat RTCPeerConnection dan memulai offer, browser mengumpulkan kandidat: cara-cara agar peer lain dapat menjangkaunya. Kandidat host adalah alamat antarmuka lokal. Kandidat server-reflexive (srflx) adalah alamat publik yang dilihat server STUN sebagai asal permintaan. Kandidat relay adalah alamat server TURN. Setiap kandidat diserahkan ke halaman dalam satu baris teks yang memuat alamatnya, sehingga skrip dapat membacanya tanpa ada panggilan yang pernah dilakukan.
Di mana letak kebocorannya
Kandidat srflx adalah yang terpenting. Untuk mendapatkannya, browser mengirim paket UDP kecil ke server STUN, yang membalas dengan alamat yang dilihatnya. Jika lalu lintas HTTP Anda melewati proxy tetapi lalu lintas UDP tidak, server STUN melihat koneksi asli Anda, dan halaman kini memiliki alamat yang berbeda dengan alamat yang dilihat server web. Perbedaan itulah kebocoran klasik. Halaman diagnostik dapat menunjukkannya dengan membandingkan keduanya.
Perhatikan apa yang terjadi dan tidak terjadi. Tidak ada media yang direkam. Tidak ada izin mikrofon atau kamera yang terlibat. Paket itu dikirim ke server STUN mana pun yang disebut halaman, sehingga server itu, seperti server mana pun yang Anda hubungi, melihat alamat Anda.
Apa yang diubah browser
Kandidat host dulu mengungkap alamat LAN privat seperti 192.168.1.23, yang berguna untuk membuat fingerprint jaringan rumah. Browser modern menggantinya dengan nama mDNS acak berakhiran .local, sehingga halaman hanya melihat nama buram, bukan alamat. Diagnostik yang melaporkan "disamarkan oleh browser" sedang menjelaskan kandidat-kandidat itu. Firefox dan Brave juga menawarkan pengaturan yang menghentikan pengumpulan kandidat di luar proxy, dan beberapa ekstensi memblokir WebRTC sepenuhnya.
Konfigurasi yang aman untuk proxy
Ada tiga pendekatan yang berhasil, dengan biaya berbeda. Menonaktifkan WebRTC mencegah kebocoran tetapi merusak setiap situs yang membutuhkannya. Memaksa WebRTC hanya memakai rute proxy (mode "aman untuk proxy" di beberapa browser) menjaga panggilan tetap berfungsi jika proxy mendukung UDP atau TURN, dan jika tidak, tidak menghasilkan kandidat publik sama sekali. Membiarkan WebRTC berperilaku normal hanya benar bila proxy membawa semua lalu lintas, seperti yang biasanya dilakukan VPN tingkat sistem.
Mana yang tepat bergantung pada pekerjaannya. Untuk profil browser terisolasi yang harus tampak berada di satu tempat, aturannya sederhana: alamat yang diungkap WebRTC harus sama dengan alamat yang dilihat server web, atau tidak ada sama sekali. Selain itu adalah kontradiksi yang bisa dikenali situs tanpa alat khusus apa pun.
Membaca hasilnya
Diagnostik menampilkan kandidat yang diamati dalam beberapa detik dan membandingkan kandidat publik mana pun dengan alamat yang dipakai untuk mengakses halaman. "Tidak ada yang terungkap" dengan beberapa kandidat yang disamarkan adalah hasil normal dan sehat untuk browser yang menjaga WebRTC tetap di dalam proxy. Alamat publik yang berbeda dari alamat halaman adalah hal yang perlu diperbaiki.
