WebRTC'yi tamamen devre dışı bırakabilir miyim?

Evet, Firefox'ta: about:config → media.peerconnection.enabled → false. Chromium tarayıcıları, uzantı olmadan bir geçiş özelliği göstermez (uBlock Origin'in bir ayarı vardır; Google'ın WebRTC Ağ Sınırlayıcısı başka bir ayardır). Devre dışı bırakmak, arama için WebRTC'yi kullanan tüm siteleri bozar.

VPN, WebRTC sızıntılarına karşı koruma sağlar mı?

Tarayıcıya bağlıdır. Modern tarayıcılar, medya izni olmadan JavaScript'in genel IP'sini açıklamaz; bu nedenle, varsayılan ayarlarda VPN yoluyla pasif bir WebRTC sızıntısı nadirdir. Ancak sayfa getUserMedia'yı çağırırsa ve kullanıcı kabul ederse, toplanan adaylar VPN'in genel IP'sini (bu beklenen bir durumdur) veya IPv6 yığını VPN çevresinde sızıyorsa gerçek IP'yi içerebilir.

STUN sunucusu nedir ve onları kim çalıştırır?

STUN sunucuları yalnızca gördükleri kaynak IP'yi ve bağlantı noktasını yansıtır; küçük, durum bilgisi olmayan ve çalıştırılması ücretsiz. Google stun.l.google.com:19302 adresinde halka açık bir STUN sunucusu işletmektedir; Twilio, Mozilla ve diğerleri kendilerininkini yönetiyorlar. Birçok uygulama varsayılan olarak Google'ınkini kullanır. STUN sunucuları yalnızca bir isteğin gerçekleştiğini görür; peşinden akan medyayı görmüyorlar.

WebRTC şifrelenmiş mi?

Her zaman, spesifikasyona göre. DTLS anlaşması, medyayı şifreleyen SRTP için anahtarlar türetir. Veri kanalı DTLS tarafından şifrelenir. Şifrelemeyi devre dışı bırakamazsınız. Uçtan uca şifreleme ayrı bir özelliktir; bir SFU aracılığıyla yapılan grup çağrıları, yalnızca uygulamanın bunu açıkça uygulaması durumunda E2EE olabilir (Zoom, Signal bunu yapar; birçok basit uygulama bunu yapmaz).

Tarayıcıdan tarayıcıya video on yıl öncesine kıyasla neden bu kadar iyi?

Codec donanım hızlandırması (GPU'da AV1, VP9, H.264), gerçek zamanlı medya için özel olarak tasarlanmış tıkanıklık kontrolü (Google'ın tıkanıklık kontrol algoritması) ve doğrudan yolları daha sık mümkün kılan daha iyi NAT geçişi. Bunların hepsi WebRTC'nin içindedir.

WebRTC Açıklandı: Görüntülü Aramalara Güç Veren ve Bazen IP'nizi Sızdıran Tarayıcı Protokolü

WebRTC, iki tarayıcının eşler arası, düşük gecikmeli, ses, video veya verilerle doğrudan birbirleriyle konuşmasına olanak tanıyan protokoldür. Tarayıcı tabanlı görüntülü aramayı mümkün kıldı. Aynı zamanda tamamen yeni bir gizlilik sızıntısı kategorisi de yarattı, çünkü NAT'lar aracılığıyla birbirlerini bulmak için tarayıcıların genel IP'lerini JavaScript'e gösterecek şekilde araştırmaları gerekiyor.

Makalenin tam metni aşağıda İngilizce olarak verilmektedir.

WebRTC (Web Gerçek Zamanlı İletişimi), web sayfalarının birbirleriyle veya yerel uygulamalarla doğrudan eşler arası bağlantılar kurmasına olanak tanıyan, her modern tarayıcıda yerleşik olarak bulunan bir dizi API'dir. Google Meet'e, tarayıcıda Zoom'a, Discord'un sesli sohbetine, Twitter Spaces'a ve sayısız küçük hizmete güç sağlar. WebRTC olmasaydı, gerçek zamanlı tarayıcı videosu yine de bir Flash ya da çökme teklifi olurdu.

Teknik özelliklerin içeriği

WebRTC üç ana API'yi bir araya getirir:

getUserMedia — kameraya erişir ve mikrofon
RTCPeerConnection — gerçek eş bağlantıyı yönetir: codec anlaşması, şifreleme, NAT geçişi, tıkanıklık kontrolü
RTCDataChannel — bağlantı üzerinden isteğe bağlı ikili veya metin verileri gönderir, eşler arası

Bağlantının kendisi, NAT geçişi için ICE (Etkileşimli Bağlantı Kurulumu), el sıkışma şifrelemesi için DTLS ve medya şifrelemesi için SRTP'yi kullanır. Bağlantının tamamı varsayılan olarak uçtan uca şifrelenir; kapatamazsınız.

Eşler birbirini nasıl bulur

Eşler arası çalışmanın zor kısmı, her iki eşin de genellikle NAT'ın arkasında olmasıdır. WebRTC olası ağ yollarını keşfetmek için ICE'yi kullanır:

Tarayıcı bir STUN sunucusuna "genel IP'm ve bağlantı noktam neye benziyor?" diye sorar. STUN sunucusu gördüğü kaynak adresiyle yanıt verir - bu, NAT'ın harici eşlemesidir.
Tarayıcı tüm aday adreslerini toplar: LAN üzerindeki yerel IP'ler, STUN tarafından keşfedilen genel IP, isteğe bağlı olarak bir TURN rölesi, eğer NAT geçilemiyorsa.
Eşler aday listelerini bir sinyal kanalı (genellikle bir WebSocket'ten uygulamanın sunucusuna).
Biri başarılı olana kadar her kombinasyona bağlanmayı denerler.

IP sızıntısı sorunu

WebRTC IP sızıntısının kaynağı aday toplama adımıdır. JavaScript, tarayıcıdan ICE adaylarını toplamaya başlamasını isteyebilir ve tarayıcı, sonuçta ortaya çıkan genel ve yerel IP'leri sayfaya gösterir. Sizi izlemek isteyen bir sayfa, new RTCPeerConnection().createDataChannel(...)'i çağırabilir, adayları toplayabilir ve artık herhangi bir HTTP katmanı gizlemesinden bağımsız olarak gerçek IP'nizi bilir.

Bu, 2015 yılında keşfedildi ve kısa sürede standart bir gizlilik silahı haline geldi. WebRTC sızıntıları, VPN kullanan bir kişinin gerçek IP adresinin doğru yolu soran bir web sitesinde hâlâ görülebilmesinin nedenidir.

Bu konuda neler yapıldı

Tarayıcı sağlayıcıları, bir sayfanın görebileceği adayları aşamalı olarak kısıtlayarak yanıt verdi:

Modern sürümlerde varsayılan davranış Chrome/Firefox/Safari, açık bir izin olmaksızın yalnızca yerel IP'leri (LAN'dakiler - genellikle 192.168.x veya 10.x) ortaya çıkaracaktır.
mDNS ana bilgisayar adları, bağlantılar için yerel IP'nin yerini alır - 192.168.1.42'i açığa çıkarmak yerine, tarayıcı rastgele bir .local kullanır. ana bilgisayar adı.
Bir sayfa getUserMedia'i çağırırsa (ör. gerçek bir video görüşmesi), tarayıcı genel IP dahil tam adayları toplar; bu noktada yine de medya izni vermiş olursunuz.

Sonuç: pasif WebRTC IP sızıntıları çoğunlukla varsayılan ayarlarda kapatılmıştır. Adayları agresif bir şekilde toplayan siteler hâlâ varlığını sürdürüyor ve eski tarayıcılara veya rahat ayarlara sahip kullanıcılar hâlâ savunmasız durumda. WebRTC sızıntı kılavuzumuz doğrulamayı kapsar.

Eşler arası neden önemlidir

İki kişilik çağrılar için, WebRTC medyayı doğrudan eşler arasında gönderir ve sinyal sunucusu yalnızca bağlantı kurulumu için kullanılır. Video, uygulamanın sunucularından geçmiyor. Bu, işletim açısından önemli ölçüde daha ucuzdur (medya için bant genişliği maliyeti yoktur) ve gecikme süresi önemli ölçüde daha düşüktür (ekstra atlama yoktur). Grup çağrıları genellikle bir Seçici İletme Birimi'ne (SFU) (medya aktaran bir sunucu) ihtiyaç duyar, ancak doğru şekilde yapılandırılırsa şifreleme yine de uçtan uca olur.

WebRTC nereye gidiyor

Sonraki büyük adım WebTransport'tir (gerçek zamanlı olmayan çift yönlü akışlar için düşük seviyeli QUIC tabanlı bir API) ve WebCodecs (kodlayıcı/kod çözücü donanımına ham erişim). Birlikte bulut oyunları, tarayıcıda düşük gecikmeli video kod dönüştürme ve RTCDataChannel'dan daha iyi tıkanıklık kontrolüyle eşler arası toplu dosya aktarımı gibi yeni kullanım durumlarının kilidini açarlar.

WebRTC'nin kendisi de modernize ediliyor; orijinal Plan B SDP semantiği, Birleşik Plan lehine aşamalı olarak kaldırılıyor ve API yüzeyi geliştiriciler için daha temiz hale geliyor.

Sık sorulan sorular

WebRTC'yi tamamen devre dışı bırakabilir miyim?: Evet, Firefox'ta: about:config → <code>media.peerconnection.enabled</code> → false. Chromium tarayıcıları, uzantı olmadan bir geçiş özelliği göstermez (uBlock Origin'in bir ayarı vardır; Google'ın WebRTC Ağ Sınırlayıcısı başka bir ayardır). Devre dışı bırakmak, arama için WebRTC'yi kullanan tüm siteleri bozar.
VPN, WebRTC sızıntılarına karşı koruma sağlar mı?: Tarayıcıya bağlıdır. Modern tarayıcılar, medya izni olmadan JavaScript'in genel IP'sini açıklamaz; bu nedenle, varsayılan ayarlarda VPN yoluyla pasif bir WebRTC sızıntısı nadirdir. Ancak sayfa getUserMedia'yı çağırırsa ve kullanıcı kabul ederse, toplanan adaylar VPN'in genel IP'sini (bu beklenen bir durumdur) veya IPv6 yığını VPN çevresinde sızıyorsa gerçek IP'yi içerebilir.
STUN sunucusu nedir ve onları kim çalıştırır?: STUN sunucuları yalnızca gördükleri kaynak IP'yi ve bağlantı noktasını yansıtır; küçük, durum bilgisi olmayan ve çalıştırılması ücretsiz. Google stun.l.google.com:19302 adresinde halka açık bir STUN sunucusu işletmektedir; Twilio, Mozilla ve diğerleri kendilerininkini yönetiyorlar. Birçok uygulama varsayılan olarak Google'ınkini kullanır. STUN sunucuları yalnızca bir isteğin gerçekleştiğini görür; peşinden akan medyayı görmüyorlar.
WebRTC şifrelenmiş mi?: Her zaman, spesifikasyona göre. DTLS anlaşması, medyayı şifreleyen SRTP için anahtarlar türetir. Veri kanalı DTLS tarafından şifrelenir. Şifrelemeyi devre dışı bırakamazsınız. Uçtan uca şifreleme ayrı bir özelliktir; bir SFU aracılığıyla yapılan grup çağrıları, yalnızca uygulamanın bunu açıkça uygulaması durumunda E2EE olabilir (Zoom, Signal bunu yapar; birçok basit uygulama bunu yapmaz).
Tarayıcıdan tarayıcıya video on yıl öncesine kıyasla neden bu kadar iyi?: Codec donanım hızlandırması (GPU'da AV1, VP9, H.264), gerçek zamanlı medya için özel olarak tasarlanmış tıkanıklık kontrolü (Google'ın tıkanıklık kontrol algoritması) ve doğrudan yolları daha sık mümkün kılan daha iyi NAT geçişi. Bunların hepsi WebRTC'nin içindedir.