WebRTC и DNS: утечки, которые не закрывает никто

Вы включили VPN. Подключили SOCKS-прокси. Настроили DNS-over-HTTPS через Cloudflare. Открыли браузер. Зашли на сайт. Сайт уже знает ваш настоящий IP-адрес, имя вашего ноутбука и страну, где стоит ваш DNS-резолвер. Вот и весь смысл вашей подписки за 12 долларов в месяц.

Сетевые утечки, протокольные утечки, DNS-утечки. Слова, которые все слышали и которые почти никто не воспринимает всерьёз. Потому что маркетинг VPN-провайдеров убедил миллионы людей, что одна кнопка «Подключиться» решает все проблемы приватности. Она не решает. Она создаёт иллюзию.

В этой статье мы разбираем конкретные механизмы утечек, подтверждённые академическими исследованиями 2022-2025 годов. Каждый из них работает прямо сейчас, в вашем браузере, независимо от того, сколько вы заплатили за «приватность».

Коротко: WebRTC утекает во всех браузерах, кроме Tor/Mullvad. DoH определяется на 95%, ODoH > на 94%. mDNS сливает имя устройства.

WebRTC: протокол, который не проектировали для приватности

WebRTC, Web Real-Time Communication, появился как способ делать видеозвонки прямо в браузере, без плагинов. Google продвигал его с 2011 года, Mozilla подхватила, Apple добавила поддержку в Safari в 2017. Сегодня WebRTC работает в каждом крупном браузере. И в каждом крупном браузере он течёт.

В ноябре 2024 года команда из Sorbonne Université и компании Snowpack представила на конференции CRiSIS 2024 работу «Preventing WebRTC IP Address Leaks». Их выводы: WebRTC API не был спроектирован с учётом приватности. Несмотря на обновления спецификации, чувствительные публичные IP-адреса по-прежнему утекают во время аудио и видеосвязи. Утечки происходят даже при использовании VPN, SOCKS или HTTP/S прокси. Тесты проводились на Linux, macOS и Windows. Результат одинаковый на всех платформах.

Чтобы понять, почему это работает, нужно разобрать механизм ICE, Interactive Connectivity Establishment.

Как STUN и TURN сливают ваш IP

Когда два браузера хотят установить прямое соединение через WebRTC, они используют протокол ICE для поиска возможных маршрутов. ICE собирает так называемые «кандидаты», candidates, три типов:

Host candidates содержат локальный IP-адрес устройства. Тот самый 192.168.x.x. На первый взгляд безобидный, но в корпоративных сетях без NAT, а таких больше, чем принято думать, host candidate содержит реальный публичный IP.

Server-reflexive candidates собираются через STUN-серверы. Браузер отправляет запрос на STUN-сервер, сервер отвечает: «Вот твой публичный IP-адрес». Этот запрос идёт мимо VPN-туннеля в определённых конфигурациях. STUN использует UDP, и не каждый VPN перехватывает все UDP-пакеты.

Relay candidates проходят через TURN-серверы, которые ретранслируют трафик. TURN, по идее, должен скрывать реальный IP. Но TURN-серверы требуют аутентификации, и сам факт использования конкретного TURN-сервера становится идентификатором.

Почему HTTP-прокси и SOCKS не решают проблему

HTTP-прокси работает на уровне приложения. SOCKS-прокси перехватывает TCP-соединения. WebRTC использует UDP. Он обращается к сетевым интерфейсам операционной системы напрямую, минуя прокси-стек полностью. Прокси-сервер просто не видит этот трафик. Он проходит мимо, как будто прокси не существует. Исследование Sorbonne/Snowpack 2024 года подтвердило это экспериментально: утечки WebRTC происходят даже при использовании VPN, SOCKS или HTTP/S прокси на всех протестированных платформах.

Даже VPN с kill switch не гарантирует защиту. ICE-сбор кандидатов запускается браузером самостоятельно, до установления основного соединения. Если VPN-клиент не перехватывает все UDP-пакеты на уровне сетевого драйвера, STUN-запрос уходит в обход. Большинство коммерческих VPN этого не делают.

ICE-кандидаты как карта вашей сети

Отдельный вектор идентификации: количество и типы ICE-кандидатов. Типичный домашний компьютер с одним сетевым интерфейсом генерирует 2-3 кандидата. Машина в корпоративной сети с несколькими адаптерами генерирует 5-8. Виртуальная машина с мостовой сетью и NAT выдаёт свой характерный набор. Ноутбук с WiFi и Ethernet одновременно создаёт кандидаты для обоих интерфейсов. Мобильный телефон в дуалсим-режиме с WiFi генерирует кандидаты для трёх сетей сразу.

Само количество кандидатов и распределение их типов рисует карту вашей сетевой инфраструктуры. Три host-кандидата, два srflx и один relay означают одну конфигурацию. Один host и ноль srflx означают другую. WHOX через чек A09 анализирует полный набор ICE-кандидатов и хеширует SDP-описание целиком. Результат: уникальная сигнатура вашей сетевой топологии, доступная любому сайту, который запросит WebRTC-соединение.

Исследование Sorbonne показало, что единственным эффективным решением оказался запуск Firefox внутри Docker-контейнера. Контейнерная изоляция работала даже при компрометации самого браузера. Всё остальное, VPN, прокси, SOCKS, оказалось недостаточным.

В октябре 2025 года вышла ещё одна работа, «WebRTC Metadata and IP Leakage in Modern Browsers: A Cross-Platform Measurement Study», протестировавшая билды 2025 года Chrome, Brave, Firefox и Tor на десктопе и мобильных устройствах. Вывод: WebRTC-утечки остаются одной из самых недооценённых уязвимостей приватности, затрагивающих пользователей VPN во всех основных браузерах. Формулировка авторов заслуживает повторения: к 2026 году WebRTC представляет собой наиболее критическую угрозу приватности для пользователей, полагающихся на VPN и прокси. Не cookies. Не canvas fingerprinting. Не third-party трекеры. Протокол, созданный для видеозвонков, оказался самым опасным каналом утечки реальной идентичности. И этот протокол включён по умолчанию в каждом браузере, который вы используете прямо сейчас.

Сравнительная таблица: какой браузер что сливает

Данные собраны на основе матрицы Joe12387, исследований CRiSIS 2024 и arXiv 2510.16168:

Утечка	Chrome	Safari	Edge	Firefox	Brave	Opera	Tor / Mullvad
WebRTC IP leak	❌ Уязвим	❌ Уязвим	❌ Уязвим	❌ Уязвим	❌ Уязвим	❌ Уязвим	✅ Отключён
IPv6 leak через VPN	❌ Уязвим	❌ Уязвим	❌ Уязвим	⚠️ Частично	⚠️ Частично	❌ Уязвим	✅ Защищён
QUIC UDP-443 leak	❌ Уязвим	✅ Нет QUIC	❌ Уязвим	❌ Включён с v88	⚠️ Частично	❌ Уязвим	✅ Отключён
mDNS device name	⚠️ Частично	⚠️ Частично	⚠️ Частично	⚠️ Частично	⚠️ Частично	⚠️ Частично	✅ Защищён
DoH fingerprinting	❌ Уязвим	❌ Уязвим	❌ Уязвим	❌ Уязвим	❌ Уязвим	❌ Уязвим	✅ Через Tor
DoT leak	❌ Если включён	❌ Если включён	❌ Если включён	❌ Если включён	❌ Если включён	❌ Если включён	✅ Защищён
DNS geo mismatch	❌ Уязвим	❌ Уязвим	❌ Уязвим	❌ Уязвим	❌ Уязвим	❌ Уязвим	✅ Защищён

Один столбец зелёный. Один. Tor Browser и Mullvad Browser, которые просто отключают WebRTC целиком. Это не элегантное решение. Это признание того, что протокол нельзя сделать безопасным, его можно только выключить. Разработчики Tor Project пришли к этому выводу после нескольких лет попыток ограничить WebRTC. Каждый патч создавал новую точку утечки. Каждый workaround ломал какой-то сценарий использования. В итоге единственный надёжный подход оказался самым грубым: media.peerconnection.enabled = false. Никакого WebRTC. Никаких кандидатов. Никаких утечек. Никаких видеозвонков.

Brave заслуживает отдельного комментария. Браузер позиционируется как приватный, блокирует трекеры, рандомизирует Canvas. Brave имеет базовые ограничения ICE-кандидатов и политику webrtc.ip_handling_policy, но полной защиты от утечки IP не обеспечивает. Лучше, чем ванильный Chrome, но далеко не иммунитет.

DNS: шифрование, которое не защищает ничего

«Используйте DNS-over-HTTPS, и ваш провайдер не увидит, какие сайты вы посещаете». Этот совет звучит на каждом втором tech-форуме. Он технически корректен и практически бесполезен.

DePL: 95% точности по 50 пакетам

В 2022 году на IEEE Icnp была представлена система DePL, «Detecting Privacy Leakage in DNS-over-HTTPS Traffic». Исследователи применили n-shot learning для классификации зашифрованного DoH-трафика.

Результат: ~95% точности в определении того, какие сайты посещает пользователь. Через зашифрованный DNS. Без расшифровки.

Параллельное исследование из Loyola University Chicago подтвердило цифры: 95% точности предсказания 1 из 10 000 сайтов по первым 50 пакетам DoH. F1-score в 93% при открытой модели с 100 000 сайтов. Ещё одна работа, «Toward Practical Defense Against Traffic Analysis on Encrypted DNS», показала, что даже с рекомендованным IETF паддингом атакующие достигают точности свыше 95%.

Механизм прост. Шифрование скрывает содержимое пакетов, но не скрывает их размеры, тайминги, объёмы и паттерны. Каждый сайт генерирует уникальную последовательность DNS-запросов: основной домен, CDN-поддомены, аналитика, шрифты, API-эндпоинты. Эта последовательность, её «форма» в трафике, уникальна как отпечаток пальца. Зашифрованный отпечаток пальца, но всё равно отпечаток.

ODoH: даже реле не спасает

Если DoH не работает, может быть, поможет Oblivious DNS-over-HTTPS? ODoH добавляет промежуточное реле между вами и DNS-резолвером. Реле знает ваш IP, но не видит запросы. Резолвер видит запросы, но не знает ваш IP. Архитектурная гарантия приватности. Используется Cloudflare 1.1.1.1 и Apple iCloud Private Relay.

На конференции IEEE DSN'25 была представлена работа «Privacy Analysis of Oblivious DNS over HTTPS: a Website Fingerprinting Study». Исследователи развернули тестовую среду на инфраструктуре Geni и применили ансамблевое глубокое обучение.

Результат: пассивный наблюдатель определяет целевые сайты по ODoH-трафику с точностью 94%.

Архитектурная гарантия разбивается о статистику. Двойное проксирование скрывает вашу личность от резолвера, но не скрывает паттерны трафика от наблюдателя, сидящего на сетевом канале между вами и реле. Провайдер, государственный регулятор или оператор точки доступа Wi-Fi видит те же пакеты, те же размеры, те же тайминги. И 94% точности.

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

Утечки, о которых вы не знали

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

mDNS: ваш ноутбук представляется по имени

Multicast DNS был придуман для удобства: чтобы устройства в локальной сети могли найти друг друга без центрального DNS-сервера. Когда WebRTC генерирует ICE-кандидаты, он использует mDNS для создания адресов вида .local. Это должно было скрыть прямые IP. Скрыло. Но при этом создало другую утечку.

Современные браузеры попытались решить проблему утечки локальных IP через mDNS-обфускацию. Вместо реального IP-адреса WebRTC генерирует случайный UUID и регистрирует его как mDNS-имя: что-то вроде a1b2c3d4-e5f6-7890-abcd-ef1234567890.local. Другой участник соединения резолвит этот UUID через mDNS и получает IP, но сам UUID ничего не выдаёт. На бумаге элегантно. На практике mDNS-запросы всё равно уходят в локальную сеть, и mDNS-ответы содержат hostname устройства. UUID защитил WebRTC-кандидат от раскрытия IP напрямую через JavaScript. Он не защитил mDNS-протокол от раскрытия hostname на сетевом уровне.

mDNS-ответы содержат hostname устройства. На типичном MacBook это выглядит как «Ivans-MacBook-Pro.local». На Windows может быть «Desktop-Ivan». Имя устройства, которое часто содержит реальное имя владельца, транслируется в локальную сеть.

В кофейне. В коворкинге. В аэропорту. В корпоративной сети. Любой участник той же подсети видит, как ваш компьютер буквально представляется: «Привет, я ноутбук Ивана». Случайный UUID в WebRTC-кандидате не меняет этого факта.

Чек A14 детектирует эту утечку. Результаты показывают, что большинство пользователей никогда не меняли дефолтное имя устройства.

IPv6: двойной стек убивает VPN

Большинство VPN-клиентов туннелируют IPv4-трафик. IPv6-трафик при этом идёт напрямую, мимо туннеля. Если ваша сеть поддерживает оба протокола, а таких сетей всё больше, ваш реальный IPv6-адрес доступен любому сайту.

IPv6-утечки опаснее утечек IPv4. Причина фундаментальна. IPv4-адрес чаще всего общий: за одним NAT-адресом сидит десяток, сотня, иногда тысяча пользователей. IPv6 проектировался так, чтобы каждому устройству дать собственный глобально уникальный адрес. Ваш IPv6-адрес, в отличие от IPv4, с высокой вероятностью принадлежит именно вашему устройству. Не вашему роутеру. Не вашей подсети. Вашему ноутбуку лично. Утечка IPv4 выдаёт район. Утечка IPv6 выдаёт конкретное устройство.

Проблема усугубляется Slaac, протоколом автоматической конфигурации IPv6-адресов. В стандартной конфигурации часть адреса генерируется из MAC-адреса сетевого интерфейса. MAC-адрес, уникальный аппаратный идентификатор вашей сетевой карты, встраивается прямо в IPv6-адрес. Существуют privacy extensions, которые рандомизируют эту часть, но они не включены по умолчанию на всех платформах. А даже с privacy extensions сам префикс IPv6-адреса по-прежнему привязан к вашей сети.

На Windows отдельную проблему представляет механизм Teredo > автоматический переход с IPv4 на IPv6. На устаревших или неправильно настроенных системах он может обойти VPN-туннель, хотя большинство современных VPN-клиентов блокируют Teredo при подключении. Вы думаете, что весь трафик идёт через VPN в Нидерландах. Ваш IPv6-трафик идёт напрямую из Москвы.

Чек A11 специально детектирует утечку IPv6 через VPN. Решение существует: отключить IPv6 на уровне операционной системы или использовать VPN, который явно обрабатывает IPv6. Большинство пользователей не делают ни того, ни другого.

QUIC: UDP на 443-м порту идёт мимо

HTTP/3 работает поверх протокола QUIC, который использует UDP на порту 443 вместо привычного TCP. Многие VPN и файрволы фильтруют только TCP-трафик. QUIC-соединения проходят мимо.

Chrome и другие Chromium-браузеры всё активнее предпочитают QUIC, когда сервер его поддерживает. Google, YouTube, Cloudflare. Все крупные платформы поддерживают HTTP/3. С каждым месяцем всё больше вашего трафика утекает мимо VPN-туннеля.

Чек A12 ловит эту утечку. Дополнительно чек A69 снимает отпечаток самого QUIC-хендшейка, JA4Q-like fingerprint. Даже если QUIC не утекает мимо VPN, сам паттерн QUIC Initial пакета становится вектором фингерпринтинга.

DoT: ещё один DNS-протокол, ещё одна утечка

DNS-over-TLS работает на порту 853. Отдельный, легко идентифицируемый порт. Если ваша система настроена на DoT, а VPN не перехватывает трафик на 853 порт, ваши DNS-запросы идут напрямую. Зашифрованные, да. Но видимые для наблюдателя как отдельный поток, который легко отфильтровать и проанализировать.

Сам факт использования DoT на порту 853, а не стандартного DNS на порту 53, уже является идентификатором. Это редкая конфигурация. Редкость означает уникальность. Уникальность означает фингерпринт.

Чек A22 детектирует утечку DoT-трафика.

DNS Resolver Mismatch: география не врёт

Вы подключились к VPN-серверу в Нидерландах. Ваш IP-адрес голландский. Ваши DNS-запросы уходят на Cloudflare в США. Или, что хуже, на DNS-сервер вашего российского провайдера.

Это несоответствие, DNS resolver country mismatch, является одним из самых надёжных сигналов для детекции VPN. Как пишет Proton VPN в своей документации: «Если IP-адрес DNS-сервера вашего провайдера раскрыт, это несоответствие позволяет сайтам понять, что вы пытаетесь скрыть свою настоящую личность».

Причина проста: современные браузеры по умолчанию включают DoH через свои собственные резолверы. Firefox отправляет DNS-запросы на Cloudflare, Chrome на Google DNS. Независимо от настроек VPN. Это называется DoH auto-translation. Чек A13 ловит именно эту утечку.

Чек C07 сравнивает географию DNS-резолвера с географией IP-адреса. Голландский IP, российский DNS. Мгновенный красный флаг. Не нужен никакой машинный интеллект, простое сравнение двух стран.

Каскадный эффект: сумма мелочей

Каждая утечка по отдельности может выглядеть несущественной. Локальный IP через WebRTC. Имя устройства через mDNS. Страна DNS-резолвера. IPv6-адрес. Тайминг QUIC-пакетов.

Но представьте профиль:

VPN IP-адрес: Германия
DNS-резолвер: Россия
IPv6-адрес: Франция
WebRTC локальный IP: корпоративная подсеть 10.x.x.x
mDNS hostname: «Jean-MacBook»
QUIC-трафик: идёт мимо VPN-туннеля
DoH-паттерн: совпадает с профилем посещения определённых сайтов на 95%

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

Важный нюанс: эти утечки работают на разных уровнях сетевого стека. WebRTC работает в браузере. IPv6 работает на уровне ОС. DNS работает на уровне резолвера. QUIC работает на транспортном уровне. mDNS работает в локальной сети. Ни одно средство защиты не покрывает все уровни одновременно. VPN работает на сетевом уровне, но пропускает WebRTC. Браузерные настройки закрывают WebRTC, но не контролируют IPv6. Системные настройки контролируют IPv6, но не влияют на DoH-паттерны. Каждый инструмент защиты оперирует на своём уровне. Утечки распределены по всем уровням.

Исследование «Long-Term Observation on Browser Fingerprinting» из PoPETs 2020 показало, что средняя стабильность отслеживаемого отпечатка составляет 1.8 недели. Но аппаратные сигналы, привязанные к GPU, аудио, WebGL, остаются стабильными месяцами и годами. А алгоритмы могут пересвязывать отпечатки даже после их изменения, отслеживая постепенную эволюцию: обновление браузера, установку нового шрифта, смену разрешения экрана.

Что проверяет WHOX

WHOX реализует 126+ проверок по трём осям: Fingerprint, Consistency и Anonymizer. Для сетевых утечек предусмотрен набор из десятка специализированных чеков:

Чек	Что детектирует	Уровень
A09	WebRTC leak: host, server-reflexive и relay candidates, хеш SDP	High
A10	Страна DNS-резолвера	Medium
A11	Утечка IPv6 через VPN	High
A12	Утечка QUIC UDP-443 мимо VPN-туннеля	Medium
A13	DoH auto-translation leak	Medium
A14	mDNS device name leak	Medium
A22	Утечка DoT-трафика	Medium
C07	Несоответствие страны DNS-резолвера и IP-адреса	High

Чек A09 не просто проверяет, есть ли WebRTC-утечка. Он анализирует все типы ICE-кандидатов: host, srflx и relay. Хеширует SDP-описание сессии. Сравнивает IP-адреса из WebRTC с заявленным публичным IP. Любое расхождение фиксируется.

Чек C07, DNS geo mismatch, работает в связке с A10. Если DNS-резолвер в одной стране, а IP в другой, система фиксирует несоответствие и повышает A-score. Это один из самых простых и при этом один из самых эффективных сигналов: подделать IP через VPN легко, заставить DNS-запросы идти через тот же VPN и ту же страну, оказывается, сложнее.

Все эти чеки входят в общий Trust Score WHOX, где ось F отвечает за уникальность отпечатка, ось C за согласованность сигналов между собой, а ось A за детекцию анонимайзеров. Веса: F = 35%, C = 30%, A = 35%. Сетевые утечки бьют сразу по двум осям: A и C.

Что с этим делать

Честный ответ: полного решения не существует. Каждая мера защиты закрывает одни утечки и создаёт новые.

Tor Browser отключает WebRTC целиком. Это единственный браузер, где столбец в таблице выше полностью зелёный. Но Tor Browser медленный, ломает половину сайтов, а сам факт использования Tor является сигналом. Чек A01 детектирует Tor exit node как Fatal.

Отключение IPv6 на уровне ОС закрывает утечку A11. Это разумная мера, если ваш VPN не обрабатывает IPv6 явно. Но это ручная настройка, которую подавляющее большинство пользователей никогда не сделают.

Отключение QUIC в настройках браузера закрывает A12. В Chrome это флаг chrome://flags/#enable-quic. Firefox включает QUIC по умолчанию с версии 88 (апрель 2021), но позволяет отключить через about:config (network.http.http3.enable = false). Но снова: ручная настройка, ручная проверка после каждого обновления.

Смена hostname устройства на что-то неличное закрывает A14. «MacBook» вместо «Ivans-MacBook-Pro». Простая мера, о которой никто не думает.

Принудительное использование DNS-сервера VPN вместо системного или браузерного закрывает C07 и частично A13. Но браузеры всё активнее внедряют собственные DoH-резолверы в обход системных настроек.

Полное отключение WebRTC в Firefox через about:config: media.peerconnection.enabled > false. Это радикальная мера. Видеозвонки через браузер перестанут работать. Но если вы не используете Google Meet или Zoom в браузере, это самый надёжный способ закрыть весь класс WebRTC-утечек разом. Один флаг, ноль кандидатов, ноль утечек. В Chrome аналогичного встроенного механизма нет. Chromium-браузеры требуют расширения для блокировки WebRTC, а расширения сами по себе становятся fingerprint-сигналом.

Настройка media.peerconnection.ice.default_address_only > true в Firefox. Компромиссный вариант. WebRTC продолжает работать, но браузер генерирует только один ICE-кандидат вместо полного набора. Видеозвонки функционируют. Утечка локального IP закрыта. Сетевая топология не раскрывается. Это минимально необходимый шаг для каждого пользователя Firefox.

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

Кому это нужно

Журналист, работающий с источником в авторитарной стране, подключается к VPN. WebRTC сливает локальный IP его корпоративной сети. mDNS транслирует имя его ноутбука. DNS-запросы уходят на резолвер в его реальной стране. Его источник под угрозой.

Исследование Knight First Amendment Institute «Silenced by Surveillance» от февраля 2025 года, основанное на 80+ интервью с журналистами и правозащитниками, документирует, как цифровые технологии стали инструментом транснациональных репрессий. Spyware, взлом аккаунтов, координированные атаки. Всё начинается с идентификации. А идентификация начинается с утечки.

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

Рядовой пользователь, купивший VPN «для приватности», тоже в зоне риска. Только его риск измеряется не тюрьмой, а профилированием. Каждая утечка DNS geo mismatch, каждый WebRTC-кандидат, каждый IPv6-адрес, утёкший мимо VPN, попадает в рекламный аукцион реального времени. В январе 2025 года хакеры слили, по их заявлению, 17 терабайт данных Gravy Analytics, собранных именно из этого аукционного потока. Миллиард устройств. Тысячи приложений. Разработчики этих приложений даже не знали, что данные их пользователей утекают. FTC ещё в декабре 2024 года подала иск против Gravy Analytics и Venntel за сбор и продажу чувствительных данных о местоположении. Рекламная инфраструктура собирает всё: IP, user agent, геолокацию, идентификаторы устройства. И когда VPN пропускает хотя бы один сигнал, этот сигнал попадает в ту же воронку. Не к спецслужбам. К рекламным биржам. Которые, как показала история Gravy Analytics, одно и то же.

Выводы

WebRTC утекает во всех браузерах, кроме Tor и Mullvad, которые его отключают. VPN, SOCKS, прокси не помогают. Исследование Sorbonne/CRiSIS 2024.
DNS-over-HTTPS не обеспечивает приватность. 95% точности идентификации сайтов по 50 пакетам. DePL, IEEE 2022.
Oblivious DoH тоже не обеспечивает приватность. 94% точности даже с промежуточным реле. IEEE DSN'25.
mDNS сливает имя вашего устройства в локальную сеть. Часто это ваше настоящее имя.
IPv6 обходит VPN на dual-stack сетях. Большинство VPN-клиентов не обрабатывают IPv6.
QUIC идёт мимо VPN-туннеля на неправильно настроенных системах. Chrome предпочитает QUIC всё чаще.
DNS geo mismatch мгновенно выдаёт использование VPN. Самый простой и самый эффективный сигнал.
Комбинация мелких утечек создаёт полный профиль. Каскадный эффект делает анонимность невозможной без закрытия каждой дыры.

Все перечисленные утечки детектируются через чеки A09, A10, A11, A12, A13, A14, A22 и C07. Если хоть один чек горит красным, ваша защита имеет дыру. Размер дыры не имеет значения. Одной дыры достаточно.

Мы не показываем это, чтобы деанонимизировать пользователей. Мы показываем это, потому что если система с 300+ сигналами может собрать ваш профиль утечек за секунды, это может сделать кто угодно с серверной инфраструктурой. Рекламные сети уже делают. Государственные системы наблюдения уже делают. Единственный вопрос: знаете ли вы о своих собственных утечках до того, как ими воспользуется кто-то другой.

FAQ

Защищает ли VPN от утечки WebRTC? Нет. Исследование Sorbonne/Snowpack (CRiSIS 2024) экспериментально подтвердило: WebRTC утекает даже при использовании VPN, SOCKS или HTTP/S прокси на всех протестированных платформах. WebRTC использует UDP и обращается к сетевым интерфейсам ОС напрямую, минуя прокси-стек. Единственное решение: полное отключение WebRTC (Tor/Mullvad) или media.peerconnection.enabled = false в Firefox.

Какие типы DNS-утечек существуют? Шесть основных: (1) DNS resolver mismatch > DNS в одной стране, IP в другой; (2) DoH fingerprinting > 95% точности определения посещённых сайтов по зашифрованному DoH (DePL, IEEE 2022); (3) DoT утечка > трафик на порту 853 идёт мимо VPN; (4) DoH auto-translation > браузеры отправляют DNS через свои резолверы в обход VPN; (5) ODoH fingerprinting > даже Oblivious DoH определяется на 94% (IEEE DSN'25); (6) DNS geo mismatch как детектор VPN.

Что такое DoH fingerprinting и почему шифрование не помогает? Шифрование скрывает содержимое DNS-запросов, но не скрывает метаданные: размеры пакетов, тайминги, объёмы. Каждый сайт генерирует уникальную последовательность DNS-запросов. DePL (IEEE Icnp 2022) достигает ~95% точности по 50 пакетам. Loyola University подтвердил: 95% предсказания 1 из 10 000 сайтов. Даже IETF-рекомендованный паддинг не спасает: атакующие всё равно достигают точности свыше 95%.

Что такое mDNS утечка и чем она опасна? mDNS (Multicast DNS) используется для обнаружения устройств в локальной сети. При генерации WebRTC ICE-кандидатов браузеры используют mDNS для обфускации IP, но mDNS-ответы содержат hostname устройства > часто реальное имя владельца («Ivans-MacBook-Pro.local»). В кофейне, коворкинге, аэропорту любой участник подсети видит это имя. UUID в WebRTC-кандидате не меняет этого факта. Решение: сменить hostname на неличное («MacBook» вместо имени).

Какой браузер наиболее безопасен от сетевых утечек? Только Tor Browser и Mullvad Browser полностью защищены: WebRTC отключён, IPv6 заблокирован, QUIC отключён, mDNS подавлен, DNS идёт через Tor/VPN. Все остальные браузеры (Chrome, Safari, Firefox, Brave, Opera) уязвимы по WebRTC, IPv6, QUIC и DNS. Firefox позволяет закрыть большинство утечек вручную (media.peerconnection.enabled = false, отключение IPv6, отключение QUIC), но это требует знаний и постоянного контроля после обновлений.