WebRTC musi wdrożyć DTLS-SRTP, ale… nie może wdrażać SDES

Drugim takim postanowieniem jest to, że każda implementacja zapewni mechanizm JavaScript aplikacji Calling, aby wskazać, że należy użyć tylko kandydatów. Może to w ogóle uniemożliwić rówieśnikowi nauki adresu IP.

Skąd pochodzą argumenty domeny DTLS w WebRTC?

W przypadku WEBRTC rówieśników, jaka jest DTLS używana do negocjacji? Jestem zdziwiony. Wydaje się, że w SDP nie ma istotnej definicji atrybutów. Czy to domena, w której znajduje się strona internetowa?

zapytał 12 lipca 2021 o 14:36

25 3 3 brązowe odznaki

1 Odpowiedź 1

WEBRTC nie korzysta z organu certyfikatu. Żadne domeny nie są zaangażowane. Z WEBRTC autentyczność, którą otrzymujesz od PKI, jest po prostu zastąpiona odciskami palców certyfikatów.

Każda strona generuje certyfikat, a następnie udostępnia odcisk palca w opisie sesji (oferta/odpowiedź). Po zakończeniu uścisku dłoni DTLS upewnia się, że wymienione certyfikat był taki sam.

Jak faktycznie działa DTLS, jest wyjaśnione w WebRTC dla ciekawego#.

odpowiedział 12 lipca 2021 o 15:25

Sean Dubois Sean Dubois

3 867 1 1 Złota odznaka 11 11 Srebrne odznaki 22 22 brązowe odznaki

Ale OpenSSL SSLConnector potrzebuje domeny. W takim przypadku, jaką wartość należy przekazać dla tego parametru?

WebRTC musi wdrożyć DTLS-SRTP, ale… nie może wdrażać SDES?

Jak się spodziewałem w moim poście na temat standaryzacji WebRTC, spotkanie IETF 87 odbyło się w zeszłym tygodniu w Berlinie w Niemczech. Jednym z elementów programu WEBRTC było to, czy SDE powinny być częścią (i jak) WEBRTC.

Zgodnie z projektami IETF każda implementacja zgodna z WEBRTC musi obsługiwać profil RTP/SAVPF, który tworzy się na górze bezpiecznego profilu RTP RTP/SAVP. Oznacza to, że kanały medialne (e.G. audio, wideo) należy zabezpieczyć za pośrednictwem Secure RTP (SRTP), który zapewnia szyfrowanie mediów wśród innych funkcji bezpieczeństwa. W rzeczywistości zastosowanie zwykłego (niezaszyfrowanego) RTP jest wyraźnie zabronione przez specyfikacje WebRTC.

Alternatywy zarządzania kluczami WebRTC

SRTP musi wchodzić w interakcje z protokołami zarządzania kluczami (e.G. Mikey, ZRTP, SDES, DTLS-SRTP) w celu negocjowania parametrów bezpieczeństwa dla sesji ruchu multimedialnego. To’S warto zauważyć, że sygnalizacja (e.G. SIP, HTTP) i media (e.G. RTP) zaangażowany w komunikację multimedialną można zabezpieczyć niezależnie. Na przykład opisy zabezpieczeń SDP dla strumieni multimediów (SDES) i Multimedia Key Exchange (Mikey) używają płaszczyzny sygnalizacyjnej do przenoszenia parametrów bezpieczeństwa sesji za pośrednictwem SDP; Oznacza to, że sygnalizacja powinna być z kolei chroniona. Jednak niezależne zabezpieczenie sygnalizacji i mediów może być niewystarczające w niektórych przypadkach, ponieważ nie stanowi gwarancji, że użytkownik sygnalizacyjny jest taki sam jak użytkownik multimediów. Stąd pożądane jest wiązanie kryptograficzne między dwoma płaszczyznami-ZRTP i DTLS-SRTP.

Wiele literatury można znaleźć na ten temat, ale w skrócie:

  • SDES – Parametry bezpieczeństwa i klucze do konfigurowania sesji SRTP są wymieniane w wyraźnym tekście w postaci atrybutów SDP, w związku z czym polegają na płaszczyźnie sygnalizacyjnej, aby zabezpieczyć komunikat SDP, przy użyciu na przykład TLS.
  • Mikey – Wykonuje kluczową wymianę i negocjuje parametry kryptograficzne w imieniu aplikacji multimedialnych. Jego wiadomości są transportowane w ładowności SDP i kodowane w Base64.
  • ZRTP-Wymieniane są wspólne tajne i inne parametry bezpieczeństwa, opierając się na Diffie-Hellman. Wzajemne uwierzytelnianie może używać krótkiego ciągu uwierzytelniania (SAS), więc nie ma’t Wymagaj wsparcia z PKI. Giełda ZRTP odbywa się na tych samych numerach portów używanych przez sesję multimedialną dla ruchu RTP (w przeciwieństwie do ścieżki sygnałowej).
  • DTLS-SRTP-umożliwia wymianę parametrów kryptograficznych i wyprowadza materiał do keying. Kluczowa wymiana odbywa się w płaszczyźnie multimediów i jest multipleksowana na tych samych portach, co same media. Będziemy o tym rozwinąć w przyszłym poście, ale krótko mówiąc, po zakończeniu niektórych kontroli ICE, DTLS-SRTP umożliwia ustanowienie kanału multimedialnego SRTP bez potrzeby ujawnienia kluczy w wymianie wiadomości SDP, jak to się dzieje z SDES.

Według Draft-ITF-RTCWEB-RTP-USAGE-07 (bieżący projekt, lipiec 2013), WebRTC:

Wdrożenia muszą obsługiwać DTLS-SRTP w celu zarządzania kluczami. Inne kluczowe programy zarządzania mogą być obsługiwane

DTLS-SRTP jest domyślnym i preferowanym mechanizmem, co oznacza, że ​​jeśli otrzyma się oferta, która obsługuje zarówno DTLS-SRTP, jak i SDES, DTLS-SRTP musi zostać wybrane-niezależnie od tego, czy sygnalizacja jest zabezpieczona, czy nie, czy nie. Z tego, co ja’Najbardziej widzę w terenie (mogę’T, powiedz wszystkie) próby WebRTC działają sygnalizowanie przez TLS, zwykle za pośrednictwem bezpiecznego HTTP (HTTPS) lub Secure WebSockets (WSS).

Debata

Zasadniczo istnieje kilka wątpliwości, że DTLS-SRTP powinien być obowiązkowy do wdrożenia (MTI) mechanizmu bezpieczeństwa dla mediów w czasie rzeczywistym WebRTC (cóż, niektórzy twierdzą, że ZRTP może potencjalnie zapewnić prostsze podejście lub jeszcze lepszą ochronę w niektórych scenariuszach). Dyskusja w Berlinie polegała na tym, czy IETF, poza nakazaniem wsparcia dla DTLS-SRTP, może udzielić zaleceń dotyczących ponownego wykorzystania innych istniejących mechanizmów, które mamy dzisiaj, aby zapewnić zacofaną zgodność; mianowicie ponowne wykorzystanie SDES w scenariuszach WEBRTC-to-SIP. Tak to’Prawda, że ​​większość ruchu RTP w sieciach VOIP nie jest dziś zabezpieczona – w rzeczywistości jest to jedna z pierwszych funkcji, o które klienci zwykle proszą dostawców, aby spełnić swoje budżety. Jednak po zabezpieczeniu większość wdrożeń i’widziane są sdes (co, jak wspomniano, ma silną zależność od zabezpieczenia płaszczyzny sygnalizacyjnej).

Jeśli chodzi o implementacje WebRTC, Google’S

WebRTC musi wdrożyć DTLS-SRTP, ale… nie może wdrażać SDES

Drugim takim postanowieniem jest to, że każda implementacja zapewni mechanizm JavaScript aplikacji Calling, aby wskazać, że należy użyć tylko kandydatów. Może to w ogóle uniemożliwić rówieśnikowi nauki adresu IP.

Skąd pochodzą argumenty domeny DTLS w WebRTC?

W przypadku WEBRTC rówieśników, jaka jest DTLS używana do negocjacji? Jestem zdziwiony. Wydaje się, że w SDP nie ma istotnej definicji atrybutów. Czy to domena, w której znajduje się strona internetowa?

zapytał 12 lipca 2021 o 14:36

25 3 3 brązowe odznaki

1 Odpowiedź 1

WEBRTC nie korzysta z organu certyfikatu. Żadne domeny nie są zaangażowane. Z WEBRTC autentyczność, którą otrzymujesz od PKI, jest po prostu zastąpiona odciskami palców certyfikatów.

Każda strona generuje certyfikat, a następnie udostępnia odcisk palca w opisie sesji (oferta/odpowiedź). Po zakończeniu uścisku dłoni DTLS upewnia się, że wymienione certyfikat był taki sam.

Jak faktycznie działa DTLS, jest wyjaśnione w WebRTC dla ciekawego#.

odpowiedział 12 lipca 2021 o 15:25

Sean Dubois Sean Dubois

3 867 1 1 Złota odznaka 11 11 Srebrne odznaki 22 22 brązowe odznaki

Ale OpenSSL SSLConnector potrzebuje domeny. W takim przypadku, jaką wartość należy przekazać dla tego parametru?

WebRTC musi wdrożyć DTLS-SRTP, ale… nie może wdrażać SDES?

Jak się spodziewałem w moim poście na temat standaryzacji WebRTC, spotkanie IETF 87 odbyło się w zeszłym tygodniu w Berlinie w Niemczech. Jednym z elementów programu WEBRTC było to, czy SDE powinny być częścią (i jak) WEBRTC.

Zgodnie z projektami IETF każda implementacja zgodna z WEBRTC musi obsługiwać profil RTP/SAVPF, który tworzy się na górze bezpiecznego profilu RTP RTP/SAVP. Oznacza to, że kanały medialne (e.G. audio, wideo) należy zabezpieczyć za pośrednictwem Secure RTP (SRTP), który zapewnia szyfrowanie mediów wśród innych funkcji bezpieczeństwa. W rzeczywistości zastosowanie zwykłego (niezaszyfrowanego) RTP jest wyraźnie zabronione przez specyfikacje WebRTC.

Alternatywy zarządzania kluczami WebRTC

SRTP musi wchodzić w interakcje z protokołami zarządzania kluczami (e.G. Mikey, ZRTP, SDES, DTLS-SRTP) w celu negocjowania parametrów bezpieczeństwa dla sesji ruchu multimedialnego. To’S warto zauważyć, że sygnalizacja (e.G. SIP, HTTP) i media (e.G. RTP) zaangażowany w komunikację multimedialną można zabezpieczyć niezależnie. Na przykład opisy zabezpieczeń SDP dla strumieni multimediów (SDES) i Multimedia Key Exchange (Mikey) używają płaszczyzny sygnalizacyjnej do przenoszenia parametrów bezpieczeństwa sesji za pośrednictwem SDP; Oznacza to, że sygnalizacja powinna być z kolei chroniona. Jednak niezależne zabezpieczenie sygnalizacji i mediów może być niewystarczające w niektórych przypadkach, ponieważ nie stanowi gwarancji, że użytkownik sygnalizacyjny jest taki sam jak użytkownik multimediów. Stąd pożądane jest wiązanie kryptograficzne między dwoma płaszczyznami-ZRTP i DTLS-SRTP.

Wiele literatury można znaleźć na ten temat, ale w skrócie:

  • SDES – Parametry bezpieczeństwa i klucze do konfigurowania sesji SRTP są wymieniane w wyraźnym tekście w postaci atrybutów SDP, w związku z czym polegają na płaszczyźnie sygnalizacyjnej, aby zabezpieczyć komunikat SDP, przy użyciu na przykład TLS.
  • Mikey – Wykonuje kluczową wymianę i negocjuje parametry kryptograficzne w imieniu aplikacji multimedialnych. Jego wiadomości są transportowane w ładowności SDP i kodowane w Base64.
  • ZRTP-Wymieniane są wspólne tajne i inne parametry bezpieczeństwa, opierając się na Diffie-Hellman. Wzajemne uwierzytelnianie może używać krótkiego ciągu uwierzytelniania (SAS), więc nie ma’t Wymagaj wsparcia z PKI. Giełda ZRTP odbywa się na tych samych numerach portów używanych przez sesję multimedialną dla ruchu RTP (w przeciwieństwie do ścieżki sygnałowej).
  • DTLS-SRTP-umożliwia wymianę parametrów kryptograficznych i wyprowadza materiał do keying. Kluczowa wymiana odbywa się w płaszczyźnie multimediów i jest multipleksowana na tych samych portach, co same media. Będziemy o tym rozwinąć w przyszłym poście, ale krótko mówiąc, po zakończeniu niektórych kontroli ICE, DTLS-SRTP umożliwia ustanowienie kanału multimedialnego SRTP bez potrzeby ujawnienia kluczy w wymianie wiadomości SDP, jak to się dzieje z SDES.

Według Draft-ITF-RTCWEB-RTP-USAGE-07 (bieżący projekt, lipiec 2013), WebRTC:

Wdrożenia muszą obsługiwać DTLS-SRTP w celu zarządzania kluczami. Inne kluczowe programy zarządzania mogą być obsługiwane

DTLS-SRTP jest domyślnym i preferowanym mechanizmem, co oznacza, że ​​jeśli otrzyma się oferta, która obsługuje zarówno DTLS-SRTP, jak i SDES, DTLS-SRTP musi zostać wybrane-niezależnie od tego, czy sygnalizacja jest zabezpieczona, czy nie, czy nie. Z tego, co ja’Najbardziej widzę w terenie (mogę’T, powiedz wszystkie) próby WebRTC działają sygnalizowanie przez TLS, zwykle za pośrednictwem bezpiecznego HTTP (HTTPS) lub Secure WebSockets (WSS).

Debata

Zasadniczo istnieje kilka wątpliwości, że DTLS-SRTP powinien być obowiązkowy do wdrożenia (MTI) mechanizmu bezpieczeństwa dla mediów w czasie rzeczywistym WebRTC (cóż, niektórzy twierdzą, że ZRTP może potencjalnie zapewnić prostsze podejście lub jeszcze lepszą ochronę w niektórych scenariuszach). Dyskusja w Berlinie polegała na tym, czy IETF, poza nakazaniem wsparcia dla DTLS-SRTP, może udzielić zaleceń dotyczących ponownego wykorzystania innych istniejących mechanizmów, które mamy dzisiaj, aby zapewnić zacofaną zgodność; mianowicie ponowne wykorzystanie SDES w scenariuszach WEBRTC-to-SIP. Tak to’Prawda, że ​​większość ruchu RTP w sieciach VOIP nie jest dziś zabezpieczona – w rzeczywistości jest to jedna z pierwszych funkcji, o które klienci zwykle proszą dostawców, aby spełnić swoje budżety. Jednak po zabezpieczeniu większość wdrożeń i’widziane są sdes (co, jak wspomniano, ma silną zależność od zabezpieczenia płaszczyzny sygnalizacyjnej).

Jeśli chodzi o implementacje WebRTC, Google’S Chrome obsługuje zarówno DTLS-SRTP, jak i SDES, a Mozilla’S Firefox tylko implementuje DTLS-SRTP. Jako ciekawość, ja’M obecnie zaangażowany w badania terenowe, w których niektóre z bram WABRTC-to-SIP w ramach oceny wdrażają tylko SDE i mają DTLS-SRTP jako element mapy drogowej. Ci dostawcy bramy prawdopodobnie uznali SDE za wystarczająco dobre do podstawowego scenariusza kontaktu i oczekiwali, że zostanie przyjęty w pewnym momencie przez specyfikacje WebRTC.

Obsługa Bezpieczeństwa Bezpieczeństwa WEBRTC

Slajdy z dyskusji w Berlinie można znaleźć tutaj. Jak widać w prezentacjach, niektóre argumenty z kibiców SDES obejmowały:

  • Zachęta komercyjna – to’S już tam i działa
  • Wczesne przycinanie mediów
  • Kompromis między złożonością a kosztami
  • Zasiłek dla kompleksowego SRTP w sprawach związanych

Na ostatniej kuli oznacza to, że nie trzeba odszyfrować ruchu SRTP na bramce interwrackingowej, jeśli punkt końcowy VoIP na drugim końcu używa SDES.

Oczywiście głównym punktem debaty było to, czy SDES naprawdę degraduje bezpieczeństwo w przypadku użycia kontaktu w porównaniu z DTLS-SRTP. Moim zdaniem niektóre argumenty stosowane przeciwko SDE mają również zastosowanie do DTLS-SRTP. Należy zauważyć, że kibice SDES nie proponowali tego dla wszystkich przypadków użycia, ale zamiast tego opowiadali się za ograniczeniem zastosowania do scenariusza związanego.

Inni twierdzili, że zgodność wsteczna nie była tak ważnym czynnikiem, gdy i tak będzie musiał użyć bram medialnych (co najmniej do zakończenia lodu); Zatem związek związany z DTLS-SRTP-to-SDES może być tylko kolejną cechą funkcji bramy (jak pokazano na poniższym schemacie wyodrębnionym z tej prezentacji).

Wynik

W wyniku dyskusji nie tylko SDE nie były zalecane z wybranych przypadków użycia, takich jak WEBRTC do SIP, ale ogólnie był całkowicie zabroniony dla WebRTC. Przyjęcie SDE zostało zinterpretowane przez większość jako narzucanie wymogu przeglądarek internetowych poza zakresem komunikacji przeglądarki do przeglądarki, a potencjalnie degradując ich właściwości bezpieczeństwa.

Uważam, że posiadanie jednego rozwiązania może być korzystne z perspektywy interoperacyjności (i.mi. Im mniej opcji zwykle oznacza lepszą interoperacyjność), ale ja’Zastanawiam się, co naprawdę zamierza wdrożyć, szczególnie w scenariuszach nie przeglądarki WebRTC, które mogą mieć różne wymagania bezpieczeństwa lub mogą chcieć bezpośrednio współpracować z istniejącymi urządzeniami VoIP (podobnie jak ja’M widzenie w projekcie może to oznaczać kilka milionów punktów końcowych). Czas pokaże, jak reagują dostawcy, ale zdecydowanie nie byłby to pierwszy przypadek, w którym określona funkcja/zachowanie jest domyślnie wyłączone, aby być zgodne z RFC, ale konfigurowalne, a czasem ukryte, opcja jest dostarczana “pojednany’własne ryzyko” Aby obsługiwać funkcję ��

Chcesz dowiedzieć się więcej o bezpieczeństwie WebRTC? Będziemy rozwinąć ten temat w przyszłych wpisach na blogu. W międzyczasie znajdź tu i tutaj kilka interesujących referencji. Moi przyjaciele i byli koledzy Jiri, Dorgham, John, Uli i Henning zawierają bardzo kompleksowy opis bezpieczeństwa multimedialnego w swojej książce bezpieczeństwa SIP. Możesz również wysłać mi wiadomość e -mail na [e -mail chroniony] lub śledzić mnie na Twitterze na @victorpascual.

powiązane posty

Kanał RSS

Interakcje czytnika

Uwagi

  1. Vijay k. Gurbani mówi 15 sierpnia 2013 o 11:14

Problem, który omawia Victor, nie jest endemiczny tylko dla WebRTC. Jest to ogólny problem, z którym Świat SIP zajął się odrobiną. Poniższy artykuł zawiera względne zalety i wady różnych programów kluczy w internetowym środowisku telekomunikacyjnym multimedialnym. Jeśli chcesz kopii, możesz wysłać mi e-mail na VKG w Bell-Labs Dot Com. Gurbani, v.K. i Kolesnikov, v., “Ankieta i analiza technik kluczy mediów w protokole inicjacji sesji (SIP),” W ankietach i samouczkach komunikacyjnych IEEE, 13 (2), PP. 183-198, 2011.

Dzięki za referencje Vijay – bardzo interesujący papier. BTW, ten nowy internetowy draft został opublikowany kilka godzin temu: “Używanie ZRTP do zabezpieczenia WebRTC”
http: // narzędzia.IETF.Org/html/draft-Johnston-rtcweb-zrtp-00 Streszczenie: “WEBRTC, Web Communications w czasie rzeczywistym, to zestaw protokołów i interfejsów API używanych do umożliwienia programistom internetowym dodawanie komunikacji w czasie rzeczywistym do ich stron internetowych i aplikacji z kilkoma wierszami JavaScript. Przepływy nośników WebRTC są szyfrowane i uwierzytelniane przez SRTP, bezpieczny protokół transportu w czasie rzeczywistym, podczas gdy kluczowa umowa jest dostarczana przez DTLS-SRTP, DataGram Transport Warstwa Security dla bezpiecznego protokołu transportu w czasie rzeczywistym w czasie rzeczywistym. Jednak bez jakiejkolwiek instrukcji obsługi tożsamości lub certyfikatów zewnętrznych przepływy mediów WebRTC nie mają ochrony przed atakiem Man-in-the-Middle (MITM). ZRTP, Kluczowa umowa ścieżki mediów dla Secure RTP, RFC 6189, zapewnia ochronę przed atakującymi MITM przy użyciu kluczowej ciągłości zwiększonej o krótki ciąg uwierzytelnienia (SAS). Ta specyfikacja opisuje, w jaki sposób ZRTP można użyć przez kanał danych WebRTC, aby zapewnić ochronę MITM dla przepływów nośników WebRTC Keyed za pomocą DTLS-SRTP. Zapewnia to ochronę użytkowników przed atakującymi MITM bez wymagania, aby przeglądarki obsługiwały ZRTP lub użytkowników do pobrania wtyczki lub rozszerzenia w celu zaimplementowania ZRTP.”

Szybka aktualizacja: Google właśnie ogłosił, że Chrome wycofuje SDES w procesie wieloetapowym “1) W Chrome 31 DTLS jest teraz domyślnie włączony, chociaż SDES jest nadal oferowany. Nie musisz już przekazać dtlssrtpkeyagreement: prawdziwe ograniczenie, aby włączyć DTL. Ponieważ używamy buforowania certyfikatów na pochodzenie, hit wydajności generowania certyfikatu DTLS nie jest już problemem, co pozwala nam uczynić to domyślnym. W tej chwili nie są konieczne zmiany aplikacji, chociaż DTLS można wyłączyć, ustawiając dtlssrtpkeyagreement: false, który powraca do operacji tylko dla SDES. 2) W nadchodzącej wersji Chrome, prawdopodobnie Chrome 33, SDES nie będzie już domyślnie oferowany i będzie używany tylko wtedy, gdy określono nowe ograniczenie TBD. W przypadku aplikacji wymagających SDE będzie to wymagało zmiany aplikacji, aby określić to nowe ograniczenie. 3) W przyszłej wersji Chrome, TBD W tym momencie to ograniczenie SDES zostanie usunięte i tylko DTLS-SRTP będzie obsługiwane. Oczekujemy, że tak szybko nastąpi w 2014 r.” Źródło: https: // grupy.Google.com/forum/#!temat/dyskusja-WEBRTC/67W4ZRTMONS

Dzięki za interesujący post Victor. Właśnie szukałem problemów bezpieczeństwa dotyczących WebRTC i znalazłem to. Być może aktualny status tego zmienił się, ponieważ post został opublikowany około rok temu, jestem nowy w WebRTC i wszystko wydaje się, że WebRTC używa DLTS-RTSP. Jednak to, co dzieje się z bezpieczeństwem w telefonach komórkowych?. O ile wiem, RTSP może być nieco powolne do odszyfrowania wideo, na przykład w mobilnych plattach. Z góry dziękuję Víctor Hidalgo

  • Chad Hart mówi 12 lipca 2014 o 7:55

Proszę nie’T Protokół przesyłania strumieniowego w czasie rzeczywistym (RTSP) z bezpiecznym transportem w czasie rzeczywistym (SRTP). WebRTC używa DTLS-SRTP. DTLS-SRTP, jak wszystkie szyfrowanie wymaga odszyfrowania i jest z tego związany, ale jest niewielki na nowoczesnych urządzeniach. Obawy dotyczące kosztów szyfrowania zwykle koncentrowały się na sprzęcie bocznym serwerowym, który musi poradzić.

  • Victor mówi 14 lipca 2014 o 3:06

Cześć Chad, prawda, odniósł się do DTLS-SRTP no dtls-rtsp, przepraszam za mój błąd. Chciałem jakiegoś wyjaśnienia przed zrobieniem testu, ponieważ oczekiwałem koszty minuscle związane z nowoczesnymi urządzeniami. Wielkie dzięki za odpowiedź. Zwycięzca

Zostaw odpowiedź Anuluj odpowiedź

Ta strona wykorzystuje AKISMET do zmniejszenia spamu. Dowiedz się, jak przetwarzane są dane dotyczące komentarzy.

Studium bezpieczeństwa WebRTC

Komunikacja w czasie rzeczywistym (skrócona jako WebRTC) to najnowszy trend w technologii aplikacji internetowych, która obiecuje możliwość włączenia komunikacji w czasie rzeczywistym w przeglądarce bez potrzeby wtyczek lub innych wymagań. Jednak charakter technologii open source może potencjalnie powodować obawy związane z bezpieczeństwem dla potencjalnych adoptorów technologii. W niniejszym dokumencie szczegółowo omówi bezpieczeństwo WebRTC w celu wykazania bezpieczeństwa porównawczego technologii.

1. Wstęp

WEBRTC to technologia aplikacji internetowych typu open source, która pozwala użytkownikom wysyłać media w czasie rzeczywistym bez potrzeby instalowania wtyczek. Korzystanie z odpowiedniej przeglądarki może umożliwić użytkownikowi wywołanie innej strony, po prostu przeglądając odpowiednią stronę internetową.

Niektóre z głównych przypadków użycia tej technologii obejmują:

  • Połączenia audio i/lub wideo w czasie rzeczywistym
  • Konferencje internetowe
  • Bezpośrednie transfery danych

W przeciwieństwie do większości systemów w czasie rzeczywistym (e.G. SIP), komunikacja WebRTC jest bezpośrednio kontrolowana przez jakiś serwer WWW, za pośrednictwem interfejsu API JavaScript.

Perspektywa włączenia wbudowanej komunikacji audio i wizualnej w przeglądarce bez wtyczek jest ekscytująca. To jednak naturalnie budzi obawy dotyczące bezpieczeństwa takiej technologii i tego, czy można jej zaufać, aby zapewnić niezawodną komunikację zarówno użytkownikom końcowym, jak i przewoźnikom pośrednikom lub stronom trzecim.

Niniejszy raport zajmie się tymi tematami i zbada zabezpieczenia, jakie WEBRTC zapewnia w celu zapewnienia bezpieczeństwa we wszystkich przypadkach. Jednak do celów tego artykułu zastosowania rodzime będą traktowane jako nieobecne.

2. Przegląd architektury WebRTC

WebRTC umożliwia bezpośrednią komunikację bogatą w media między dwoma rówieśnikami, używając topologii peer-to-peer (P2P). WebRTC znajduje się w przeglądarce użytkownika i nie wymaga żadnego dodatkowego oprogramowania do obsługi. Rzeczywista komunikacja między rówieśnikami jest poprzedzona wymianą metadanych, zwanej „sygnalizacją”. Proces ten służy do inicjowania i reklamowania połączeń oraz ułatwia ustanowienie połączeń między nieznanymi stronami.

Jak pokazano na rysunku 1, proces ten występuje za pośrednictwem serwera pośredniego:

Rysunek 1. Prosta topologia połączeń WebRTC

Rysunek 1. Prosta topologia WEBRTC Call

Protokół sygnalizacyjny nie jest określony w WEBRTC, co pozwala programistom na wdrożenie własnego wyboru protokołu. Pozwala to na głębszy stopień elastyczności w dostosowaniu aplikacji WebRTC do określonego przypadku lub scenariusza użycia.

Jak działa komunikacja WebRTC?

WebRTC polega na trzech interfejsach API, z których każdy wykonuje określoną funkcję, aby umożliwić komunikację w czasie rzeczywistym w aplikacji internetowej. Te interfejsy API zostaną nazwane i wyjaśnione krótko. Wdrożenie i szczegóły techniczne każdego protokołu i technologii są poza zakresem tego raportu, jednak odpowiednia dokumentacja jest łatwo dostępna online.

Getusermedia

Przez wiele lat konieczne było poleganie na wtyczkach przeglądarki innej firmy, takich jak Flash lub Silverlight, aby przechwytywać dźwięk lub wideo z komputera. Jednak era HTML 5 zapoczątkowała bezpośredni dostęp do wielu urządzeń i zapewnia interfejs JavaScript, które łączą się z funkcjami sprzętowymi podstawowymi systemowymi.

Getusermedia to jeden z takich interfejsów API, umożliwiający przeglądarce dostęp do aparatu i mikrofonu użytkownika. Chociaż wykorzystywane przez WebRTC, ten interfejs API jest faktycznie oferowany jako część HTML 5.

RtcpeerConnection

RTCPeerConnection jest pierwszym z dwóch interfejsów API, które są oferowane specjalnie jako część specyfikacji WebRTC. Interfejs RTCPeerConnection reprezentuje rzeczywiste połączenie WebRTC i opiera się na obsłudze wydajnego przesyłania danych między dwoma rówieśnikami.

Kiedy dzwoniący chce zainicjować połączenie ze stroną zdalną, przeglądarka zaczyna się od instancji obiektu RTCPeerConnection. Obejmuje to samodzielny opis SDP do wymiany z rówieśnikiem. Odbiorca z kolei odpowiada własnym opisem SDP. Opisy SDP są używane jako część pełnego przepływu pracy na lodzie dla Traversal NAT.

Po ustaleniu połączenia, RTCPeerConnection umożliwia wysyłanie danych audio i wideo w czasie rzeczywistym jako strumień bitów między przeglądarkami.

Ostatecznie API RTCPeerConnection jest odpowiedzialne za zarządzanie pełnym cyklem życia każdego połączenia peer-to-peer i zawiera całą konfigurację, zarządzanie i stan połączenia w jednym łatwym w użyciu interfejsie.

RTCPeerConnection ma dwie specyficzne cechy: – Bezpośrednia komunikacja peer -to -peer między dwoma przeglądarkami – użycie UDP/IP – nie ma gwarancji przybycia pakietu (jak w TCP/IP), ale w rezultacie jest znacznie zmniejszone koszty ogólne. – (Pozwalając na utratę niektórych danych, możemy skupić się na oferowaniu komunikacji w czasie rzeczywistym.)

RTCDATACHANNEL

RTCDATACHANNEL jest drugim głównym interfejsem API oferowanym jako część WebRTC i reprezentuje główny kanał komunikacyjny, za pomocą którego wymiana dowolnych danych dotyczących aplikacji występuje między rówieśnikami. Innymi słowy, służy do przesyłania danych bezpośrednio z jednego równorzędnego do drugiego.

Chociaż istnieje szereg alternatywnych opcji kanałów komunikacji (e.G. WebSocket, Server wysłane zdarzenia), jednak te alternatywy zostały zaprojektowane do komunikacji z serwerem, a nie bezpośrednio połączonym rówieśnikiem. RTCDATACHANNEL przypomina popularne WebSocket, ale zamiast tego przyjmuje format peer-to-peer, oferując konfigurowalne właściwości dostawy transportu podstawowego.

2.1. Technologie podstawowe

Trzy główne interfejsy API to aspekty WEBRTC skierowane do programistów, ale istnieje wiele fundamentalnych technologii, które są wykorzystywane w celu dostarczenia tych protokołów (API RTCPEerConnection i RTCDatachannel).

Rysunek 2. Stos protokołu WebRTC

Rysunek 2. Stos protokołu WebRTC

Lód, ogłuszenie i obrót są niezbędne do ustanowienia i utrzymania połączenia peer-to-peer nad UDP. DTLS służy do zabezpieczenia wszystkich transferów danych między rówieśnikami, ponieważ szyfrowanie jest obowiązkową cechą WebRTC. Wreszcie, SCTP i SRTP to protokoły aplikacji używane do multipleksowania różnych strumieni, zapewnienia zatorów i kontroli przepływu oraz zapewnienia częściowo niezawodnej dostawy i innych dodatkowych usług oprócz UDP.

SDP: Protokół opisu sesji

Protokół opisu sesji (SDP) to protokół opisowy, który jest stosowany jako standardowa metoda ogłaszania i zarządzania zaproszeniami sesji, a także wykonywania innych zadań inicjacyjnych dla sesji multimedialnych. SDP reprezentuje możliwości i preferencje przeglądarki w formacie tekstowym i może zawierać następujące informacje: – Możliwości multimedialne (wideo, audio) i zastosowane kodeki – adres IP i numer portu – P2P Protocol transmisji danych (WABRTC używa SECURERTP) – Bandwidth Użyte.) -> Jednak nie są one używane w WebRTC. – Inne powiązane metadane.

Na dzień dzisiejszy SDP jest szeroko stosowany w kontekstach protokołu inicjacji sesji (SIP), protokołu transportu w czasie rzeczywistym (RTP) i protokołu strumieniowego strumieniowego w czasie rzeczywistym (RSP).

ICE: interaktywna zakład łączności

Sygnalizacja wymaga początkowego użycia serwera pośredniego do wymiany metadanych, ale po zakończeniu WEBRTC próbuje ustanowić bezpośrednie połączenie P2P między użytkownikami. Proces ten jest wykonywany w ramach lodowych.

ICE to ramy używane do nawiązywania połączenia między rówieśnikami przez Internet. Chociaż WebRTC próbuje wykorzystać bezpośrednie połączenia P2P, w rzeczywistości powszechna obecność NAT (translacja adresu sieci.

Ze względu na ciągłe powszechne rozpowszechnienie adresów IPv4 z ich ograniczoną 32-bitową reprezentacją, większość urządzeń z obsługą sieci nie ma unikalnego publicznego adresu IPv4, z którym byłby bezpośrednio widoczny w Internecie. Nat działa dynamicznie tłumaczeniem prywatnych adresów na publiczne, gdy przechodzi przez nie żądanie wychodzące. Podobnie, żądania przychodzące do publicznego adresu IP są konwertowane z powrotem na prywatny adres IP, aby zapewnić prawidłowe routing w sieci wewnętrznej. W rezultacie udostępnianie prywatnego adresu IP jest często niewystarczającymi informacjami, aby nawiązać połączenie z rówieśnikiem. ICE próbuje przezwyciężyć trudności związane z komunikowaniem się za pośrednictwem NAT, aby znaleźć najlepszą ścieżkę do połączenia rówieśników.

Próbując równolegle wszystkich możliwości, ICE jest w stanie wybrać najbardziej wydajną opcję, która działa. ICE najpierw próbuje nawiązać połączenie za pomocą adresu hosta uzyskanego z systemu operacyjnego i karty sieciowej urządzenia; Jeśli to się nie powiedzie (co nieuchronnie będzie dla urządzeń za NATS) ICE, otrzymuje adres zewnętrzny za pomocą serwera ogłuszenia. Jeśli to również się nie powiedzie, ruch powraca do routingu za pośrednictwem serwera przekaźnika tury.

Kandydatów trasy komunikacyjne są renderowane w formacie tekstowym, a lista uporządkowana według priorytetu. Opcje przybierają formę jednego z następujących: – Bezpośrednia komunikacja P2P – za pomocą ogłuszenia, z mapowaniem portów dla NAT Traversal (ta trasa ostatecznie rozwiązuje się do bezpośredniej komunikacji P2P) – przy użyciu Turn jako pośrednika (ta konfiguracja wykorzystuje przekazaną komunikację zamiast P2P)

Spośród wszystkich możliwych kandydatów wybierana jest trasa z najmniejszym kosztem.

Ogłuszność: Session Traversal Utilities dla NAT

Aby przeprowadzić komunikację P2P, obie strony koniecznie wymagają przynajmniej wiedzy na temat adresu IP ich rówieśników i przypisanego portu UDP. W rezultacie konieczna jest pewna wymiana informacji, zanim można ustanowić komunikację WebRTC.

Każdy rówieśnik używany jest serwer ogłuszenia do określenia ich publicznego adresu IP i jest do nich odwoływany przez framework podczas ustanowienia połączenia. Serwery z odgadami są zazwyczaj dostępne publicznie i mogą być używane swobodnie przez aplikacje WebRTC.

Turn: Traversal za pomocą przekaźników wokół Nat

W ewentualności, że ustanowienie komunikacji P2P nie powiedzie. Przekraczając ruch między rówieśnikami, można zapewnić komunikację WebRTC, ale może ponieść degradację jakości i opóźnień mediów.

Turn serwery mogą zapewnić wysoki sukces w konfigurowaniu połączeń, niezależnie od środowisk użytkownika końcowego. Ponieważ dane są wysyłane przez serwer pośredni, przepustowość serwera jest również zużywana. Jeśli wiele połączeń jest jednocześnie kierowanych przez serwer, przepustowość stała się również znacząca pod względem wielkości.

Sam serwer jest zazwyczaj nie dostępny i musi być specjalnie podany (lub wynajęty) przez dostawcę aplikacji.

3. Rozważania dotyczące bezpieczeństwa oparte na przeglądarce

Istnieje wiele sposobów, aby aplikacja komunikacyjna w czasie rzeczywistym może nakładać zagrożenia bezpieczeństwa, zarówno na przewoźnika, jak i użytkowników końcowych. Takie zagrożenia bezpieczeństwa mogą mieć zastosowanie do dowolnej aplikacji, która dotyczy transmisji danych w czasie rzeczywistym i multimedialnym.

WebRTC różni się od innych aplikacji RTC, zapewniając silną i niezawodną infrastrukturę dla nawet nowych programistów do wykorzystania bez uszczerbku dla bezpieczeństwa. Teraz będziemy omawiać, w jaki sposób WEBRTC z kolei radzi sobie z każdym z tych zagrożeń.

3.1. Model zaufania przeglądarki

Architektura WebRTC zakłada z perspektywy bezpieczeństwa, że ​​zasoby sieciowe istnieją w hierarchii zaufania. Z perspektywy użytkownika przeglądarka (lub klient użytkownika) jest podstawą wszystkich zabezpieczeń WebRTC i działa jako ich zaufana baza komputerowa (TCB).

Zadaniem przeglądarki jest umożliwienie dostępu do Internetu, przy jednoczesnym zapewnieniu odpowiedniej ochrony bezpieczeństwa użytkownikowi. Wymagania bezpieczeństwa WebRTC są budowane bezpośrednio na podstawie tego wymogu; Przeglądarka to portal, za pomocą którego użytkownik uzyskuje dostęp do wszystkich aplikacji i treści WebRTC.

Podczas gdy HTML i JS dostarczone przez serwer mogą spowodować wykonywanie przeglądarki, przeglądarka segreguje te skrypty na piaskownicy. Wspomniane piaskownicy izolują skrypty od siebie i od komputera użytkownika. Ogólnie rzecz biorąc, skrypty mogą wchodzić tylko w interakcje z zasobami z tej samej domeny – a dokładniej tego samego „pochodzenia”.

Przeglądarka wymusza wszystkie zasady bezpieczeństwa, których użytkownik pragnie i jest pierwszym krokiem w weryfikacji wszystkich stron trzecich. Wszystkie uwierzytelnione podmioty mają sprawdzone tożsamość przez przeglądarkę.

Jeśli użytkownik wybierze odpowiednią przeglądarkę, o której wie, że może zaufać, cała komunikacja WebRTC może być uznana za „bezpieczną” i aby przestrzegać standardowej architektury bezpieczeństwa technologii WebRTC. Jednak w razie wątpliwości, że przeglądarka jest „godna zaufania” (e.G. Pobrano z strony trzeciej, a nie z zaufanej lokalizacji), a następnie wszystkie następujące interakcje z aplikacjami WebRTC są wpływające na niezawodne bezpieczne.

Innymi słowy, na poziom zaufania dostarczonego użytkownikowi przez WebRTC ma bezpośredni wpływ zaufanie użytkownika do przeglądarki.

3.2. SOP: Polityka tego samego pochodzenia

Jest to fundamentalny aspekt DOM, że wszystkie zasoby stron internetowych są pobierane z serwera stron internetowego, ilekroć niektóre lub całość strony są ładowane. Pobieranie zasobów odbywa się albo, gdy strona jest świeżo załadowana przez przeglądarkę, albo gdy skrypt przebywający na stronie internetowej składa takie żądanie. Takie skrypty są w stanie złożyć żądania HTTP za pośrednictwem E.G. interfejs API xmlhttprequest (), ale nie wolno składać takich żądań do dowolnego określonego serwera. Raczej prośby należy składać do tego samego „pochodzenia”, skąd pochodzi skrypt. „Pochodzenie” obejmuje schemat URI, nazwę hosta i numer portu. To ogólne ograniczenie nazywa się „Polityką tego samego pochodzenia” (SOP).

SOP zmusza skrypty do wykonywania w izolowanych piaskownicach specyficznych dla ich domeny pochodzącej, w ten sposób zapobiegając stronom z różnych pochodzenia, a nawet iFrame na tej samej stronie z wymiany informacji. Strony internetowe i skrypty z tego samego serwera pochodzenia pozostają bez przeszkód w interakcji’S JS zmienne. Jako takie pochodzenie stanowi podstawową jednostkę piaskownic internetowych.

Poprzez egzekwowanie piaskownicy wykonania na podstawie oryginów użytkownik końcowy jest chroniony przed niewłaściwym użyciem swoich poświadczeń. Zasadniczo spodziewałbyś się bezpiecznego korzystania z sieci społecznościowej bez scenariusza wykonującego z panelu reklamowego i kradzieży informacji o logowaniu.

Podobnie serwery E.G. Dostawca stron internetowych jest chroniony przed atakami zamontowanymi za pośrednictwem przeglądarki użytkownika; Gdyby takie zabezpieczenia nie istniały, ataki DOS mogłyby zostać uruchomione za pomocą obraźliwych żądań zasobów.

3.2.1 omijanie SOP

SOP jest niezwykle ważny dla bezpieczeństwa zarówno serwerów użytkownika, jak i internetowych w ogóle, chociaż ma wadę utrudnienia niektórych rodzajów aplikacji internetowych. Istnieją metody umożliwienia interakcji międzynarodowych, chociaż są one zwykle wzajemnie zgodne i ograniczone do niektórych kanałów.

Specyfikacja W3C Cross-Aphource Resource Shafing (CORS) jest jedną z odpowiedzi na problem. Pozwala przeglądarce skontaktować się z serwerem docelowym skryptu w celu ustalenia, czy jest skłonny uczestniczyć w danym rodzaju transakcji. Jako takie, żądania między originami mogą być bezpiecznie dozwolone, dając docelowy serwer opcji konkretnego wyboru niektórych żądań i odrzucenia wszystkich innych.

WebSockets to kolejna opcja umożliwiająca podobną funkcjonalność, ale na przezroczystych kanałach, a nie izolowane żądania HTTP. Po ustanowieniu takiego połączenia skrypt może przenosić ruch i zasoby, jak to lubi, z koniecznością ramowania jako serii transakcji żądania/odpowiedzi HTTP.

W obu przypadkach początkowy etap weryfikacji zapobiega dowolnym przesyłaniu danych przez skrypt o innym pochodzeniu.

4. Względy bezpieczeństwa WebRTC

4.1. Instalacja i aktualizacje

Powszechnym problemem z tradycyjnym oprogramowaniem komputerowym jest to, czy można zaufać samej aplikacji. Instalacja nowego oprogramowania lub wtyczki może potencjalnie skrzeźcznie zainstalować złośliwe oprogramowanie lub inne niepożądane oprogramowanie. Wielu użytkowników końcowych nie ma pojęcia, gdzie zostało stworzone oprogramowanie lub dokładnie od tego, z czego pobiera aplikację. Złośliwe strony trzecie odniosły wielki sukces w przepakowaniu całkowicie bezpiecznego i zaufanego oprogramowania, aby zawierać złośliwe oprogramowanie oraz oferować swój niestandardowy pakiet na bezpłatnych stronach oprogramowania.

WebRTC nie jest jednak wtyczką, ani nie ma żadnego procesu instalacji dla żadnego z jego komponentów. Cała podstawowa technologia WebRTC jest instalowana po prostu w ramach pobierania odpowiedniej przeglądarki kompatybilnej z WEBRTC, taką jak Chrome lub Firefox. Jeśli użytkownik ma taką przeglądarkę, może przeglądać i używać dowolnej aplikacji WebRTC bez innej konfiguracji lub przygotowania. Jako takie nie ma ryzyka instalacji złośliwego oprogramowania lub wirusów za pomocą odpowiedniej aplikacji WebRTC. Jednak aplikacje WebRTC należy nadal uzyskać dostęp za pośrednictwem strony internetowej HTTPS podpisanej przez prawidłowego uwierzytelniającego, takiego jak Verisign.

Innym powiązanym rozważaniem jest łatanie odkrytych wad bezpieczeństwa w oprogramowaniu. Podobnie jak w przypadku każdej technologii oprogramowania, jest całkowicie możliwe, że przyszłe błędy lub luki zostaną odkryte w WebRTC. Jeśli w tradycyjnej aplikacji stacjonarnej można znaleźć podatność (taka jak typowa aplikacja VoIP), opracowanie łatki może zająć dużo czasu. Jest to częste problem z opracowywaniem aplikacji, ponieważ bezpieczeństwo jest nadal często traktowane jako wtórne rozważanie po funkcjonalności. Idąc głębiej, możemy rozważać metody komunikacji oparte na sprzętowych. Jak często telefon VoIP otrzymuje aktualizację bezpieczeństwa? Czy możesz ufać osobie odpowiedzialnej za regularną aktualizację? Czy nawet wiesz, kto jest odpowiedzialny?

W przeciwieństwie do tego, przeglądarki są szybką sceną rozwoju ze względu na częstotliwość i zakres ryzyka, na które użytkownicy są narażeni, a także ich wszechobecny charakter (i znaczenie informacji dostępnych przez przeglądarkę). Ponieważ komponenty WebRTC są oferowane jako część przeglądarki, są one również aktualizowane, gdy przeglądarka jest aktualizowana. Gdyby wdrożenie przyszłej podatności na wdrożenie WEBRTC w przeglądarce, poprawka prawdopodobnie zostanie szybko dostarczona. Można to szczególnie postrzegać w cyklach szybkiego rozwoju Chrome i Firefox. W rzeczywistości w erze automatycznych aktualizacji komponenty WebRTC można aktualizować za pośrednictwem nowej wersji przeglądarki, gdy tylko łatka zostanie udostępniona na serwerach. Większość współczesnych przeglądarek ma dobrą rejestra.

Na marginesie: chociaż stwierdziliśmy, że WebRTC nie wymaga instalacji wtyczek, możliwe jest, że frameworki WEBRTC innej firmy mogą oferować wtyczki, aby umożliwić obsługę obecnie nieobsługiwanych przeglądarków (takich jak Safari i IE). W takich przypadkach zaleca się ostrożność użytkownika (lub obsługiwaną przeglądarkę).

4.2. Dostęp do zasobów mediów/lokalnych

Przeglądarka może uzyskać dostęp do lokalnych zasobów (w tym kamer. Jeśli aplikacje internetowe mogłyby swobodnie uzyskać dostęp do aparatu lub mikrofonu użytkownika, pozbawiona skrupułów aplikacja może próbować nagrać lub rozpowszechniać kanały wideo lub audio bez wiedzy użytkownika. Może to być prosta sprawa dla strony internetowej przebywającej na karcie tła, aby nadużywać zaufania użytkownika (użytkownik może nawet nie zdawać sobie sprawy z witryny, która ma taką aplikację komunikacyjną).

WEBRTC zwalcza to, wymagając od użytkownika wyraźnego zgody na użycie aparatu lub mikrofonu (oba można konfigurować indywidualnie). Można poprosić użytkownika o jednorazowy lub stały dostęp. Aplikacja WebRTC nie jest możliwa do dowolnego uzyskiwania dostępu lub obsługi żadnego urządzenia. Ponadto, gdy używany jest mikrofon lub aparat, interfejs klient. W Chrome przyjmuje to formę czerwonej kropki na dowolnej karcie, uzyskując dostęp do mediów użytkownika.

Rysunek 3. Chrome wskaźniki interfejsu użytkownika

Rysunek 3. Chrome wskaźniki interfejsu użytkownika

Filozofia tej ochrony bezpieczeństwa polega na tym, że użytkownik powinien zawsze podejmować świadomą decyzję, czy powinien zezwolić na połączenie, czy też otrzymywać połączenie. Innymi słowy, użytkownik musi zrozumieć: – kto lub o co żąda dostępu do jego mediów – dokąd idą media – lub jedno i drugie.

Jako dodatkowy przepis, specyfikacja WebRTC określa, że ​​przeglądarki powinny zatrzymać aparat i mikrofon, gdy wskaźnik interfejsu użytkownika jest maskowany (e.G. według nakładania się okna). Chociaż jest to bardziej idealne zachowanie, niekoniecznie jest to gwarantowane, a użytkownicy powinni zachować ostrożność. Na szczęście jednak ta dodatkowa funkcjonalność prawdopodobnie nie będzie oczekiwana przez użytkownika.

Udostępnianie ekranu wprowadza dalsze względy bezpieczeństwa ze względu na nieodłączną elastyczność zakresu. Użytkownik może nie być od razu świadomy zakresu informacji, które dzielą. Na przykład mogą wierzyć, że po prostu dzielą strumień określonego okna (e.G. Podczas prezentacji odległych stron), kiedy w rzeczywistości pokazują cały ekran swoim odbiorcom. Może to wynikać z tego, że użytkownik nie ustali prawidłowego ustalenia początkowej konfiguracji udostępniania ekranu, w przeciwnym razie użytkownik może po prostu zapomnieć o zakresie tego, co udostępnia.

4.3. Szyfrowanie mediów i bezpieczeństwo komunikacji

Istnieje wiele sposobów, aby aplikacja komunikacji w czasie rzeczywistym może nałożyć ryzyko bezpieczeństwa. Jednym ze szczególnie godnych uwagi jest przechwycenie niezaszyfrowanych mediów lub danych podczas transmisji. Może się to zdarzyć między komunikacją przeglądarki lub przeglądarki-serwer, z podskoczeniem stron trzecich. Szyfrowanie jednak uniemożliwia określenie zawartości strumieni komunikacyjnych. Tylko strony z dostępem do tajnego klucza szyfrowania mogą dekodować strumienie komunikacji.

Szyfrowanie jest obowiązkową cechą WebRTC i jest egzekwowane na wszystkich komponentach, w tym mechanizmy sygnalizacyjne. W rezultacie wszystkie strumienie mediów wysyłane przez WebRTC są bezpiecznie szyfrowane, wprowadzane za pomocą znormalizowanych i znanych protokołów szyfrowania. Zastosowany protokół szyfrowania zależy od typu kanału; Strumienie danych są szyfrowane przy użyciu bezpieczeństwa warstwy transportowej DataGram (DTLS), a strumienie mediów są szyfrowane przy użyciu bezpiecznego protokołu transportu w czasie rzeczywistym (SRTP).

4.3.1. DTLS: Bezpieczeństwo warstwy transportowej DataGram

WEBRTC szyfruje informacje (w szczególności kanały danych) przy użyciu bezpieczeństwa warstwy transportowej DataGram (DTLS). Wszystkie dane wysyłane przez RTCDatachannel są zabezpieczone za pomocą DTLS.

DTLS to znormalizowany protokół, który jest wbudowany we wszystkie przeglądarki, które obsługują WebRTC, i jest jednym z protokołów konsekwentnie używanych w przeglądarkach internetowych, e -mailach i platform VoIP do szyfrowania informacji. Wbudowany charakter oznacza również, że przed użyciem nie wymaga wcześniejszej konfiguracji. Podobnie jak w przypadku innych protokołów szyfrowania, jest zaprojektowany w celu zapobiegania podsłuchowi i manipulowaniu informacjami. Sam DTLS jest modelowany na zorientowanym na strumieniu TLS, protokołach, który oferuje pełne szyfrowanie metodami kryptografii asymetrycznej, uwierzytelnianiem danych i uwierzytelnianiem wiadomości. TLS jest de-facto standardem szyfrowania sieci, wykorzystywanym do celów takich protokołów jak HTTPS. TLS jest przeznaczony do niezawodnego mechanizmu transportu TCP, ale aplikacje VoIP (i gry itp.) Zazwyczaj używaj niewiarygodnych transportów Datagram, takich jak UDP.

Ponieważ DTLS jest pochodną SSL, wszystkie dane są tak bezpieczne, jak przy użyciu dowolnego standardowego połączenia opartego na SSL. W rzeczywistości dane WebRTC można zabezpieczyć za pośrednictwem dowolnego standardowego połączenia opartego na SSL w Internecie, umożliwiając WEBRTC oferowanie kompleksowego szyfrowania między rówieśnikami z prawie każdym układem serwera.

4.3.1.1. DTLS na turnie

Domyślną opcją dla całej komunikacji WebRTC jest bezpośrednia komunikacja P2P między dwoma przeglądarkami, wspomagana z serwerami sygnalizacyjnymi podczas fazy konfiguracji. Szyfrowanie P2P jest stosunkowo łatwe do przewidzenia i konfiguracji, ale w przypadku awarii konfiguracja WebRTC powraca do komunikacji za pośrednictwem serwera Turn (jeśli jest dostępny). Komunikacja Komunikacja Media mogą ponieść utratę jakości i zwiększone opóźnienia, ale pozwala scenariuszowi „jeśli wszystko inne zawiedzie” umożliwić aplikację WebRTC działać nawet w trudnych okolicznościach. Musimy również rozważyć zaszyfrowaną komunikację w alternatywnej strukturze komunikacji Turn.

Wiadomo, że niezależnie od metody komunikacji, wysłane dane są szyfrowane w punktach końcowych. Celem serwera Turn jest po prostu przekaźnik danych WebRTC między stronami w połączeniu, a jedynie paruj warstwę UDP pakietu WebRTC do celów routingu. Serwery nie zdekodują warstwy danych aplikacji w celu prowadzenia pakietów, a zatem wiemy, że nie (i nie mogą) dotykać szyfrowania DTLS.

W rezultacie zabezpieczenia wprowadzone poprzez szyfrowanie nie są zatem zagrożone podczas komunikacji WebRTC w okresie.

4.3.2. SRTP: bezpieczny protokół transportu w czasie rzeczywistym

Podstawowy RTP nie ma żadnych wbudowanych mechanizmów bezpieczeństwa, a zatem nie powoduje ochrony poufności przesyłanych danych. Zamiast tego opierają się mechanizmy zewnętrzne, aby zapewnić szyfrowanie. W rzeczywistości użycie niezaszyfrowanego RTP jest wyraźnie zabronione przez specyfikację WebRTC.

WebRTC wykorzystuje SRTP do szyfrowania strumieni mediów, a nie DTLS. Wynika to z faktu, że SRTP jest opcją lżejszą niż DTLS. Specyfikacja wymaga, aby wszelkie zgodne z implementacją WEBRTC obsługę RTP/SAVPF (który jest zbudowany na RTP/SAVP) [9] . Jednak faktyczna wymiana klawiszy SRTP jest początkowo wykonywana z DTLS-SRTP, umożliwiając wykrycie wszelkich ataków MITM.

4.3.3. Ustanowienie bezpiecznego linku

Przejrzyjmy proces ustanowienia nowego połączenia w aplikacji WebRTC. W tym przypadku zaangażowane będą dwie strony; Alice i Bob. Procedura połączenia jest inicjowana, gdy jedna strona (Alice) wywołuje drugą (BOB), a proces sygnalizacyjny wymienia odpowiednie metadane między obiema stronami.

Po zakończeniu wstępnych kontroli lodu (lub konkretnie niektórych z nich), dwaj rówieśnicy zaczną konfigurować jeden lub bardziej bezpieczne kanały. Początkowo uścisk dłoni DTLS jest wykonywany na wszystkich kanałach, które są ustanowione przez ICE. W przypadku kanałów danych sam ten krok jest wystarczający, ponieważ do szyfrowania stosuje się zwykły prosty DTLS. W przypadku kanałów medialnych podejmowane są dalsze kroki.

Po zakończeniu uścisku dłoni DTLS klawisze są „eksportowane” i używane do kluczowego SRTP dla kanałów medialnych. Na tym etapie obie strony wiedzą, że udostępniają zestaw bezpiecznych danych i/lub kanałów medialnych z klawiszami, które nie są znane żadnemu złośliwemu stronom trzecim.

4.3.4. DTLS-SRTP vs SDES

Aby wynegocjować parametry bezpieczeństwa dla sesji ruchu multimedialnego, SRTP musi wchodzić w interakcje z protokołem zarządzania kluczowym. Ten protokół nie jest ustalany, oferując szereg możliwych opcji dla zadania. Dwie takie opcje to SDES i DTLS-SRTP.

Warto zauważyć, że sygnalizacja (SIP, HTTP) i media (RTP) zaangażowane w komunikację multimedialną można zabezpieczyć niezależnie.

SDES

Opisy bezpieczeństwa SDP dla strumieni multimediów (SDES) były opcją wcześniej faworyzowaną przez WebRTC.

W SDES parametry bezpieczeństwa i klucze używane do konfigurowania sesji SRTP są wymieniane w wyraźnym tekście w postaci atrybutów SDP. Ponieważ SDP jest przekazywany nad płaszczyzną sygnalizacyjną, jeśli szyfrowanie nie jest dodatkowo wprowadzane na podstawie takich komunikatów sygnalizacyjnych, wchodząca strona trzecia może uzyskać klucze dla zaszyfrowanych danych SDES. Innymi słowy, należy zastosować dalszy protokół szyfrowania specjalnie do szyfrowania płaszczyzny sygnalizacyjnej. Jedną z takich opcji jest użycie TLS.

Niezależnie jednak zabezpieczenie sygnalizacji i mediów może prowadzić do sytuacji, ponieważ użytkownik multimediów różni się od użytkownika sygnalizacyjnego (ponieważ nie jest zapewniana gwarancja). Aby zapewnić tę gwarancję, konieczne jest wiązanie kryptograficzne. DTLS-SRTP to jeden taki mechanizm, który to zapewnia, ale SDE nie.

Pozostaje faktem, że nawet dziś większość ruchu RTP w sieciach VOIP nie jest zabezpieczona. W rzeczywistości szyfrowanie jest jedną z pierwszych funkcji, które klienci zwykle proszą dostawców o usunięcie, aby spełnić swoje budżety. Po zabezpieczeniu większość wdrożeń wykorzystuje SDE, które, jak już wspomnieliśmy.

DTLS-SRTP

DTLS-SRTP z drugiej strony wymienia klucze na płaszczyznę nośnika, a nie płaszczyznę sygnałową. Konsekwencją takiej różnicy jest to, że kanał multimedialny SRTP nie musi ujawniać tajnych kluczy szyfrowania za pośrednictwem wymiany wiadomości SDP, podobnie jak w przypadku SDES.

Specyfikacja WebRTC [9] twierdzi, że wdrożenia WebRTC są wymagane do obsługi DTLS-SRTP do zarządzania kluczami. Ponadto określa się, że jest to domyślny i preferowany program, i nie ma żadnych przepisów dotyczących wdrożenia innych kluczowych programów zarządzania. Innymi słowy, inne schematy mogą być w ogóle wspierane.

Jeśli oferta lub „połączenie” jest odbierane z obsługi reklamowej rówieśniczej zarówno dla DTLS-SRTP, jak i SDES, należy wybrać DTLS-SRTP-niezależnie od tego, czy sygnalizacja jest zabezpieczona, czy nie.

Debata

Ogólnie przyjmuje się, że DTLS-SRTP powinien być obowiązkową i domyślną opcją szyfrowania mediów WebRTC. Pyta się, czy inne mechanizmy, a mianowicie SDE, należy wykorzystać do zapewnienia kompatybilności wstecznej.

Z perspektywy kompatybilności przeglądarka Google Chrome zapewnia obsługę zarówno SDES, jak i DTLS-SRTP. Z drugiej strony Firefox Mozilli tylko implementuje DTLS-SRTP.

4.3.5. Słabość SRTP

SRTP szyfruje tylko ładunek pakietów RTP, nie zapewniając szyfrowania nagłówka. Jednak nagłówek zawiera różnorodne informacje, które mogą być pożądane, aby zachować tajemnicę.

Jedną z takich informacji zawartych w nagłówku RTP są poziomy audio zawartych danych multimedialnych. Skutecznie każdy, kto może zobaczyć pakiety SRTP, może stwierdzić, czy użytkownik mówi, czy nie w danym momencie. Chociaż zawartość samych mediów pozostaje w tajemnicy dla każdego podgrzewacza, wciąż jest to przerażająca perspektywa. Na przykład funkcjonariusze organów ścigania mogą ustalić, czy użytkownik komunikuje się ze znanym złym facetem.

4.4. Internetowe uwierzytelnianie rówieśnicze i zarządzanie tożsamością

Pożądane jest, aby użytkownik mógł zweryfikować tożsamość swoich rówieśników. I.mi. Użytkownik naturalnie chce mieć pewność, że rozmawia z osobą, którą uważają, że rozmawiają, a nie oszustem.

Chociaż serwer sygnalizacyjny może być w stanie przejść do ubiegania się o tożsamość użytkownika, sam serwer sygnalizacyjny może nie (i w przypadku uwierzytelnienia nie powinien być zaufany). Musimy być w stanie wykonać uwierzytelnianie naszych rówieśników niezależnie od serwera sygnalizacyjnego. Może to być możliwe dzięki zastosowaniu dostawców tożsamości.

Rysunek 4. Wezwanie z tożsamością opartą na IDP

Rysunek 4. Połączenie z tożsamością opartą na IDP

Wiele internetowych dostawców tożsamości (IDP) stało się ostatnio powszechne w Internecie, w tym Facebook Connect, Browserid (autor: Mozilla), OAuth (przez Twitter). Celem tych mechanizmów jest po prostu zweryfikowanie Twojej tożsamości wobec innych usług/użytkowników, w sprawie autorytetu samego dostawcy tożsamości. Jeśli użytkownik ma konto na Facebooku, może skorzystać z Facebooka Connect, IDP Facebooka, aby udowodnić innym, że są tym, co mówią, że są na Facebooku. Umożliwia to użytkownikom powiązanie uwierzytelniania na inne usługi z głównym kontem w usłudze „zaufanej”. Zauważ, że w tym przypadku poziom „zaufania”, jaki posiada dostawca tożsamości, jest subiektywny dla użytkownika lub usługi końcowej, i często jest w dużej mierze powiązany z bazą użytkowników i reputacją na całym świecie Web Web.

Wdrożenie każdego IDP mogą różnić się z powodu niezależnego rozwoju różnych firm, a nie opartych na standardzie open source, ale podstawowa zasada i funkcjonalność pozostają zasadniczo takie same. IDP nie zapewniają uwierzytelnienia dla serwera sygnalizacyjnego; Zapewniają raczej uwierzytelnianie użytkownikowi (i jego przeglądarce przez proces). WABRTC nie nakłada również wymagań, na których należy korzystać usługi, a te, które są używane, oparte są na wdrożeniu aplikacji internetowej.

Ponieważ aplikacja internetowa (witryna wywołująca) jest niezwiązana z tym procesem uwierzytelniania, ważne jest, aby przeglądarka bezpiecznie wygenerowała dane wejściowe do procesu uwierzytelniania, a także bezpiecznie wyświetla dane wyjściowe w aplikacji internetowej. Proces ten nie może być sfałszowany lub wprowadzony w błąd przez aplikację internetową.

Rysunek 5. Działanie dostawcy tożsamości

Rysunek 5. Działanie dostawcy tożsamości

4.5. Prywatność lokalizacji IP

Jednym niekorzystnym efektem ubocznym korzystania z lodu jest to, że rówieśnik może nauczyć się adresu IP. Ponieważ adresy IP są publicznie zarejestrowane w organach globalnych, mogą ujawnić takie szczegóły jak lokalizacja danego peer. Może to naturalnie mieć negatywne konsekwencje dla rówieśnika, którego chcieliby uniknąć.

WEBRTC nie jest zaprojektowany z zamiarem ochrony użytkownika przed złośliwą stroną internetową, która chce nauczyć się tych informacji. Zazwyczaj taka witryna uczy się przynajmniej adresu odruchowego serwera użytkownika z dowolnej transakcji HTTP. Ukrywanie adresu IP przed serwerem wymagałoby pewnego rodzaju wyraźnego mechanizmu zachowania prywatności na kliencie i nie jest w zakresie tego raportu.

WABRTC zapewnia jednak szereg mechanizmów, które mają na celu umożliwienie aplikacji internetowej na współpracę z użytkownikiem w celu ukrycia adresu IP użytkownika z drugiej strony połączenia. Te mechanizmy zostaną szczegółowo opisane.

Wymaganie WEBRTC jest wymagane do zapewnienia mechanizmu umożliwiającego JS tłumienia negocjacji lodu. Ten przepis pomaga użytkownikom końcowym w uniemożliwieniu rówieśnikowi na naukę adresu IP, jeśli zdecydują się nie odbierać połączenia. Ma to efekt uboczny ukrywania, czy użytkownik jest online, czy nie dla swoich rówieśników.

Drugim takim postanowieniem jest to, że każda implementacja zapewni mechanizm JavaScript aplikacji Calling, aby wskazać, że należy użyć tylko kandydatów. Może to w ogóle uniemożliwić rówieśnikowi nauki adresu IP.

Ponadto istnieje mechanizm aplikacji powołania do ponownego skonfigurowania istniejącego wezwania do dodania kandydatów bez obrotu. W połączeniu z poprzednim przepisem umożliwia to negocjacje ICE rozpocząć natychmiastowe powiadomienie o połączeniu, zmniejszając w ten sposób opóźnienie, ale także unikając ujawnienia adresu IP użytkownika, dopóki nie zdecyduje się odpowiedzieć. To pozwala użytkownikom całkowicie ukryć swój adres IP na czas trwania połączenia.

4.6. Warstwa sygnalizacyjna

Ponieważ protokół sygnalizacyjny nie jest określony przez WebRTC, mechanizm szyfrowania oczywiście zależy od wybranego protokołu sygnalizacyjnego. Ze względu na stosunkowo otwarty charakter bezpieczeństwa sygnalizacyjnego, raport ten skupi się na i krótko wyjaśni najczęstszego protokołu, SIP (protokół inicjacji sesji).

SIP to powszechnie zaimplementowany standard używany w komunikacji VOIP do konfigurowania połączeń telefonicznych. Jest to jednak pochodna HTTP i SMTP – oba są protokołami, które są regularnie wykorzystywane. Ponieważ używa wiadomości o prostym teście do wymiany informacji, możliwe jest, aby każda złośliwa strona dotknęła sieci i przechwytywać wiadomości SIP. Jeśli atakujący może odczytać poufne informacje użytkownika, może użyć tych informacji, aby sfałszować użytkownika. A jeśli atakujący może dalej uzyskać dostęp do sieci operatora, może być nawet możliwe rozszyfrowanie zawartości komunikacji WebRTC. [14]

Ponieważ SIP jest wysyłany w wyraźnym tekście, zdeterminowany atakujący jest przechwytujący wiadomości SIP. To, co dzieje się dalej, jest pozostawione w wyobraźni atakującego, ale nietrudno wyobrazić sobie ewentualność, ponieważ zawartość ciała lub nagłówka jest manipulowana. Jeśli atakujący przechwytuje wiadomość zaproszoną, może następnie zmienić nagłówek z nagłówkiem, aby odzwierciedlić swój własny adres IP.

4.6.1. SIP luki w zabezpieczeniach

SIP to protokół komunikacji do sygnalizacji i kontrolowania multimedialnych sesji komunikacyjnych i jest często wdrażany w technologiach VOIP w celu konfigurowania i rozrywania połączeń telefonicznych. Można go podobnie użyć w implementacji WebRTC do celów sygnalizacyjnych, jako jedna z wielu możliwych takich opcji. Jednak wiadomości SIP są często wysyłane w zwykłym tekście. Ponieważ może to naturalnie spowodować szereg potencjalnych wektorów ataku, podejmiemy bliżej tego obszaru.

Przepływ SIP

W trakcie konfigurowania połączenia przeglądarka użytkownika (lub „agent użytkownika”) rejestruje się z centralnym rejestratorem. Ta rejestracja jest koniecznością w tradycyjnym VoIP, ponieważ konieczne jest dostarczenie środków do zlokalizowania i skontaktowania się z odległą stroną.

Kiedy strona (Bob) chce zainicjować połączenie, wysyła wiadomość zaproszoną za pośrednictwem centralnego serwera proxy (to jest serwer sygnalizacyjny). Serwer jest odpowiedzialny za przekazanie takich wiadomości i zapewnienie środków do zlokalizowania innych użytkowników. Serwer może podjąć szereg miar zlokalizowania użytkownika końcowego podczas tego procesu wyszukiwania, takich jak korzystanie z DNS.

Porwanie rejestracji

Początkowa rejestracja przeglądarki służy do ogłoszenia punktu kontaktowego użytkownika i wskazuje, że urządzenie użytkownika akceptuje połączenia. Proces ten stanowi wektor dla złośliwych bytów do wykonania ataku „rejestracyjnego porwania”.

Wymiana komunikatów rejestracyjnych obejmuje pole „kontakt:”, zawierające adres IP użytkownika. Ilekroć serwer sygnalizacyjny przetwarza połączenie przychodzące, nazwa użytkownika (lub numer telefonu) jest dopasowany do zarejestrowanego adresu IP, a zaproszenie jest odpowiednio przekazywane. Rejestracje te są okresowo aktualizowane, zapewniając, że rekordy są przechowywane najnowsze i aktualne.

Ponieważ wiadomości SIP są zawsze wysyłane prostym tekstem, może być trywialne, aby atakujący przechwytywał i odczytał zawartość tych wiadomości rejestracyjnych. Po przechwyceniu można użyć odpowiedniego narzędzia (takiego jak generator wiadomości SIVUS) do generowania podobnych informacji SIP, ale z prawdziwym adresem IP użytkownika zastąpionym własnym atakującym. Atakujący musi wówczas jedynie wyłączyć prawdziwego użytkownika i okresowo wysyłać te informacje, aby przekierować wszystkie przychodzące połączenia.

Istnieje szereg metod, które atakujący mógłby wykorzystać, aby wyłączyć legalnego użytkownika, w tym: – wykonanie ataku DOS na urządzenie użytkownika – deregisterka użytkownika (kolejna liczba ataków, która nie jest tutaj objęta) – generowanie kwalifikacji wyścigowej rejestracji, w której atakujący wysyła wielokrotnie rejestrację żądań w krótszym czasie (jak każda 15 sekund) w celu przeglądu prośby o rejestrację uzasadnionego użytkownika. To wszystko jest prawdziwe ryzyko dla usług sygnalizacyjnych WebRTC.

Ponieważ wdrożenie SIP nie obsługuje integralności sprawdzania zawartości wiadomości, ataki modyfikacji i powtórki nie są wykrywane i są wykonalnym wektorem ataku. Ten atak działa, nawet jeśli serwer wymaga uwierzytelnienia rejestracji użytkownika, ponieważ atakujący może ponownie przechwycić, zmodyfikować i odtworzyć wiadomości zgodnie z potrzebami.

Atak ten można stłumić, wdrażając SIP (SIP przez TLS) i uwierzytelnianie żądań i odpowiedzi SIP (które mogą obejmować ochronę integralności). W rzeczywistości użycie SIPS i uwierzytelnianie odpowiedzi może tłumić wiele powiązanych ataków, w tym podsługa i podszywanie się w wiadomości lub użytkownika.

Inne możliwe ataki

  • Atak MITM
    • Jeśli atakujący jest w stanie przechwycić początkowe wiadomości SIP, może następnie wykonać atak MITM.
    • Zrejestrowane pakiety można odtworzyć na serwerze przez złośliwą imprezę, powodując, że serwer wywołał oryginalne miejsce docelowe połączenia. Innymi słowy, prawdopodobnie przybrałoby to formę drugiego niezamówionego żądania połączenia, identycznego z jedną, którą strona już otrzymała. Chociaż jest uciążliwość, napastnik nie byłby stroną połączenia, ponieważ ich informacje o adresie IP nie byłyby uwzględnione w pakietach sygnalizacyjnych.
    • Serwery internetowe nie są stanowcze, a każde żądanie służyło osobnej sesji (łagodzi potrzebę ciągłego uwierzytelniania). Pliki cookie do uwierzytelnienia, ale są niczym więcej niż plikami danych zawierającymi identyfikator sesji. Te pliki cookie są wysyłane przez serwer WWW do przeglądarki po początkowym dostępie.

    Szyfrowanie

    Chociaż może się wydawać, że sygnalizacja stanowi szczególnie kuszący punkt widzenia dla atakujących, wszystko nie jest utracone. Oprócz strumieni multimediów można również szyfrować warstwę sygnalizacyjną. Jedną z takich zaszyfrowanych opcji jest OnsiP, która używa SIP przez bezpieczne WebSockets (WSS: // zamiast WS: //), z połączeniem WebSocket zaszyfrowanym przez TLS.

    Chociaż poza zakresem tego raportu inne technologie sygnalizacyjne mogą podobnie wykorzystywać TLS do szyfrowania swojego WebSocket lub innego ruchu internetowego. Podobnie jak w przypadku całego szyfrowania, jeśli strona trzecia nie zna tajnego klucza szyfrowania, nie są w stanie odczytać zawartości polegającej na tekstie komunikacji. Pomaga to wyeliminować ryzyko większości powyższych wektorów ataku, chociaż należy zauważyć, że programista aplikacji musi konkretnie zaimplementować zaszyfrowaną metodę sygnalizacyjną, aby miała zastosowanie.

    4.7. Dodatkowe tematy bezpieczeństwa

    Punkt widzenia sieci telekomunikacyjnej

    Zapewniając wsparcie WebRTC, sieć telekomunikacyjna powinna racjonalnie oczekiwać, że nie będzie narażona na zwiększone zagrożenie bezpieczeństwa. Jednak urządzenia lub oprogramowanie w rękach konsumentów nieuchronnie będą narażone przez złośliwe partie.

    Z tego powodu wszystkie dane otrzymane z niezaufanych źródeł (e.G. od konsumentów/użytkowników) musi zostać zatwierdzony, a sieć telekomunikacyjna musi założyć, że wszelkie dane wysłane do klienta zostaną uzyskane przez złośliwe źródła.

    Przyjmując te dwie zasady, dostawca telekomunikacyjny musi starać się podjąć wszelkie uzasadnione próby ochrony konsumenta przed własnymi błędami, które mogą zagrozić własnym systemom.

    Skrypty krzyżowe (XSS)

    Skrypty między witrynami to podatność typu zwykle występująca w aplikacjach internetowych (takich jak przeglądarki internetowe poprzez naruszenia bezpieczeństwa przeglądarki), która umożliwia atakującym skrypt po stronie internetowej przeglądane przez innych użytkowników. Atakerzy może użyć podatności na skryptowe skryptowanie.

    Ich wpływ może wahać się od drobnego uciążliwości do znacznego ryzyka bezpieczeństwa, w zależności od wrażliwości danych obsługiwanych przez stronę wrażliwą i charakter wszelkich łagodzeń bezpieczeństwa wdrożonych przez stronę’właściciel S.

    Ponieważ oczekuje się, że podstawową metodą dostępu do WebRTC jest stosowanie przeglądarek obsługiwanych przez HTML5, istnieją szczególne względy bezpieczeństwa dotyczące ich zastosowania, takie jak; Ochrona klawiszy i wrażliwych danych przed atakami między witrynami lub atakami między domenami, używaniem WebSocket, bezpieczeństwa iframe i innych problemów. Ponieważ oprogramowanie klienta będzie kontrolowane przez użytkownika i ponieważ przeglądarka nie w większości przypadków działa w chronionym środowisku, istnieje dodatkowe szanse, że klient WebRTC zostanie naruszony. Oznacza to, że wszystkie dane wysłane do klienta mogą zostać ujawnione.

    5. Porównanie z konkurencyjnymi/podobnymi technologiami

    Badanie bezpieczeństwa porównawczego WebRTC nie miałoby sensu bez rozważania bezpieczeństwa konkurencji. Na szczęście dla WebRTC konkurencja na internetowej arenie komunikacyjnej ma własny udział w problemach.

    W tej sekcji zbadano porównawcze mocne i słabe strony WebRTC i innych platform oferujących konkurencyjne funkcje RTC.

    Niektóre platformy, które moglibyśmy zbadać. Platformy do zbadania nie zostały jeszcze wybrane. (Przyjść po pierwszym diecie.)

    Chociaż powszechnie opierane, dodatkowe procesy instalacji mogą stanowić barierę

    6. Bezpieczne praktyki projektowe

    WEBRTC jest zbudowany tak, aby był bezpieczny. Jednak nie tylko ślepo poleganie na podstawowej technologii, dobrym pomysłem jest świadomie kodowanie z myślą o bezpieczeństwie. W tej sekcji omówi praktyki kodowania, które można zastosować, aby zapewnić większe bezpieczeństwo w stosunku do wanilii WEBRTC. W szczególności praktyki te mogą mieć zastosowanie do organizacji, które spodziewają się obsługi poufnych informacji, e.G. instytucje bankowe, instytucje opieki zdrowotnej lub poufne informacje korporacyjne.

    Bezpieczna sygnalizacja

    Jak wspomniano wcześniej, WebRTC nie nakłada żadnych ograniczeń na proces sygnaliza. Chociaż pozwala to na stopień elastyczności, który może mieć implementację WebRTC dostosowaną do potrzeb aplikacji, może istnieć ryzyko związane z niektórymi protokołami sygnalizacyjnymi.

    Wskazane jest wdrożenie protokołu sygnalizacyjnego, który zapewnia dodatkowe bezpieczeństwo, takie jak szyfrowanie ruchu sygnalizacyjnego. Domyślnie proces sygnalizacyjny może nie obejmować żadnego szyfrowania, które może pozostawić zawartość wszystkich wymienionych komunikatów sygnalizacyjnych otwartych na podsłuch. Aplikacje z naciskiem na bezpieczeństwo/poufność powinny zatem zapewnić wdrożenie ich warstwy sygnalizacyjnej w stosunku do bezpiecznego protokołu, takich jak SIP, OpenSip, HTTPS lub WSS.

    Uwierzytelnianie i monitorowanie rówieśników

    Podstawowa aplikacja WebRTC wymaga tylko identyfikatora użytkownika w celu wykonania połączenia, bez uwierzytelnienia z punktu widzenia samej usługi. Może być pożądane wymaganie wstępnej rejestracji lub uwierzytelnienia, zanim jakikolwiek użytkownik będzie mógł wziąć udział w połączeniu. Nieautentyczne podmioty należy następnie trzymać z dala od sesji’zasięg, ograniczając dostęp do niezaufanych stron.

    Ponieważ połączenia multimedialne to P2P, zawartość mediów (kanały audio i wideo) są przesyłane między rówieśnikami bezpośrednio w pełnym dupleksie. Zatem gdy serwer sygnalizacyjny utrzymuje liczbę rówieśników w komunikacji, można go konsekwentnie monitorować w celu dodania podejrzanych rówieśników podczas sesji połączeń. Jeśli liczba rówieśników faktycznie obecnych na serwerze sygnalizacyjnym jest bardziej niż liczba rówieśników oddziałujących na stronie WebRTC, może to oznaczać, że ktoś podsługa potajemnie i powinien zostać zakończony z dostępu do sesji przez siłę.

    Żądania uprawnień

    Jest to znane zachowanie, które często użytkownicy zgodzą się na żądania zgody lub podobne dialog bez świadomego czytania wiadomości. Stwarza to ryzyko przyznania aplikacji internetowej z uprawnieniami, które nie były w rzeczywistości przeznaczone przez użytkownika.

    Chociaż samo zachowań nie można łatwo rozwiązać, jednym z rozwiązań może być jasne szczegółowe szczegółowe informacje na stronie, o jakie uprawnienia poprosi. Taka aplikacja umieszcza prywatność użytkownika na pierwszym planie.

    Człowiek w środku

    W ewentualnym, że złośliwej partii uda się ustanowić atak MITM, zazwyczaj nie ma łatwego rozwiązania do odkrycia lub walki z nim. Wynika to z faktu, że atak nie ma ostrzeżenia, a komunikacja może postępować jak zwykle. Jeśli nie oczekuje takiego ataku, atak prawdopodobnie będzie niezauważony.

    Jednak poprzez regularne monitorowanie ścieżki medialnej bez podejrzanych przekaźników, możemy zrobić jeden mały krok w kierunku łagodzenia ataków MITM. Należy to połączyć z zaszyfrowaną sygnalizacją, jak wspomniano powyżej.

    Udostępnianie ekranu

    Aplikacja oferująca dowolny stopień funkcjonalności udostępniania ekranu powinien mieć ostrzeżenia w celu ochrony użytkownika. Jak wspomniano wcześniej, użytkownik może nie być świadomy zakresu udostępniania ekranu. Taki problem powinien wrócić do odpowiednio zaprojektowanej aplikacji, aby dostarczyć odpowiednich takich informacji.

    Na przykład przed rozpoczęciem strumieniowego przesyłania dowolnej części ekranu użytkownik powinien zostać odpowiednio powiadomiony i zalecany zamknięciem dowolnego ekranu zawierającego poufne informacje.

    Awans

    Jako ostateczny środek awarii moglibyśmy zaryzykować, jeśli chodzi o wyobrażenie o sytuacji, ponieważ aktywna sesja połączeń jest narażona na nieuprawnioną stronę. Jeśli potwierdzono, że połączenie jest zagrożone w taki sposób, powinno być ono w zasilaniu serwera aplikacji WWW, renderującą stronę WebRTC do odcięcia połączenia.

    7. Wniosek

    We współczesnym wieku smartfonów i urządzeń mobilnych ludzie komunikują się bardziej niż kiedykolwiek, i na jeszcze bardziej osobisty sposób, niż wcześniej wiedzieliśmy. W szczególności szyfrowanie stało się dużym tematem w ostatnich latach, po rosnącej świadomości głównych skandali hakowania korporacyjnego i powszechnego podsłuchu telekomunikacji rządowej. Rezultatem był szybki wzrost nieufności użytkowników wobec takich organizacji i wymaga broni do wdrażania znacznie lepszych środków bezpieczeństwa. Wszystko, czego chce użytkownik końcowy, to wiedzieć, że ich dane osobowe są prywatne pod kontrolą.

    WEBRTC ma dużą przewagę nad większością usług VoIP w obszarze bezpieczeństwa. Do tej pory większość usług zwykle traktowała bezpieczeństwo jako opcjonalne, co oznacza, że ​​większość użytkowników końcowych używa połączeń VoIP bez szyfrowania. W szczególności duże korporacje są wiodącym winowajcą, wybierając zaoszczędzenie pieniędzy na tańszych implementacjach, a nie prawidłowo rozważając ich użytkowników lub wartość danych, z którymi obsługują dane. Ale ponieważ WebRTC zagraża niezaszyfrowanej komunikacji, użytkownicy mogą być pewni, że ich dane pozostają bezpieczne i prywatne.

    Zaprojektowano z myślą o bezpieczeństwie, WebRTC egzekwuje lub zachęca do ważnych koncepcji bezpieczeństwa we wszystkich głównych obszarach. Jako takie, a także po prostu zbudowane, zachęca programistów WebRTC do poważnego traktowania ich bezpieczeństwa.

    W wyniku tego silnego skupienia się na bezpiecznej komunikacji WEBRTC jest obecnie uważany za jedno z najbezpieczniejszych rozwiązań VoIP. Główną założeniem, że szyfrowanie domyślnie polega na tym, że połączenie jest przez cały czas prywatne. Bezpieczeństwo i szyfrowanie nie są już uważane za funkcje opcjonalne. Aby wszystko zakończyć, WebRTC jest dostępny dla wszystkich, zapewniając kuszącą i niezawodną ramy dla programistów do zbudowania następnej aplikacji.

    W najbliższej przyszłości możemy spodziewać się coraz więcej usług komunikacyjnych zapewniających znacznie zwiększone bezpieczeństwo swoim użytkownikom. Ale na razie WebRTC jest jednym z tych, którzy prowadzą szarżę.

    8. Bibliografia

    2. Krótkie wprowadzenie do API RTCPeerConnection .
    Wysoko wydajne sieci przeglądarki. Dostęp w dniach 2015-07-28.

    3. SDP dla WebRTC .
    narzędzia.IETF.org. Dostęp w dniach 2015-07-28.

    8. Atak tygodnia: DataGram TLS .
    blog.Kryptograficzne obsługę.com. Dostęp w dniach 2015-07-28.

    12. Agenda IETF-87 RTCWEB .
    narzędzia.IETF.org. Dostęp w dniach 2015-07-28.

    15. Bezpieczeństwo w sieci SIP: identyfikacja ataków sieciowych .
    SearchunifiedCommunications.TechTarget.com. Dostęp w dniach 2015-07-28.

    17. Bezpieczeństwo aplikacji WebRTC .
    Altanaitalelecom.WordPress.com. Dostęp w dniach 2015-07-28.

    18. WEBRTC Security .
    Altanaitalelecom.WordPress.com. Dostęp w dniach 2015-07-28.

    SRTP za pomocą protokołu DTLS

    W przypadku połączeń SBC możesz skonfigurować urządzenie do korzystania z protokołu Datagram Transport Warstwa Security (DTLS) w celu zabezpieczenia ruchu opartego na UDP (zgodnie z RFC 4347 i 6347) dla określonych jednostek SIP, używając profili IP, używając profili IP. DTLS pozwala aplikacjom opartym na datagramie komunikować. Protokół DTLS opiera się na protokole TLS zorientowanym na strumień, zapewniając podobne bezpieczeństwo. Urządzenie może zatem interpretować w mieszanych środowiskach, w których jedna sieć może wymagać DTLS, a druga może wymagać opisów bezpieczeństwa protokołu sesji (SDES), a nawet niezabezpieczonego RTP. Urządzenie obsługuje negocjacje DTLS dla połączeń RTP-to-SRTP i SRTP-to-SRTP.

    Obsługa DTLS jest ważna dla wdrożeń z WEBRTC. WEBRTC wymaga szyfrowania kanałów multimede. Negocjacje klawiszy SRTP przez DTLS odbywają się podczas uścisku dłoni DTLS między klientem WebRTC a rówieśnikiem. Aby uzyskać więcej informacji na temat WebRTC, patrz WebRTC.

    W przeciwieństwie do SDES, szyfrowanie klucza DTLS odbywa się przez kanał multimedialny (UDP), a nie przez kanał sygnalizacyjny. Zatem DTLS-SRTP jest ogólnie znany jako „zabezpieczona wymiana kluczy nad mediami”. DTLS jest podobny do TLS, ale działa nad UDP, podczas gdy TLS jest ponad TCP. Przed uściskiem dłoni DTLS parametry DTLS Extls (odcisk palca i konfiguracja) oraz typy algorytmu w treści SDP wiadomości SIP wymienionych na ustanowienie połączenia (żądanie i odpowiedź zaproszenia). Rówieśnicy uczestniczą w uścisku dłoni DTLS, podczas którego wymieniają certyfikaty. Te certyfikaty służą do uzyskania klucza symetrycznego, który służy do szyfrowania danych (SRTP) między rówieśnikami. Wartość skrótu obliczona przez certyfikat jest transportowana w SDP przy użyciu atrybutu „a = odcisk palca”. Na końcu uścisku dłoni każda strona sprawdza, czy certyfikat otrzymany z drugiej strony pasuje do odcisku palca z SDP. Aby wskazać obsługę DTLS, oferta/odpowiedź SDP/odpowiedź komunikatu SIP używa atrybutu „a = setup”. Wartość atrybutu „a = setup: aktPass” jest używana w ofercie SDP przez urządzenie. Wskazuje to, że urządzenie jest skłonne być klientem („ACT”) lub serwerem („pass”) w uścisku dłoni. Wartość atrybutu „a = setup: Active” jest używana w odpowiedzi SDP przez urządzenie. Oznacza to, że urządzenie chce być klientem („aktywnym”) w uścisku dłoni.

    a = konfiguracja: ActPass
    A = odcisk palca: SHA-1 \ 4a: AD: B9: B1: 3f: 82: 18: 3b: 54: 02: 12: DF: 3e: 5d: 49: 6b: 19: e5: 7c: AB: AB: AB: AB: AB: AB: AB: AB: AB: AB: AB: AB: AB: AB

    DTLS Cipher Suite ponownie wykorzystuje apartament szyfru TLS. Uzupełnienie dłoni DTLS odbywa się dla każdego nowego połączenia skonfigurowanego dla DTLS. Innymi słowy, w przeciwieństwie do TLS, w których połączenie pozostaje „otwarte” dla przyszłych połączeń, dla każdego nowego połączenia wymagane jest nowe połączenie DTLS. Należy zauważyć, że całe uwierzytelnianie i wymianę kluczy do zabezpieczenia ruchu multimedialnego są obsługiwane na ścieżce multimediów przez DTLS. Ścieżka sygnalizacyjna jest używana tylko do weryfikacji odcisków palców certyfikatów rówieśników. Wiadomości DTLS są multipleksowane na tych samych portach, które są używane dla multimediów.

    ➢ Aby skonfigurować DTLS:
    1. W tabeli kontekstowej TLS (patrz Konfigurowanie kontekstów certyfikatów TLS) skonfiguruj kontekst TLS z wersją DTLS [tlsContexts_dtlSversion].
    2. Otwórz tabelę grup IP (patrz Konfigurowanie grup IP), a następnie dla grupy IP powiązanej z encją SIP, przypisz jej kontekst TLS dla DTLS, używając parametru „Media TLS Context” [ipgroup_dtlscontext].
    3. Otwórz tabelę profili IP (patrz Konfigurowanie profili IP), a następnie dla profilu IP powiązanego z encją SIP, skonfiguruj następujące:
    ● Skonfiguruj parametr „Tryb bezpieczeństwa multimedialnego SBC [IPPROFILE_SBCMEDIASECURETYBEBELEBEHAVIOR] .
    ● Skonfiguruj parametr „metoda bezpieczeństwa mediów” [ipprofile_sbcmediasecurityMethod] na DTLS .
    ● Skonfiguruj parametr „RTCP MUX” [ipprofile_sbcrtcpmux] do obsługi . Multipleksowanie jest wymagane, ponieważ uścisk dłoni DTLS jest wykonywany dla portu używanego dla RTP, a zatem RTCP i RTP muszą być multipleksowane na tym samym porcie.
    ● Skonfiguruj parametr pliku INI [SBCDTLSMTU] (lub polecenie CLI Skonfiguruj VoIP> SBC Ustawienia> SBC-DTLS-MTU), aby zdefiniować rozmiar maksymalnego jednostki transmisji (MTU) dla uścisku dłoni DTLS.
    4. Skonfiguruj minimalny odstęp, który urządzenie czeka między transmisją pakietów DTLS w tym samym uścisku dłoni DTLS, przy użyciu parametru pliku INI [dtlstimeBetWeentransmissions].
    ● Parametr „serwera szyfrów” musi być skonfigurowany do „wszystkich”.
    ● Urządzenie nie obsługuje przekazywania DTLS przezroczystych między punktami końcowymi.