Утечки WebRTC: почему ваш реальный адрес может быть виден даже за прокси
WebRTC существует для того, чтобы браузеры могли общаться напрямую — для звонков и показа экрана. Для этого им нужно выяснить, по каким адресам их можно достичь, и именно процесс обнаружения называют «утечкой WebRTC».
ICE-кандидаты в одном абзаце
Когда страница создаёт RTCPeerConnection и запускает предложение, браузер собирает кандидатов: способы, которыми его мог бы достичь другой участник. Кандидат host — это адрес локального интерфейса. Кандидат server-reflexive (srflx) — это публичный адрес, с которого STUN-сервер увидел приход запроса. Кандидат relay — это адрес сервера TURN. Каждый кандидат передаётся странице текстовой строкой, содержащей адрес, и именно так скрипт может его прочитать, даже если никакой звонок не совершался.
Где утечка
Важен кандидат srflx. Чтобы его получить, браузер отправляет небольшой UDP-пакет на STUN-сервер, который отвечает адресом, с которого пришёл пакет. Если ваш HTTP-трафик идёт через прокси, а UDP-трафик нет, STUN-сервер видит ваше настоящее подключение, и у страницы появляется адрес, расходящийся с тем, который увидел веб-сервер. Это расхождение и есть классическая утечка. Диагностическая страница может показать её, сравнив два адреса.
Обратите внимание, что происходит и чего не происходит. Никакие медиаданные не захватываются. Разрешения на микрофон или камеру не задействованы. Пакет уходит на тот STUN-сервер, который указала страница, поэтому этот сервер, как и любой сервер, с которым вы связываетесь, видит ваш адрес.
Что изменили браузеры
Кандидаты host раньше раскрывали частные адреса локальной сети вроде 192.168.1.23, полезные для снятия отпечатка домашней сети. Современные браузеры заменяют их случайно сгенерированными именами mDNS, оканчивающимися на .local, так что страница видит непрозрачное имя, а не адрес. Диагностика, сообщающая «скрыто браузером», описывает именно их. Firefox и Brave также предлагают настройки, которые прекращают сбор кандидатов в обход прокси, а некоторые расширения полностью блокируют WebRTC.
Конфигурации, безопасные для прокси
Работают три подхода с разной ценой. Отключение WebRTC предотвращает утечку и ломает каждый сайт, которому он нужен. Принуждение WebRTC использовать только маршрут прокси (режим «безопасно для прокси» в некоторых браузерах) сохраняет работу звонков, если прокси поддерживает UDP или TURN, а иначе вообще не даёт публичного кандидата. Нормальное поведение WebRTC правильно лишь тогда, когда прокси несёт весь трафик, как это обычно делает системный VPN.
Что правильно, зависит от задачи. Для изолированного профиля браузера, который должен выглядеть находящимся в одном месте, правило простое: адрес, который раскрывает WebRTC, должен совпадать с адресом, который видит веб-сервер, или его не должно быть вовсе. Всё остальное — противоречие, которое сайт может заметить без какого-либо специального инструментария.
Как читать результат
Диагностика за несколько секунд показывает замеченных кандидатов и сравнивает любого публичного с адресом, с которого открыта страница. «Не раскрыто» при наличии нескольких скрытых кандидатов — нормальный, здоровый результат для браузера, удерживающего WebRTC внутри прокси. Публичный адрес, отличающийся от адреса страницы, — то, что нужно исправлять.
