Apa Itu Kebocoran DNS atau WebRTC?

Anggap DNS sebagai buku telepon internet. Setiap kali Anda mengetik sebuah alamat web, perangkat Anda tidak bisa memakai nama itu begitu saja. Nama itu harus diubah menjadi angka, yaitu alamat IP, dan untuk itu perangkat bertanya ke sebuah resolver DNS. Di sebagian besar jaringan, resolver itu milik pihak yang menjalankan jaringan tersebut. Itu ISP Anda di rumah, atau tim IT di kantor.

Jadi permintaan kecil yang berbunyi “di mana example.com?” itu berjalan ke mesin yang tidak Anda kendalikan, dan ia membawa nama situs yang hendak Anda buka. Kebocoran DNS terjadi saat pencarian itu lolos dari perlindungan apa pun yang Anda kira sedang melindungi Anda. Anda mungkin memakai sesuatu yang mengenkripsi lalu lintasnya sendiri, tetapi jika pencarian nama host tetap keluar ke resolver milik jaringan, jaringan tetap mengetahui nama setiap situs yang Anda akses.

Hal penting yang perlu diperhatikan adalah apa yang bocor. Kebocoran DNS tidak mengungkap apa yang Anda kirim atau baca. Yang terungkap adalah ke mana Anda menuju, dan bagi banyak orang justru itulah bagian yang sensitif.

WebRTC adalah kumpulan fitur yang tertanam di setiap browser modern agar panggilan video, obrolan suara, dan sebagian fitur berbagi berkas secara langsung bisa berjalan tanpa aplikasi terpisah. Untuk menghubungkan 2 orang, WebRTC lebih dulu harus mencari tahu alamat yang bisa dipakai menjangkau masing‑masing pihak. WebRTC mengumpulkan kandidat alamat, termasuk alamat jaringan lokal perangkat Anda dan, dengan bantuan server yang disebut server STUN, IP publik Anda.

Jebakannya, pengumpulan alamat itu bisa berjalan langsung dari JavaScript di sebuah halaman, dan bisa keluar lewat jalurnya sendiri, bukan jalur yang dipakai alat‑alat Anda yang lain. Jadi sebuah halaman bisa diam‑diam bertanya kepada browser, “berapa IP asli pengunjung ini?”, dan mendapat jawabannya, bahkan saat koneksi utama tampak terkunci rapat.

Itulah kebocoran WebRTC. Lewat kebocoran ini, alamat IP asli Anda bisa diserahkan kepada sebuah halaman web melalui fitur yang tidak pernah Anda nyalakan sendiri, dan justru itulah yang menjebak orang‑orang yang mengira satu alat sudah cukup melindungi mereka.

Sandingkan keduanya. Kebocoran DNS memberi tahu jaringan nama‑nama tempat yang Anda kunjungi. Kebocoran WebRTC memberi tahu sebuah situs web angka yang mengidentifikasi koneksi Anda. Jika Anda memakai perangkat atau jaringan yang dikendalikan orang lain, kedua hal itulah yang dipertaruhkan.

Alasan Anda memakai proxy atau alat privasi sejak awal adalah menjaga salah satu dari 2 fakta itu tetap rahasia. Kebocoran di salah satu saluran menggagalkan upaya itu tanpa tanda apa pun. Tidak ada yang tampak rusak. Halaman tetap termuat. Anda hanya menyerahkan lebih banyak daripada yang Anda niatkan.

• Kebocoran DNS: yang bocor adalah nama situs, yang melihatnya adalah jaringan (ISP Anda atau resolver lokal), dan Anda bisa mendeteksinya dengan uji kebocoran DNS.
• Kebocoran WebRTC: yang bocor adalah alamat IP asli Anda, yang melihatnya adalah halaman web yang Anda kunjungi, dan Anda bisa mendeteksinya dengan uji kebocoran WebRTC.

Di sinilah web proxy yang menulis ulang konten menunjukkan manfaatnya, dan di sini pula penting untuk teliti soal apa yang ia lakukan dan tidak lakukan.

Saat Anda membuka sebuah situs lewat TrickyBird, yang sebenarnya Anda muat adalah alamat milik TrickyBird sendiri. Alamat situs tujuan dikodekan di dalamnya, dan nama situsnya diterjemahkan menjadi alamat IP di sisi kami; yang dicari perangkat Anda adalah alamat kami. Jadi kalau yang Anda tanyakan adalah apa yang dilakukan web proxy untuk Anda di sini, inilah jawabannya: web proxy menyembunyikan IP Anda dari situs yang Anda buka, dan nama situs itu diterjemahkan menjadi alamat IP di sisi kami. Inilah prinsip nol kebocoran domain yang sama: di mana pun alamat tujuan harus dibawa, alamat itu dibawa dikodekan, bukan ditulis apa adanya (lihat situs mana yang saat ini tampil bersih di /status). Tidak ada unduhan dan tidak ada aplikasi, dan itulah yang penting saat blokirnya ada di perangkat yang tidak mengizinkan Anda memasang apa pun.

Ada satu batasan yang perlu kami sampaikan terus terang. Gateway kami tetap harus mencari alamat IP situs tujuan dan terhubung ke sana untuk mengambilnya, jadi tahap itu tidak tersembunyi. Kami menyimpan catatan yang sengaja dibuat kecil tentangnya: alamat IP yang dipotong menjadi /24 atau /48 sehingga menunjuk sebuah lingkungan, bukan satu rumah, ditambah nama host tujuan dan detail dasar respons, paling lama 48 jam. Detail lengkap retensi dan penghapusan ada di /security. Itu pencatatan minimal berumur pendek yang bisa diverifikasi, dan intinya Anda bisa memeriksanya alih‑alih sekadar percaya pada ucapan kami. Sikap itu sangat berbeda dari janji mutlak yang tidak bisa Anda periksa. Lihat perbandingan kebijakannya.

Tidak, dan soal ini perlu dikatakan dengan jelas. TrickyBird menulis ulang halaman yang disajikannya, tetapi tidak mencegat WebRTC. WebRTC berjalan sebagai subsistem browser tersendiri lewat jalur jaringannya sendiri, sehingga halaman yang Anda buka melalui proxy masih bisa menjangkau server STUN secara langsung dan memperoleh IP asli Anda, bahkan saat sisa halaman itu dimuat melalui TrickyBird.

Jadi perlakukan WebRTC sebagai sesuatu yang Anda matikan sendiri, bukan sesuatu yang ditangani proxy untuk Anda. Matikan di browser Anda dengan langkah‑langkah di bawah, lalu jalankan uji kebocoran WebRTC di perangkat dan jaringan yang benar‑benar Anda pakai, untuk memastikan IP asli Anda tidak lagi muncul. Sebaiknya Anda memeriksanya sendiri daripada memercayai klaim apa pun, termasuk klaim ini.

Anda tidak harus bergantung pada satu alat saja. WebRTC juga bisa diredam di tingkat browser, dan cara itu layak diketahui. Di Firefox Anda bisa membuka about:config dan menyetel media.peerconnection.enabled ke false untuk mematikan fitur itu. Chrome tidak menyediakan sakelar bawaan, jadi orang biasanya memakai ekstensi dengan ulasan yang baik yang memblokir WebRTC, meski di perangkat terkelola Anda mungkin tidak diizinkan menambahkannya.

Di perangkat seluler gambarannya berbeda menurut platform. Safari di iOS lebih ketat soal apa yang diserahkan WebRTC ke sebuah halaman, sementara Chrome di Android berperilaku mirip versi desktop. Jadi kalau pertanyaannya apakah iOS bisa bocor lewat WebRTC, jawabannya bisa, hanya tidak seleluasa browser di komputer.

DNS punya opsi tingkat browser tersendiri yang layak disebut. DNS over HTTPS, atau DoH, mengirim pencarian Anda ke sebuah resolver lewat saluran terenkripsi alih‑alih saluran bawaan jaringan, dan dari sanalah banyak orang memulai saat pertama kali membaca soal kebocoran DNS. Tak satu pun dari semua ini menggantikan pengujian. Semua itu cara yang bisa dicoba, lalu diverifikasi.

Anda tidak harus memercayai kalimat pemasaran, dan memang tidak seharusnya. Uji kebocoran memakan waktu sekitar 1 menit. Buka halaman uji kebocoran DNS dan WebRTC, yaitu pemeriksa netral seperti browserleaks.com atau ipleak.net. Halaman itu akan menunjukkan resolver mana yang dijangkau pencarian Anda serta IP publik Anda yang bisa dilihat sebuah halaman, termasuk lewat WebRTC.

Lakukan sekali di jaringan yang benar‑benar Anda pakai. Jika resolver yang tercantum milik ISP Anda atau jaringan lokal, DNS Anda bocor. Jika IP publik yang ditampilkan adalah alamat Anda sendiri, berarti alamat itu terungkap lewat WebRTC atau lewat koneksi utama Anda. Nyalakan alat Anda dan jalankan pemeriksaan yang sama lagi untuk melihat apakah angkanya berubah.

Halaman uji kebocoran web proxy milik TrickyBird (/proof) memeriksa hal yang berbeda, dan keduanya sebaiknya tidak dicampuradukkan. Halaman itu menuntun Anda melihat ke mana saja alamat situs yang Anda buka sebenarnya terkirim: di bilah alamat dan di header Referer dan Origin yang dikirim browser Anda, alamat itu dikodekan di dalam alamat kami sendiri, bukan ditulis apa adanya, dan di kode sumber halaman, alamat itu tertulis di satu tempat yang ditunjukkan halaman itu kepada Anda. Itu pemeriksaan kebocoran domain, bukan uji DNS atau WebRTC, dan tidak menampilkan IP maupun memberi tahu apakah WebRTC membocorkan IP Anda. Untuk itu, gunakan halaman uji kebocoran di atas dan matikan WebRTC di browser Anda. Alat yang layak dipakai adalah alat yang tetap tahan saat seseorang membuka alat developer dan memeriksanya. Standar yang sama layak diterapkan pada web proxy gratis mana pun, termasuk milik kami.

Teruslah membaca jika Anda ingin dasar yang menopang topik ini.

• Apa itu web proxy?
• Web proxy vs VPN
• Apakah menggunakan proxy legal?
• Buka blokir sebuah situs
• Kebijakan pencatatan dan keamanan kami