Предложение по I2P №166: Учетная запись/Хост Поддержка типов туннелей

Proposal 166
Открыто
Author eyedeekay
Created 2024-05-27
Last Updated 2024-08-27
Target Version 0.9.65

Предложение для хост-осведомленного HTTP-прокси туннеля

Это предложение направлено на решение проблемы “Разделенная идентичность” в конвенциональном использовании HTTP-over-I2P посредством введения нового типа туннеля HTTP-прокси. Этот тип туннеля обладает дополнительным поведением, целью которого является предотвращение или ограничение возможности отслеживания потенциальными враждебными операторами скрытых сервисов, направленного на целевые пользовательские агенты (браузеры) и само I2P клиентское приложение.

В чем заключается проблема “Разделенной идентичности”?

Проблема “Разделенной идентичности” возникает, когда пользовательский агент в криптографически адресованной оверлейной сети делится криптографической идентичностью с другим пользовательским агентом. Это происходит, например, когда как Firefox, так и GNU Wget настроены использовать один и тот же HTTP-прокси.

В этом сценарии сервер может собирать и хранить криптографический адрес (Назначение), используемый для ответа на действия. Он может рассматривать это как “Отпечаток”, который всегда на 100% уникален, потому что он криптографически обоснован. Это означает, что установимость, наблюдаемая в проблеме Разделенной идентичности, является идеальной.

Но это проблема? ^^^^^^^^^^^^^^^^^^^^

Проблема разделенной идентичности — это проблема, когда пользовательские агенты, говорящие на одном и том же протоколе, стремятся к разъединенности. Впервые в контексте HTTP она была упомянута в этом ветке на Reddit , с комментариями, доступными благодаря pullpush.io. На тот момент я был одним из самых активных респондентов и на тот момент я считал, что вопрос незначителен. За последние 8 лет ситуация и мое мнение о ней изменились, я теперь считаю, что угроза, вызванная злонамеренной корреляцией назначений, значительно выросла, так как больше сайтов оказываются в положении “профилирования” конкретных пользователей.

Эта атака имеет очень низкие барьеры для входа. Она требует лишь, чтобы оператор скрытого сервиса управлял несколькими сервисами. Для атак на современные визиты (посещение нескольких сайтов одновременно) — это единственное требование. Для не современного связывания один из этих сервисов должен быть сервисом, который размещает “учетные записи”, принадлежавшие одному пользователю, который отслеживается.

В настоящее время любой оператор сервиса, который размещает учетные записи пользователей, сможет их связывать с активностью на любых сайтах, которые они контролируют, эксплуатируя проблему Разделенной идентичности. Mastodon, Gitlab или даже простые форумы могут оказаться атакующими под прикрытием, если только они управляют более чем одним сервисом и имеют интерес в создании профиля пользователя. Это наблюдение может происходить с целью преследования, финансовой выгоды или по причинам, связанным с разведкой. Прямо сейчас существуют десятки крупных операторов, которые могут провести эту атаку и получить от нее значимые данные. Мы в основном доверяем им не делать этого пока, но могут появиться игроки, которые не заботятся о наших мнениях.

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

Разделенная идентичность не полезна против пользователя, который использует I2P исключительно для скрытия геолокации. Она также не может использоваться для нарушения маршрутизации I2P. Это только проблема управления контекстной идентичностью.

  • Невозможно использовать проблему Разделенной идентичности для геолокации пользователя I2P.
  • Невозможно использовать проблему Разделенной идентичности для связывания сессий I2P, если они не являются современными.

Однако возможно использовать её для ухудшения анонимности пользователя I2P в обстоятельствах, которые, вероятно, довольно часто встречаются. Одна из причин, по которой они часто встречаются, заключается в том, что мы поощряем использование Firefox, веб-браузера, который поддерживает “вкладки”.

  • Всегда возможно создать отпечаток из проблемы Разделенной идентичности в любом веб-браузере, поддерживающем запрос сторонних ресурсов.
  • Отключение Javascript не достигает ничего против проблемы Разделенной идентичности.
  • Если связь может быть установлена между не современными сеансами, такими как “традиционное” отпечатки браузера, тогда Разделенная идентичность может быть применена транзитивно, потенциально позволяя стратегию не современного связывания.
  • Если связь может быть установлена между активностью в Clearnet и идентичностью I2P, например, если цель вошла на сайт как с I2P, так и с Clearnet, Разделенная идентичность может быть применена транзитивно, потенциально позволяя полную де-анонимизацию.

Как вы оцениваете серьезность проблемы Разделенной идентичности, примененной к HTTP-прокси I2P, зависит от того, где вы (или более того, “пользователь” с потенциально неинформированными ожиданиями) думаете, что “контекстная идентичность” для приложения находится. Есть несколько вариантов:

  1. HTTP — это как Приложение, так и Контекстная Идентичность — это как это работает сейчас. Все HTTP приложения разделяют идентичность.
  2. Процесс — это Приложение и Контекстная Идентичность — это как это происходит, когда приложение использует API, такие как SAMv3 или I2CP, где приложение создает свою идентичность и контролирует её срок службы.
  3. HTTP — это Приложение, но Хост — это Контекстная Идентичность
    • Это цель этого предложения, которое рассматривает каждый хост как потенциальное “веб-приложение” и соответственно угрожает поверхности.

Решаемо ли это? ^^^^^^^^^^^^^^^

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

Это позволяет нам улучшить поведение HTTP-прокси для этого типа HTTP пользовательских агентов, сделав поведение прокси совпадающим с поведением пользовательского агента, предоставляя каждому хосту своё собственное назначение при использовании с HTTP-прокси. Это изменение делает невозможным использование проблемы Разделенной идентичности для получения отпечатка, который можно использовать для связывания активности клиента с 2 хостами, поскольку эти 2 хоста просто больше не будут разделять обратную идентичность.

Описание: ^^^^^^^^^^^^

Будет создан новый HTTP-прокси и добавлен в Менеджер Скрытых Сервисов (I2PTunnel). Новый HTTP-прокси будет работать как “мультиплексор” I2PSocketManagers. Сам мультиплексор не имеет назначения. Каждый индивидуальный I2PSocketManager, который становится частью мультиплекса, имеет свое собственное локальное назначение и свой собственный пул туннелей. I2PSocketManagers создаются по запросу мультиплексором, где “запрос” — это первый визит к новому хосту. Возможно оптимизировать создание I2PSocketManagers до их вставки в мультиплексор, создав один или более заранее и сохранив их вне мультиплексора. Это может улучшить производительность.

Дополнительный I2PSocketManager, с собственным назначением, будет настроен как носитель “Аутпрокси” для любого сайта, который не имеет назначения I2P, например, для любого сайта Clearnet. Это эффективно делает все использование Аутпрокси одной Контекстной Идентичностью, с оговоркой, что настройка нескольких Аутпрокси для туннеля вызовет нормальную “Липкую” ротацию аутпрокси, где каждый аутпрокси получает запросы только для одного сайта. Это почти эквивалентное поведение, как изоляция HTTP-over-I2P прокси по назначению, в явном интернете.

Ресурсные соображения: ’’’’’’’’’’’’’’’’’’’’’’''

Новый HTTP-прокси требует дополнительных ресурсов по сравнению с существующим HTTP-прокси. Он будет:

  • Потенциально строить больше туннелей и I2PSocketManagers
  • Строить туннели чаще

Каждое из этого требует:

  • Локальные вычислительные ресурсы
  • Сетевые ресурсы от пиров

Настройки: ’’’’’’’''

Чтобы минимизировать влияние увеличенного использования ресурсов, прокси должен быть настроен на использование как можно меньших ресурсов. Прокси, которые входят в состав мультиплексора (не родительский прокси), должны быть настроены на:

  • Мультиплексированные I2PSocketManagers строят 1 туннель внутрь, 1 туннель наружу в своих пулах туннелей
  • Мультиплексированные I2PSocketManagers по умолчанию берут 3 хопа.
  • Закрывайте сокеты через 10 минут бездействия
  • I2PSocketManagers, запущенные мультиплексором, разделяют срок службы мультиплексора. Мультиплексированные туннели не “удаляются” до тех пор, пока родительский мультиплексор не будет.

Диаграммы: ^^^^^^^^^

Ниже представлена диаграмма текущей работы HTTP-прокси, которая соответствует “Возможности 1.” в разделе “Является ли это проблемой”. Как вы можете видеть, HTTP-прокси взаимодействует с I2P-сайтами напрямую, используя только одно назначение. В этом сценарии HTTP является как приложением, так и контекстной идентичностью.

**Текущая ситуация: HTTP — это приложение, HTTP — это контекстная идентичность**
                                                          __-> Outproxy <-> i2pgit.org
                                                         /
   Браузер <-> HTTP-прокси (одно назначение)<->I2PSocketManager <---> idk.i2p
                                                         \__-> translate.idk.i2p
                                                          \__-> git.idk.i2p

Ниже представлена диаграмма работы хост-осведомленного HTTP-прокси, которая соответствует “Возможности 3.” в разделе “Является ли это проблемой”. В этом сценарии HTTP является приложением, но хост определяет контекстную идентичность, где каждый сайт I2P взаимодействует с различным HTTP-прокси с уникальным назначением для каждого хоста. Это предотвращает операторов нескольких сайтов от возможности различать, когда тот же человек посещает несколько сайтов, которые они управляют.

**После изменения: HTTP — это приложение, хост — это контекстная идентичность**
                                                        __-> I2PSocketManager(Назначение A - только аутпрокси) <--> i2pgit.org
                                                       /
   Браузер <-> HTTP-прокси мультиплексор (Без назначения) <---> I2PSocketManager(Назначение B) <--> idk.i2p
                                                       \__-> I2PSocketManager(Назначение C) <--> translate.idk.i2p
                                                        \__-> I2PSocketManager(Назначение 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 прокси и положит в основу команду:

#! /bin/sh
command_to_proxy="$@"
java -jar ~/i2p/lib/i2ptunnel.jar -wait -e 'sockstunnel 7695'
torsocks --port 7695 $command_to_proxy

Приложение: пример реализации атаки

Пример реализации атаки Разделенной идентичности на HTTP пользовательских агентов существует уже несколько лет. Еще один пример доступен в подкаталоге simple-colluder репозитория idk’s prop166 Эти примеры специально разработаны, чтобы продемонстрировать, что атака работает и потребует модификации (хотя и незначительной) для превращения в реальную атаку.