Могу ли я полностью отключить 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: протокол браузера, который обеспечивает видеозвонки и иногда раскрывает ваш IP-адрес

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

Полный текст статьи на английском языке представлен ниже.

WebRTC (Веб-коммуникация в реальном времени) — это набор API-интерфейсов, встроенных в каждый современный браузер, который позволяет веб-страницам устанавливать прямые одноранговые соединения друг с другом или с собственными приложениями. Он поддерживает Google Meet, Zoom в браузере, голосовой чат Discord, Twitter Spaces и бесчисленное множество небольших сервисов. Без WebRTC видео в браузере в реальном времени по-прежнему было бы бесполезным предложением.

Что содержит спецификация

WebRTC объединяет три основных API:

getUserMedia — обращается к камере и микрофон
RTCPeerConnection — управляет фактическим одноранговым соединением: согласование кодека, шифрование, обход NAT, контроль перегрузки.
RTCDataChannel — отправляет произвольные двоичные или текстовые данные по соединению, одноранговое соединение

Само соединение использует ICE (интерактивное установление соединения) для прохождения NAT, DTLS для шифрования рукопожатия и SRTP для шифрования мультимедиа. По умолчанию все соединение шифруется сквозным шифрованием; вы не можете его отключить.

Как одноранговые узлы находят друг друга

Сложность одноранговой сети заключается в том, что оба узла обычно находятся за NAT. WebRTC использует ICE для обнаружения возможных сетевых путей:

. Браузер спрашивает сервер STUN: «Как выглядят мой общедоступный IP-адрес и порт?» Сервер STUN отвечает обнаруженным им исходным адресом, который является внешним отображением NAT.
Браузер собирает все свои адреса-кандидаты: локальные IP-адреса в локальной сети, общедоступный IP-адрес, обнаруженный STUN, опционально 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 имя хоста.
Если страница вызывает getUserMedia (например, настоящий видеозвонок), браузер соберет полных кандидатов, включая общедоступный IP-адрес — на этом этапе вы все равно предоставили разрешение мультимедиа.

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

Почему одноранговая связь имеет значение

Для вызовов двух человек WebRTC отправляет медиафайлы напрямую между узлами, а сервер сигнализации используется только для установки соединения. Видео не передается на серверы приложения. Это значительно дешевле в эксплуатации (нет затрат на полосу пропускания для мультимедиа) и значительно снижает задержку (без дополнительных переходов). Групповым вызовам обычно требуется блок выборочной пересылки (SFU) — сервер, который ретранслирует мультимедиа, — но шифрование по-прежнему остается сквозным, если оно настроено правильно. WebCodecs (непосредственный доступ к оборудованию кодера/декодера). Вместе они открывают новые варианты использования, такие как облачные игры, перекодирование видео с малой задержкой в браузере и массовая одноранговая передача файлов с лучшим контролем перегрузки, чем RTCDataChannel.

Сам WebRTC также модернизируется — исходная семантика SDP Plan B заменяется Unified Plan, а поверхность 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.