IETF · Standards Track · Ocak 2021

RFC 8826

WebRTC için Güvenlik Hususları

Yazarlar: E. Rescorla · Mozilla
Tüm RFC'ler Orijinal RFC

Internet Engineering Task Force (IETF)

Request for Comments: 8826

Kategori: Standartlar İzleme

ISSN: 2070-1721

Yazar: E. Rescorla, Mozilla

Tarih: Ocak 2021

#Özet

WebRTC, tarayıcılarda dağıtılabilen gerçek zamanlı uygulamalarla kullanılmak üzere bir protokol paketidir — "Web üzerinde gerçek zamanlı iletişim". Bu belge, WebRTC tehdit modelini tanımlar ve bu model kapsamında WebRTC’nin güvenlik tehditlerini analiz eder.

#1. Giriş

Real-Time Communications on the Web (RTCWEB) Çalışma Grubu, Web tarayıcıları arasında gerçek zamanlı iletişim için protokolleri standartlaştırmıştır; bu protokoller genel olarak "WebRTC" [RFC8825] olarak adlandırılır. WebRTC teknolojisinin başlıca kullanım alanları gerçek zamanlı ses ve/veya görüntü aramaları, Web konferansları ve doğrudan veri aktarımıdır. Çoğu geleneksel gerçek zamanlı sistemin (örneğin SIP tabanlı [RFC3261] yazılım telefonları) aksine, WebRTC iletişimleri doğrudan bir Web sunucusu tarafından denetlenir. Basit bir durum aşağıda gösterilmektedir.

+----------------+
|                |
|   Web Sunucusu |
|                |
+----------------+
    ^        ^
   /          \
HTTPS        HTTPS
  veya        veya
WebSockets  WebSockets
  v            v
JS API      JS API
+-----------+  +-----------+
|           |  |           |
|  Tarayıcı |<>|  Tarayıcı |
|           |  |           |
+-----------+  +-----------+
    Alice         Bob

Şekil 1: Basit Bir WebRTC Sistemi

Şekil 1’de gösterilen sistemde, Alice ve Bob’un her ikisi de WebRTC özellikli tarayıcılara sahiptir ve bir arama hizmeti işleten bir Web sunucusunu ziyaret ederler. Tarayıcılarının her biri, Web sunucusu tarafından Alice ile Bob arasında bir arama kurmak için kullanılan, standartlaştırılmış JavaScript (JS) arama API’lerini (tarayıcı yerleşikleri olarak uygulanmış) sunar. Web sunucusu ayrıca, tarayıcılar arasında denetim iletilerini taşımak için sinyalizasyon kanalı olarak da görev yapar. Bu sistem topolojik olarak geleneksel bir SIP tabanlı sisteme (Web sunucusunun sinyalizasyon hizmeti, tarayıcıların ise yazılım telefonları olarak davrandığı) benzer olsa da, denetim merkezi Web sunucusuna taşınmıştır; tarayıcı yalnızca arama hizmeti tarafından kullanılan API noktalarını sağlar. Her Web uygulamasında olduğu gibi, Web sunucusu mantığı sunucu ile tarayıcıdaki JavaScript arasında taşıyabilir; ancak kodun nerede çalıştığından bağımsız olarak, nihayetinde sunucunun denetimi altındadır.

Bu tür bir sistemin, geleneksel bir Voice over IP (VoIP) sisteminin ötesinde yeni güvenlik zorlukları ortaya koyduğu hemen fark edilmelidir. Özellikle, kötü niyetli arama hizmetleriyle başa çıkması gerekir. Örneğin, arama hizmeti tarayıcının istediği herhangi bir zamanda, kendi seçtiği herhangi bir alıcıyı aramasına neden olabiliyorsa, bu yetenek kullanıcının bilgisayarını bilgisi dışında dinlemek için kullanılabilir; yalnızca bir kayıt hizmetine arama yerleştirilmesi yeterlidir. Daha incelikli olarak, açığa çıkarılan API’ler sunucunun tarayıcıya rastgele içerik göndermesini emredebilmesine izin veriyorsa, bunlar güvenlik duvarlarını aşmak veya hizmet engelleme (DoS) saldırıları düzenlemek için kullanılabilir. Başarılı herhangi bir sistemin, bu ve diğer saldırılara karşı dayanıklı olması gerekir.

Eşlik eden bir belge [RFC8827], bu belgede ele alınan sorunları çözmeyi amaçlayan bir güvenlik mimarisini açıklar.

#2. Terminoloji

Bu belgede yer alan "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" ve "OPTIONAL" anahtar sözcükleri, yalnızca burada gösterildiği gibi tamamen büyük harflerle göründüklerinde, BCP 14 [RFC2119] [RFC8174]’te açıklandığı şekilde yorumlanacaktır.

#3. Tarayıcı Tehdit Modeli

WebRTC için güvenlik gereksinimleri, tarayıcının görevinin kullanıcıyı korumak olması gereksiniminden doğrudan türetilir. Huang ve diğerleri [huang-w2sp], temel tarayıcı güvenlik güvencesini şu şekilde özetler:

Kullanıcılar, rastgele Web sitelerini güvenli bir şekilde ziyaret edebilir ve bu siteler tarafından sağlanan betikleri çalıştırabilir.

Bunun, rastgele kötü niyetli betikler barındıran siteleri de kapsadığını fark etmek önemlidir. Bu gereksinimin motivasyonu basittir: saldırganların kullanıcıları kendi seçtikleri sitelere yönlendirmesi son derece kolaydır. Örneğin, bir saldırgan, kullanıcıyı (otomatik olarak veya kullanıcının tıklaması yoluyla) kendi sitesine yönlendiren görüntülü reklamlar satın alabilir; bu noktada tarayıcı saldırganın betiklerini çalıştıracaktır. Dolayısıyla, rastgele kötü niyetli sayfaların görüntülenmesinin güvenli olması kritik önemdedir. Elbette, tarayıcılar kaçınılmaz olarak bu hedeften sapmalarına neden olan hatalara sahiptir; ancak herhangi bir yeni WebRTC işlevi, bu standardı karşılamayı amaçlayacak şekilde tasarlanmalıdır. Bu bölümün geri kalanı, mevcut Web güvenlik modeli hakkında daha fazla arka plan bilgisi sunar.

Bu modelde, tarayıcı hem kullanıcının bakış açısından hem de belirli bir ölçüde sunucunun bakış açısından Güvenilir Hesaplama Tabanı (Trusted Computing Base - TCB) olarak hareket eder. Sunucu tarafından sağlanan HTML ve JavaScript, tarayıcının çeşitli eylemleri yürütmesine neden olabilse de, bu betikler aşağıda ayrıntılandırıldığı üzere hem kullanıcının bilgisayarından hem de birbirlerinden yalıtan bir sandbox içinde çalışır.

Geleneksel olarak, ya sizi sitelerini ziyaret etmeye yönlendirebilen ancak ağı denetlemeyen Web saldırganlarından ya da ağınızı denetleyebilen ağ saldırganlarından söz ederiz. Ağ saldırganları, [RFC3552] "İnternet Tehdit Modeli"ne karşılık gelir. Bazı durumlarda bir ağ saldırganının aynı zamanda bir Web saldırganı olabileceğine dikkat edin; çünkü bütünlük koruması sağlamayan taşıma protokolleri, ağın herhangi bir iletişim eşininmiş gibi trafik enjekte etmesine izin verir. TLS ve özellikle HTTPS bu saldırıları engeller; ancak HTTP bağlantılarını analiz ederken, trafiğin saldırgana gittiğini varsaymak zorundayız.

3.1. Yerel Kaynaklara Erişim

Tarayıcı, anahtarlama materyali, dosyalar, kamera ve mikrofon gibi yerel kaynaklara erişime sahip olsa da, Web sunucularının aynı kaynaklara erişimini sıkı biçimde sınırlar veya tamamen yasaklar. Örneğin, dosya yüklemeye izin veren bir HTML formu oluşturmak mümkün olsa da, bir betik bunu kullanıcı onayı olmadan yapamaz ve hatta belirli bir dosyayı (örneğin /etc/passwd) önermesi bile mümkün değildir; kullanıcının dosyayı açıkça seçmesi ve yüklenmesine onay vermesi gerekir. (Not: Birçok durumda tarayıcılar, "güvenlik kontrollerini atlamak için buraya tıklayın" anlamına gelen iletişim kutularından özellikle kaçınacak şekilde tasarlanmıştır; kapsamlı araştırmalar [cranor-wolf], kullanıcıların bu tür durumlarda onay vermeye yatkın olduğunu göstermektedir.)

Benzer şekilde, Flash programları (SWF’ler) [SWF] kamera ve mikrofona erişebilse de, bu erişim için açıkça kullanıcı onayı gerektirir. Ayrıca, bazı kaynaklara tarayıcıdan hiç erişilemez. Örneğin, belirli çalıştırılabilir dosyaları doğrudan bir betikten çalıştırmanın gerçekçi bir yolu yoktur (elbet kullanıcı çalıştırılabilir dosyaları indirmeye ve çalıştırmaya yönlendirilebilir).

3.2. Aynı-Köken Politikası

Diğer birçok kaynak erişilebilir ancak yalıtılmıştır. Örneğin, betiklerin fetch() API’si aracılığıyla HTTP istekleri yapmasına izin verilse de (bkz. [fetch]), istekler betiğin geldiği aynı köken dışındaki bir sunucuya yapıldığında [RFC6454], yanıtları okuyamazlar. Aşağıda açıklandığı üzere, Çapraz Köken Kaynak Paylaşımı (CORS) [fetch] ve WebSockets [RFC6455] bu kısıtlamadan çıkış yolları sağlar. Bu aynı-köken politikası (SOP), sunucu A’nın kullanıcının tarayıcısı üzerinden sunucu B’ye saldırılar düzenlemesini engeller; bu hem kullanıcıyı (örneğin kimlik bilgilerinin kötüye kullanılmasına karşı) hem de sunucu B’yi (örneğin DoS saldırılarına karşı) korur.

Daha genel olarak SOP, her sitenin betiklerinin kendi yalıtılmış sandbox’larında çalışmasını zorunlu kılar. Etkileşime izin veren teknikler mevcut olsa da, bu etkileşimler genellikle karşılıklı rızaya (her site tarafından) dayanır ve belirli kanallarla sınırlıdır. Örneğin, aynı kökenden gelen birden fazla sayfa veya tarayıcı bölmesi birbirlerinin JS değişkenlerini okuyabilir; ancak farklı kökenlerden gelen sayfalar — hatta aynı sayfadaki farklı kökenlerden IFRAME’ler — bunu yapamaz.

3.3. SOP’nin Aşılması: CORS, WebSockets ve İletişim İçin Onay

SOP önemli bir güvenlik işlevi görse de, belirli uygulama sınıflarını yazmayı zorlaştırır. Özellikle, köken A’dan gelen bir betiğin köken B’den kaynakları kullandığı mash-up’lar, ancak belirli ölçüde hileli yöntemlerle elde edilebilir. W3C CORS belirtimi [fetch], bu talebe bir yanıttır. CORS’ta, köken A’dan gelen bir betik potansiyel olarak güvensiz bir çapraz köken isteği yürüttüğünde, tarayıcı bunun yerine hedef sunucuyla iletişime geçerek A’dan gelen çapraz köken isteklerine izin vermeye istekli olup olmadığını belirler. Eğer istekliyse, tarayıcı isteğe izin verir. Bu onay doğrulama süreci, çapraz köken isteklerinin güvenli biçimde yapılmasına olanak tanıyacak şekilde tasarlanmıştır.

CORS, çapraz köken HTTP isteklerine izin vermek üzere tasarlanmışken, WebSockets [RFC6455] çapraz köken şeffaf kanalların kurulmasına olanak tanır. Bir betikten bir siteye WebSockets bağlantısı kurulduktan sonra, betik trafiği bir dizi HTTP istek/yanıt işlemi olarak çerçevelemek zorunda kalmadan, istediği herhangi bir trafiği değiş tokuş edebilir. CORS’ta olduğu gibi, bir WebSockets işlemi de betiklerin başka bir kökene rastgele veri göndermesine izin verilmesini önlemek amacıyla bir onay doğrulama aşamasıyla başlar.

Onay doğrulama kavramsal olarak basit olsa da — gerçek veriyi değiştirmeye başlamadan önce bir el sıkışma yapmak yeterlidir — deneyimler, doğru bir onay doğrulama sistemi tasarlamanın zor olduğunu göstermiştir. Özellikle, Huang ve diğerleri [huang-w2sp], mevcut Java ve Flash onay doğrulama tekniklerinde ve WebSockets el sıkışmasının basitleştirilmiş bir sürümünde güvenlik açıkları göstermiştir. Saldırgan betiğin, Web dışı bir protokol durum makinesi tarafından kabul edilebilir trafik ürettiği çapraz protokol saldırılarına karşı dikkatli olmak önemlidir. Bu saldırı biçimine direnmek için WebSockets, tel üzerindeki bitleri rastgeleleştirmeyi amaçlayan bir maskeleme tekniği içerir; böylece belirli bir protokole benzeyen trafik üretmek daha zor hâle gelir.

#4. WebRTC Uygulamaları için Güvenlik

4.1. Yerel Cihazlara Erişim

Bölüm 1’de tartışıldığı üzere, rastgele sitelerin arama başlatmasına izin vermek, temel Web güvenlik güvencesini ihlal eder; yerel cihazlara yönelik bazı erişim kısıtlamaları olmaksızın, herhangi bir kötü niyetli site bir kullanıcıyı kolayca dinleyebilir. En azından, rastgele sitelerin kullanıcı onayı olmadan rastgele konumlara arama başlatması MÜMKÜN OLMAMALIDIR. Ancak bu durum, kullanıcı onayının kapsamının ne olması gerektiği sorusunu da hemen gündeme getirir.

Kullanıcının bir aramaya izin verip vermeme (ve dolayısıyla kamera ve mikrofon girdilerinin bir yere yönlendirilip yönlendirilmeyeceği) konusunda bilinçli bir karar verebilmesi için, ya kimin erişim talep ettiğini, medyanın nereye gittiğini ya da her ikisini birden anlaması gerekir. Aşağıda ayrıntılandırıldığı üzere, iki temel kavramsal model vardır:

  1. Medyanızı varlık A’ya gönderiyorsunuz; çünkü varlık A ile konuşmak istiyorsunuz (örneğin anneniz).
  2. Varlık A (örneğin bir arama hizmeti), medyayı varlık B’ye (örneğin anneniz) aktaracağı güvencesiyle kullanıcının cihazlarına erişim talep eder.

Her iki durumda da kimlik, herhangi bir onay kararının merkezinde yer alır. Dahası, tarayıcının anlamlı biçimde zorlayabildiği tek şey, tarayıcının bağlandığı tarafın kimliğidir; eğer A’yı arıyorsanız, A medyayı kolayca C’ye iletebilir. Benzer şekilde, A’ya B’yi araması için yetki verirseniz, A bunun yerine C’yi arayabilir. Her iki durumda da tarayıcının yapabildiği tek şey, medyanın nereye gideceğini denetleyen taraf için doğrulama yapmak ve yetkilendirmeyi kontrol etmektir. Medyanın hedefi elbette bir güvenlik/gizlilik politikası ilan edebilir; ancak bu, tarayıcının zorlayabileceği bir şey değildir. Yine de, farklı teknik onay mekanizmalarını motive eden çeşitli onay senaryoları vardır. Bu mekanizmaları aşağıdaki bölümlerde ele alıyoruz.

Yerel cihazlara erişim için verilen onayın, ağ üzerinden çeşitli türlerde veri iletimine onay vermekten büyük ölçüde ortogonal olduğunu anlamak önemlidir (bkz. Bölüm 4.2). Cihaz erişimi için onay, esas olarak kullanıcının gizliliğini kötü niyetli sitelerden korumakla ilgilidir. Buna karşılık, ağ trafiği göndermeye onay vermek, kullanıcının tarayıcısının yerel ağına saldırmak için kullanılmasını önlemekle ilgilidir. Dolayısıyla, site kameraya ve mikrofona hiç erişemese bile iletişim onayını sağlamamız gerekir (bu nedenle WebSockets’in onay mekanizması vardır) ve benzer şekilde, veriler geleneksel HTTP tabanlı ağ mekanizmaları (örneğin HTTP POST) aracılığıyla siteye geri gönderilecek olsa bile sitenin kullanıcının kamerasına ve mikrofonuna erişmesi konusunda da endişe duymamız gerekir.

4.1.1. Ekran Paylaşımından Kaynaklanan Tehditler

Kamera ve mikrofon erişimine ek olarak, ekran ve/veya uygulama paylaşımı işlevselliğine yönelik bir talep ortaya çıkmıştır. Ne yazık ki, bu işlevselliğin güvenlik etkileri, kullanıcıların kamera ve mikrofon erişimine kıyasla sezgisel olarak analiz etmesi çok daha zordur. (Ayrıntılı bir analiz için https://lists.w3.org/Archives/Public/public-webrtc/2013Mar/0024.html adresine bakın.)

En belirgin tehditler, basitçe "aşırı paylaşım"dır; yani kullanıcı bir pencere paylaştığını sanırken gerçekte bir uygulamayı paylaşıyor olabilir ya da tüm ekranını, simgeleri, bildirimleri ve her şeyi paylaştığını unutabilir. Bu durum mevcut ekran paylaşım teknolojilerinde zaten bir sorundur ve kaynağın paylaşılmasını isteme sorumluluğu kullanıcının kendisi yerine kısmen güvenilen bir siteye verildiğinde biraz daha da kötüleşir.

Daha az belirgin bir tehdit, ekran paylaşımının Web güvenlik modeli üzerindeki etkisini içerir. Aynı-Köken Politikası’nın temel bir parçası, A sitesinden gelen HTML veya JS’nin B sitesindeki içeriğe başvurabilmesi ve tarayıcının bunu yüklemesine neden olabilmesidir; ancak (açıkça izin verilmedikçe) sonucu göremez. Bununla birlikte, bir siteden gelen bir Web uygulaması tarayıcıyı ekran paylaşımı yoluyla paylaşıyorsa, bu değişmezi ihlal eder ve ciddi güvenlik sonuçları doğurur. Örneğin, bir saldırgan site ekran paylaşımı talep edebilir ve ardından kullanıcının bankasına ya da web e‑posta hesabına kısa süreliğine yeni bir pencere açarak, ortaya çıkan görüntülenen içeriği ekran paylaşımı üzerinden okuyabilir. Daha sofistike bir saldırı, bir sitenin kaynak görünümü penceresini açmak ve ekran paylaşımı çıktısını kullanarak siteler arası istek sahteciliğine karşı koruma belirteçlerini (anti-CSRF token’ları) görüntülemek olabilir.

Bu tehditler, ekran/uygulama paylaşımının kamera veya mikrofona erişime kıyasla daha yüksek düzeyde bir kullanıcı onayı gerektirebileceğini göstermektedir.

4.1.2. Arama Senaryoları ve Kullanıcı Beklentileri

Çok sayıda olası arama senaryosu bulunmakla birlikte, bu bölümde ele alınan senaryolar, onayın ilgili kapsamını belirlemenin birçok zorluğunu ortaya koymaktadır.

4.1.2.1. Özel Arama Hizmetleri

Ele aldığımız ilk senaryo, özel bir arama hizmetidir. Bu durumda kullanıcı, bir arama sitesiyle ilişki kurar ve bu sitede tekrar tekrar aramalar yapar. Her arama için izin vermek zorunda kalmak yerine, kullanıcının arama hizmetine kamera ve mikrofona uzun vadeli erişim izni vermek istemesi muhtemeldir. Bu, uzun vadeli bir onay mekanizmasıyla doğal olarak uyumludur (örneğin, arama hizmeti için izin verildiğini göstermek amacıyla bir uygulama mağazası "uygulaması" yüklemek). Özel arama hizmetinin bir varyantı, oyuncuların birbirleriyle konuşabilmesi için özel bir arama hizmeti barındıran bir oyun sitesidir (örneğin bir poker sitesi).

Kullanıcının aynı hizmeti birçok farklı kişiyle konuşmak için kullanabileceği her tür hizmette, kullanıcının kiminle konuştuğunu bilip bilemeyeceği sorusu ortaya çıkar. Arama hizmeti A’ya benim adıma arama yapma izni verirsem, örtük olarak bilgisayarımı istediği zaman dinleyebilmesine de izin vermiş olurum. Bu durum, bir sitenin arama yapma yetkisine sahip olduğu ancak yalnızca belirli hedef varlıklara (Bölüm 4.3.2 ve özellikle Bölüm 4.3.2.3’te açıklandığı üzere medya düzlemi kriptografik mekanizmalarıyla tanımlanan) arama yapabildiği başka bir onay modelini düşündürmektedir. Buradaki onay sorusunun, eş kimliği (peer identity) sorusuyla ilişkili ancak ondan farklı olduğunu unutmayın: Bir arama sitesinin genel olarak benim adıma arama başlatmasına izin vermeye istekli olabilirim, ancak yine de bu site üzerinden yapılan bazı aramalarda sitenin dinlemediğinden emin olmak isteyebilirim.

4.1.2.2. Bulunduğunuz Siteyi Aramak

Bir başka basit senaryo, gerçekten ziyaret etmekte olduğunuz siteyi aramaktır. Buradaki tipik örnek, birçok alışveriş sitesinde görünen "bir temsilciyle konuşmak için buraya tıklayın" pencereleridir. Bu durumda kullanıcının beklentisi, ziyaret ettiği siteyi aradığı yönündedir. Ancak, böyle bir siteye genel bir onay vermek istemesi pek olası değildir; bir araba hakkında bilgi istemem, otomobil üreticisinin mikrofonumu istedikleri zaman etkinleştirebilmesi anlamına gelmez. Dolayısıyla bu, yalnızca belirli bir aramanın süresi boyunca onay verdiğim ikinci bir onay mekanizmasına duyulan ihtiyacı göstermektedir. Bölüm 3.1’de açıklandığı gibi, kullanıcıların sadece tıklayıp geçmesini önlemek için bu arayüzün tasarımında büyük özen gösterilmelidir. Ayrıca, kullanıcı arayüzü chrome’u — yani kullanıcının kullanıcı aracısının kendisiyle etkileşime geçtiği temsil — aramanın devam ettiğini açıkça gösteren öğeleri sergilemelidir; aksi takdirde arama yapan sitenin aramayı süresiz olarak açık bırakıp, bunun tersini ima eden bir Web arayüzü göstermesi gibi saldırılar mümkün olabilir.

4.1.3. Köken Tabanlı Güvenlik

Arama senaryolarını tanımladığımıza göre, artık güvenlik gereksinimleri hakkında akıl yürütebiliriz.

Bölüm 3.2’de tartışıldığı üzere, Web sandboxing’in temel birimi kökendir ve bu nedenle onayı kökene göre kapsamlandırmak doğaldır. Özellikle, A kökeninden gelen bir betiğin, yalnızca kullanıcı o köken için erişimi açıkça yetkilendirmişse iletişim başlatmasına (ve dolayısıyla kamera ve mikrofona erişmesine) İZİN VERİLMELİDİR. Elbette daha geniş kapsamlı izinlere teknik olarak sahip olmak mümkündür, ancak Web modeli kökene göre kapsamlandığından bu durum zor bir uyumsuzluk oluşturur.

Tartışmalı olmakla birlikte, köken yeterince ince taneli olmayabilir. Alice’in bir siteyi ziyaret edip tek bir arama yapması için yetkilendirdiği durumu düşünün. Onay yalnızca köken açısından ifade edilirse, o siteye gelecekte yapılacak herhangi bir ziyarette (bir mash‑up ya da reklam ağı aracılığıyla tetiklenenler dâhil) site Alice’in bilgisayarını dinleyebilir, bilgisayarı sahte aramalar yapmak için kullanabilir vb. İlke olarak Alice ayrıcalığı verip sonra geri alabilir, ancak pratikte ayrıcalıklar birikir; bu saldırıdan endişe ediyorsak başka bir şeye ihtiyaç vardır. Bu tür bir soruna karşı bir dizi olası karşı önlem bulunmaktadır.

Bireysel Onay Her arama için kullanıcıdan izin istemek.

Aranan Taraf Odaklı Onay Yalnızca belirli bir kullanıcıya arama yapılmasına izin vermek.

Kriptografik Onay Yalnızca belirli bir eş anahtarlama materyali kümesine veya kriptografik olarak kurulmuş bir kimliğe arama yapılmasına izin vermek.

Ne yazık ki, bu yaklaşımların hiçbiri tüm durumlar için tatmin edici değildir. Yukarıda tartışıldığı gibi, bireysel onay, her arama için kullanıcının onayını kullanıcı arayüzü akışına yerleştirir. Bu, hızla rahatsız edici hâle gelmekle kalmaz, aynı zamanda kullanıcıyı sadece "OK" düğmesine basmaya alıştırabilir; bu noktada onay anlamsızlaşır. Dolayısıyla bazı durumlarda bireysel onaya ihtiyaç duyulabilse de, bu (örneğin) arama hizmeti senaryosu için uygun bir çözüm değildir. Gerekli olduğunda, akış içi kullanıcı arayüzleri, kullanıcının düşünmeden tıklaması riskini azaltacak şekilde dikkatle tasarlanmalıdır.

Diğer iki seçenek, aramaları belirli bir hedefle sınırlandırmak üzere tasarlanmıştır. Arama sitesinin sağladığı aranan taraf odaklı onay iyi çalışmaz; çünkü kötü niyetli bir site, kullanıcının istediği herhangi bir kullanıcıyı aradığını iddia edebilir. Bunun bir çözümü, aramaları kriptografik olarak kurulmuş bir kimliğe bağlamaktır. Tüm durumlar için uygun olmasa da, bu yaklaşım bazıları için faydalı olabilir. Reklamcılık durumunu ele alırsak, reklamverenin izin almak için barındıran sitede bir IFRAME başlatmasını zorunlu kılmak pek kullanışlı değildir; daha elverişli bir yaklaşım, reklamverenin sertifikasını doğrudan iletişime kriptografik olarak bağlamaktır. Burada hâlâ izinleri kökene bağlıyoruz, ancak Web kökeni yerine medya kökenine (ve/veya hedefe) bağlıyoruz. [RFC8827], bu tür bir onayı kolaylaştıran mekanizmaları tanımlar.

Medya düzeyinde kriptografik kimliğin anlamlı olduğu bir başka durum, kullanıcının arama sitesine gerçekten güvenmediği durumlardır. Örneğin, arama hizmetinin bilgisayarımı dinlemeye çalışacağından endişe edebilirim; ancak yine de arkadaşlarımı kolayca aramak isterim. Onay belirli iletişim uç noktalarına bağlanırsa, riskim sınırlanır. Doğal olarak, bu tür bir politikayı ifade eden kullanıcı arayüzü ilkel yapılarını tasarlamak bir miktar zorludur. Çok kullanıcılı arama durumlarında bu sorun daha da zorlaşır.

4.1.4. Arama Sayfasının Güvenlik Özellikleri

Köken tabanlı güvenlik, Web saldırganlarına karşı koruma sağlamayı amaçlar. Ancak ağ saldırganları durumunu da dikkate almamız gerekir. HTTP şemasına sahip bir kökenden (örneğin http://calling-service.example.com) bir arama hizmetine izin verdiğim durumu düşünün. Bilgisayarımı güvenli olmayan bir ağda (örneğin bir hotspot ya da kendi ev kablosuz ağım güvensizse) kullandığımda ve herhangi bir HTTP sitesine göz attığımda, bir saldırgan bilgisayarımı dinleyebilir. Saldırı şu şekilde ilerler:

  1. http://anything.example.org/ adresine bağlanırım. Bu sitenin arama hizmetiyle ilişkili olmadığını unutmayın.
  2. Saldırgan, HTTP bağlantımı değiştirerek http://calling-service.example.com adresine bir IFRAME (veya bir yönlendirme) enjekte eder.
  3. Saldırgan, http://calling-service.example.com adresinden gelen yanıtı sahteleyerek kendilerine bir arama başlatacak JS enjekte eder.

Bu saldırının medyanın güvensiz olmasına bağlı olmadığını unutmayın. Arama saldırgana yapıldığı için, arama onlara doğru da şifrelenmiştir. Ayrıca bunun hemen gerçekleştirilmesi gerekmez; saldırgan kökeni yarı kalıcı biçimde "enfekte" edebilir (örneğin bir Web worker veya ana pencerenin altında gizlenen açılır bir pencere ile) ve böylece enfekte ağdan ayrıldıktan çok sonra bile beni dinleyebilir. Bu risk, HTTP üzerinden getirilen bir sayfadan aramalara hiç izin verilmesiyle ortaya çıkar.

Aramalar yalnızca HTTPS [RFC2818] sitelerinden mümkün olsa bile, bu siteler güvenilmeyen bir siteden etkin içerik (örneğin JavaScript) içeriyorsa, bu JavaScript sayfanın güvenlik bağlamında çalıştırılır. Bu, üst sayfa güvenli olsa bile bir aramanın ele geçirilmesine yol açabilir. Not: Bu sorun yalnızca güvenilmeyen içerik barındıran sayfalar ile sınırlı değildir. Belirli bir kökenden gelen herhangi bir sayfa bir saldırgandan JavaScript yüklerse, saldırganın tarayıcının o köken kavramını yarı kalıcı olarak enfekte etmesi mümkün hâle gelir.

4.2. İletişim Onayının Doğrulanması

Bölüm 3.3’te tartışıldığı üzere, Web uygulamalarına tarayıcı üzerinden sınırsız ağ erişimi verilmesi, tarayıcının, kötü niyetli site için normalde erişilemeyecek makinelere (örneğin topolojik olarak kısıtlı oldukları için; bir güvenlik duvarı veya NAT arkasında olmaları gibi) karşı bir saldırı platformu olarak kullanılma riskini beraberinde getirir. Bu tür saldırıları ve ayrıca çapraz protokol saldırılarını önlemek için, trafiğin hedefinin söz konusu trafiği almaya açıkça onay vermesini şart koşmak önemlidir. Belirli bir uç nokta için bu onay doğrulanana kadar, onay el sıkışması dışındaki trafik bu uç noktaya GÖNDERİLMEMELİDİR.

Onay doğrulamasının ağ kaynaklarının aşırı kullanımını önlemek için yeterli olmadığını unutmayın. WebRTC, bir Web sitesinin kullanıcı onayı olmaksızın iki tarayıcı örneği arasında veri akışları oluşturmasına izin verdiğinden, kötü niyetli bir site, başka bir kullanıcıya böyle bir kanal kurarak kendisine önemli bir maliyet yüklemeden kullanıcının bant genişliğinin kayda değer bir kısmını tüketebilir. Bununla birlikte, pratikte veri kaynağı olarak hareket edebilecek çok sayıda Web sitesi vardır; dolayısıyla bir saldırgan mevcut Web API’leriyle en azından aşağı yönlü bant genişliğini kullanabilir. Ancak bu potansiyel DoS vektörü, WebRTC protokolleri için yeterli tıkanıklık kontrolünün gerekliliğini pekiştirir; böylece kullanıcının bant genişliği üzerindeki diğer taleplerle adil şekilde çalışmaları sağlanır.

4.2.1. ICE

Alıcı onayını doğrulamak bir tür açık el sıkışması gerektirir; neyse ki NAT delme (hole‑punching) yapmak için zaten buna ihtiyacımız vardır. Interactive Connectivity Establishment (ICE) [RFC8445], alıcı unsurun göndericiden trafik almak istediğini doğrulamak için tasarlanmış bir el sıkışması içerir. Burada ICE’i başlatan sitenin kötü niyetli olduğu varsayılır; el sıkışmasının güvenli olabilmesi için alıcı unsur, site tarafından erişilemeyen bir değerin alındığını/bilindiğini göstermelidir (böylece sitenin yanıtları sahtelemesi önlenir). Bu hedefe ICE ile ulaşmak için, Session Traversal Utilities for NAT (STUN) işlem kimlikleri tarayıcı tarafından üretilmeli ve tanılama arayüzü dâhil hiçbir şekilde başlatıcı betiğe sunulmamalıdır. Alıcı onayının doğrulanması ayrıca alıcının belirli bir göndericiden ve belirli bir zamanda trafik almak istediğinin doğrulanmasını gerektirir; örneğin kötü niyetli bir site, diğer oturumlar için ICE kullanan bilinen sunuculara basitçe ICE denemeleri yapabilir. ICE, STUN kimlik bilgilerini oturum başına paylaşılan bir sır biçiminde kullanarak bu doğrulamayı da sağlar. Bu kimlik bilgileri Web uygulaması tarafından bilinir; ancak faydalı olabilmeleri için STUN alan unsur tarafından da bilinmesi ve kullanılması gerekir.

Tarayıcının, trafiğin hedefinin bunu almaya devam etmek isteyip istemediğini doğrulaması için de bir mekanizma gerekir. ICE keepalive’ları bildirim (indication) olduğu için burada işe yaramaz. [RFC7675], onay tazeliğini sağlamaya yönelik mekanizmayı tanımlar.

4.2.2. Maskeleme

Onay doğrulandıktan sonra bile, Huang ve diğerleri tarafından tanımlanan yanlış yorumlama saldırılarıyla ilgili hâlâ bazı endişeler vardır [huang-w2sp]. ICE el sıkışması alıcı onayını zorunlu kıldığı ve Huang’ın incelediği türden pasif DTLS proxy’lerine dair çok az kanıt bulunduğu için, DTLS ile bunun ciddi bir endişe olduğu pek görünmemektedir. Ancak RTCWEB TCP üzerinde çalışabildiğinden, saldırganların SCTP’ye girdi olarak verilen düz metni kontrol ederek şifreli metni kontrol edebileceğine dair bazı endişeler vardır. Bu risk, SCTP yığınının paketlerin çerçevelenmesini kontrol etmesi gerçeğiyle yalnızca kısmen azaltılır.

İlke olarak bir saldırganın, WebAudio API ve son derece sıkı zamanlama kontrolünün bir kombinasyonunu kullanarak Secure Real-time Transport Protocol (SRTP) paketleri üzerinde bir miktar kontrol sağlayabileceğini unutmayın. Buradaki birincil risk, SRTP’nin Traversal Using Relays around NAT (TURN) TCP üzerinden taşınması gibi görünmektedir. Bununla birlikte, SRTP paketlerinin son derece karakteristik bir paket başlığına sahip olması nedeniyle, en agresif ara birimler dışında herhangi birinin başka bir uygulama katmanı protokolünün kullanıldığını sanarak yanılması pek olası değildir.

4.2.3. Geriye Dönük Uyumluluk

Not: RTCWEB WG nihayetinde ICE kullanımını zorunlu kılmaya karar verdi. Bu bölüm, bu karar için bağlam sağlar.

ICE kullanma gereksinimi, eski (legacy) ICE kullanmayan istemcilerle uyumluluğu sınırlar. Herhangi bir denetim gereksinimini tamamen kaldırmak güvensiz görünmektedir. Önerilen tüm denetimler, tarayıcının aday trafik alıcısına bir mesaj göndermesi ve bu mesaja yanıt alınana kadar diğer trafiği göndermeyi reddetmesi ortak özelliğine sahiptir. Mesaj/yanıt çifti, Web uygulamasını kontrol eden bir saldırganın bunları sahte olarak üretemeyeceği şekilde oluşturulmalıdır; bu genellikle mesajın, yanıt içinde bir şekilde (örneğin yankılanarak, karma içine dahil edilerek vb.) kullanılmak zorunda olan gizli bir değer içermesiyle sağlanır. Bu rol için ICE dışı adaylar (eski uç noktanın genel bir adrese sahip olduğu durumlarda) şunları içerir:

  • ICE kullanmadan STUN denetimleri (yani RTC-web olmayan uç noktanın bir STUN yanıtlayıcısı kurması).
  • RTP Kontrol Protokolü’nün (RTCP) örtük bir erişilebilirlik denetimi olarak kullanılması.

RTCP yaklaşımında, WebRTC uç noktasının onay alınmadan önce sınırlı sayıda RTP paketi göndermesine izin verilir. Bu, kısa bir saldırı penceresine olanak tanır. Ayrıca, bazı eski uç noktalar RTCP’yi desteklemez; bu nedenle bu tür uç noktalar için bu çözüm çok daha maliyetlidir ve büyük olasılıkla ICE’i uygulamak daha kolay olacaktır. Bu iki nedenden ötürü, RTCP tabanlı bir yaklaşım güvenlik sorununu tatmin edici biçimde ele alıyor gibi görünmemektedir.

STUN yaklaşımında, WebRTC uç noktası alıcının bir tür STUN uç noktası çalıştırdığını doğrulayabilir; ancak STUN yanıtlayıcısı ICE kullanıcı adı/parola oluşturma sistemiyle bütünleşik değilse, WebRTC uç noktası alıcının bu belirli çağrıya rıza gösterdiğini doğrulayamaz. Bu, mevcut STUN sunucularının bant genişliği tabanlı saldırıları kaldıramayacak adreslerde işletildiği durumlarda bir sorun olabilir. Dolayısıyla bu yaklaşım da tatmin edici görünmemektedir.

Sistemler sıkı biçimde bütünleşikse (yani STUN uç noktası, ICE kimlik bilgileriyle doğrulanmış yanıtlar döndürüyorsa), bu sorun ortaya çıkmaz. Ancak böyle bir tasarım, ICE-Lite uygulamasına çok yakındır (hatta tartışmalı olarak bir tanesidir). Ara bir yaklaşım, STUN’un, WebRTC denetimlerine yanıt verdiğini ancak ICE kimlik bilgilerine dayalı bütünlük denetimleri hesaplamadığını belirten bir uzantısına sahip olmasıdır. Bu, bağımsız STUN sunucularının, eski STUN sunucularıyla karıştırılma riski olmadan kullanılmasına olanak tanır. ICE dışı eski bir çözüme ihtiyaç varsa, muhtemelen en iyi seçenek budur.

İlk rıza doğrulandıktan sonra, iki kişinin kısa süreliğine aynı IP’yi paylaştığı (örneğin bir İnternet kafede NAT arkasında) ve saldırganın ağa büyük, durdurulamaz bir trafik akışı ayarlayıp ardından ayrıldığı saldırılardan kaçınmak için, devam eden rızayı da doğrulamamız gerekir. Buradaki uygun teknolojiler, ilk rıza için olanlara oldukça benzerdir; ancak tehditler daha az şiddetli olduğundan muhtemelen daha zayıftırlar.

4.2.4. IP Konum Gizliliği

Aranan taraf ICE adaylarını gönderir göndermez, arayan taraf arananın IP adreslerini öğrenir. Arananın sunucu-yansıtmalı adresi, arananın konumu hakkında çok fazla bilgi açığa çıkarır. İzlemeyi önlemek için, uygulamalar aranan taraf yanıt verene kadar ICE müzakeresinin başlamasını bastırmak isteyebilir. Ayrıca, her iki taraf da tüm trafiği bir TURN sunucusu üzerinden zorlayarak konumunu karşı taraftan tamamen gizlemek isteyebilir.

Normal çalışmada, site tarayıcının IP adresini öğrenir; ancak bu adres Tor https://www.torproject.org veya bir VPN gibi mekanizmalarla gizlenebilir. Bununla birlikte, siteler tarayıcının IP adreslerini sağlamasına neden olabildiğinden, bu durum, kullanıcı IP adresini maskeleyen bir VPN arkasında olsa bile sitelerin kullanıcının ağ ortamı hakkında bilgi edinmesi için bir mekanizma sağlar. Uygulamalar, özellikle Tor gibi gizlilik odaklı sistemlerde, kullanıcı belirli türde VPN’ler üzerindeyse VPN dışı tüm adayları bastıran ayarlar sunmak isteyebilir. Ek bilgi için [RFC8828]’e bakınız.

4.3. İletişim Güvenliği

Son olarak, SIP dünyasından aşina olunan bir sorunu ele alıyoruz: iletişim güvenliği. Açık nedenlerle, iletişim kuran tarafların hem mesajın ele geçirilmesine hem de mesajın değiştirilmesine karşı güvenli bir kanal kurabilmesi ZORUNLUDUR. (Daha fazla ayrıntı için [RFC5479]’a bakınız.) Bu hizmet hem veri hem de ses/video için sağlanmalıdır. İdeal olarak, her iki içerik türü için de aynı güvenlik mekanizmaları kullanılmalıdır. Bu hizmeti sağlama teknolojisi (örneğin SRTP [RFC3711], DTLS [RFC6347] ve DTLS-SRTP [RFC5763]) iyi anlaşılmıştır. Ancak, tehdit modeli biraz farklı olduğundan, bu teknolojiyi WebRTC bağlamında incelememiz gerekir.

Genel olarak, geleneksel bir SIP proxy’sinin aksine, arama hizmetinin (yani Web sunucusunun) yalnızca iletişim kuran uç noktalar arasındaki kanalı değil, aynı zamanda kullanıcının tarayıcısında çalışan uygulamayı da kontrol ettiğini anlamak önemlidir. İlke olarak tarayıcının arama hizmetini devre dışı bırakıp güvenilir bilgiyi doğrudan sunması (ve belki rıza alması) mümkün olsa da, modern tarayıcılarda uygulama, mümkün olduğunca bundan kaçınmaktır. Kullanıcının belirli eylemlere rıza göstermesini gerektiren "akış içi" (in-flow) kipli iletişim kutuları, insan faktörleri araştırmalarının, son derece müdahaleci olmadıkları sürece kullanıcıların bunlara bilinçli rıza vermeden basitçe onayladığını göstermesi nedeniyle özellikle tercih edilmez [abarth-rtcweb]. Bu nedenle, neredeyse tüm kullanıcı arayüzü zorunlu olarak tarayıcı tarafından çizilecektir, ancak arama hizmetinin kontrolü altında olacaktır. Buna, sonuçta yalnızca belirli bir arama hizmeti bağlamında anlamlı olan eşin kimlik bilgileri de büyük olasılıkla dahildir.

Bu sınırlama, arama hizmeti tarafından yapılan saldırıları önlemenin tamamen umutsuz olduğu anlamına gelmez. Ancak iki saldırı sınıfını ayırt etmemiz gerekir:

Arama hizmetinin geriye dönük olarak ele geçirilmesi: Arama hizmeti bir çağrı sırasında kötü niyetli değildir, ancak sonrasında ele geçirilir ve daha eski bir çağrıya saldırmak ister (genellikle "pasif saldırı" olarak adlandırılır).

Arama sırasında arama hizmeti tarafından saldırı: Arama hizmeti, saldırmak istediği çağrı sırasında ele geçirilir (genellikle "aktif saldırı" olarak adlandırılır).

Birinci tür saldırıya karşı güvenlik sağlamak, Bölüm 4.3.1’de ele alınan teknikler kullanılarak pratiktir. Ancak, güvenilir fakat kötü niyetli bir arama hizmetinin, ya Ortadaki Adam (MITM) saldırısı düzenleyerek ya da çağrıları tamamen başka yöne çevirerek kullanıcının çağrılarına aktif olarak saldırmasını önlemek son derece zordur. (Bu saldırının, arama hizmetiyle olan iletişimler güvenli değilse, bir ağ saldırganı için de aynı şekilde geçerli olduğunu unutmayın.) Olası bazı yaklaşımları Bölüm 4.3.2’de tartışıyoruz.

4.3.1. Geriye Dönük Ele Geçirmeye Karşı Koruma

Geriye dönük bir saldırıda, arama hizmeti çağrı sırasında ele geçirilmemiştir; ancak bir saldırgan sonradan çağrının içeriğini ele geçirmek ister. Saldırganın korumalı medya akışına erişimi olduğunu ve arama hizmeti üzerinde tam kontrole sahip olduğunu varsayıyoruz.

Arama hizmetinin trafik anahtarlama materyaline erişimi varsa (Güvenlik Tanımları (SDES) [RFC4568]’de olduğu gibi), geriye dönük saldırı önemsizdir. Bu saldırı biçimi, Web bağlamında özellikle ciddidir; çünkü Web hizmetlerinde kapsamlı günlükleme ve izleme çalıştırmak standart uygulamadır. Dolayısıyla, trafik anahtarı herhangi bir HTTP isteğinin parçasıysa, bir yerde kaydedilmiş olması ve böylece sonradan ele geçirilmeye açık olması son derece olasıdır. Bu husus, WebRTC için otomatik, açık anahtar tabanlı bir anahtar değişim mekanizmasını zorunlu kılar (bu, her türlü iletişim güvenliği sistemi için iyi bir fikirdir) ve bu mekanizma İleri Gizlilik (Forward Secrecy, FS) SAĞLAMALIDIR. Sinyalizasyon kanalı/arama hizmeti bu mekanizmanın kimlik doğrulaması için kullanılabilir.

Buna ek olarak, uçtan uca anahtarlama kullanılıyorsa, sistem uzun süreli anahtarlama materyalini çıkarmaya veya depolanmış trafik anahtarlarına doğrudan erişmeye yönelik hiçbir API SUNMAMALIDIR. Aksi takdirde, sonradan arama hizmetini ele geçiren bir saldırgan bu API’leri kullanarak trafik anahtarlarını geri alabilir ve böylece trafiği tehlikeye atabilir.

4.3.2. Çağrı Sırasında Saldırıya Karşı Koruma

Çağrı sırasında yapılan saldırılara karşı koruma, daha zor bir önermedir. Arama hizmeti anahtarlama materyaline doğrudan erişemese bile (önceki bölümde önerildiği gibi), bağlantı üzerinde basitçe bir ortadaki adam saldırısı düzenleyebilir; Alice’e Bob’u aradığını, Bob’a da Alice’i aradığını söyleyerek, gerçekte arama hizmetinin bir çağrı köprüsü gibi davranıp tüm trafiği yakalamasını sağlayabilir. Bu tür bir saldırıya karşı koruma, parmak izi gibi açık bant dışı anahtar doğrulaması veya [RFC8827]’de açıklandığı gibi üçüncü taraf bir kimlik hizmeti gibi, uzak uç noktanın olumlu kimlik doğrulamasını gerektirir.

4.3.2.1. Anahtar Sürekliliği

Doğal bir yaklaşım "anahtar sürekliliği" kullanmaktır. Kötü niyetli bir arama hizmeti kullanıcıya istediği herhangi bir kimliği sunabilir; ancak belirli bir açık anahtara karşılık gelen bir özel anahtar üretemez. Bu nedenle, tarayıcının belirli bir kullanıcının açık anahtarını not etmesi ve bu kullanıcının anahtarı değiştiğinde bir alarm üretmesi mümkündür. Secure Shell (SSH) protokolü [RFC4251] benzer bir teknik kullanır. (Her çağrıda açık kullanıcı rızasından kaçınma gereksiniminin, tarayıcının eşin anahtarının derhal elle denetlenmesini istemesini engellediğini unutmayın.)

Ne yazık ki, bu tür bir anahtar sürekliliği mekanizması WebRTC bağlamında çok daha az faydalıdır. Birincisi, WebRTC’nin (ve herhangi bir Web uygulamasının) erdemlerinin büyük bir kısmı, belirli bir istemci yazılımına bağlı olmamasıdır. Dolayısıyla, bir kullanıcının farklı bilgisayarlarda birden fazla tarayıcı kullanması yalnızca mümkün değil, aynı zamanda olağandır ve bunların elbette farklı anahtarlama materyalleri olacaktır (Securely Available Credentials (SACRED) [RFC3760] buna rağmen). Sonuç olarak, kullanıcılar tamamen meşru olan anahtar uyuşmazlıkları konusunda sık sık uyarılacak ve bunun sonucunda bunları basitçe geçmeye alışacaklardır. Kullanıcıların çok daha ciddi uyarıları bile rutin olarak geçtikleri bilindiğinden [cranor-wolf], herhangi bir anahtar sürekliliği mekanizmasının etkili olmaktan ziyade yalnızca rahatsız edici olması son derece olasıdır.

Dahası, bu tür bir mekanizmayı aşmak bile son derece kolaydır. SSH durumunun aksine, tarayıcının eşin kimliğini kullanıcıdan doğrudan almadığını hatırlayın. Aksine, bu bilgi arama hizmeti tarafından sağlanır. Bu tür bir mekanizmayı etkinleştirmek bile, arama hizmetinin tarayıcıya "bu, kullanıcı X’e yapılan bir çağrıdır" demesine olanak tanıyan bir API gerektirir. Anahtar sürekliliği uyarısını tetiklemekten kaçınmak için arama hizmetinin yapması gereken tek şey, tarayıcıya "bu, kullanıcı Y’ye yapılan bir çağrıdır" demektir; burada Y, X ile karıştırılabilir durumdadır. Kullanıcı gerçekten karşı tarafın adını kontrol etse bile (mevcut tüm kanıtlar bunun pek olası olmadığını göstermektedir), bu (a) tarayıcının adı sağlamak için güvenilir kullanıcı arayüzünü kullanmasını ve (b) kullanıcının benzer görünen adlar tarafından aldatılmamasını gerektirir.

4.3.2.2. Kısa Kimlik Doğrulama Dizgeleri

ZRTP [RFC6189], anahtar anlaşma protokolünden türetilen bir "Kısa Kimlik Doğrulama Dizgesi" (Short Authentication String, SAS) kullanır. Bu SAS, kullanıcılar tarafından karşılaştırılmak üzere tasarlanmıştır (örneğin ses kanalı üzerinden yüksek sesle okunarak veya bant dışı bir kanal aracılığıyla iletilerek) ve her iki tarafça doğrulanırsa MITM saldırısını engeller. Amaç, SAS’in bir kez kullanılması ve ardından anahtar sürekliliğinin (yukarıda tartışılandan farklı bir mekanizma ile) devreye girmesidir.

Ne yazık ki, SAS ele geçirilmiş bir arama hizmeti sorununa pratik bir çözüm sunmaz. Belirli bir konuşmacının sesini taklit eden "ses klonlama" sistemleri, aktif bir araştırma alanıdır [deepfakes-ftc] ve halihazırda gerçek dünyadaki saldırılarda kullanılmaktadır [deepfakes-fraud]. Bu saldırıların gelecekte, özellikle kullanıcının sadece telefon görüşmesine devam etmek istediği bir ortamda, daha da gelişmesi muhtemeldir. Dolayısıyla, SAS bugün etkili olsa bile, çok uzun süre böyle kalması olası değildir.

Buna ek olarak, kullanıcıların SAS’i gerçekten kullanıp kullanmayacağı da belirsizdir. Yukarıda tartışıldığı gibi, tarayıcı kullanıcı arayüzü kısıtları, çağrı tamamlanmadan önce SAS değişimini zorunlu kılmayı engeller; dolayısıyla bu gönüllü olmalıdır. En fazla, tarayıcı SAS’in henüz kontrol edilmediğini belirten bir kullanıcı arayüzü göstergesi sunacaktır. Ancak, isteğe bağlı güvenlik mekanizmalarıyla karşılaşıldığında birçok kullanıcının bunları basitçe yok saydığı iyi bilinmektedir [whitten-johnny].

Kullanıcılar SAS’i bir kez kontrol ettikten sonra, her çağrıda kontrol etmek zorunda kalmamaları için anahtar sürekliliği gerekir. Ancak bu, Bölüm 4.3.2.1’de belirtilen nedenlerden ötürü sorunludur. İlke olarak, çağrıların kimliği doğrulanmamış bir anahtarlama materyali kümesi kullandığını göstermek için farklı bir kullanıcı arayüzü öğesi çizmek elbette mümkündür (saldırganın, saldırının yeni bir cihaza yapılan bir çağrıya veya daha önce aramadığınız birine yapılan bir çağrıya aitmiş gibi aynı kullanıcı arayüzünü göstermesi için yalnızca biraz farklı bir ad sunabileceğini hatırlayın); ancak pratikte, kullanıcılar karışık içerik uyarılarının çok daha ciddi olduğu durumlarda bile bu tür göstergeleri basitçe görmezden gelmektedir.

4.3.2.3. Üçüncü Taraf Kimliği

İletişim kimliği sağlamanın geleneksel yaklaşımı, elbette uç noktaları doğrulamak için bir tür üçüncü taraf kimlik sistemi (örneğin PKI) kullanmak olmuştur. Bu tür mekanizmalar, tipik kullanıcılar için (ve yöneticiler için neredeyse) kullanımı fazla zahmetli olduğunu kanıtlamıştır. Ancak, Web tabanlı yeni bir kimlik sağlayıcılar nesli (BrowserID, Federated Google Login, Facebook Connect, OAuth [RFC6749], OpenID [OpenID], WebFinger [RFC7033]) geliştirilmiştir ve kullanıcı açısından hafif olan üçüncü taraf kimlik doğrulamalı işlemler sağlamak için Web teknolojilerini kullanır. Bu tür sistemleri WebRTC çağrılarını doğrulamak için kullanmak ve bunları mevcut kullanıcı kimliği anlayışlarıyla (örneğin Facebook bağlantıları) ilişkilendirmek mümkündür. Özellikle, üçüncü taraf kimlik sistemi, kullanıcının kimliğini kriptografik anahtarlama materyaline bağlamak için kullanılır; bu materyal daha sonra arama uç noktalarını doğrulamak için kullanılır. Bu şekilde doğrulanan çağrılar, arama sitesi tarafından yapılan aktif MITM saldırılarına karşı bile doğal olarak dirençlidir.

PKI tarzı sertifikaların pratik bir çözüm sağladığı özel bir durum olduğunu unutmayın: son kullanıcılardan büyük sitelere yapılan çağrılar. Örneğin Amazon.com’a bir çağrı yapıyorsanız, Amazon medya trafiğini doğrulamak için kolaylıkla bir sertifika alabilir; tıpkı Web trafiğini doğrulamak için aldığı gibi. Bu, arama sitesi ile medya eşinin aynı olduğu durumlarda ek bir güvenlik değeri sağlamaz; ancak üçüncü tarafların (örneğin reklam ağları veya perakendeciler) çağrıları ayarladığı fakat bunlara katılmadığı durumlarda yararlı olabilir.

4.3.2.4. Medyaya Sayfa Erişimi

Uzak medya uç noktasının kimliğinin belirlenmesi, medya güvenliğinin sağlanması için gerekli ancak yeterli olmayan bir koşuldur. WebRTC’de medya akışları, çağrıyı başlatan site tarafından manipüle edilebilen HTML5 MediaStream’lerine dönüştürülür. Açıkça görülmektedir ki, site medyayı değiştirebiliyor veya görüntüleyebiliyorsa, kullanıcı eşini kimlik doğrulaması yapabilme imkânından bekleyeceği güvence düzeyini elde edememektedir. Pek çok durumda bu kabul edilebilir; çünkü kullanıcı, siteden tamamen korunmuş bir güvenlikten ziyade site tabanlı özel efektlere değer verir. Bununla birlikte, kullanıcıların sitenin müdahale edemediğini bilmek istediği durumlar da vardır. Bunu mümkün kılmak için, sitenin medya akışlarına erişimden doğrulanabilir biçimde vazgeçebilmesini sağlayan özelliklerin sunulması gerekecektir. Bu doğrulamanın hem yerel taraftan hem de uzak taraftan mümkün olması gerekir. Yani kullanıcılar, aradıkları kişinin güvenli bir medya modunu etkinleştirdiğini doğrulayabilmelidir (bkz. Bölüm 4.3.3). Bunu başarmak için, yerel medya erişim politikasına ilişkin bir göstergenin, önceki bölümlerde ayrıntıları verilen kriptografik kimlik doğrulama prosedürlerine kriptografik olarak bağlanması gerekecektir.

Bu güvenli medya modunun kullanımının sitenin takdirine bırakıldığı belirtilmelidir. Böyle bir mod etkinleştirildiğinde, tarayıcının kullanıcıya, ilişkili medyanın tanımlanan kullanıcıdan geldiğinin doğrulandığını gösteren işaretler sunması gerekecektir. Bu, uçtan uca güvenlik iddiasında bulunmak isteyen WebRTC hizmetlerinin bunu kullanıcı tarafından kolayca doğrulanabilecek bir şekilde yapabilmesini sağlar. Bu model, Bölüm 3’te açıklandığı üzere, uzak tarafın tarayıcısının TCB kapsamına dâhil edilmesini gerektirir.

4.3.3. Kötü Niyetli Eşler

Genel olarak önlemeye çalışmadığımız saldırı sınıflarından biri kötü niyetli eşlerdir. Örneğin, hangi gizlilik önlemlerini uygularsanız uygulayın, konuştuğunuz kişi görüşmeyi kaydedip İnternet’te yayımlayabilir. Benzer şekilde, görünüşlerini gizlemek veya değiştirmek için ses ya da video işleme teknolojileri kullanmalarını engellemeye çalışmayız. Bu sorunları ele almaya yönelik teknolojiler (Dijital Haklar Yönetimi (DRM) vb.) mevcut olsa da, bunlar genellikle açık sistemlerle uyumlu değildir ve WebRTC bunları ele almaz.

Aynı şekilde, şaka aramaları veya diğer istenmeyen aramaları engellemeye yönelik bir girişimde bulunmayız. Genel olarak bu, çağrıyı yapan sitenin kapsamındadır; ancak WebRTC bazı güçlü kimlik doğrulama biçimleri sunduğundan, bunlar bu tür saldırılara karşı bir savunmanın parçası olarak yararlı olabilir.

4.4. Gizlilik Hususları

4.4.1. Anonim Aramaların İlişkilendirilmesi

Kalıcı uç nokta tanımlayıcıları yararlı bir güvenlik özelliği olabilse de (bkz. Bölüm 4.3.2.1), kullanıcının anonim kalmak istediği ortamlarda bir gizlilik tehdidi de oluşturabilirler. WebRTC, DTLS sertifikaları (bağlantılar arasında yeniden kullanıldıklarında) ve RTCP CNAME’leri (gizliliği koruyan [RFC7022] modu yerine [RFC6222]’ye göre üretildiklerinde) gibi bir dizi olası kalıcı tanımlayıcı sağlar. Bu tür ilişkilendirmeyi önlemek için tarayıcıların, bu tanımlayıcıları sıfırlamaya yönelik mekanizmalar sunması gerekir (örneğin, çerezlerle aynı yaşam süresine sahip olacak şekilde). Ayrıca API, anonim arama için tasarlanan sitelerin yeni tanımlayıcıların basılmasını zorlamasına olanak tanıyan mekanizmalar sağlamalıdır. Buna ek olarak, IP adresleri de çağrıların ilişkilendirilmesi için bir kaynak olabilir [RFC8828].

4.4.2. Tarayıcı Parmak İzi Çıkarma

Her yeni API özellik kümesi tarayıcı parmak izi çıkarma riskini artırır ve WebRTC de bunun istisnası değildir. Özellikle siteler, belirli cihazların varlığını veya yokluğunu bir tarayıcı parmak izi olarak kullanabilir. Genel olarak API, işlevsellik ile artan parmak izi riski arasında dengelenmelidir. Bkz. [Fingerprinting].

#5. Güvenlik Hususları

Bu belgenin tamamı güvenlikle ilgilidir.

#6. IANA Hususları

Bu belgenin IANA ile ilgili herhangi bir işlemi yoktur.

#7. Kaynaklar

7.1. Normatif Kaynaklar

7.2. Bilgilendirici Kaynaklar

#Kaynaklar

#Yazarın Adresi

Eric Rescorla Mozilla

E-posta: ekr@rtfm.com

Uğur Toprakdeviren

Kendi öğrenme sürecimden notlar.

ugur@toprak.run