„Czy WebRTC jest bezpieczne?” to jedno z tych pytań, które brzmią prosto, a zasługują na rzetelną odpowiedź, zwłaszcza jeśli zaraz przeprowadzisz za jego pomocą prezentację dla zarządu, rozmowę z inwestorami albo pitch dla klienta. Krótka wersja brzmi: tak, z założenia. Uczciwa wersja wyjaśnia jednak dlaczego, bo „to standard webowy” sam w sobie nie jest żadnym argumentem.
WebRTC to technologia stojąca za większością nowoczesnych narzędzi peer-to-peer do wideo i sterowania, w tym za połączeniem między telefonem prezentera a komputerem, na którym działają jego slajdy w Cliqer. Zrozumienie, co chroni, a czego nie, pozwoli Ci lepiej ocenić każde narzędzie, które z niego korzysta, nie tylko nasze.
WebRTC, czyli Web Real-Time Communication, to otwarty standard utrzymywany przez W3C i natywnie obsługiwany przez każdą popularną przeglądarkę. Określa, jak dwa urządzenia mogą nawiązać bezpośrednie połączenie, aby wymieniać dźwięk, obraz lub dowolne dane, bez konieczności instalowania wtyczki po żadnej ze stron. Specyfikację techniczną i informacje ogólne znajdziesz na webrtc.org.
Słowo kluczowe to „bezpośrednie”. W przeciwieństwie do rozmowy wideo kierowanej w całości przez serwery firmy, WebRTC jest zaprojektowane tak, by łączyć dwa urządzenia ze sobą tak bezpośrednio, jak pozwala na to sieć, i korzystać z przekaźnika tylko wtedy, gdy bezpośrednia ścieżka jest niemożliwa. Właśnie ta jedna decyzja projektowa sprawia, że reszta artykułu ma znaczenie: protokół zbudowany wokół połączeń bezpośrednich potrzebuje innego modelu bezpieczeństwa niż protokół oparty na centralnym serwerze, a obie te połowy warto zrozumieć, zanim powierzysz mu treści z sali posiedzeń zarządu.
To jest część, która faktycznie odpowiada na pytanie o bezpieczeństwo. WebRTC nie oferuje trybu nieszyfrowanego. Każde połączenie WebRTC, niezależnie od tego, czy przenosi kanał danych, dźwięk czy obraz, jest z założenia szyfrowane:
Nie ma flagi konfiguracyjnej, która by to wyłączała. Szyfrowanie jest wbudowane w standard, co stanowi zupełnie inną gwarancję niż „zdecydowaliśmy się włączyć szyfrowanie”, bo nie da się go po cichu źle skonfigurować.
Ponieważ WebRTC łączy urządzenia bezpośrednio, zbudowana na nim aplikacja ma realny wybór, którego nie mają narzędzia kierujące ruch przez serwer: czy treści w ogóle muszą trafić na jakikolwiek serwer. W Cliqer polecenia przełączania slajdów, współrzędne wskaźnika laserowego, stan timera oraz każdy strumień ekranu lub kamery przesyłane są bezpośrednio między urządzeniem prezentera a komputerem hosta albo przez zaszyfrowany przekaźnik, jeśli bezpośrednia ścieżka nie jest dostępna. Serwery aplikacji koordynują, kto jest w pokoju; nigdy nie znajdują się na samej ścieżce mediów, a treść Twojej prezentacji nigdy nie jest przesyłana na serwer.
Taka architektura ma największe znaczenie przy wszystkim, co poufne: prezentacjach dla zarządu, roadmapach produktów, nieopublikowanych danych finansowych. Ten konkretny przypadek omawiamy szerzej w artykule prezentowanie poufnych treści.
Nie każda sieć pozwala na połączenie bezpośrednie. Firmowe zapory sieciowe, hotelowe Wi-Fi i NAT operatorski (CGNAT) mogą blokować bezpośrednią ścieżkę preferowaną przez WebRTC. Gdy tak się dzieje, połączenie przechodzi na przekaźnik TURN, który przekazuje te same pakiety zaszyfrowane DTLS i SRTP, nie mając kluczy do ich odszyfrowania. Przekaźnik przenosi bajty; nie może ich odczytać.
Dokładnie, jak działa ten mechanizm awaryjny i dlaczego nie obniża poziomu bezpieczeństwa, wyjaśniamy w artykule serwery TURN w pigułce. To także powód, dla którego firmowe zapory rzadko całkowicie blokują dobrze zbudowane narzędzie WebRTC, o czym piszemy w artykule dlaczego firmowe zapory blokują narzędzia do prezentacji.
| Warstwa | Protokół | Chroni |
|---|---|---|
| Sygnalizacja | WSS (TLS 1.2+) | Metadane koordynacji pokoju, zanim powstanie połączenie peer-to-peer |
| Kanał danych | DTLS | Sygnały sterujące: polecenia slajdów, pozycja wskaźnika, stan timera |
| Media | SRTP | Strumienie z kamery i udostępniania ekranu, gdy są włączone |
| Przekaźnik awaryjny | DTLS/SRTP przez TURN | Ten sam zaszyfrowany ładunek, przekazywany bez odszyfrowania na przekaźniku |
Szyfrowanie w transmisji to nie cała historia bezpieczeństwa i warto uczciwie powiedzieć, czego nie obejmuje:
Przejęcie urządzenia końcowego
Jeśli samo urządzenie zostało przejęte, szyfrowanie w transmisji nie pomoże. Aktualizuj system operacyjny, przeglądarkę i oprogramowanie do prezentacji.
Kogo wpuszczasz do pokoju
WebRTC zabezpiecza łącze; kontrola dostępu decyduje, kto w ogóle je dostaje. To zadanie dla ról w zespole i SSO, a nie dla protokołu transportowego.
Metadane
Sygnalizacja przenosi informacje o tym, kto jest w pokoju i jak się z nim połączyć, czyli dane koordynacyjne, a nie treść prezentacji, ale i tak warto wiedzieć, że istnieją. Pełne zestawienie znajdziesz na diagramie przepływu danych.
Kto loguje się do samego konta
Silne szyfrowanie transportu nic nie daje kontu chronionemu słabym lub wielokrotnie używanym hasłem. Połącz je z single sign-on lub kluczami dostępu na poziomie konta.
Nie musisz wierzyć dostawcy na słowo. Kilka praktycznych testów:
Jeśli oceniasz narzędzie dla całego zespołu, a nie na pojedyncze spotkanie, włącz to do szerszej listy kontrolnej bezpieczeństwa oprogramowania do prezentacji, bo szyfrowanie to tylko jedna z wielu pozycji, które powinien obejmować rzetelny przegląd.
Tak, w tym sensie, że każde połączenie jest z założenia szyfrowane i nie ma trybu nieszyfrowanego. To, czy aplikacja zbudowana na WebRTC nadaje się do poufnych treści, zależy też od tego, czy gdziekolwiek je przechowuje, a to pytanie dotyczy aplikacji, nie protokołu.
Nie. Preferuje połączenie bezpośrednie, ale przechodzi na zaszyfrowany przekaźnik TURN, gdy sieć na to nie pozwala, na przykład za niektórymi firmowymi zaporami lub przy symetrycznym NAT.
Nie. Przekaźniki TURN przekazują zaszyfrowane pakiety DTLS i SRTP, nie mając kluczy potrzebnych do ich odszyfrowania. Przenoszą bajty, nie treści.
Nie. VPN szyfruje cały ruch urządzenia i kieruje go przez podmiot zewnętrzny. WebRTC nawiązuje zaszyfrowane połączenie dla konkretnej aplikacji, najlepiej bezpośrednio między dwoma zaangażowanymi urządzeniami, z przekaźnikiem wyłącznie jako rozwiązaniem awaryjnym.
Jeśli szyfrowanie i routing peer-to-peer mają znaczenie przy ocenie narzędzi do prezentacji, przeczytaj pełny przegląd bezpieczeństwa albo wypróbuj Cliqer za darmo i sprawdź działanie połączenia samodzielnie, zanim zaprezentujesz z jego pomocą cokolwiek poufnego.
Prezentacje uczniów: technologia w klasie, która usuwa przeszkody
Technologia w klasie, dzięki której uczniowie prezentują ze swojego miejsca, bez przepinania kabli i logowania, które zjadają czas lekcji.
Operator slajdów czy kontrola przez prelegenta? Jak wybrać właściwy model
Czy slajdy powinien przełączać operator, czy prelegenci mają klikać sami? Jak wybrać właściwy model dla Twojego wydarzenia.
Czytaj dalej
Praktyczne poradniki dla prezenterów, ekip AV i zespołów eventowych oraz wydania Cliqer, które mają znaczenie. Bez spamu, rezygnacja jednym kliknięciem.
