Güvenli bir aramanın birden fazla veri yolu vardır. Sinyalleşme, kimin aradığını ve uç noktaların nasıl bağlandığını koordine eder; medya yolu ise ses ve videoyu taşır. Bir yolu korumak diğerini otomatik olarak korumaz ve hiçbiri tek başına tüm iletişim örüntülerini gizlemez.
WebRTC önemli güvenlik mekanizmaları sağlar; ancak gizlilik sınırının tamamını yine uygulamanın kimlik kontrolleri, sunucu rolleri ve kayıt modu belirler.
Sinyalleşme ve medya farklı işler yapar
| Katman | Tipik amaç | Güvenlik sorusu |
|---|---|---|
| Sinyalleşme | Davetler, oturum açıklamaları ve bağlantı adayları | Kurulum bilgilerini kim okuyabilir veya değiştirebilir ve amaçlanan eşin kimliği nasıl doğrulanır? |
| Medya | Ses, video ve ilgili gerçek zamanlı akışlar | Şifreleme nerede sonlanır ve hangi uç noktalar medyaya erişebilir? |
| İşletim kayıtları | Yönlendirme, bağlantı zamanlaması ve teslimat durumu | Hizmet veya ağ hangi meta verileri gözlemleyebilir? |
| Kayıt | Saklanacak bir kopya oluşturma | Açık metni veya kullanılabilir kayıt anahtarlarını kim alır ve kopya nerede saklanır? |
Bir mesajlaşma protokolü şifreli sinyalleşme taşıyabilir; ancak WebRTC, belirli bir mesajlaşma uygulamasının zarf biçimini evrensel olarak zorunlu kılmaz. Kimlik doğrulamalı başka tasarımlar da mümkündür.
DTLS-SRTP ne sağlar?
WebRTC Güvenlik Mimarisi, RFC 8827, medya kanalları için koruma gerektirir ve DTLS-SRTP anahtar oluşturma sürecini açıklar. Basitleştirirsek, DTLS kriptografik bağlamın kurulmasına yardımcı olur, SRTP ise gerçek zamanlı medya paketlerini korur.
Bu korumanın uç noktaları önemlidir. Katılımcılar arasındaki doğrudan şifreli bağlantı, medya işleyen bir sunucuda sonlanan bağlantıdan farklıdır. Bazı çok taraflı sistemler, sunucuya dönük taşıma şifrelemesinin üzerine ayrı bir uçtan uca katman ekler. Tek başına “WebRTC” sözcüğü, ürünün hangi mimariyi kullandığını söylemez.
Sinyalleşmede kimlik doğrulama neden önemlidir?
Arama kurulumu, medya bağlantısını amaçlanan tarafa bağlamak için kullanılan bilgileri içerebilir. Saldırgan bu bilgileri fark edilmeden değiştirebilirse şifreleme, yanlış uç noktaya korumalı bir bağlantı kurabilir.
RFC 8827, sinyalleşme, kimlikler ve DTLS parmak izleri arasındaki bu ilişkiyi ele alır. HTTPS, sinyalleşme hizmetine bağlantıyı korur; tek başına kötü niyetli veya ele geçirilmiş bir hizmeti hesaba katma gereğini ortadan kaldırmaz. Uçtan uca kimlik doğrulamalı sinyalleşme veya uygun bir bağımsız eş doğrulama mekanizması bu sınırı güçlendirebilir.
Sinyalleşme gizliliği, ilişkili ama farklı bir hedeftir: kurulum ayrıntılarını kimin okuyabileceğini sınırlar. Bir tasarım, şifreli bir veri yığınını her ikisine de yeterli kanıt saymak yerine hem gizliliği hem de kimlik doğrulamayı açıklamalıdır.
Şifreli sinyalleşme aramayı görünmez yapmaz
Aktarıcı, hangi hesaplar veya cihazlar arasında yönlendirme yaptığını hâlâ bilebilir. Ağ gözlemcileri bağlantı zamanlamasını, trafik hacmini ve sunucu adreslerini görebilir. Eşler veya aktarıcı altyapısı da bağlantı tasarımına bağlı olarak ağ bilgilerini öğrenebilir.
Dolayısıyla bir arama davetini şifrelemek, hizmetin arama yapıldığını çıkaramayacağını, ilişkileri haritalayamayacağını veya aramayla ilgili kayıtları tutamayacağını kanıtlamaz. İçeriği gizlemek ile trafik örüntülerini gizlemek ayrı sorunlardır.
Livara'nın yayımladığı sınır
Livara'nın güvenlik sayfası, doğrudan ve grup aramalarını uçtan uca şifreli olarak tanımlar, ancak isteğe bağlı sunucu kaydı için açık bir istisna belirtir: görünür REC durumu etkinken arama, E2EE yerine taşıma şifrelemesi kullanır.
Tehdit modeli de meta veri anonimliği ve ele geçirilmiş bir cihaza karşı koruma iddialarını reddeder. Bunlar ürün açıklamalarıdır; her arama yolunun bağımsız doğrulaması değildir. Bu kılavuz, doğrulanmamış bir katılımcı sınırı, sinyalleşme biçimi veya kuantum sonrası medya uygulaması iddia etmez.
Özellikle, bir mesajlaşma uygulamasının kuantum sonrası anahtar değişimi, ayrı bir WebRTC medya el sıkışmasını otomatik olarak yükseltmez. Medya yolundaki algoritmalar ve anahtar bağlama bağımsız olarak değerlendirilmelidir.
Hassas bir aramadan önce
- Katılımcıları doğrulayın ve beklenmedik kimlik değişikliklerini inceleyin.
- Kaydın etkin olup olmadığını ve uygulamanın bunun neyi değiştirdiğini söylediğini kontrol edin.
- Hizmetin medyayı işleyip işlemediğini veya yalnızca korunan paketleri iletip iletmediğini anlayın.
- Katılımcıların cihazlarını ve bulundukları odaları düşünün: kötü amaçlı yazılım, ekran yakalama veya yakındaki bir dinleyici, şifre çözümünden sonra içeriği açığa çıkarabilir.
- Genel bir “şifreli aramalar” rozetine güvenmek yerine, tam olarak kullandığınız mod için mimari ve test kanıtı isteyin.
Yararlı güvenlik iddiası, sinyalleşmeye, medyaya, meta verilere ve kayıtlara kimlerin erişebildiğini ayrı ayrı belirtir.
