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 adalah saat pencarian itu lolos dari perlindungan apa pun yang Anda kira sedang menaungi 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 jangkau.

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

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

Jebakannya, pengumpulan alamat itu bisa berjalan langsung dari JavaScript di sebuah halaman, dan bisa menjangkau 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. Ia bisa menyerahkan alamat IP asli Anda kepada sebuah halaman web lewat fitur yang tidak pernah Anda pilih untuk dinyalakan, 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, pasangan itulah keseluruhan taruhannya.

Alasan Anda memakai proxy atau alat privasi sejak awal adalah menjaga salah satu dari 2 fakta itu tetap milik Anda sendiri. Kebocoran di salah satu saluran menggagalkan upaya itu tanpa sinyal sama sekali. 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 menangkapnya dengan uji kebocoran DNS.
• Kebocoran WebRTC: yang bocor adalah alamat IP asli Anda, yang melihatnya adalah halaman web yang Anda kunjungi, dan Anda menangkapnya dengan uji kebocoran WebRTC.

Di sinilah web proxy yang menulis ulang konten membuktikan nilainya, 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 tujuannya dikodekan di dalam path, jadi browser Anda hanya pernah berbicara dengan TrickyBird. Pencarian untuk situs yang benar-benar Anda inginkan terjadi di sisi kami, bukan di perangkat Anda. Sederhananya, nama host tujuan tidak pernah masuk ke kueri DNS yang dikirim browser Anda ke jaringan di sekitar Anda. Jadi kalau pertanyaannya apakah web proxy menyembunyikan IP saya dan menjauhkan tujuan saya dari resolver lokal, itulah tugas yang dikerjakan skema ini. Ini nol kebocoran domain yang sama yang menjaga nama tujuan tidak muncul di bilah URL dan di halaman (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 batas jujur yang layak dinyatakan terang-terangan. Gateway kami tetap harus me-resolve dan terhubung ke situs tujuan untuk mengambilnya, jadi tahapan 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 memercayai kata 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 persis yang Anda pedulikan, untuk memastikan IP asli Anda tidak lagi muncul. Sebaiknya Anda memeriksanya sendiri daripada mempercayai klaim apa pun, termasuk klaim ini.

Anda tidak harus bergantung pada satu alat tunggal. 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, yang mematikan fiturnya. Chrome tidak menyediakan sakelar bawaan, jadi orang biasanya memakai ekstensi berulasan baik yang memblokir WebRTC, meski di perangkat yang dikelola 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 desktop.

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. Semuanya tuas untuk dicoba, lalu diverifikasi.

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

Lakukan sekali di jaringan yang benar-benar Anda pedulikan. Jika resolver yang tercantum milik ISP Anda atau jaringan lokal, DNS Anda bocor. Jika IP publik yang ditampilkan adalah alamat Anda sendiri, WebRTC atau koneksinyalah yang mengungkapnya. Nyalakan alat Anda dan jalankan pemeriksaan yang sama lagi untuk melihat apakah angkanya berubah.

Halaman /proof milik TrickyBird memeriksa hal yang berbeda, dan keduanya sebaiknya tidak dicampuradukkan. Halaman itu menunjukkan bahwa alamat situs yang Anda buka tidak pernah muncul di bilah URL, di kode sumber halaman, atau di header Referer dan Origin yang dikirim browser 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 developer tools 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