13. Gizlilik ve Güvenlik Hususları

Bu bölüm normatif değildir. Yeni bir davranış belirtmez; bunun yerine belirtimin diğer bölümlerinde hâlihazırda mevcut olan bilgileri özetler. WebRTC'de kullanılan genel API ve protokoller kümesinin genel güvenlik hususları [RFC8827]'de açıklanmaktadır.

13.1 Aynı köken ilkesine etkisi

Bu belge, Web platformunu tarayıcılar ile diğer aygıtlar arasında — diğer tarayıcılar dâhil olmak üzere — gerçek zamanlı ve doğrudan iletişim kurma yeteneğiyle genişletir.

Bu, farklı tarayıcılarda çalışan uygulamalar arasında ya da aynı tarayıcıda çalışan bir uygulama ile tarayıcı olmayan bir şey arasında veri ve medyanın paylaşılabileceği anlamına gelir; bu da farklı kökenlere sahip varlıklar arasında veri gönderimine karşı Web modelindeki olağan engellere bir uzantıdır.

WebRTC belirtimi, iletişim için kullanıcı istemleri veya tarayıcı arayüzü göstergeleri sağlamaz. Web sayfasına medyaya erişim izni verildikten sonra, bu medyayı seçtiği diğer varlıklarla paylaşmakta serbest olduğu varsayılır. WebRTC veri kanalları üzerinden eşler arası veri alışverişleri — tıpkı Web Sockets üzerinde olduğu gibi — herhangi bir açık kullanıcı onayı olmaksızın gerçekleşebilir.

13.2 IP adreslerinin açığa çıkması

WebRTC olmasa bile, bir Web uygulamasını sağlayan Web sunucusu, uygulamanın iletildiği genel IP adresini bilir. İletişim kurulması, tarayıcının ağ bağlamına ilişkin ek bilgileri Web uygulamasına açığa çıkarır ve WebRTC kullanımına uygun tarayıcıya ait (muhtemelen özel) IP adresleri kümesini içerebilir. Bu bilgilerin bir kısmının, bir iletişim oturumunun kurulabilmesi için karşı tarafa iletilmesi gerekir.

Riskler: IP adreslerinin açığa çıkması, konum ve bağlantı araçlarını sızdırabilir. Ağ ortamına bağlı olarak, parmak izi çıkarma yüzeyini de artırabilir ve kullanıcının kolayca temizleyemeyeceği kalıcı, kökenler arası durum oluşturabilir.

Bir bağlantı, iletişim için önerilen IP adreslerini her zaman karşı tarafa açığa çıkarır. Uygulama, RTCIceTransportPolicy sözlüğü tarafından sunulan ayarları kullanarak belirli adresleri kullanmamayı seçerek ve katılımcılar arasında doğrudan bağlantılar yerine aktarıcılar (örneğin TURN sunucuları) kullanarak bu maruziyeti sınırlayabilir. Normalde TURN sunucularının IP adreslerinin hassas bilgi olmadığı varsayılır.

IP adreslerinin uygulamanın kendisine açığa çıkmasını azaltmak, kullanılabilecek IP adreslerini sınırlamayı gerektirir; bu da uç noktalar arasındaki en doğrudan yol üzerinden iletişim kurabilme yeteneğini etkileyecektir. Tarayıcıların, kullanıcının istediği güvenlik duruşuna bağlı olarak hangi IP adreslerinin uygulamalara sunulacağına karar vermek için uygun denetimler sağlaması teşvik edilir. Hangi adreslerin açığa çıkarılacağına ilişkin seçim yerel politika tarafından kontrol edilir (ayrıntılar için [RFC8828]'e bakınız).

13.3 Yerel ağ üzerindeki etki

Tarayıcı, güvenilir bir ağ ortamında (güvenlik duvarının içinde) çalışan etkin bir platform olduğundan, tarayıcının yerel ağdaki diğer öğelere verebileceği zararı sınırlamak ve güvenilmeyen katılımcılar tarafından verilerin ele geçirilmesine, değiştirilmesine ve tahrif edilmesine karşı koruma sağlamak önemlidir.

Azaltma önlemleri şunları içerir:

ICE izin denetimi: Bir kullanıcı aracısı, ICE kullanarak iletişim kurmak için her zaman karşılık gelen kullanıcı aracısından izin ister. Bu, yalnızca kimlik bilgilerini paylaştığınız ortaklara gönderim yapabilmenizi sağlar.

Sürekli onay mekanizması: Bir kullanıcı aracısı, ICE sürekli onayı kullanarak gönderime devam etmek için her zaman devam eden izin ister. Bu, bir alıcının almayı sürdürme onayını geri çekebilmesini sağlar.

Güçlü şifreleme: Bir kullanıcı aracısı, güçlü oturum başına anahtarlama ile verileri her zaman şifreler (DTLS-SRTP).

Tıkanıklık denetimi: Bir kullanıcı aracısı, her zaman tıkanıklık denetimi kullanır. Bu, WebRTC'nin ağı taşırmak için kullanılamamasını sağlar.

Bu önlemler ilgili IETF belgelerinde belirtilmiştir.

13.4 İletişimin Gizliliği

İletişimin gerçekleştiği gerçeği, ağı gözlemleyebilen hasımlardan gizlenemez; bu nedenle bunun kamuya açık bilgi olarak değerlendirilmesi gerekir.

İletişim sertifikaları, gelecekteki ihtiyaçlar öngörülerek postMessage(message, options) kullanılarak opak biçimde paylaşılabilir. Kullanıcı aracılarının, bellek saldırı yüzeyini azaltmak için bu nesnelerin bir tanıtıcı tuttuğu özel anahtarlama materyalini, RTCCertificate nesnelerine erişimi olan süreçlerden yalıtmaları güçlü biçimde teşvik edilir.

13.5 WebRTC tarafından açığa çıkarılan kalıcı bilgiler

Yukarıda açıklandığı gibi, WebRTC API'si tarafından açığa çıkarılan IP adresleri listesi, kalıcı bir kökenler arası durum olarak kullanılabilir.

IP adreslerinin ötesinde, WebRTC API'si RTCRtpSender.getCapabilities ve RTCRtpReceiver.getCapabilities yöntemleri aracılığıyla, sistemin üretebildiği ve tüketebildiği codec'lere ilişkin ayrıntılı ve sıralı bilgiler dâhil olmak üzere, alttaki medya sistemi hakkında bilgi açığa çıkarır.

Parmak izi riski: Bu bilgilerin bir alt kümesi, oturum müzakeresi sırasında üretilen SDP oturum tanımlarında temsil edilmesi muhtemeldir. Bu bilgiler çoğu durumda zaman ve kökenler boyunca kalıcıdır ve belirli bir aygıtın parmak izi yüzeyini artırır.

DTLS bağlantıları kurulurken, WebRTC API'si uygulama tarafından kalıcı hâle getirilebilen sertifikalar üretebilir (ör. IndexedDB'de). Bu sertifikalar kökenler arasında paylaşılmaz ve köken için kalıcı depolama temizlendiğinde silinir.

13.6 Uzak uç noktalardan SDP ayarlama

setRemoteDescription, hatalı biçimlendirilmiş ve geçersiz SDP'ye karşı istisnalar fırlatarak koruma sağlar, ancak uygulama için beklenmedik olabilecek SDP'ye karşı herhangi bir koruma sağlamaya çalışmaz.

Uzak tanımın ayarlanması aşağıdaki sonuçlara yol açabilir:

Önemli kaynakların tahsis edilmesi (görüntü arabellekleri ve ağ portları dâhil)
Medyanın akmaya başlaması (gizlilik ve bant genişliği etkileri olabilir)
Kaynak yoksunluğu riski
İstemeden gelen medyaya izin verme
Diğer uç nokta gönderim müzakeresi yapmadığında ontrack gibi belirli olayların tetiklenmemesi

Uyarı: Kötücül SDP'ye karşı önlem almayan uygulamalar, ciddi güvenlik riskleriyle karşılaşabilir. Uygulamaların zararlı SDP'ye karşı dikkatli olması gerekir.

14. Erişilebilirlik Hususları

Bu bölüm normatif değildir.

WebRTC 1.0 belirtimi, gerçek zamanlı ses, video ve veri alışverişini kurmak için gerekli olan (IETF içinde tanımlanan) protokolleri denetlemek üzere bir API sunar.

14.1 Gerçek Zamanlı Metin ve TDD/TTY

Telekomünikasyon İşitme Engelliler Cihazı (TDD/TTY), işitme veya konuşma engeli olan bireylerin (diğerlerinin yanı sıra) telefon hatları üzerinden iletişim kurmasını sağlar.

RFC 4103 — Gerçek Zamanlı Metin (Real-Time Text): RTP içinde kapsüllenmiş T.140'ı kullanarak TDD/TTY cihazlarından IP tabanlı iletişimlere geçişi mümkün kılar; buna Kamu Güvenliği Erişim Noktaları (PSAP) ile acil durum iletişimi de dahildir.

14.2 Veri kanalı üzerinden destek

Gerçek Zamanlı Metin, neredeyse gerçek zamanlı olarak veri gönderme ve alma yeteneği gerektirdiğinden, en iyi şekilde WebRTC 1.0 veri kanalı API'si üzerinden desteklenebilir.

IETF tarafından tanımlandığı üzere, veri kanalı protokolü SCTP/DTLS/UDP protokol yığınını kullanır ve hem güvenilir hem de güvenilir olmayan veri kanallarını destekler. IETF, SRTP anahtar yönetimine dayanan ve güvenilir olmayan iletişimlere odaklanan RTP veri kanalı önerileri yerine SCTP/DTLS/UDP'yi standartlaştırmayı tercih etmiştir.

14.3 Standartlaştırma boşluğu

IETF, WebRTC protokol paketinin bir parçası olarak RTP veri kanalından farklı bir yaklaşımı seçtiğinden, bu yayının hazırlandığı tarih itibarıyla WebRTC API'lerinin, IETF'de tanımlandığı ve ABD (FCC) düzenlemelerinde uygulandığı şekliyle Gerçek Zamanlı Metni doğrudan desteklemesi için standartlaştırılmış bir yol bulunmamaktadır.

WebRTC Çalışma Grubu, bu alanda gelişmekte olan IETF protokollerinin tarayıcı API'lerinde doğrudan sunulmasını gerektirip gerektirmediğini değerlendirecek ve bu potansiyel boşluk hakkında ilgili kullanıcı topluluklarından geri bildirim talep etmektedir.

14.4 Devam eden çalışmalar

IETF MMUSIC Çalışma Grubu bünyesinde, Gerçek zamanlı metnin WebRTC veri kanalı üzerinden gönderilmesini mümkün kılacak çalışmalar sürmektedir; bu sayede SCTP veri kanalı protokolü ile RFC 4103 Gerçek Zamanlı Metin arasında çeviri yapan ağ geçitlerinin devreye alınmasına olanak tanınacaktır.

Bu çalışma tamamlandığında, ağ geçidi aracılığıyla ya da başka yollarla WebRTC kullanıcı ajanlarında (tarayıcılar dâhil) gerçek zamanlı metnin entegrasyonu için birleşik ve birlikte çalışabilir bir yaklaşım sağlaması beklenmektedir.

14.5 Geçici çözüm

Bu yayının hazırlandığı tarih itibarıyla, WebRTC istemcilerinde etkili RTT desteği sağlayan ağ geçitleri — örneğin özel bir WebRTC veri kanalı aracılığıyla — geliştirilebilir. Bu durum, SCTP veri kanalı protokolü ve RFC 4103 Gerçek Zamanlı Metin gibi IETF protokolleri üzerinden gelecekte standartlaştırılmış ağ geçitleri etkinleştirilene kadar yeterli görülmektedir.

Bunun, RTT desteğinin uluslararası düzeyde etkili ve tutarlı bir biçimde standartlaştırılması için W3C gruplarındaki ilgili çalışmalarla birlikte IETF'de tanımlanması gerekecektir.

← 12. Olay Özeti Ek A. Aday Değişiklikler →