Чи можу я повністю вимкнути WebRTC?

Так, у Firefox: about:config → media.peerconnection.enabled → false. Браузери Chromium не відображають перемикач без розширення (uBlock Origin має налаштування; WebRTC Network Limiter від Google є ще одним). Вимкнення порушує роботу будь-якого сайту, який використовує WebRTC для викликів.

Чи захищає VPN від витоку WebRTC?

Залежить від браузера. Сучасні браузери не розкривають загальнодоступну IP-адресу JavaScript без дозволу медіа, тому пасивний витік WebRTC через VPN рідко трапляється за умовчанням. Але якщо сторінка викликає getUserMedia і користувач погоджується, зібрані кандидати можуть містити загальнодоступну IP-адресу VPN (це очікувано) або справжню IP-адресу, якщо стек IPv6 просочується навколо VPN.

Що таке сервер STUN і хто ним керує?

Сервери STUN просто відображають вихідну IP-адресу та порт, які вони бачать — маленькі, без збереження даних, вільні для роботи. Google керує публічним сервером STUN за адресою stun.l.google.com:19302; Twilio, Mozilla та інші керують своїми. Багато програм використовують Google за умовчанням. Сервери STUN бачать лише те, що запит відбувся; вони не бачать медіа, яке тече після.

Чи зашифровано WebRTC?

Завжди, за спец. Рукостискання DTLS отримує ключі для SRTP, який шифрує медіа. Канал даних зашифрований DTLS. Ви не можете вимкнути шифрування. Наскрізне шифрування є окремою властивістю — групові виклики через SFU можуть бути E2EE, лише якщо програма явно реалізує це (Zoom, Signal роблять; багато простіших програм цього не роблять).

Чому міжбраузерне відео зараз таке гарне, ніж десять років тому?

Апаратне прискорення кодека (AV1, VP9, H.264 на графічному процесорі), контроль перевантажень, налаштований для медіа в реальному часі (алгоритм контролю перевантажень Google) і кращий обхід NAT, що робить прямі шляхи можливими частіше. Усе це всередині WebRTC.

Пояснення WebRTC: протокол браузера, який підтримує відеодзвінки

WebRTC — це протокол, який дозволяє двом браузерам спілкуватися один з одним напряму — одноранговий, з низькою затримкою, зі звуком, відео або даними. Це зробило відеодзвінки через браузер життєздатними. Це також створило абсолютно нову категорію витоку конфіденційності, тому що, щоб знайти один одного через NAT, браузери повинні досліджувати свої загальнодоступні IP-адреси таким чином, щоб розкрити їх JavaScript.

Повний текст статті подано англійською мовою нижче.

WebRTC (Web Real-Time Communication) — це набір API, вбудований у кожен сучасний браузер, який дозволяє веб-сторінкам встановлювати прямі однорангові з’єднання одна з одною або з рідними програмами. Він підтримує Google Meet, Zoom у веб-переглядачі, голосовий чат Discord, Twitter Spaces у їхні дні та незліченну кількість менших служб. Без WebRTC відео в режимі реального часу в браузері все ще було б пропозицією Flash або bust.

Що містить специфікація

WebRTC об’єднує три основні API:

getUserMedia — доступ до камери та microphone
RTCPeerConnection — керує фактичним одноранговим з’єднанням: узгодження кодеків, шифрування, обхід NAT, контроль перевантаження
RTCDataChannel — надсилає довільні двійкові або текстові дані через з’єднання, однорангове

Саме підключення використовує ICE (Interactive Connectivity Establishment) для обходу NAT, DTLS для шифрування рукостискання та SRTP для шифрування медіа. За замовчуванням усе з’єднання зашифровано наскрізно; ви не можете вимкнути його.

Як однорангові вузли знаходять один одного

Важкою частиною однорангового з’єднання є те, що обидва однорангові вузли зазвичай знаходяться за NAT. WebRTC використовує ICE для виявлення можливих мережевих шляхів:

Браузер запитує сервер STUN «як виглядають мої публічні IP-адреса та порт?» Сервер STUN відповідає з адресою джерела, яку він побачив — це зовнішнє відображення NAT.
Браузер збирає всі свої адреси-кандидати: локальні IP-адреси в локальній мережі, відкриті STUN загальнодоступні IP-адреси, за бажанням ретрансляцію TURN, якщо NAT неможливо пройти.
Однорангові вузли обмінюються списками кандидатів через сигнальний канал (зазвичай це WebSocket до сервера програми).
Вони намагаються підключитися до кожної комбінації, доки одна з них не вдасться.

Проблема витоку IP-адреси

Крок збору кандидатів є джерелом витоку IP-адреси WebRTC. JavaScript може попросити веб-переглядач розпочати збір кандидатів ICE — і веб-переглядач відкриє на сторінці загальнодоступні та локальні IP-адреси. Сторінка, яка хоче відстежувати вас, може викликати new RTCPeerConnection().createDataChannel(...), зібрати кандидатів і тепер знати ваш справжній IP незалежно від будь-якої обфускації HTTP-рівня.

Це було виявлено в 2015 році та швидко стало стандартною пістолетом конфіденційності. Витоки WebRTC пояснюють, чому особа, яка користується VPN, усе ще може бачити свою справжню IP-адресу для веб-сайту, який запитує правильний шлях.

Що з цим зроблено

Постачальники браузерів у відповідь поступово обмежують список кандидатів, які може бачити сторінка:

Поведінка за замовчуванням у сучасному Chrome/Firefox/Safari розкривати лише локальні IP-адреси (ті, що знаходяться в локальній мережі — зазвичай 192.168.x або 10.x) без явного дозволу. Імена хостів
mDNS замінюють локальні IP-адреси для з’єднань — замість того, щоб розкривати 192.168.1.42, браузер використовує рандомізований .local hostname.
IЯкщо сторінка викликає getUserMedia (наприклад, справжній відеодзвінок), браузер збирає повні кандидати, включаючи загальнодоступну IP-адресу — на цьому етапі ви все одно надали дозвіл на медіа.

Результат: пасивні IP-витоки WebRTC здебільшого закриті в налаштуваннях за замовчуванням. Сайти, які агресивно збирають кандидатів, все ще існують, а користувачі зі старими браузерами або послабленими налаштуваннями все ще вразливі. Наш посібник із витоків WebRTC охоплює перевірку.

Чому одноранговий зв’язок важливий

Для викликів двох осіб WebRTC надсилає медіафайли безпосередньо між одноранговими вузлами, а сервер сигналізації використовується лише для налаштування з’єднання. Відео не проходить через сервери програми. Це значно дешевше в експлуатації (без витрат на смугу пропускання для медіа) і значно менша затримка (без додаткових стрибків). Для групових дзвінків зазвичай потрібен блок вибіркової переадресації (SFU) — сервер, який передає медіа — але шифрування все одно є наскрізним, якщо його налаштовано правильно.

Куди йде WebRTC

Наступним важливим кроком є WebTransport (низькопівневий API на основі QUIC для нереального часу двонаправлені потоки) і WebCodecs (необроблений доступ до обладнання кодера/декодера). Разом вони відкривають нові варіанти використання, такі як хмарні ігри, перекодування відео з низькою затримкою в браузері та масова однорангова передача файлів із кращим контролем перевантажень, ніж RTCDataChannel.

Сам WebRTC також модернізується — оригінальна семантика SDP плану B поступово припиняється на користь уніфікованого плану, а поверхня API стає чистішою для розробників.

Часті запитання

Чи можу я повністю вимкнути WebRTC?: Так, у Firefox: about:config → <code>media.peerconnection.enabled</code> → false. Браузери Chromium не відображають перемикач без розширення (uBlock Origin має налаштування; WebRTC Network Limiter від Google є ще одним). Вимкнення порушує роботу будь-якого сайту, який використовує WebRTC для викликів.
Чи захищає VPN від витоку WebRTC?: Залежить від браузера. Сучасні браузери не розкривають загальнодоступну IP-адресу JavaScript без дозволу медіа, тому пасивний витік WebRTC через VPN рідко трапляється за умовчанням. Але якщо сторінка викликає getUserMedia і користувач погоджується, зібрані кандидати можуть містити загальнодоступну IP-адресу VPN (це очікувано) або справжню IP-адресу, якщо стек IPv6 просочується навколо VPN.
Що таке сервер STUN і хто ним керує?: Сервери STUN просто відображають вихідну IP-адресу та порт, які вони бачать — маленькі, без збереження даних, вільні для роботи. Google керує публічним сервером STUN за адресою stun.l.google.com:19302; Twilio, Mozilla та інші керують своїми. Багато програм використовують Google за умовчанням. Сервери STUN бачать лише те, що запит відбувся; вони не бачать медіа, яке тече після.
Чи зашифровано WebRTC?: Завжди, за спец. Рукостискання DTLS отримує ключі для SRTP, який шифрує медіа. Канал даних зашифрований DTLS. Ви не можете вимкнути шифрування. Наскрізне шифрування є окремою властивістю — групові виклики через SFU можуть бути E2EE, лише якщо програма явно реалізує це (Zoom, Signal роблять; багато простіших програм цього не роблять).
Чому міжбраузерне відео зараз таке гарне, ніж десять років тому?: Апаратне прискорення кодека (AV1, VP9, H.264 на графічному процесорі), контроль перевантажень, налаштований для медіа в реальному часі (алгоритм контролю перевантажень Google) і кращий обхід NAT, що робить прямі шляхи можливими частіше. Усе це всередині WebRTC.