Сразу три механизма в WebKit позволяют обойти iCloud Private Relay; по сути это утечка IP-адреса пользователя там, где сервис обещает обратное. Проблема затрагивает Safari, все браузеры на iOS и iPadOS, которые обязаны использовать WebKit, а также WebKit-браузеры на macOS. Для команд, которые воспринимали Private Relay как «достаточно анонимный» слой по умолчанию, новость неприятная: двухрелейная схема не помогает, если часть трафика уходит мимо нее.
О находке сообщает The Hacker News со ссылкой на исследователей Talal Haj Bakry и Tommy Mysk. Они разобрали поведение WebKit и пришли к выводу, что DNS prefetching, WebAuthn Related Origin Requests и WebTransport в ряде сценариев обходят настроенный прокси и отправляют запросы напрямую с устройства. Иными словами, сайт может получить не только трафик, прошедший через Private Relay, но и реальный сетевой адрес клиента.
Сам Private Relay Apple запустила вместе с iOS 15 в 2021 году и включила в подписку iCloud+. Идея была простой и хорошо продаваемой: Safari отправляет трафик через два реле, чтобы ни одна сторона, включая саму Apple, не видела одновременно и пользователя, и полную картину его запросов. На практике многие пользователи воспринимали сервис как мягкую альтернативу VPN для повседневного серфинга. Именно поэтому новая утечка IP-адреса выглядит особенно неприятно. Уязвимость бьет не по маркетинговой формулировке, а по базовому обещанию сервиса: скрывать реальный адрес устройства во время веб-сессии.
Механика обхода у трех функций разная, но итог один. DNS prefetching заранее резолвит доменные имена через обычный DNS-путь устройства, а не через прокси, заданный браузером. WebAuthn Related Origin Requests заставляет системный сервис учетных данных запрашивать файл валидации напрямую с устройства. WebTransport, рассчитанный на современные двусторонние соединения поверх HTTP/3, способен открыть прямое соединение в обход прокси-конфигурации. Ирония в том, что все три механизма нужны браузеру ради скорости, совместимости или новых веб-сценариев, а ломают они именно приватность. Для пользователя это выглядит как обычная загрузка страницы, но часть сетевой активности уже идет не тем маршрутом, который должен был ее защищать.
Самый неприятный кусок истории связан с WebAuthn и passkeys. По словам Tommy Mysk, любой сайт может настроить поддержку этого стандарта так, чтобы WebKit выдал реальный IP-адрес даже при включенном Private Relay. Пользователю не нужно входить по ключу доступа, нажимать кнопку или вообще что-то подтверждать: достаточно открыть страницу, которая намеренно эксплуатирует баг. Исследователь отдельно уточнил, что сайту придется специально использовать эту ошибку, чтобы связать текущую сессию с утекшим адресом, но это не требует ни passkeys как таковых, ни отдельного действия со стороны человека. Исследователи даже подняли PoC-сайт для проверки, утекает ли адрес вне прокси-маршрута в конкретном браузере и на конкретном устройстве.
Масштаб проблемы шире одного Safari. На iOS и iPadOS все сторонние браузеры, включая Chrome, Edge, Firefox и Brave, все равно работают поверх WebKit, так что они наследуют особенности его сетевого поведения. На мобильных платформах логотип браузера тут вообще мало что меняет: под разными иконками работает один и тот же движок, а вместе с ним и одна и та же проблема. На macOS риск касается тех браузеров, которые опираются на API прокси-настроек WebKit. При этом исследователи отдельно оговаривают две важные детали: утечки происходят не во всех браузерах, а настольный Chrome, например, не затронут; кроме того, эффект смягчается, если устройство подключено через VPN. Для разработчиков это полезное напоминание, что «браузер под прокси» и «браузер без прямых сетевых выходов» не одно и то же.
Apple не ответила на запрос The Hacker News до публикации, но сообщила 404 Media, что изучает отчет исследователей. И это уже не первая трещина в приватном фасаде сервиса. Вскоре после запуска Private Relay в 2021 году компания FingerprintJS описала механизм утечки реального IP через WebRTC. Чуть больше месяца назад Apple также исправила другую проблему, на этот раз в Hide My Email: в отдельных условиях сервис мог раскрывать настоящий адрес электронной почты пользователя. Для бизнеса из этого следует довольно приземленный вывод: потребительские функции приватности нельзя без оговорок записывать в замену VPN, корпоративным прокси или собственной модели анонимизации трафика. А для продуктовых и ИБ-команд еще и то, что тесты на утечку IP-адреса стоит гонять не только на уровне приложения, но и на стыке браузерного движка, системных сервисов и новых веб-API, отдельно проверяя DNS-запросы, сценарии с WebAuthn и прямые HTTP/3-сессии.
История неприятна не только для Apple. Она показывает, где именно теперь ломается приватность: не в шифровании и не в красивой схеме из двух реле, а на стыке движка браузера, системных API и все более «умных» веб-стандартов вроде WebAuthn и WebTransport. Чем больше таких механизмов появляется, тем выше шанс, что очередная оптимизация снова превратит утечку реального адреса из исключения в побочный эффект. Подробности инцидента собраны в материале .