Deteksi Kebocoran IP WebRTC: Dari Bug Menjadi Fitur

WebRTC — Web Real-Time Communication — dirancang untuk memungkinkan panggilan video, berbagi berkas, dan transfer data peer-to-peer langsung di dalam browser. Untuk membangun koneksi ini, browser perlu menemukan antarmuka jaringannya sendiri dan menegosiasikan konektivitas dengan peer jarak jauh. Proses ini melibatkan server STUN (Session Traversal Utilities for NAT) dan TURN (Traversal Using Relays around NAT) yang membantu browser menemukan alamat IP publiknya dan menembus firewall NAT.

Efek sampingnya sangat kuat: bahkan ketika pengguna terhubung melalui VPN, tumpukan WebRTC di browser dapat mengungkap alamat IP asli di balik terowongan. Hal ini terjadi karena candidate ICE (Interactive Connectivity Establishment) WebRTC menyertakan alamat antarmuka jaringan lokal yang tidak disembunyikan oleh VPN.

Bagaimana Kebocoran Terjadi

Ketika browser membuat RTCPeerConnection dan mengumpulkan candidate ICE, ia melakukan kueri ke server STUN untuk menemukan IP publiknya. Namun, ia juga mendata antarmuka jaringan lokal — termasuk IP privat dari adapter fisik. Jika VPN hanya menerowongkan lalu lintas pada lapisan IP tetapi tidak mengonfigurasi tumpukan WebRTC browser untuk memakai antarmuka terowongan secara eksklusif, IP asli akan bocor melalui host candidate.

Di tracio.ai, kami menyelidiki perilaku ini dengan cermat. Sistem IP Intelligence kami membuat permintaan STUN yang terkontrol dan menganalisis candidate ICE yang dikembalikan browser. Ketika IP publik dari STUN berbeda dengan IP yang kami lihat di server, kami menandainya sebagai VPN atau proxy. Ketika IP antarmuka lokal mengungkap rentang jaringan privat yang bertentangan dengan lokasi geografis yang diklaim, kami menaikkan skor kecurigaan.

Dari Bug Menjadi Sinyal Deteksi

Sebagian besar browser yang berfokus pada privasi telah menambal kebocoran ini — Chrome mensyaratkan izin eksplisit dari pengguna untuk WebRTC, dan Firefox menyediakan pengaturan untuk menonaktifkan UDP non-proxied. Namun perlombaan senjata terus berlanjut: beberapa klien VPN tidak mengonfigurasi WebRTC dengan benar, versi browser lama tetap rentan, dan pola perilaku respons WebRTC yang "sudah ditambal" versus yang "bocor" itu sendiri merupakan sinyal yang berguna.

Pendekatan kami memperlakukan respons WebRTC sebagai sinyal komposit: keberadaan host candidate, jumlah candidate ICE yang dikembalikan, jenis candidate (host, srflx, relay), dan waktu respons semuanya berkontribusi pada fingerprint perangkat. Bahkan ketika tidak ada IP yang bocor, pola perilaku WebRTC tetap khas.

Probing Server TURN

Selain STUN, kami juga menyelidiki perilaku server TURN. Relay TURN biasanya digunakan ketika koneksi peer-to-peer langsung gagal — umum terjadi pada jaringan korporat di balik firewall yang ketat. Respons alokasi TURN mengungkap informasi tentang jalur relay: protokol transport (UDP versus TCP versus TLS), alamat relay, dan masa berlaku alokasi.

Sistem SignalProbe kami mengirim permintaan alokasi TURN yang dirancang dengan cermat ke server relay milik kami sendiri. Waktu respons, transport yang didukung, serta pola keberhasilan/kegagalan alokasi bervariasi menurut lingkungan jaringan dan memberikan keragaman sinyal tambahan untuk fingerprinting perangkat.

Pertimbangan Privasi

Kami ingin menegaskan: tracio.ai tidak mengeksploitasi kebocoran WebRTC untuk membuka anonimitas pengguna. Sistem kami mendeteksi ketika VPN sedang digunakan dan melaporkannya sebagai sinyal risiko. Kami tidak pernah menyimpan atau mengekspos alamat IP yang bocor. Sinyalnya bersifat biner: "VPN terdeteksi dengan inkonsistensi WebRTC" atau "perilaku WebRTC konsisten dengan koneksi langsung".

Pendekatan ini memberi tim pencegahan fraud informasi yang mereka butuhkan — bahwa seorang pengunjung menyembunyikan lokasi aslinya — tanpa mengorbankan privasi individu. Sinyal ini membantu mendeteksi serangan fraud terkoordinasi ketika banyak akun berasal dari lokasi tersembunyi yang sama.