WebRTC sızıntıları: gerçek adresiniz proxy arkasında bile neden görünebilir
WebRTC, tarayıcıların arama ve ekran paylaşımı için birbirleriyle doğrudan konuşabilmesi amacıyla vardır. Bunu yapmak için ulaşılabilecekleri adresleri keşfetmeleri gerekir ve “WebRTC sızıntısı”nın işaret ettiği şey bu keşif sürecidir.
Tek paragrafta ICE adayları
Bir sayfa RTCPeerConnection oluşturup bir teklif başlattığında tarayıcı adayları toplar: başka bir eşin ona ulaşabileceği yollar. Host adayı, yerel bir arayüz adresidir. Server-reflexive (srflx) adayı, bir STUN sunucusunun isteğin hangi adresten geldiğini gördüğü genel adrestir. Relay adayı bir TURN sunucusunun adresidir. Her aday sayfaya adresi içeren bir metin satırı olarak verilir; bir betiğin, hiçbir çağrı yapılmadan bile bunu okuyabilmesinin yolu budur.
Sızıntı nerede
Önemli olan srflx adayıdır. Onu almak için tarayıcı bir STUN sunucusuna küçük bir UDP paketi gönderir ve sunucu gördüğü adresle yanıt verir. HTTP trafiğiniz bir proxy üzerinden geçip UDP trafiğiniz geçmiyorsa, STUN sunucusu gerçek bağlantınızı görür ve sayfa artık web sunucusunun gördüğüyle uyuşmayan bir adrese sahip olur. Bu uyuşmazlık klasik sızıntıdır. Bir tanılama sayfası ikisini karşılaştırarak bunu gösterebilir.
Neyin olup neyin olmadığına dikkat edin. Hiçbir medya yakalanmaz. Mikrofon ya da kamera izni söz konusu değildir. Paket, sayfanın adını verdiği hangi STUN sunucusuysa ona gider; bu yüzden o sunucu, iletişime geçtiğiniz her sunucu gibi adresinizi görür.
Tarayıcılar ne değiştirdi
Host adayları eskiden 192.168.1.23 gibi özel LAN adreslerini ifşa ederdi; bu da bir ev ağının parmak izini çıkarmak için işe yarıyordu. Modern tarayıcılar bunların yerine .local ile biten rastgele üretilmiş mDNS adlarını koyar; böylece sayfa bir adres yerine anlaşılmaz bir ad görür. “Tarayıcı tarafından maskelendi” diyen bir tanılama bunları anlatır. Firefox ve Brave ayrıca aday toplamayı proxy dışında durduran ayarlar sunar ve bazı uzantılar WebRTC'yi tümüyle engeller.
Proxy için güvenli yapılandırmalar
Üç yaklaşım işe yarar; maliyetleri farklıdır. WebRTC'yi devre dışı bırakmak sızıntıyı önler ve ona ihtiyaç duyan her siteyi bozar. WebRTC'yi yalnızca proxy'nin rotasını kullanmaya zorlamak (bazı tarayıcılardaki “proxy için güvenli” mod), proxy UDP ya da TURN'ü destekliyorsa aramaları çalışır halde tutar, desteklemiyorsa hiç genel aday vermez. WebRTC'nin normal davranmasına izin vermek yalnızca proxy tüm trafiği taşıyorsa doğrudur; sistem düzeyindeki bir VPN genellikle bunu yapar.
Hangisinin doğru olduğu işe bağlıdır. Tek bir yerde görünmesi gereken yalıtılmış bir tarayıcı profili için kural basittir: WebRTC'nin ifşa ettiği adres, web sunucusunun gördüğü adresle aynı olmalıdır, ya da hiç olmamalıdır. Bunun dışındaki her şey, bir sitenin özel bir araca gerek duymadan fark edebileceği bir çelişkidir.
Sonucu okumak
Bir tanılama, gözlemlediği adayları birkaç saniye içinde gösterir ve herhangi bir genel adayı sayfaya ulaşılan adresle karşılaştırır. Bazı maskelenmiş adaylarla birlikte “hiçbiri ifşa edilmedi”, WebRTC'yi proxy içinde tutan bir tarayıcı için normal, sağlıklı bir sonuçtur. Sayfanın adresinden farklı bir genel adres ise düzeltilmesi gereken şeydir.
