Предложение о введении HTTP-прокси туннеля с учётом хоста
Это предложение направлено на решение проблемы «Общего Идентификатора» при традиционном использовании HTTP через I2P посредством введения нового типа HTTP-прокси туннеля. Данный тип туннеля обладает дополнительным поведением, призванным предотвратить или ограничить возможность отслеживания со стороны потенциально враждебных операторов скрытых сервисов за целевыми пользовательскими агентами (браузерами) и самим клиентским приложением I2P.
Что такое проблема «Общего Идентификатора»?
Проблема «Общего Идентификатора» возникает, когда пользовательский агент в криптографически адресуемой оверлейной сети использует один и тот же криптографический идентификатор с другим пользовательским агентом. Это происходит, например, когда Firefox и GNU Wget настроены на использование одного и того же HTTP-прокси.
В этом сценарии сервер может собирать и хранить криптографический адрес (Destination), используемый для ответа на действия пользователя. Он может рассматривать его как «отпечаток», который всегда 100% уникален, поскольку имеет криптографическое происхождение. Это означает, что связность, наблюдаемая в рамках проблемы общего идентификатора, является абсолютной.
Но является ли это проблемой? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Проблема общего идентификатора актуальна, когда пользовательские агенты, использующие один и тот же протокол, стремятся к несвязности. Она была впервые упомянута в контексте HTTP в этой ветке Reddit , с удалёнными комментариями, доступными благодаря pullpush.io . На тот момент я был одним из самых активных участников обсуждения, и на тот момент я считал, что проблема незначительна. За последние 8 лет ситуация и моё мнение изменились: теперь я считаю, что угроза, связанная с враждебной корреляцией адресов, значительно возрастает по мере того, как всё больше сайтов получают возможность «создавать профили» конкретных пользователей.
У этой атаки очень низкий порог входа. Она требует лишь, чтобы оператор скрытого сервиса управлял несколькими сервисами. Для атак на текущие посещения (посещение нескольких сайтов одновременно) это единственное требование. Для неодновременной корреляции один из этих сервисов должен быть сервисом, предоставляющим «учётные записи», принадлежащие одному пользователю, которого отслеживают.
В настоящее время любой оператор сервиса, предоставляющий учётные записи, может коррелировать их с активностью пользователя на всех сайтах, которые он контролирует, используя проблему общего идентификатора. Mastodon, Gitlab или даже простые форумы могут быть атакующими под маской, если они управляют более чем одним сервисом и заинтересованы в создании профиля пользователя. Такая слежка может вестись в целях преследования, получения финансовой выгоды или разведывательной деятельности. Сейчас существует десятки крупных операторов, которые могут провести такую атаку и получить значимые данные. Мы в основном доверяем им, что они этого не делают, но могут появиться участники, которым наши мнения безразличны.
Это напрямую связано с довольно простой формой построения профилей в открытой сети, когда организации могут коррелировать взаимодействия на своих сайтах с действиями в контролируемых ими сетях. В I2P, поскольку криптографический адрес уникален, этот метод может быть даже более надёжным, хотя и без дополнительной возможности геолокации.
Проблема общего идентификатора бесполезна против пользователя, использующего I2P исключительно для маскировки геолокации. Она также не может быть использована для нарушения маршрутизации I2P. Это лишь проблема управления контекстной идентичностью.
- Невозможно использовать проблему общего идентификатора для определения геолокации пользователя I2P.
- Невозможно использовать проблему общего идентификатора для связывания сессий I2P, если они не происходят одновременно.
Однако возможно использовать её для снижения анонимности пользователя I2P в ситуациях, которые, вероятно, очень распространены. Одна из причин их распространённости — мы поощряем использование Firefox, веб-браузера, поддерживающего работу с «вкладками».
- Всегда возможно создать отпечаток на основе проблемы общего идентификатора в любом веб-браузере, который поддерживает запрос ресурсов третьих сторон.
- Отключение JavaScript ничего не даёт против проблемы общего идентификатора.
- Если можно установить связь между неодновременными сессиями, например, с помощью «традиционного» отпечатка браузера, то общий идентификатор может быть применён транзитивно, потенциально позволяя стратегию неодновременной корреляции.
- Если можно установить связь между активностью в clearnet и идентификатором I2P, например, если цель авторизована на сайте с наличием как I2P, так и clearnet версий, общий идентификатор может быть применён транзитивно, потенциально позволяя полную деанонимизацию.
Оценка вами серьёзности проблемы общего идентификатора в контексте HTTP-прокси I2P зависит от того, где вы (или, точнее, «пользователь» с потенциально неосведомлёнными ожиданиями) считаете, что лежит «контекстная идентичность» приложения. Существует несколько возможностей:
- HTTP является и приложением, и контекстной идентичностью — именно так это работает сейчас. Все HTTP-приложения используют один идентификатор.
- Процесс является приложением и контекстной идентичностью — именно так это работает, когда приложение использует API, например SAMv3 или I2CP, где приложение создаёт свой идентификатор и управляет его временем жизни.
- HTTP — это приложение, но хост — это контекстная идентичность — это и есть суть данного предложения, которое рассматривает каждый хост как потенциальное «веб-приложение» и соответствующим образом оценивает поверхность угроз.
Можно ли это решить? ^^^^^^^^^^^^^^^^^^^^
Вероятно, невозможно создать прокси, который умело реагировал бы на каждый возможный случай, когда его работа может ослабить анонимность приложения. Однако возможно создать прокси, который умело реагирует на конкретное приложение, ведущее себя предсказуемо. Например, в современных веб-браузерах ожидается, что пользователи будут иметь несколько открытых вкладок, взаимодействуя с несколькими веб-сайтами, различаемыми по имени хоста.
Это позволяет улучшить поведение HTTP-прокси для этого типа пользовательских агентов, заставив прокси вести себя так же, как и пользовательский агент — назначая каждому хосту собственный Destination при использовании HTTP-прокси. Это изменение делает невозможным использование проблемы общего идентификатора для получения отпечатка, который можно использовать для корреляции активности клиента с двумя хостами, поскольку эти два хоста больше не будут использовать один и тот же обратный идентификатор.
Описание: ^^^^^^^^^
Будет создан новый HTTP-прокси и добавлен в Менеджер Скрытых Сервисов (I2PTunnel). Новый HTTP-прокси будет работать как «мультиплексор» I2PSocketManagers. Сам мультиплексор не имеет Destination. Каждый отдельный I2PSocketManager, входящий в мультиплекс, имеет собственный локальный Destination и собственный пул туннелей. I2PSocketManagers создаются мультиплексором по требованию, где «требование» — это первый визит на новый хост. Можно оптимизировать создание I2PSocketManagers до их вставки в мультиплексор, создавая один или несколько заранее и храня их вне мультиплексора. Это может улучшить производительность.
Дополнительный I2PSocketManager с собственным Destination настраивается как передатчик «Outproxy» для любого сайта, у которого нет I2P Destination, например, любого сайта clearnet. Это фактически делает всё использование Outproxy одной контекстной идентичностью, с оговоркой, что настройка нескольких Outproxy для туннеля вызовет обычное «прилипание» (Sticky) ротации Outproxy, при которой каждый Outproxy получает запросы только для одного сайта. Это почти эквивалентно изоляции HTTP-over-I2P прокси по Destination в clearnet.
Ресурсные соображения: ’’’’’’’’’’’’’’’’’’’’’’''
Новый HTTP-прокси требует дополнительных ресурсов по сравнению с существующим HTTP-прокси. Он будет:
- Потенциально строить больше туннелей и I2PSocketManagers
- Строить туннели чаще
Каждое из этих действий требует:
- Локальных вычислительных ресурсов
- Сетевых ресурсов от пиров
Настройки: ’’’’’’’''
Для минимизации влияния увеличенного потребления ресурсов прокси должен быть настроен на использование минимально возможного объёма. Прокси, входящие в мультиплекс (не родительский прокси), должны быть настроены так, чтобы:
- Мультиплексированные I2PSocketManagers создавали по 1 входящему и 1 исходящему туннелю в своих пулах туннелей
- Мультиплексированные I2PSocketManagers использовали по умолчанию 3 прыжка
- Закрывали сокеты после 10 минут бездействия
- I2PSocketManagers, запущенные мультиплексором, разделяли срок жизни с мультиплексором. Мультиплексированные туннели не «уничтожаются», пока не будет уничтожен родительский мультиплексор.
Диаграммы: ^^^^^^^^^
На диаграмме ниже показана текущая работа HTTP-прокси, соответствующая «Возможности 1» в разделе «Является ли это проблемой». Как видно, HTTP-прокси взаимодействует с сайтами I2P напрямую, используя только один Destination. В этом сценарии HTTP является и приложением, и контекстной идентичностью.
**Текущая ситуация: HTTP — это приложение, HTTP — это контекстная идентичность**
__-> Outproxy <-> i2pgit.org
/
Browser <-> HTTP Proxy(one Destination)<->I2PSocketManager <---> idk.i2p
\__-> translate.idk.i2p
\__-> git.idk.i2p
На диаграмме ниже показана работа HTTP-прокси с учётом хоста, соответствующая «Возможности 3» в разделе «Является ли это проблемой». В этом сценарии HTTP — это приложение, но хост определяет контекстную идентичность, при которой каждый сайт I2P взаимодействует с разным HTTP-прокси, имеющим уникальный Destination для каждого хоста. Это предотвращает возможность операторам нескольких сайтов определить, что один и тот же человек посещает несколько сайтов, которыми они управляют.
**После изменений: HTTP — это приложение, хост — это контекстная идентичность**
__-> I2PSocketManager(Destination A - Только Outproxy) <--> i2pgit.org
/
Browser <-> HTTP Proxy Multiplexer(Без Destination) <---> I2PSocketManager(Destination B) <--> idk.i2p
\__-> I2PSocketManager(Destination C) <--> translate.idk.i2p
\__-> I2PSocketManager(Destination C) <--> git.idk.i2p
Статус: ^^^^^^^
Рабочая реализация на Java прокси с учётом хоста, соответствующая более старой версии этого предложения, доступна в форке idk на ветке: i2p.i2p.2.6.0-browser-proxy-post-keepalive (ссылка в цитатах). Она активно перерабатывается, чтобы разбить изменения на более мелкие части.
Реализации с различными возможностями были написаны на Go с использованием библиотеки SAMv3. Они могут быть полезны для встраивания в другие приложения на Go или в go-i2p, но не подходят для Java I2P. Кроме того, они плохо поддерживают интерактивную работу с зашифрованными leaseSets.
Дополнение: i2psocks
Простой подход, ориентированный на приложения, для изоляции других типов клиентов возможен без реализации нового типа туннеля или изменения существующего кода I2P, путём комбинирования уже существующих инструментов I2PTunnel, которые широко доступны и протестированы в сообществе приватности. Однако этот подход делает сложное предположение, которое неверно для HTTP и также неверно для многих других потенциальных клиентов I2P.
Примерно следующий скрипт создаст SOCKS5-прокси, учитывающий приложение, и socksify базовую команду:
#! /bin/sh
command_to_proxy="$@"
java -jar ~/i2p/lib/i2ptunnel.jar -wait -e 'sockstunnel 7695'
torsocks --port 7695 $command_to_proxy
Дополнение: пример реализации атаки
Пример реализации атаки общего идентификатора на HTTP-пользовательские агенты
существует уже несколько лет. Дополнительный пример доступен в подкаталоге simple-colluder репозитория prop166 от idk
. Эти примеры намеренно разработаны, чтобы продемонстрировать работоспособность атаки и потребуют модификации (хотя и незначительной), чтобы превратиться в реальную атаку.