4 августа 2026 года исследователи Mysk опубликовали разбор трёх механизмов WebKit, которые отправляют трафик в обход настроенного прокси — напрямую с устройства. Под ударом оказались все iOS-браузеры с прокси-режимом, включая Tor-браузеры, а заодно и собственный сервис Apple — iCloud Private Relay. Прокси включён, интерфейс показывает чужую страну, а сайт при этом видит ваш настоящий IP и ваш домашний DNS-резолвер.
Это не экзотическая уязвимость для параноиков. Это наглядная демонстрация архитектурного правила, которое стоит усвоить всем, кто работает через прокси: прокси на уровне приложения защищает только тот трафик, который проходит через сетевой стек этого приложения. Всё, что порождает операционная система или отдельная системная служба, идёт мимо.
Что именно течёт
Исследование началось с бытовой ситуации: пользователь прокси-браузера Psylo пожаловался разработчику на утечку DNS. Разбор жалобы вскрыл три независимых канала утечки — все они лежат в самом WebKit, а не в конкретном приложении.
1. DNS prefetching — самый простой и самый неприятный
Механизм: тег <link rel="dns-prefetch"> просит браузер заранее разрешить имя хоста, чтобы ускорить будущую загрузку. Проблема в том, что WebKit на iOS резолвит такие имена через обычный DNS-путь устройства, а не через прокси.
Настольная Safari поддерживает dns-prefetch со времён Safari 5, но iOS этот тег игнорировал — вплоть до iOS 26.0 (сентябрь 2025). Тогда WebKit включил его в рамках того же изменения, которое убрало старый неявный спекулятивный DNS-префетчинг (баг 285744).
Как это эксплуатируется: страница вшивает в такие теги уникальные для каждого посетителя имена хостов, а затем просто смотрит, как запросы приходят на её собственный авторитативный DNS-сервер — с реального адреса сети посетителя. Никакого JavaScript, никакого взаимодействия с пользователем. Достаточно открыть страницу.
2. WebAuthn Related Origin Requests — утечка через паспорт от passkey
Этот канал появился ещё в iOS 18.0. Когда сайт запрашивает учётные данные WebAuthn (то есть passkey), система идёт проверять файл https://<rpId>/.well-known/webauthn — чтобы убедиться, что домен действительно связан с указанным relying party.
Ключевая деталь: этот проверочный запрос уходит не из сетевого стека браузера. Его выполняет служба учётных данных операционной системы, которая сама шлёт HTTPS-запрос прямо с устройства. Прокси, настроенный внутри браузера, о нём попросту не знает (баг 268426).
То есть достаточно, чтобы страница инициировала запрос passkey — и сервер атакующего получает соединение с вашего настоящего IP.
3. WebTransport — QUIC напрямую с устройства
Самый свежий канал. Вызов new WebTransport(url) открывает QUIC-соединение непосредственно с устройства, минуя прокси-конфигурацию. WebTransport в WebKit долго был выключен и публично приехал в iOS 26.4 в марте 2026 года (баги 260810 и 303453).
Кого это касается
Apple требует, чтобы все браузеры на iPhone использовали WebKit. Следовательно, затронут каждый iOS-браузер, который полагается на прокси-API WebKit — включая все iOS-версии Tor-браузеров и сам Psylo, с которого началось расследование. Плюс Safari и iCloud Private Relay.
Что не затронуто — VPN-приложения. Они работают на системном уровне и заворачивают весь трафик устройства целиком, включая тот, что порождают системные службы. Это и есть суть различия: у системного туннеля нет «мимо». Отдельное исключение — Onion Browser на уровне безопасности Silver с включённым Lockdown Mode: он невосприимчив к утечке через WebTransport.
Со стороны разработчиков реакция уже есть. В Psylo 1.3.1 закрыты все три канала: приложение блокирует подсказки dns-prefetch (страница больше не может заставить устройство резолвить подконтрольные атакующему имена), а WebTransport и WebAuthn выключены по умолчанию — включить их можно точечно, отдельными тумблерами. Apple, по данным на момент публикации, должна устранить проблемы в будущем обновлении; конкретных сроков компания не называла.
Почему это всплыло только сейчас
Хронология здесь показательна, и её стоит разобрать отдельно — она объясняет, почему проблему не заметили раньше.
- Сентябрь 2024, iOS 18.0 — появляется механизм WebAuthn Related Origin Requests. Канал утечки существует почти два года и всё это время никем не обсуждается: проверка домена для passkey выглядит как элемент безопасности, а не как способ раскрыть адрес.
- Сентябрь 2025, iOS 26.0 — WebKit включает поддержку dns-prefetch на мобильных устройствах. Формально это оптимизация скорости загрузки; фактически — страница получает возможность заставить устройство обратиться к произвольному DNS-имени в обход прокси.
- Март 2026, iOS 26.4 — публично включается WebTransport. Третий канал.
- Август 2026 — жалоба одного пользователя на утечку DNS приводит к разбору, который вскрывает все три сразу.
Общий знаменатель: ни одна из этих функций не задумывалась как канал деанонимизации. Все три — обычные возможности платформы: ускорение резолва, проверка passkey, современный транспорт. Утечкой они становятся только в сочетании с прокси-режимом уровня приложения, и именно поэтому их годами никто не проверял в этом качестве.
Вывод для практики простой и неприятный: отсутствие новостей об утечках не означает их отсутствия. Проверять надо самому и регулярно, а не ждать, пока кто-то опубликует разбор.
Как проверить себя
Исследователи выложили публичный стенд — leaks.psylo.app. Он проверяет три вещи: обычный HTTPS-трафик (какой IP и какие DNS-резолверы видит сервер), WebTransport и связку WebAuthn + dns-prefetch. Открываете со включённым прокси и сравниваете результат с тем адресом, который ожидаете увидеть.
Отдельно стоит проверить базовую гигиену — совпадает ли IP, DNS и WebRTC-адрес в вашей рабочей связке. Если раньше вы этим не занимались системно, начните с нашего разбора: как проверить прокси на утечку DNS.
Практический вывод: слой имеет значение
История с WebKit — частный случай общего правила, которое стоит держать в голове при любой работе через прокси, на любой платформе.
- Прокси в браузере ≠ прокси на устройстве. Настройка внутри приложения покрывает ровно тот трафик, который приложение само отправляет. Системные службы, фоновые процессы, обновления, пуш-соединения и, как выяснилось, встроенная служба passkey — всё это идёт своим путём.
- Утечки бывают не только в «известных» местах. WebRTC давно на слуху, и его научились затыкать. А DNS-префетчинг и проверка WebAuthn — это функции производительности и безопасности, которые никто не рассматривал как канал деанонимизации. Новые фичи браузеров регулярно создают новые обходные пути.
- Обновление платформы способно сломать вашу защиту молча. Тут это видно буквально по датам: DNS-префетчинг «включился» в iOS 26.0, WebTransport — в iOS 26.4. Пользователь ничего не менял, а поверхность утечки выросла сама.
Что это значит для мультиаккаунтинга и автоматизации
Для тех, кто ведёт несколько аккаунтов или собирает данные, риск здесь не абстрактно-приватный, а вполне финансовый. Антифрод-системы площадок сопоставляют сигналы: если сессия заявляет один IP, а сопутствующий запрос приходит с другого адреса и с домашнего резолвера, это готовый повод связать аккаунты между собой или пометить сессию как подозрительную.
Практические следствия:
- Не ведите рабочие мультиаккаунт-сессии в мобильных браузерах с прокси-режимом. Пока платформа не закрыла дыры, слой приложения на iOS ненадёжен по определению.
- Заворачивайте трафик системно. Если задача — именно мобильное окружение, разумнее поднимать прокси на уровне устройства или маршрутизировать через отдельный шлюз, а не полагаться на настройку внутри браузера.
- Проверяйте связку после каждого крупного обновления ОС и браузера. Раз в квартал — минимум. Заведите это в чек-лист, а не «когда что-то пойдёт не так».
- Отключайте то, чем не пользуетесь. WebTransport и WebAuthn в рабочем профиле для парсинга или SMM почти наверняка не нужны — их отключение убирает два канала утечки из трёх.
Качество самого IP при этом остаётся отдельной переменной: даже при герметичной конфигурации датацентровый адрес выдаёт себя по ASN. Для сценариев, где важно выглядеть обычным пользователем, работают резидентные прокси, а для мобильных приложений и площадок с самым жёстким антифродом — мобильные прокси с IP реальных сотовых операторов. Но никакой класс прокси не спасёт, если часть трафика физически идёт мимо него — сначала герметичность, потом качество адреса.
Итог
Три бага WebKit — DNS prefetching, WebAuthn Related Origin Requests и WebTransport — показали, что «прокси включён» и «весь трафик идёт через прокси» это два разных утверждения. На iOS разрыв между ними оказался достаточно широким, чтобы обычная веб-страница без единой строки JavaScript могла узнать реальный адрес посетителя Tor-браузера.
Пока Apple готовит исправление, единственная рабочая стратегия — проверять, а не предполагать. Откройте тестовый стенд, сравните адреса, отключите лишние API. И относитесь к каждому крупному апдейту ОС как к событию, после которого конфигурацию надо перепроверить заново. Разница между приватностью и её иллюзией часто состоит ровно в одном не заданном вовремя вопросе: «а точно ли весь трафик?». Полезно также понимать, какие ещё сигналы вас выдают помимо адреса — об этом мы писали в материале про защиту от браузерного фингерпринтинга.