Утечка WebRTC

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

WebRTC сам по себе не является вредной функцией. Он поддерживает видеозвонки, голосовой чат, совместное использование экрана и передачу данных в реальном времени в браузере. Проблема конфиденциальности связана с тем, как он ищет рабочий сетевой путь.

Проще говоря, Утечка WebRTC означает, что браузер обнаруживает неожиданный адрес при подготовке соединения в реальном времени.

Что такое Утечка WebRTC?

Слово «утечка» нуждается в контексте. Веб-сайт обычно видит общедоступный IP-адрес, используемый для загрузки страницы. Тест WebRTC также может показать тот же адрес. Если оба результата указывают на выбранный вами VPN или прокси-сервер, утечки может вообще не быть.

Проблема начинается, когда WebRTC обнаруживает адрес за пределами ожидаемого маршрута. Вы можете увидеть IP-адрес VPN при обычной проверке IP-адреса, а затем найти IP-адрес своего домашнего интернет-провайдера в результатах WebRTC. Вы также можете обнаружить открытый адрес IPv6, который не был пропущен при первом тесте.

Я не рассматриваю каждую строчку средства проверки утечек как ошибку. Я ищу адрес, который текущая настройка должна была скрыть.

Когда разоблачение IP становится утечкой

Предположим, ваш обычный адрес интернет-провайдера находится в Лондоне. Вы подключаетесь к прокси в Нью-Йорке. Стандартная проверка IP теперь показывает прокси-сервер Нью-Йорка. Эта часть работает так, как ожидалось.

Затем вы запускаете тест WebRTC. Если он также показывает адрес в Нью-Йорке, сигналы сети совпадают. Если он также показывает исходный адрес лондонского интернет-провайдера, браузер обнаружил неожиданный путь.

Та же логика применима и к VPN. Это также относится к IPv6. Защищенный маршрут IPv4 не сильно поможет, если отдельный адрес IPv6 по-прежнему указывает на исходную сеть.

Зачем WebRTC нужны сетевые адреса

Для связи в реальном времени необходим путь между двумя конечными точками. Этот путь может быть прямым. Он может проходить через устройство NAT. Реле может потребоваться, когда прямое соединение не может быть установлено.

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

Этот процесс отличается от доступа к камере и микрофону. Страница может создать одноранговое соединение или канал данных и начать сбор кандидатов на подключение. Для доступа к мультимедийным устройствам по-прежнему требуется соответствующее разрешение браузера.

Как происходит Утечка WebRTC?

Процесс начинается с RTCPeerConnection. Веб-приложение создает этот объект, когда ему требуется соединение в реальном времени. Затем браузер использует систему интерактивного подключения, обычно называемую ICE, для сбора возможных кандидатов на подключение.

Эти кандидаты описывают способы, которыми может работать эта связь. Веб-приложение может считывать информацию о кандидате и передавать ее удаленной стороне через свою систему сигнализации.

Если в браузере указан адрес интернет-провайдера, который должен был оставаться за VPN или прокси-сервером, приложение может его увидеть. Это может произойти при раздельном туннелировании, дополнительном сетевом интерфейсе, незащищенном маршруте IPv6 или прокси-сервере браузера, который по-прежнему позволяет WebRTC подключаться за пределами ожидаемого пути.

Сбор кандидатов ICE

Поток состоит из пяти шагов:

1. Страница создает RTCPeerConnection.
2. Агент ICE проверяет доступные пути подключения.
3. Браузер собирает кандидатов на хост, STUN или TURN-ретранслятор.
4. Приложение получает кандидатов, которых ему разрешено видеть.
5. ICE тестирует пары кандидатов и выбирает рабочий путь.

ICE не является сервером. Это процесс, используемый для поиска и проверки вариантов подключения. STUN и TURN поддерживают этот процесс по-разному.

Кандидаты на хост, STUN и TURN

Каждый тип кандидата раскрывает различную часть связи.

Реле TURN может хранить прямые адреса конечных точек вдали от удаленного узла. Он также добавляет к пути еще один сервер. Это может увеличить задержку, стоимость полосы пропускания и эксплуатационную зависимость от ретранслятора.

Когда VPN или прокси-сервер открывает неожиданный путь

VPN и прокси не следует рассматривать как один и тот же инструмент. Полнотуннельная VPN может маршрутизировать широкий трафик устройств и использовать правила брандмауэра для остановки трафика за пределами туннеля. VPN с разделенным туннелем позволяет выбранному трафику использовать другой маршрут.

Прокси браузера часто обрабатывает веб-запросы для одного браузера или профиля. Он может не контролировать каждый путь WebRTC. SOCKS5 может поддерживать UDP, но фактическая маршрутизация WebRTC по-прежнему зависит от браузера и его конфигурации.

Прокси, VPN и браузеры с защитой от обнаружения управляют разными уровнями. Прокси маршрутизирует выбранный трафик. VPN может управлять более широким зашифрованным туннелем. Антидетект Браузер управляет профилями браузера и сигналами на стороне браузера. Одно не заменяет автоматически другие.

Какую информацию может предоставить WebRTC?

На большинстве тестовых страниц отображается более одного поля. Ярлыки могут выглядеть тревожно, особенно когда локальные и публичные адреса встречаются вместе. Это помогает судить о каждом типе отдельно.

Публичные IP-адреса

Публичный IP-адрес виден в Интернете. Он может указывать интернет-провайдера, ASN, широкое местоположение и тип используемой сети.

Когда VPN или прокси-сервер активны, самым важным предупреждением является появление общедоступного IP-адреса базового интернет-провайдера. Это может быть адрес IPv4, адрес IPv6 или оба.

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

Локальные IP-адреса и имена mDNS

Локальные адреса часто начинаются с таких диапазонов, как 192.168 или 10. Эти адреса повторно используются во многих частных сетях. Один локальный IP-адрес обычно менее информативен, чем общедоступный адрес интернет-провайдера.

Это не делает местную информацию бессмысленной. Это может показать часть схемы сети. Стабильная комбинация локальных интерфейсов также может добавить еще один сигнал при сравнении сеансов.

Современные браузеры часто скрывают адрес локального хоста за случайным .local именем mDNS. Видение этого имени не означает, что общедоступный IP-адрес вашего интернет-провайдера утек. Это означает, что браузер избегает прямого раскрытия локального адреса. Он также не удаляет все возможные сигналы WebRTC.

IPv6 и несколько сетевых интерфейсов

Многие люди проверяют IPv4 и останавливаются на этом. Это легко понять. IPv4 по-прежнему является адресом, который знаком большинству пользователей.

IPv6 нуждается в собственной проверке. VPN может правильно обрабатывать IPv4, в то время как другая конфигурация оставляет IPv6 видимым. Wi-Fi, Ethernet, виртуальные адаптеры и интерфейсы VPN также могут создать несколько кандидатов.

Результаты различаются в зависимости от браузера, операционной системы, сети и политики конфиденциальности. Живой тест используемой вами настройки расскажет вам больше, чем общий список браузеров.

Как проверить наличие Утечка WebRTC

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

Пошаговый тест на утечку Утечка WebRTC

1. Отключите VPN или прокси.
2. Запишите текущие общедоступные адреса IPv4 и IPv6.
3. Закройте тестовую страницу.
4. Подключите VPN или прокси-сервер или запустите профиль браузера, который хотите проверить.
5. Используйте обычную программу проверки IP-адресов, чтобы подтвердить ожидаемый выходной IP-адрес.
6. Откройте средство проверки, специфичное для WebRTC.
7. Сравните общедоступные, локальные, mDNS, IPv6 и результаты ретрансляции с базовыми показателями.
8. Измените соответствующую настройку и проверьте еще раз, отображается ли исходный адрес интернет-провайдера.

Элементы управления браузером со временем меняются. Тщательный Утечка WebRTC имеет большее значение, чем старый список предположительно безопасных настроек.

Как прочитать результаты теста

Один тест BrowserLeaks от MoreLogin проверил IP, WebRTC, часовой пояс, язык, Canvas, WebGL и шрифты в одном профиле.

Это был один тест на одной конфигурации. Его не следует воспринимать как обещание для каждой версии браузера, устройства, прокси-сервера или профиля.

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

Зеленый результат выглядит обнадеживающе. Я бы все равно не стал относиться к этому как к бессрочному сертификату.

Протестируйте еще раз после любых изменений, которые могут повлиять на браузер или сеть:

• Обновление браузера
• Новый VPN-сервер или прокси
• Изменение расширения
• Новая сеть
• IPv6 включен
• Новый профиль браузера
• Другая политика WebRTC

Тест на утечку — это снимок одного браузера, сети и конфигурации. Этого достаточно, чтобы принять полезное решение. Это не постоянная гарантия конфиденциальности.

Как предотвратить или исправить Утечка WebRTC

Не существует единого исправления, подходящего для каждого браузера и каждого рабочего процесса. Правильный выбор зависит от того, должны ли функции WebRTC оставаться доступными.

Используйте VPN с проверенной защитой от утечек

VPN системного уровня может защитить трафик WebRTC с помощью правил маршрутизации и брандмауэра. Проверьте, активно ли раздельное туннелирование. Проверьте также IPv6. Затем запустите тест вместо того, чтобы доверять статусу подключения в приложении.

Бренд VPN имеет меньшее значение, чем наблюдаемый результат на устройстве и в браузере, которые вы фактически используете.

Ограничьте непрокси-трафик или используйте WebRTC только с ретрансляцией.

Другой вариант — запретить WebRTC использовать путь за пределами прокси. Некоторые элементы управления блокируют UDP без проксирования. Другие принудительно пропускают трафик через настроенный прокси.

Если UDP не может использовать этот маршрут, WebRTC может вернуться к TCP или TURN. Это также может потерпеть неудачу. Результат зависит от реализации.

WebRTC только для реле использует кандидатов TURN. Это может держать прямых кандидатов подальше от удаленного узла, сохраняя при этом связь в реальном времени. Компромисс — большая задержка, больший ретрансляционный трафик и более сильная зависимость от доступности TURN.

Измените настройки браузера или используйте расширение

Firefox предлагает расширенные настройки, которые могут ограничить или отключить WebRTC. Браузеры на базе Chromium часто полагаются на расширения, корпоративную политику или сетевые элементы управления на уровне браузера.

Расширения могут помочь. Они также нуждаются в уходе. Устаревшее расширение может перестать работать после обновления браузера. Он может запросить широкие разрешения. Он также может вести себя по-разному в разных версиях браузера.

Если вы его используете, выберите поддерживаемый источник и еще раз проверьте результат. Значок на панели инструментов не является доказательством. Сетевой результат такой.

Используйте элементы управления WebRTC для каждого профиля.

Глобальные настройки становятся неудобными, когда несколько профилей используют разные прокси или сетевые местоположения. Каждому профилю необходимо четкое назначение прокси и политика WebRTC, соответствующая поставленной задаче.

Профиль не готов только потому, что подключается его прокси. После того как вы настроить прокси в MoreLogin, подтвердите видимый IP-адрес и запустите отдельную проверку WebRTC.

В MoreLogin Документация по API профиля браузера перечислены параметры конфиденциальности, замены, реального, отключенного и пересылки в качестве параметров WebRTC для каждого профиля. Он не полностью объясняет, как каждый режим обрабатывает кандидатов на хост, STUN, TURN, UDP, IPv4 и IPv6.

Одной метки режима недостаточно. Проверьте выбранное поведение в текущей версии продукта.

Стоит ли отключать WebRTC?

Отключение WebRTC может закрыть путь раскрытия этого адреса. Это также вариант, который, скорее всего, повлияет на обычные функции браузера.

Что предотвращает отключение WebRTC

Если RTCPeerConnection недоступен, страница не может использовать этот API для сбора одних и тех же кандидатов на подключение. Это может предотвратить утечку IP-адресов на основе WebRTC.

Это не останавливает утечки DNS. Он не скрывает отпечаток браузера. Он не удаляет файлы cookie или данные учетной записи.

Что может перестать работать

Сайты могут потерять функции, зависящие от WebRTC, в том числе:

• Видеозвонки через браузер
• Голосовой чат
• Совместное использование экрана
• Одноранговая передача файлов
• Виджеты поддержки и сотрудничества в режиме реального времени

Некоторые сервисы могут предлагать другой маршрут. Другие могут выйти из строя или потерять качество.

Отключить, ограничить или ретранслировать

Отключите WebRTC, если профилю не требуется связь в реальном времени. Ограничьте или ретранслируйте ее, когда функция должна оставаться доступной и сетевой путь может быть проверен.

Утечка WebRTC и утечка DNS

Утечки WebRTC и DNS легко перепутать, поскольку оба могут ослабить настройку конфиденциальности. Они раскрывают разную информацию.

И то, и другое может произойти одновременно. Исправление одного не доказывает, что другого больше нет.

Утечки WebRTC и изолированные профили браузера

Сетевая идентификация и идентификация браузера находятся на разных уровнях. Это различие становится важным, когда профили используются повторно с течением времени.

Прокси-сервер или VPN контролируют сетевой маршрут. Политика WebRTC контролирует, как предоставляются или ретранслируются кандидаты на подключение. Профиль браузера содержит файлы cookie, локальное хранилище, настройки браузера и другие сигналы.

Информация WebRTC может стать частью более широкого отпечатка браузера наряду с версией браузера, часовым поясом, шрифтами, выводом Canvas и поведением WebGL.

Обеспечьте единообразие сетевых сигналов каждого профиля.

Прежде чем использовать профиль, проверьте части, которые должны согласовываться:

• Ожидаемый общедоступный IP-адрес прокси-сервера или VPN
• Публичный IP-адрес WebRTC
• Воздействие IPv6
• Поведение локального IP или mDNS
• Часовой пояс и геолокация
• Язык браузера

Последовательность не делает профиль невидимым. Это уменьшает количество несоответствий, которых можно было бы избежать, и облегчает диагностику проблем.

Проверьте профиль перед важной работой

Соблазнительно остановиться, когда обычная проверка IP выглядит правильно. Обнаружение утечки несколько дней спустя разочаровывает, и ее труднее распутать.

В MoreLogin профиль браузера с несколькими учетными записями сохраняет настройки прокси-сервера, конфигурацию WebRTC, файлы cookie, хранилище и другие сигналы браузера в одной среде многократного использования. Это упрощает проверку настройки. Результат по-прежнему зависит от выбранных настроек, сети и прокси.

Протестируйте новый профиль перед его использованием. Проверьте еще раз, когда изменится прокси, версия браузера или политика WebRTC.

Ключевые выводы

• Утечка WebRTC — это неожиданное раскрытие сетевого адреса, а не появление какого-либо IP-адреса в тесте.
• ICE может собирать кандидатов на хост, STUN и TURN-ретрансляторы.
• Полезный тест сравнивает базовый IP-адрес интернет-провайдера с результатом VPN, прокси или профиля.
• Отключение, ограничение, проксирование и использование только ретрансляции WebRTC имеют различные компромиссы в отношении конфиденциальности и совместимости.

Утечка WebRTC Часто задаваемые вопросы

Всегда ли WebRTC передает ваш настоящий IP-адрес?

Нет. Результат зависит от браузера, сети, маршрута VPN или прокси, конфигурации IPv6 и политики WebRTC. При правильной маршрутизации может отображаться только IP-адрес VPN или прокси-сервера. При настройке только реле может отображаться адрес TURN.

Может ли WebRTC обойти VPN или прокси?

Он может предоставить дополнительный адрес, когда браузеру разрешено использовать другой сетевой путь. Этому результату могут способствовать раздельное туннелирование, незащищенный маршрут IPv6 или прокси-сервер браузера, который не контролирует трафик WebRTC.

Является ли локальный IP-адрес Утечка WebRTC?

Это раскрытие информации в локальной сети. Обычно это менее прямолинейно, чем раскрытие общедоступного IP-адреса интернет-провайдера. Его значение зависит от адреса, его стабильности, наличия других интерфейсов и способа объединения информации.

Что означает адрес .local в тесте WebRTC?

Случайный адрес .local обычно представляет собой имя хоста mDNS. Современные браузеры используют его, чтобы избежать прямого отображения IP-адреса локального хоста. Это не означает, что публичный IP-адрес интернет-провайдера утек.

Может ли веб-сайт проверять WebRTC без разрешения камеры?

Страница может создать одноранговое соединение или канал данных и инициировать сбор кандидатов ICE. Для доступа к камере и микрофону по-прежнему требуется соответствующее разрешение СМИ.

Повредит ли отключение WebRTC веб-сайты?

Это может повлиять на видеовызовы, голосовой чат, совместное использование экрана, передачу файлов и другие функции реального времени. Некоторые сайты могут предоставлять запасной вариант. Другие могут потерять функцию или работать с пониженным качеством.

Как часто мне следует проверять утечки WebRTC?

Протестируйте после изменения браузера, VPN, прокси-сервера, расширения, сети, настроек IPv6, профиля браузера или политики WebRTC. Быстрое повторное тестирование может выявить маршрут, который изменился без явного предупреждения.

Держите настройки WebRTC и прокси в порядке

Защита WebRTC работает лучше всего, когда она рассматривается как часть настройки всего профиля. Прокси, видимый IP-адрес, маршрут IPv6, часовой пояс, язык и политика WebRTC должны иметь смысл вместе.

Попробуйте MoreLogin бесплатно для создания многоразовых профилей браузера, настройки сети и параметров браузера отдельно, а также проверки каждой среды перед использованием.