I2p

Или, сказ о неожиданных способах раскрытия пользователей распределенных сетей-анонимайзеров.

Пользователи анонимных сетей и браузеров, вероятно, используют их для посещения преимущественно заблокированных/защищенных сайтов. При этом, далеко не все из них ожидают, что факт данного посещения останется анонимным. Если анонимность вас не беспокоит, то, дальнейшее содержимое статьи, скорее всего, вас не заинтересует.

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

Заявление

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

Векторы атаки

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

Под деанонимизацией мы будем понимать раскрытие настоящего IP адреса пользователя.

Фингерпринтинг

Если пользователь использует один и тот-же браузер для серфинга в обычной и "анонимной" сети, то его можно элементарно вычислить через отпечаток. Отпечаток сохраняется из "анонимной" сессии браузера, а, потом находится в базах данных отпечатков которые хранят миллиардами Google, Facebook и другие, в том числе, государственные, учреждения разных стран.

Способов снятия отпечатков много, и, все они известны, потому, не буду их здесь перечислять. Стоит использовать отдельный браузер для серфинга по "закрытому" интернету. И, даже там, желательно затирать историю после каждого использования.

Возможность доступа в обычную сеть

Пусть, вы используете отдельный браузер для серфинга в "закрытой" сети. Но, если из этого браузера сохраняется принципиальная возможность доступа в обычный интернет в обход "защищенной сети", то, сайт из onion/i2p домена может использовать эту возможность для вашей деанонимизации отправив запрос куда нужно. Это можно сделать через HTTP, DNS,WebRTC и т.п.

Чтобы этого избежать, - как минимум, запретите этому браузеру на Firewall все входящие и исходящие соединения на все IP кроме localhost и порта, на котором работает ваш анонимизирующий прокси.

Вы не сможете этого сделать, если ваш анонимайзер встроен в браузер и работает с ним в одном процессе.

Помимо этого, надо как-то убедиться, что ваш браузер, ни при каких обстоятельствах, не будет использовать API операционной системы для разрешения имен DNS и т.п..

Проверить последнее можно сформировав запрос через адресную строку параллельно просматривая трафик через wireshark или tcpdump.

Нестандартные протоколы

Ну, помимо http:// и https:// есть другие протоколы, в которых могут быть свои дыры. Например file:// и smb://, при помощи которых можно попытаться заставить ваш браузер/ОС отправить запрос по нужному адресу.

Все протоколы, кроме http:// https:// должны быть отключены в браузере намертво.

GPS координаты/микрофон/камера в браузере

Очевидно, но, можно очень просто и глупо спалиться.

Дыры в браузере

Это достаточно очевидная вещь, но, браузеры, это решето. Их надо регулярно обновлять. Но, и это вас не особо спасет. Рано или поздно появится новая дыра.

Браузерные плагины

Да. Будьте осторожны с плагинами к браузерам. В них могут быть уязвимости. Они могут видеть всё, что вы делаете, и, в некоторых случаях, могут отправлять данные на сторону.

Антивирусы

Ваш антивирус может вас деанонимизировать. Как?

Сайт в onion/i2p домене просто даст вам скачать уникальную страничку/файл. Браузер сохранит её на диске. Ваш антивирус, прежде чем сканировать ваш файл на "миллиард" существующих вирусов, может сначала поискать хэш этого файла в базе данных антивирусной компании, или, распределенной сети объединяющей всех пользователей. Тем самым, вы будете деанонимизированы.

Телеметрия ОС

Да. Возможно, ваша ОС имеет встроенный антивирус или средства телеметрии, которые тоже не гнушаются коллекционированием и отправкой хэшей ваших файлов в "облака".

Как быть

Рекомендую использовать изолированную от сети виртуальную машину, которая автоматом останавливается при обнаружении неожиданного трафика (отличного от tor|i2p) с её IP адреса.

Контроль должен быть внешним. Средствами другой ВМ или, лучше, другого физического хоста.

Рекомендую подход на основе трех видов трафика от виртуальной машины:

1. Зеленый - только доступ к I2P/TOR прокси, запущенном на ДРУГОЙ виртуальной машине. Сама ВМ принципиально не должна иметь возможности доступа в открытый интернет, и знать внешний IP пользователя.

2. Желтый - ранее проанализированный сторонний трафик, признанный допустимым. Он должен быть полностью заблокирован. Его "допустимость" означает, что мы не будем останавливать ВМ при его обнаружении, а просто заблокируем. Это, например, попытки Windows достучаться до Windows Update или отправить телеметрию.

3. Красный - все остальное. Заблокировано полностью. Помимо этого, при обнаружении ВМ немедленно останавливается, а, запись трафика (которая непрерывно ведется средствами контроля) и состояния ВМ, - анализируется. По результатам, трафик либо признается "желтым", либо определяется его источник/дыра в системе. В последнем случае, если трафик не может быть гарантировано признан "желтым", рекомендую откатить ВМ к "заводским настройкам". Вообще, рекомендую откатывать к "заводским настройкам" после каждого использования.

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

Камеры/микрофоны в зоне досягаемости

Камеры - достаточно очевидная штука. Надеюсь, никто не догадается лазить по закрытым сайтам на камеру. Про микрофоны на других устройствах, - это не совсем очевидно, но.

Когда вы печатаете сообщение на "защищенный" сайт, - этот сайт (или вставленный туда скрипт) может замерять интервалы между нажатиями кнопок на клавиатуре.

Интересно, что эту информацию можно извлекать даже из защищенной/зашифрованной TCP/HTTPS сессии пользователя замеряя интервалы между IP пакетами.

Микрофон (например, в вашем мобильнике) в зоне досягаемости может делать то-же самое. На основе этого, можно составить специальный индекс, который, по аналогии с сервисом определения названия играющей в фоне музыкальной композиции, сможет определить, что печатаете сообщение именно вы.

Частично спасает отключение JS, но, клики мышкой при переходе по страницам никуда не деваются, так что, держите микрофоны подальше от вашего рабочего места.

П.С.

Хорошей вам паранойи, товарищи!

I2P (Invisible Internet Project, Проект невидимого интернета) одноранговая сеть с открытым исходным кодом, где анонимность участников главная повестка всех архитектурных решений.

В I2P присутствует две основные сущности: роутер и конечная точка. Роутером называется программный клиент, который необходимо установить для использования I2P. По умолчанию роутер публикует реальные IP-адреса и активно взаимодействует с другими подобными участниками, выступая в роли транзитного узла и расширяя собственный рисунок сети, т.е. накапливает информацию о других доступных роутерах для их дальнейшего использования в своих туннелях. Конечная точка это осмысленная сущность сети, ведущая скрытую активность. Например, скрытый сайт, или выходной прокси обычного пользователя. Фактор анонимности I2P заключается в секретности месторасположений конечных точек: выявить роутер, являющийся родителем конечной точки, крайне сложно, а при должном подходе администратора невозможно.

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

Установка

I2Pd (Invisible Internet Protocol Daemon) роутер от преимущественно русскоговорящего сообщества PurpleI2P. Разрабатывается с 2013 года. Реализован на языке программирования C++, использует библиотеки OpenSSL и Boost. I2Pd является кроссплатформенным, готовые бинарники распространяются для платформ Windows, Linux, MacOS и Android. Очевидна возможность ручной компиляции, в том числе под операционные системы, не перечисленные выше. I2Pd имеется в стандартных репозиториях некоторых дистрибутивов Linux, однако для использования актуальной версии рекомендуется репозиторий сообщества. Основным местом распространения исходных кодов и бинарных файлов является репозиторий GitHub.

К счастью, администрирование I2P-роутера на всех платформах фактически идентично: веб-консоль на локальном адресе главный источник информации о текущей активности роутера. Адрес веб-консоли по умолчанию: http://127.0.0.1:7070.

Webconsole: Main page

Разберем всё по порядку:

Uptime Показывает прошедшее время с момента запуска.

Network status Сообщает сетевой статус роутера. В версиях выше 2.37.0 присутствует Network status 6 для отдельного отображения состояния сети на интерфейсах IPv6. Принимает значения:

• Testing: Тестирование сетевых возможностей роутера.

• OK: Всё в норме. Означает, что роутер работает в штатном режиме и доступен для соединений извне по протоколу TCP и UDP. Как правило, статус ОК появляется, когда порт I2Pd в операционной системе открыт, а IP-адрес доступен глобально, т.е. является выделенным, или белым (либо через NAT прокинут порт для I2Pd).

• Firewalled: Является индикатором недоступности порта TCP извне. Может быть сигналом о блокировке рабочего порта I2Pd файерволом операционной системы. В большинстве случаев статус Firewalled видят пользователи за NAT-сервером, не имеющие выделенного IP-адреса: главным образом пользователи сотовых операторов.

• Proxy: Работа роутера через прокси. Подразумевает работу только по протоколу NTCP2 (криптоаналог TCP), так как SSU (криптоаналог UDP) через прокси не ходит. Настраивается вручную через конфиг.

• Mesh: Работа роутера в меш-сети. На момент написания статьи поддерживается работа в Yggdrasil Network. Статус Mesh подразумевает работу роутера исключительно через меш-сеть, минуя обычный интернет. В случае использования режима Mesh вместе с прокси, или непосредственной работой через интернет, статус Mesh не выводится.

• Unknown: Отсутствует трафик SSU, при этом конфигурация роутера не соответствует индикаторам Proxy или Mesh.

Tunnel creation success rate Процент успешно построенных туннелей, т.е. процент успешно созданных туннелей от числа инициированных роутером. В среднем варьируется от 20 до 50%.

Received и Sent Объем полученной и отправленной информации с момента запуска роутера. В скобках указывается скорость передачи в настоящий момент.

Transit Объем транзитного трафика и актуальная скорость его потока.

Data path Рабочая директория роутера, где хранятся ключи и локальная база сети.

I2Pd поддерживает портабельный режим работы, когда все необходимые файлы приложения хранятся в одной директории рядом с исполняемым файлом. I2Pd автоматически начинает работать в портабельном режиме, если рядом с исполняемым файлом находится конфигурационный файл i2pd.conf.

Hidden content. Press on text to see Спойлер с чувствительной информацией о роутере. По умолчанию скрыт. Здесь отображаются IP-адреса с указанием протокола: SSU, SSUv6, NTCP2 и NTCP2v6 (приставка v6 обозначает работу по IPv6), а также криптографическое имя роутера (Router Ident), образуемое от публичного ключа router.keys. Этим ключом шифруется информация, адресуемая нашему роутеру.

В секции Our external address отображаются внешние IP-адреса роутера с указанием рабочего порта, на который роутер принимает внешние обращения. Случайный порт генерируется при первом запуске и сохраняется в файле router.info. Также есть возможность указать случайный рабочий порт вручную при запуске или в конфигурационном файле. Если в веб-консоли вы видите локальный адрес или нули, это сигнал о том, что рабочий порт роутера закрыт файерволом, либо ваш IP-адрес недоступен извне (т.е. не является выделенным). В случае протокола SSU при работе за NAT-сервером (например, через USB-модем), в списке внешних адресов роутера появится адрес NAT-сервера провайдера и порт, который в настоящее время закреплен за вами (Hole punch).

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

• f: Floodfill роутер является флудфилом.

• H: Hidden роутер не публикует свои IP-адреса.

• K: Канал для транзитного трафика до 12КБ/сек.

• L: Канал для транзитного трафика до 48 КБ/сек (по умолчанию).

• M: Канал для транзитного трафика до 64 КБ/сек.

• N: Канал для транзитного трафика до 128 КБ/сек.

• O: Канал для транзитного трафика до 256 КБ/сек.

• P: Канал для транзитного трафика до 2000 КБ/сек.

• X: Канал для транзитного трафика 2000 КБ/сек и выше (значение по умолчанию для флудфила).

• R: Reachable роутер доступен для обращений извне, имеет выделенный адрес и открытый порт.

• U: Unreachable роутер недоступен для внешних обращений.

Флаги роутера R и U в I2Pd указываются для корректной работы морально устаревшего Java-роутера. I2Pd эти флаги игнорирует и использует аналогичные флаги из Router Info (RI). Логично, что для каждого адреса флаги доступности могут различаться (например, для IPv4 за NAT и выделенного IPv6). В RI флаги указываются для каждого IP-адреса отдельно.

Router Info информация, публикуемая роутером о себе, которая включает ключи, флаги и IP-адреса. Файл router.info генерируется после каждого изменения состояния роутера и находится в рабочей директории Data path.

Помимо перечисленных флагов R и U, к адресам в Router Info опционально добавляются следующие:

• 4: Скрытый адрес IPv4.

• 6: Скрытый адрес IPv6.

• B: Означает, что SSU-адрес обрабатывает пиртесты, т.е. может быть привлечен для проверки доступности роутера извне.

• С: Означает, что адрес может быть интродьюсером (introducer) сущностью, выступающей в роли связующего звена для обращения к узлу со скрытым IP-адресом. Информация об использовании конечным узлом IPv4 или IPv6 необходима для совместимости на уровне транспорта после ответа связующего звена (флаги 4 и 6). Интродьюсер весьма емкая тема, которая будет подробно рассмотрена в отдельной статье.

Routers Отображает актуальное количество известных роутеров сети в локальной базе.

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

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

Client Tunnels Количество построенных и используемых туннелей нашим локальным роутером в настоящий момент времени. Отображаются только успешно построенные туннели: как серверные, т.е. принимающие соединение, так и клиентские, через которые мы подключаемся к другим скрытым ресурсам сети.

Transit Tunnels Количество транзитных туннелей, частью которых является роутер в настоящий момент времени.

В нижней части страницы, под заголовком Services обозначено состояние служб (активна или нет):

• HTTP Proxy HTTP-прокси пользователя для выхода в скрытую сеть. По умолчанию доступен на адресе 127.0.0.1:4444.

• SOCKS Proxy Пользовательский SOCKS-прокси для выхода в скрытую сеть. По умолчанию доступен на адресе 127.0.0.1:4447.

• BOB (Basic Open Bridge) Является интерфейсом для прикладных программ, работающих через I2P. Основная задача заключается в создании динамических туннелей. В Java-роутере считается устаревшим из-за подписи DSA, ненадежной из-за успешной практики взлома хеша SHA1, используемого в этой подписи. В I2Pd BOB активно поддерживается, использует актуальные алгоритмы подписи, а также имеет расширения протокола, вовсе отсутствующие в Java-роутере. В общем, является актуальным инструментом.

• SAM (Simple Anonymous Messaging) Является интерфейсом для прикладных программ, работающих через I2P. Основная задача также заключается в создании динамических туннелей. В I2Pd SAM является равноценной альтернативой BOB, а в Java-роутере единственным протоколом в своем роде.

  Сходство BOB и SAM обусловлено изначальной разработкой разными людьми со схожими целями: BOB для торрент-клиента Robert, SAM для iMule. В итоге и Robert и iMule ушли на задний план, а протоколы взаимодействия приложений с I2P-роутером остались.

• I2CP (I2P Control Protocol) протокол взаимодействия внешних программ с роутером, строго разделяющий I2P-роутер с программой, обращающейся в скрытую сеть. Концепция заключается в том, что работой с данными должно заниматься некое внешнее по отношению к маршрутизатору приложение. На практике это означает, что внешнее приложение должно содержать ~2/3 кода I2P-роутера, чтобы делать что-то осмысленное. В Java-роутере абсолютно весь трафик проходит через протокол I2CP, что сильно влияет на падение гибкости: стримы (сессии TCP фактически вся активность пользователя) не могут контролировать доступ к туннелям и лизсетам.

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

  В I2Pd протокол I2CP существует, как инструмент совместимости с приложениями, написанными в парадигме Java-роутера. Из рабочей логики I2Pd этот протокол убран, а все клиентские данные обрабатываются в рамках внутренних библиотек libi2pd и libi2pd_client, что позволяет прикладным программам полностью контролировать свою активность в скрытой сети.

• I2PControl протокол, позволяющий получить информацию о работе роутера в виде запросов и ответов в формате JSON. Является альтернативой веб-консоли и используется редко, поэтому в рамках статьи рассмотрен не будет.

Webconsole: Router commands

На этой странице представлено несколько интуитивно понятных команд, не изменяющих конфигурационный файл и действующих до рестарта роутера:

• Run peer test запустить проверку доступности роутера. Может понадобиться, если при запуске роутера рабочий порт был закрыт и статус сети отображается, как Firewalled. Роутер автоматически проверяет свою доступность примерно раз в час, но есть возможность ускорить процесс вручную.

• Decline transit tunnels отклонять новые транзитные туннели (жизненный цикл уже созданных транзитных туннелей прерван не будет). Узлы, предлагающие нам стать частью туннелей, будут получать отказ. Команда может пригодиться при изучении сетевой активности сервера, чтобы убрать все мусорные подключения, при этом сохранив работоспособность скрытых сервисов I2P, в том числе сессию SSH.

• Start graceful shutdown запустить корректную остановку роутера. После запуска в течение 10 минут роутер продолжит обычную работу, не принимая новые транзитные подключения. Так как все туннели живут 10 минут, этого достаточно, чтобы выключить роутер, не оборвав туннели других участников сети.

• Force shutdown незамедлительная остановка I2P-роутера.

• Logging level (none, error, warn, info, debug) смена режима логирования. Может пригодиться при неожиданно возникшей потребности в дебаге. Логи продолжат писаться в стандартный файл (/var/log/i2pd/i2pd.log).

• Transit tunnels limit позволяет сменить лимит количества транзитных туннелей. По умолчанию 2500.

Webconsole: Local Destinations

Здесь представлен список конечных точек, расположенных на роутере. Каждый адрес образуется уникальным ключом, однако на одном ключе может располагаться несколько туннелей, поэтому в большинстве случаев удобно пользоваться пунктом I2P tunnels, чтобы анализировать туннели в отдельности (сравнимо с доменным именем в обычной сети и отдельными службами, работающими на домене на разных портах). Увидеть детальную информацию о конечной точке можно кликнув на ее имя.

Base64 полный адрес конечной точки, закодированный в base64. Включает в себя публичный ключ шифрования, публичный ключ подписи и прочую служебную информацию. Обычно этот массив составляет 391 байт. Кстати, хеш SHA256 в кодировке base32 от этого массива Base64 образует привычный адрес *.b32.i2p.

Address registration line позволяет получить строку для регистрации домена на ресурсах reg.i2p (поддерживается сообществом разработчиков i2pd) и stats.i2p (поддерживается командой Java-роутера). Домен будет привязан к актуальному ключу, для которого открыта строка регистрации.

Регистрация коротких доменов будет подробно рассмотрена в следующей.

LeaseSets количество опубликованных лизсетов (их публикуют только серверные туннели, чтобы к ним могли обратиться другие участники сети).

Inbound tunnels и Outbound tunnels входящие и исходящие туннели конечной точки, размещенной на локальном роутере. Суть обозначений входящего туннеля приведена на иллюстрации, для исходящих туннелей всё аналогично.

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

Tags список адресов, при взаимодействии с которыми локальная конечная точка использовала одноразовые криптографические ключи, называемые тегами. Amount это количество тегов. Минимальное число генерируемых тегов, как видно на скриншоте, равняется четырем. Нулевое количество означает израсходование ранее сгенерированных тегов. Применяется при использовании алгоритма ElGamal (внутреннее обозначение типа шифрования 0).

ElGamal считается очень ресурсоемким и устаревшим алгоритмом. На смену ему приходит тип шифрования 4 новый быстрый протокол сквозного шифрования ECIES-X25519-AEAD-Ratchet. Теги здесь тоже присутствуют, но в другом виде.

При этом алгоритме ключи не передаются по сети: каждый абонент выводит их математическим путем локально. Параметр Incoming Tags обозначает количество выведенных тегов на будущее, а Tags sessions отображает количество сессий и адреса, с которыми они установлены. Status говорит о состоянии сессии, где 4 означает Established, а всё, что меньше сессия по каким-то причинам зависла. Больше 4 тоже норма.

Streams стримы (TCP-сессии передачи информации), активные подключения внешнего приложения к I2P через локальный роутер. Соответствуют клиентским соединениям TCP/IP. Stream ID номер туннеля. Необходим для возможности различать разные потоки, сравним с номером порта. Пиктограмма с крестиком позволяет закрыть, т.е. прервать стрим. Destination адрес конечной точки на другом конце провода. Sent и Received объем отправленной и полученной информации в байтах.

RTT время в миллисекундах от отправки пакета до подтверждения его получения. Window текущий размер окна для отправки, измеряется в пакетах. Buf количество неотправленных байт, ожидающих места в окне. Out количество пакетов, находящихся в окне без подтверждения. In количество полученных пакетов, которые клиентское приложение еще не приняло. Status состояние стрима, где 1 означает открытое соединение.

Размеры пакетов: 1730 байт для ElGamal и 1812 байт для ECIES-X25519-AEAD-Ratchet.

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

Основываясь на этой общей модели, можно сказать, что транзитные туннели работают на втором уровне (на самом его низу, если разобраться), задействуя минимум логических ресурсов роутера. Благодаря этому стандартные 2500 транзитных туннелей не перегружают роутер даже на одноплатных компьютерах. Работа флудфила несколько накладнее по ресурсам, т.к. задействует сквозное шифрование, поэтому флудфил-одноплатник со слабым процессором может начать сбоить.

Webconsole: LeaseSets

Пункт, актуальный для роутеров, являющихся флудфилами. Содержит список лизсетов, опубликованных у нас скрытыми ресурсами, т.е. анонимными конечными точками сети. Имя лизсета является доменом *.b32.i2p без обозначения этого окончания. Лизсет содержит информацию о входном туннеле целевого ресурса и срок годности (в среднем 10 минут). Также существуют зашифрованные лизсеты, не поддающиеся очевидному анализу. Подробно тема лизсетов будет рассмотрена в следующей статье.

Webconsole: Tunnels / Transit tunnels

Во вкладке Tunnels можно увидеть все входящие и исходящие туннели роутера, инициированные самим роутером. Туннели с пометкой exploratory являются зондирующими они строятся автоматически через небольшой промежуток времени, имеют низкое движение трафика и служат для исследования сети: получение трех случайных роутеров от случайного флудфила. Также через них иногда ходят служебные запросы роутера и публикация своего Router Info.

Transit tunnels отображает только транзитные туннели. Информация тут более, чем скудная, так как все туннели в I2P являются однонаправленными и транзитный роутер знает лишь откуда принимать и куда передавать чужие пакеты информации (с соответствующей манипуляцией с симметричным ключом шифрования, который был выдан его при создании транзитного туннеля).

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

Webconsole: Transports

Страница с отображением прямого взаимодействия с другими роутерами с указанием количества соединений по каждому протоколу (NTCP2, NTCP2v6, SSU, SSUv6). В квадратных скобках указывается количество [отправленных : полученных] байт. Стрелки демонстрируют статус соединения: входящее или исходящее.

Webconsole: I2P Tunnels

Страница схожа с Local destinations, но удобнее в практическом применении, т.к. позволяет анализировать каждый туннель в отдельности, даже если несколько туннелей используют один ключ (один адрес). Название туннеля берется из его конфигурационного файла.

Отображается три типа туннелей: клиентские, серверные и Server Forwards. Туннели типа Forwards являются UDP-туннелями: могут быть как серверными, так и клиентскими.

Webconsole: SAM sessions

Страница со списком сессий внешних приложений с роутером по протоколу SAM. Имя сессии задается приложением. Кликнув по сессии, можно увидеть внешний I2P-адрес сессии и список локальных подключений к роутеру в рамках SAM-сессии. Протокол BOB может иметь подобный интерфейс, но в силу малой популярности страница в веб-консоли отсутствует (но теоретически может быть добавлена в будущем). Короче, если будете писать приложения для I2P, лучше ориентироваться на API в виде протокола SAM, чтобы бедные пользователи Java-роутера тоже могли пользоваться вашим продуктом.

Подключение к веб-консоли удаленного роутера

Веб-консоль I2Pd поддерживает конфигурацию с доступом по внешнему адресу и позволяет включить авторизацию пользователя по логину и паролю. Пример такой конфигурации приведен на иллюстрации (показано два вида синтаксиса, поддерживаемых конфигом I2Pd).

Такой подход чреват уязвимостью в случае, когда подключение к веб-консоли осуществляется через обычный интернет без использования дополнительного шифрования трафика (https). Одним из самых практичных и безопасных способов является подключение к веб-консоли через SSH с прокинутым портом. Протокол SSH не нуждается в дополнительной защите, так как имеет встроенное шифрование, и отлично подходит для повседневного использования в силу простоты и распространенности. Локальный порт прокидывается на удаленную машину через флаг -D: ssh -D 8888 user@<server ip> -p <ssh port>.

Приведенная команда позволит подключиться в браузере на SOCKS-прокси по адресу 127.0.0.1:8888 и выходить в глобальную сеть с IP-адреса сервера, а также иметь доступ к локальным ресурсам удаленной машины, словно браузер запущен на ней. В том числе получится подключиться по локальному адресу 127.0.0.1:7070 к веб-консоли I2P-роутера, развернутого на сервере.

Конфигурационный файл

Несмотря на способность роутера работать с передаваемыми значениями (параметры при запуске), распространенной практикой является использование конфигурационного файла. На Debian при установке из пакета конфиг i2pd.conf находится в директории /etc/i2pd/. При запуске бинарника без установки (например, после ручной компиляции роутера), конфигурационный файл читается из директории ~./i2pd/. На Android все рабочие файлы роутера (в том числе конфиг) лежат в одной папке, чаще всего это /sdcard/i2pd/. На Windows стандартной рабочей директорией является %AppData%\i2pd.

Конфигурационные файлы на разных операционных системах принимают одинаковые значения с небольшими исключениями, с которыми можно ознакомиться в официальной документации. Стандартный конфиг с комментариями можно найти в исходниках, в папке contrib (при установке из пакета в системе появляется именно он).

Конфигурационный файл поддерживает два вида синтаксиса:

1. Указание конфигурируемой секции в квадратных скобках с перечислением параметров этой секции ниже до следующих квадратных скобок;

2. Указание параметра через точку после имени секции.

Параметры по умолчанию (в том числе при запуске без конфигурационного файла):

• Веб-консоль включена, доступна по адресу http://127.0.0.1:7070

• HTTP-прокси включен, доступен по адресу 127.0.0.1:4444

• SOCKS-прокси включен, доступен по адресу 127.0.0.1:4447

• SAM включен, доступен по адресу 127.0.0.1:7656

• Активен фоновый режим работы роутера (демон)

• Логирование на уровне warn (от warning внимание!)

• IPv4 включен, IPv6 отключен

  Неупомянутые параметры по умолчанию неактивны.

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

family дополнительный опознавательный признак роутера. В концепции, в которую поверили лишь единицы, в том числе ведущий разработчик Java-роутера с ником zzz, family указывается добропорядочными пользователями для того, чтобы роутеры одного админа не появились вместе в одном туннеле. Как не трудно понять, эта опция никем и никогда не используется, а злонамеренными людьми, которые хотят захватывать как можно больше туннелей для попытки мониторинга сети, family не используется тем более.

[reseed] Параметры получения стартового пакета (ресида) с несколькими роутерами для начала взаимодействия с сетью I2P. В первую очередь, ресид важен при первом запуске, когда локальная база сети пуста (папка netDb).

verify Проверка подписи полученного ресида. По умолчанию параметр является отключенным. Однако, в стандартном конфиге в состоянии true. Подразумевается, что экземпляр конфигурационного файла имеется после установки из пакета, в который входят сертификаты стартовых узлов (папка certificates). Если верификацию включить, не имея сертификатов, роутер не сможет стартовать.

urls веб-адреса, с которых будет скачен ресид (например, https://example.ru/).

yggurls адрес IPv6 Yggdrasil, с которого будет скачен ресид.

file путь до локального .su3-файла, или прямая ссылка https.

zipfile путь до локального zip-архива базы роутера, или прямая ссылка https.

proxy прокси, используемый при обращении к ресиду.

threshold минимальное количество известных роутеров, при достижении которого произойдет обращение к одному из ресидов. По умолчанию 25.

[persist] Секция, отвечающая за сохранение на диск некоторой динамической информации.

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

addressbook отвечает за сохранение полных адресов. При отключении уменьшает нагрузку на диск.

Послесловие

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

Продолжение следует: в статье Администратор скрытого ресурса в I2P: Практический курс рассмотрим конфигурацию туннелей, безопасное хранение ключей, мультихоуминг и регистрацию коротких доменов в зоне .i2p.

Агрессивный рынок готов заработать на всем, что возможно продать, но популярные предложения в сфере приватной коммуникации являются фикцией и ложью. Это происходит по простым причинам: во-первых, бизнес придумали не меценаты, а корыстные люди; во-вторых, любой предприниматель даже при самых лучших побуждениях подотчетен третьим лицам и в спорных ситуациях свои интересы всегда ставит выше интересов клиента.

Сейчас пойдет речь про I2P некоммерческую сингулярность сетевой приватности и анонимности, где никто кроме вас не знает куда и кто передает вашу информацию. Сеть I2P (расшифровывается как Invisible Internet Project, Проект невидимого интернета) это оверлейная децентрализованная одноранговая сеть. Оверлейная значит работает поверх других сетей, например, обычного интернета; децентрализованная распределенная, не имеющая единой точки отказа: упадет один узел, полсети, или во всей сети останется 3 пользователя I2P все равно будет функционировать. I2P является одноранговой сетью, так как все участники имеют равные права и возможности: каждый пользователь скрытой сети строит свои туннели через других участников и сам является потенциальным звеном в цепочке другого пользователя. При этом естественная сетевая активность никак не компрометирует абонента перед домашним провайдером или участниками скрытой сети.

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

Отличие традиционной сети от скрытой

Традиционный интернет является ничем иным, как разветвленной сетью компьютеров. Он устроен так, что отследить действия пользователей не составляет трудности: интернет-провайдеру доступна история вашего веб-серфинга хотите вы этого или нет. Это может быть и VPN-провайдер, в любом случае о ваших интересах знают некие третьи лица. Благодаря этому глобальная сеть превращается в инструмент манипуляций и однобокой пропаганды.

Скрытые сети, так называемый даркнет, нацелены на обратное полную анонимность пользователей.

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

Жители общаются через окна это обмен информацией по открытым каналам. Обратите внимание на наличие уполномоченного соседа (домик 2), который все слышит, и, как мы знаем, записывает. Проведем аналогию шифрования информации с тайным языком: даже если соседи говорят на незнакомом для шпиона языке, как минимум он знает, что определенные дома поддерживают контакт. В случае обычного интернета провайдер хранит информацию о сайтах, которые вы посещаете. Ему не обязательно знать, что именно вы писали на оппозиционном форуме. Один факт посещения подобного ресурса говорит о многом. У двух домов (4 и 5) имеются связанные подземные туннели они обмениваются сообщениями без крика на улицу. Шпион не видит, что эти люди общаются.

Важный термин, который понадобится в дальнейшем это DPI (deep packet inspection). На нашей иллюстрации этим понятием можно охарактеризовать навык шпиона понимать тайное значение услышанных слов. Например, люди будут кричать в окно слово труба перед тем, как начать общаться через скрытые туннели. Шпион быстро это поймет и станет рыскать возле домов, откуда донеслось кодовое слово. Это будет называться выявлением при помощи технологии DPI.

Для представления скрытой одноранговой сети, где все узлы имеют равные права и возможности, сделаем важное замечание: каждый дом может передавать сообщение только ближайшему соседу, прося отправить сообщение дальше. Так получается иллюстрация peer-to-peer сети, в которой каждый узел одновременно выступает получателем, отправителем и транзитным узлом. Очевидны несколько проблем: анонимность отправителя, сохранность и секретность данных на транзитных узлах, а также наличие злонамеренных участников сети, которые могут пытаться анализировать проходящие через них сообщения для определения личности анонимных абонентов. Сеть I2P изначально была спроектирована с учетом предположения, что все промежуточные узлы являются скомпрометированными или злонамеренными. Туннели I2P являются однонаправленными, т.е. входящий трафик идет по одной цепочке узлов, а исходящий по другой. Помимо этого все передаваемые сетевые зашифрованные сообщения имеют свойство накладываться друг на друга, сливаясь в информационный шум, что делает бессмысленным попытки прослушать и проанализировать проходящий поток данных.

Базовое понимание криптографии

Существуют два основных вида алгоритмов шифрования: симметричный и асимметричный. Эти знания понадобятся, чтобы понимать дальнейший рассказ.

Симметричные алгоритмы более просты и за счет этого работают в разы быстрее: в них для шифрования и расшифровки информации используется один ключ. Слабое место такого подхода это передача ключа от одного пользователя другому. Если злоумышленник сможет перехватить ключ, он получит доступ к секретной информации. Фактором безопасности в симметричном шифровании (в частности AES распространенном алгоритме) является вектор инициализации (IV). Вектор инициализации критически важная составляющая, имитирующая первый блок информации. Так как при AES-шифровании каждый блок из 16 байт влияет на следующий блок, целостность информации критически важна.

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

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

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

Цифровая подпись является производным совместного использования асимметричных алгоритмов шифрования и хеш-функции: сначала выводится хеш-сумма, а затем секретным ключом в нее закладывается идентификатор ключа подписавшего пользователя. Имея открытый ключ подписавшего, мы самостоятельно проверяем хеш-сумму информации и сравниваем ее с той, которую изначально заложил отправитель. Так проверяется достоверность полученной информации.

Общие принципы работы I2P

В сети I2P все пакеты зашифровываются на стороне отправителя и расшифровываются только на стороне получателя, при этом никто из промежуточных участников обмена не имеет возможности перехватить исходные данные. По этой причине нет необходимости беспокоиться о том, чтобы прикладные программы обеспечивали шифрование своего трафика. Например, сайту в I2P не нужно использовать TLS-шифрование, чтобы вводимые данные пользователя не были перехвачены, как это делается в обычном интернете, т.е. нет нужды использовать протокол HTTPS.

Также, никто из участников сети не знает, кто на самом деле отправитель и кто получатель, так как статус узла, от которого пришел пакет неизвестен, он может быть отправителем или промежуточным, а следующий, которому нужно этот пакет отправить, может являться получателем или таким же промежуточным узлом. Узнать конечные точки отправителя и получателя промежуточный узел никак не может, так же как не может узнать, что произошло с только что переданным следующему узлу пакетом: обработал ли тот его, или передал куда-то дальше.

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

Конечная точка наоборот является осмысленной сущностью либо сервером, либо клиентом, но ее реальное местоположение неизвестно. В качестве адресов конечных точек сети I2P используются идентификаторы, выведенные из открытого ключа подписи: хеш-сумма дает уникальную строку фиксированной длины, в конце которой для удобочитаемости подставляется псевдодоменная зона .b32.i2p так получается привычный внутрисетевой адрес. Для использования человекочитаемых доменов в зоне .i2p, например acetone.i2p, существуют бесплатные регистраторы, достаточно незамысловатые в использовании. Привязка домена происходит к полному адресу.

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

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

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

По умолчанию длина туннелей составляет 3 узла, но в зависимости от потребностей пользователя может составлять 1 транзитный узел или целых 8, и даже 0, тогда будет происходить прямое подключение к туннелю второй стороны. Как видим, администратор конечного ресурса имеет входной туннель в 4 узла. Получив запрос, веб-ресурс отсылает ответ во входной туннель пользователя через свой выходной туннель, т.е. по абсолютно другому пути. Смотря на схему, можно представить насколько сложно пользователю определить реальное местоположение собеседника. Учитывая, что каждые 10 минут происходит смена существующего туннеля на новый с новыми цифровыми подписями и ключами шифрования, деанонимизация кого-либо вовсе кажется фантастикой.

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

Лизсет включат в себя полный адрес конечной точки, ключи шифрования и список входящих туннелей. Обращаясь к какому-либо адресу в I2P, вы автоматически запрашиваете у случайного флудфила лизсет этого адреса. Если флудфил не знает запрошенный адрес, он сообщает адреса других флудфилов и поиск продолжается. Флудфил является роутером (а не конечной точкой) и принимает подключения напрямую, т.е. не имеет своих входных туннелей. Однако конечные точки обращаются к нему исключительно через анонимные цепочки, тем самым скрывая местоположение публикуемых ресурсов и тех, кто хочет к ним обратиться.

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

Помимо поиска лизсетов, белый шум генерируется зондированием сети: каждый роутер с небольшой периодичностью опрашивает случайный флудфил, получая от него в ответ три новых роутера (таким образом увеличивая собственный рисунок сети и находя новые флудфилы). Главным источником сетевого шума на роутере является транзитный трафик: он создает большую сетевую активность вне зависимости от конечных точек, расположенных на роутере. Также, будучи транзитным звеном, роутер подмешивает к трафику чужих туннелей полезную нагрузку трафик своих скрытых сервисов. Чем больше транзитного трафика на роутере, тем абсолютнее секретность его конечных точек: какие-либо действия на скрытом ресурсе, даже DDoS-атаку, нельзя сопоставить с сетевой активностью конкретно взятого сервера. Активный узел сети имеет в своей базе в среднем 5000 активных роутеров и принимает сотни, а то и тысячи абсолютно случайных транзитных подключений. Как говорится: попробуй проанализируй.

Отдельно отметим механизм выбора флудфила пользователем. Это важный вопрос, которому при разработке было уделено надлежащее внимание. Так как любой из флудфилов может содержать злонамеренный пользователь, стояла задача сделать его попытки анализа и прочих недобросовестных действий не применимыми к конкретному человеку. Флудфил для запроса выбирается следующим образом: берется целевой адрес и сегодняшняя дата. Из этой информации выводится хеш SHA256 получаются данные той же длины, что и обычный адрес. Затем осуществляется поиск флудфила в локальной базе роутера: используется тот, который при операции ИСКЛЮЧАЮЩЕЕ ИЛИ с блоком целевой адрес + дата даст наименьшее число. Подобный подход делает выбор узла для служебных запросов непредсказуемым и ежедневно изменяющимся для каждого адреса. В рамках этого материала упоминается случайный флудфил, однако знайте, что кроется за этими словами.

Недавно мы упомянули DPI исследование сетевых пакетов с целью выявления типа передаваемой информации. Упомянули не зря, потому что вы должны знать об этой технологии, а также о том, что весь трафик I2P устойчив перед анализом. Трафик сети зашифрован с самого низа, начиная с транспортных протоколов. В I2P используются: NTCP2, как крипто-аналог TCP, и SSU, как крипто-аналог UDP. I2P-роутер принимает сетевой трафик прикладных программ, обращающихся в скрытую сеть, и оборачивает привычные протоколы в их зашифрованные аналоги. После обработки в сетевых пакетах невозможно выявить что-либо вразумительное, потому что шифруется все, в том числе заголовки и размер. Размер пакетов скрывается паддингом, т.е. заполнением пакетов случайными данными до определенного размера. Информация о настоящем размере сетевого пакета передается в нем же в зашифрованном виде. При расшифровке на конечном устройстве примешанный мусор просто отбрасывается. Таким образом белый шум сети, т.е. практически бессмысленная для человека информация смешивается с пользовательской информацией и со стороны абсолютно от нее неотличима.

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

Дополняя и закрепляя все сказанное, подробно опишем процесс от первого запуска роутера до открытия веб-страницы. При первом запуске роутер не имеет каких-либо данных о сети, поэтому происходит обращение к случайному ресид-серверу, который отдает пользователю свою базу известных роутеров. Ресиды держат энтузиасты, их список имеется в свободном доступе. По сути дела, информация от ресида представляет собой zip-архив папки netDb, в которой каждый роутер хранит информацию о сети. Так как передача данных происходит через обычный интернет, во избежание подмены по пути, архивы подписываются цифровым ключом. Публичные ключи всех актуальных ресидов содержатся в самом I2P-роутере. Если по каким-то причинам мы не хотим обращаться к публичным ресид-серверам, можно использовать уже имеющиеся базы сети, например, с других наших роутеров. Обращение к ресиду не происходит, если в папке netDb имеется не менее 25 роутеров. После подключения к нескольким актуальным участникам начинается автоматическое непрерывное расширение рисунка сети.

Построение туннелей

Для создания туннелей, обеспечивающих исчерпывающий уровень приватности, в I2P используется так называемое чесночное шифрование. Чеснок I2P представляет блок информации, включающий несколько чесночин по 528 байт. Чесночины закладываются в случайном порядке, поэтому их последовательность не несет какой-либо информации. Каждый получатель чеснока опознает свой зубчик по первым 16 байтам, которые являются частью хеша его адреса. После того, как нужный зубчик чеснока найден, содержащиеся в нем инструкции расшифровываются ключом роутера.

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

При создании входящего туннеля картина еще изящнее: через исходящий туннель случайному роутеру передается чеснок, последний получатель которого сам создатель. С позиции последнего транзитного звена передача чеснока создателю туннеля воспринимается как передача следующему транзитному узлу. Именно поэтому транзитные узлы не могут знать длину туннелей и их владельцев.

При построении туннеля длиной не более 4 участников, i2pd формирует чеснок из 4 зубчиков, в остальных случаях формируется чеснок из 8 частей. Пустые зубчики чеснока заполняются случайной информацией и неотличимы от настоящих.

Протокол I2P не предусматривает туннели длиннее 8 участников, однако на практике 4 транзитных узла считаются исчерпывающим решением.

В чесноке содержится информация для каждого участника:

1. Номер туннеля на его роутере (случайные 4 байта).

2. Адрес следующего роутера и номер туннеля на нем (почти как IP-адрес и номер порта в обычной сети).

3. Ключ симметричного шифрования и ключ шифрования вектора инициализации (IV). Сам вектор инициализации содержится в начале сообщения.

4. Роль узла в цепочке: конечный или промежуточный.

5. Ключ симметричного шифрования и вектор инициализации для ответа. Ими шифруется статус транзитного роутера: готов ли он принять новый туннель. Если в конце окажется, что хотя бы один роутер выразил несогласие, туннель не будет создан и весь процесс создания начнется с нуля.

В зависимости от типа туннеля (входящий или исходящий), последнее звено принимает роль либо Endpoint, либо Gateway. Между участниками одного туннеля зашифрованная информация передается блоками по 1 килобайту это нынешний стандарт протокола. Задача последнего исходящего узла собрать информацию в более весомый пакет и переслать нужному пользователю на его входящий туннель. Работа роутера входящего туннеля обратная: он разделяет полученную информацию на блоки и отправляет ее на другой конец туннеля. Каждый туннель существует 10 минут. Во избежание разрыва соединения, стороны заранее создают новые туннели и обмениваются их лизсетами.

Модель взаимодействия

По умолчанию, i2pd предоставляет для прикладных программ SOCKS и HTTP прокси. Прокси это посредник. В нашем случае посредник для выхода в скрытую сеть. По умолчанию SOCKS5 доступен по адресу 127.0.0.1:4447, HTTP-прокси на порту 4444. Чтобы открыть веб-страницу, размещенную в сети I2P, в браузере необходимо установить соответствующие настройки. В Firefox прокси удобно настраивается через конфигурацию сети, либо через плагин FoxyProxy. Когда мы ввели адрес сайта в настроенном браузере, I2P-роутер получил наш запрос и начал работу.

Сначала происходит обращение к случайному флудфилу с запросом лизсета нужной точки назначения. Выходной прокси пользователя является конечной точкой, т.е. скрытой сущностью. Чтобы не раскрыть ее местоположение, обращение к флудфилу происходит через цепочку транзитных узлов. Также мы сообщаем ему данные нашего входного туннеля для ответа. Допустим, что флудфил не знает нужного адреса, поэтому вместо лизсета он возвращает три случайных флудфила из своей базы. Из полученных новых флудфилов случайным образом выбирается один, к которому роутер повторяет прежний запрос. В нашем примере второй флудфил дает нужный лизсет: всю необходимую информацию для связи с конечной точкой, которая включает в себя сведения о входных туннелях и ключах. Входных туннелей, как правило, не меньше трех. Выбрав случайный входной туннель получателя, роутер отправляет через него запрос на сервер. Если все прошло успешно и запрос дошел, сервер отсылает нам веб-страничку. В обычной сети это происходит по тому же пути, откуда пришел запрос, но в I2P дела обстоят совсем иначе. Свой лизсет для ответа конечная точка локального прокси отправляет вместе с нашим запросом. Достучавшись до сервера, мы сообщили ему адрес для ответа: чтобы веб-страница открылась в браузере, серверу необходимо через свой исходящий туннель отправить ответ в наш входящий. Приняв ответ через входящий туннель, наш роутер обрабатывает информацию и в нашем браузере открывается заветная страничка!

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

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

Практическое использование

Область применения I2P обширна и не ограничивается только веб-сайтами. Вы можете размещать в I2P любые веб-ресурсы: форумы, доски объявлений, гит-репозитории, блоги и персональные одностраничники. Вполне реально организовать даже сетевые пошаговые игры, не требующие низкой задержки при передаче пакетов, например, шахматы или карты. Также найти применение I2P можно в построении выходных туннелей из неопределенного места в глобальную сеть, для полноты картины размещая выходные прокси на анонимно оплаченных серверах. Организуя ssh-доступ к арендуемой машине через I2P, вам всего лишь единожды потребуется зайти на сервер посредством других сетей, чтобы установить i2pd и сконфигурировать туннель, который будет принимать подключения. Единственное ограничение фантазий скорость передачи данных внутри сети. Надо заметить, что от года к году скорость становится все ближе к привычным показателям обычного интернета благодаря оптимизации программного кода и общему росту количества узлов.

Разработка протокола

се это интересно, но напрашивается закономерный вопрос: кто за этим стоит? Судя по сложности протокола, можно подумать, что это как и в случае с сетью Tor что-то связанное со спецслужбами и государственным финансированием, но нет. I2P полностью свободный проект, рожденный и поддерживаемый энтузиастами по сей день. Разработка I2P на языке программирования Java была начата неким JRANDOM. Первый релиз состоялся в 2003 году. Несколько лет спустя JRANDOM отошел от разработки, не оставив о себе вестей, а его место занял пользователь с никнеймом zzz американец, предположительно из района Нью-Йорка, который на момент выхода статьи все еще курирует разработку. Так прошло 10 лет: сообщество росло, I2P-роутер писали как могли, также в это время была написана официальная документация. При поисковом запросе I2P первая ссылка, как правило, ведет нас на сайт geti2p.net официальную страницу того самого I2P-роутера на Java. Но история на этом не заканчивается.

В 2013 году русскоговорящий пользователь orignal с французским никнеймом, судя по всему большой любитель пиратской литературы, обнаружил в онлайн-библиотеке Флибуста сообщение о недоступности скачивания книг через клирнет, т.е. обычный интернет. Вместо этого пользователям предлагалось использовать I2P. Однако Ориньяль, как он говорит, не нашел существующей нормальной реализации протокола, а только некое поделие на джаве. Несмотря на то, что разработка этого поделия уже велась десять лет, orignal, как искушенный программист, ее не оценил. На тот момент в сети лежало еще с десяток попыток написать i2p-роутер на языках C и C++, в которых не было сделано совсем ничего. Что-то было в продукте под названием i2pcpp, но до чего-то годного тоже было далеко. И что делает orignal: за три месяца он написал на С++ рабочую программу, пригодную для скачивания книг с Флибусты, и на этом уже хотел остановиться. На дворе был июль 2013 года. Однако некий человек уговорил его изложить свой опыт в статье на Хабре. Дело в том, что orignal пришлось вникать в дебри джава-кода, т.к. официальная документация оказалась не полноценной и имела разрозненную структуру. После публикации первой статьи что-то случилось: наверное, заметив интерес общественности, и почувствовав некоторый азарт, присущий всем программистам, писателям и композиторам, orignal взялся за написание полноценного клиента сети. Дебютный релиз 0.1.0 состоялся 17 октября 2014 года. Для его реализации orignal пришлось собственноручно реализовать на С++ несколько криптографических функций (которые с расширением библиотеки OpenSSL в дальнейшем были заменены на библиотечные). Новый клиент получил название i2pd Invisible Internet Protocol Daemon. После первого релиза к orignal присоединились энтузиасты, которые также начали работу над совершенствованием нового I2P-роутера. Сообщество разработчиков получило имя PurpleI2P.

В первые годы к инициативе i2pd было проявлено много скептицизма сторонних наблюдателей: в PurpleI2P искали руку Кремля, закладки от ФСБ, следы масонов и рептилоидов. Само название Purple в апогее наркотического прихода отдельные индивидуумы сводили к флагу Российской Федерации: смешение красного, синего и белого цветов дает тот самый фиолетовый. Однако orignal, ведущий разработчик i2pd, пояснил, что название PurpleI2P не содержит великой тайны: название было придумано после кружки английского эля с оглядкой на королевскую корону Британской империи. Наверное, это можно считать отсылкой к лидерству i2pd перед изначальным клиентом на Java.

Ориньяль по сей день продолжает публиковать русскоязычные статьи про I2P, рассказывая широким массам о развитии протокола. В команде программистов-энтузиастов появляются новые никнеймы, другие наоборот уходят в перманентный оффлайн. В основном планирование разработки происходит в IRC, в сети ILITA. Русскоязычное сообщество достаточно активно и в IRC на самом деле обсуждается все: от новых фич в I2Pd до климата в Африке и новых мемов.

Каждая версия роутера сменяется следующей, сообщество живет, разработчики постоянно что-то кодят. Чтобы не возникало вопросов что же меняется, если и так все работает хорошо, вкратце скажем о развитии протокола: мало ли параноики решат, что протокол не меняется, а оттачивается только бэкдор от силовых структур. В начале пути, ветки джава-роутера и роутера на C++ развивались не синхронно, согласование нюансов с соседним лагерем происходило с некоторой задержкой. Сейчас разработчики, не смотря на расхождения во взглядах, вместе реализуют значимые решения. Самое заметное изменение за последние годы: переход с транспортного протокола NTCP на NTCP2. Этот протокол является адаптированным крипто-аналогом привычного TCP и используется повсеместно: начиная открытием веб-страницы и заканчивая загрузкой торрента. Главное различие двух протоколов заключается в использовании алгоритма шифрования: в старом NTCP используется Диффи-Хеллман, очень медленный и жадный до системных ресурсов, а в NTCP2 алгоритм на основе эллиптических кривых тренд в сфере скоростных криптосистем, превосходящий по криптостойкости и производительности своего предшественника. Это изменение сделало I2P-роутеры более легковесными и полностью пригодными для использования на малых устройствах вроде одноплатных компьютеров и смартфонов (по крайней мере i2pd точно). Замена алгоритма согласования ключей Диффи-Хеллмана новыми решениями происходит и в других частях протокола. Для зрителей, понимающих в криптографии, особо заметим, что сеть I2P постепенно переходит на криптографические протоколы семейства Noise, что тоже является хорошим решением для производительности, анонимности и надежности. I2P-роутеры, как и все программы на свете, подвержены недочетам вроде багов и неполноценной реализации каких-то функций, что влечет дальнейшее развитие, исправление, и новые релизы. Если интересны детали, более подробную информацию можно найти через поисковик и в чатах сообщества.

Почему стоит использовать i2pd на C++ вместо роутера на Джаве? Ответ прост: потому что i2pd архитектурно превосходит поделие на Джаве. I2P кладезь различной криптографии, реализация которой на Джаве была бы жутко тормозной. Потому в Джава-роутере используются библиотеки, написанные на языке С. И все бы ничего, но каждый вызов этих библиотек это большие накладные расходы. И как бы разработчики не старались, а тормоза есть. Не такие большие, как могли бы быть, но до скорости нативной (т.е. встроенной) криптографии из i2pd им очень далеко. Также весь трафик джава-роутера локально проходит через фактически лишний протокол I2CP, что, не вникая в детали, сильно портит качество работы, в то время как в i2pd этот протокол существует исключительно для совместимости с приложениями на джава-роутерах. Для пытливых умов можно сказать более подробно: главная проблема I2CP в том, что через него сессии TCP (которые называются стримами) не могут контролировать доступ к туннелям и лизсетам. Также I2CP лишает пользователей джава-роутера нормальной поддержки UDP-туннелей: их поддержка обеспечивается отдельным приложением streamr. Как уже знает бывалый зритель, протокол UDP используется для быстрой потоковой передачи данных, например, голос собеседника при онлайн-звонке. Сложно переоценить качественную поддержку этого протокола. В I2Pd UDP-туннели поддерживаются без каких-либо проблем и дополнительных программных наслоений.

Помимо более быстрой работы i2pd, этот роутер также потребляет меньше системных ресурсов в сравнении с джаво-версией, т.к. программа на C++ напрямую взаимодействует с системой, в отличие от Джавы, где все крутится внутри виртуальной машины дополнительной прослойке между операционной системой и программным обеспечением. Дальше только больше: исследуя просторы внутрисетевых площадок, вы не однократно наткнетесь на описание различнейшних проблем с производительностью сети I2P, где источником проблем будет не протокол, а его кривая реализация в популярном клиенте. В рамках тестов со скоростными серверами и сетью, полностью исключающей наличие джава-роутеров, удалось достичь скорости чуть меньше мегабита в секунду. Сегодня такой показатель на фоне средних нескольких десятков килобит кажется невероятным! В видео, по тексту которого составлена эта статья, приведен скриншот недавней переписки двух ведущих разработчиков: orignal и zzz. В то время, как через i2pd в тестовом режиме гоняют видеостримы, джава-роутер не позволяет слушать даже онлайн-радио. Чтобы увеличить среднюю скорость сети I2P нужно: во-первых, каждому держать свой узел включенным максимально доступное время, во-вторых, это должен быть узел сети, работающий на i2pd.

Сравнение с другими сетями

Если вы имеете представление о сети Tor и о меш-сетях вроде Yggdrasil Network, после всего сказанного об I2P, не имеет большого смысла говорить, чем они различаются. Это абсолютно разные концепции. Однако для начинающих читателей приведем несколько основных пунктов.

Начнем с Tor: Во-первых, он сильно привязан к корневым серверам конторы, к которым осуществляется стартовое обращение для построения рисунка сети. В I2P это явно указанные в коде ресиды, которые можно сменить на свои, либо просто использовать уже готовые адресные книги, отталкиваясь от которых роутер продолжит работу, вовсе минуя стартовые узлы. Во-вторых, по мнению компетентных пользователей, Tor изначально и до сих пор принадлежит АНБ, поэтому относительно него не стоит строить иллюзий. В-третьих, Тor имеет более простую архитектуру туннелей и меньше возможностей их конфигурации. В-четвертых, Тор изначально предполагает проксирование в обычный интернет, а в I2P это возможно только при дополнительной конфигурации соответствующих узлов и туннелей к ним. Этот пункт по настроению можно отнести к минусам I2P, но мы не согласимся.

Про Yggdrasil и аналогичные меш-сети: подобные разработки ориентируются на легкость развертки, скорость передачи данных и самоорганизацию. Трафик внутри Yggdrasil искусственно не путается, сеть имеет простой и интуитивно понятный рисунок. Пользователи имеют устойчивые двунаправленные зашифрованные туннели, и чем короче тем лучше. Как видно, у I2P с Тором совсем мало общего, а с распространенными меш-сетями и того меньше. Разве что I2P может свободно работать через Yggdrasil (поддержка в i2pd с версии 2.36.0). Через Тор тоже, кстати говоря. На этом, пожалуй, все.

Послесловие

Последнее по теме I2P и скрытых сетей в целом: этично ли это? Устоявшееся общественное мнение таково, что любые попытки анонимизации расцениваются, как преступный умысел. Например, в скрытых сетях люди могут размещать то, что будет заблокировано в цензурируемой сети. Это конечно бесит цензоров. Не умолчим и про криминал, который может найти себе пристанище в I2P, все это очевидно. Но что об этом думают разработчики I2P, у которых также могут быть семьи, дети и тяга к справедливости, и как считает большинство криптоанархистов? Если кратко: кухонным ножом можно нарезать хлеб, а можно причинить вред, но из-за возможного злоупотребления кухонные ножи не запрещают. Так же и тут: нельзя бороться с технологиями приватности под предлогом борьбы с преступностью, так как самое распространенное преступление сегодня это нарушение гражданских прав и свобод: тотальный контроль и продажа личных данных.

Если вас до сих пор увлекал нетсталкинг, т.е. романтическое исследование содержимого скрытых сетей, призываем идти дальше изучать механику работы этих сетей и содействовать их развитию. Даркнет (или дипвеб) по своей сути это не что-то экзотическое; это современный набор необходимых инструментов для свободного распространения информации и личного общения людей без искусственных преград.

Текст статьи и иллюстрации являются адаптированными исходниками видео про I2P: на русском и английском. Материал в формате PDF размещен на i2pd.website. Оригинальная статья опубликована в блоге дата-центра ITSOFT на Хабре.

История сети I2P берет свое начало в 2003 году, в связи с чем обросла слухами, домыслами и статьями об уязвимостях, часть из которых уже неактуальна. Перед началом основного повествования обозначим решенные проблемы, упоминание которых вы можете встретить до сих пор. Пусть они вас не смущают.

Распространенные заблуждения

Байка номер один: I2P плохо масштабируется и при большом приросте узлов сеть будет парализована, т.к. справочные узлы - флудфилы - не справятся с потоком информации. Дескать I2P работает только пока не популярна, а стоит общей нагрузке вырасти - сеть ляжет.

На самом деле количество флудфилов растет вместе с сетью, а для обращения к определенному скрытому сервису все флудфилы вовсе не требуются. Каждый скрытый сервис публикует свой полный адрес (называемый лизсетом) на двух флудфилах, ближайших по DHT. В свою очередь координаты DHT меняются каждые сутки практически случайным образом.
При получении публикуемого лизсета, каждый из двух флудфилов дублирует информацию трем другим флудфилам, являющимся наиболее близкими в логическом смысле. Итого лизсет публикуется не менее, чем на четырех практически случайных роутерах, к которым и происходит обращение при поиске адреса конкретного сайта или другого скрытого ресурса. Короче говоря: сеть является распределенной и ресурсы для обработки лизсетов растут вместе с общим количеством узлов. Со времен зарождения байки о плохой масштабируемости I2P, сеть многократно выросла и до сих пор остается функциональной без каких-либо намеков на перегрузку флудфилов. Также стоит добавить, что осуществляется переход на новое шифрование, призванное снизить нагрузку на флудфилы.

Байка номер два: роутер, на котором располагается конкретный скрытый сервис, можно определить по ключу шифрования роутера в лизсете скрытого ресурса. Модель строится на том, что луковичное шифрование, используемое в туннелях, не является достаточным, и в первую очередь к сообщению применяется сквозное шифрование ключом роутера, который должен расшифровать сообщение и передать его локальной конечной точке.

Подразумевается, что ключи у скрытых сервисов уникальные, а у роутера - один единственный и, имея идентификатор этого ключа, можно отслеживать другие туннели пользователя. На самом деле эта угроза была ликвидирована на ранних стадиях разработки I2P. Современный лизсет содержит ключ шифрования, никак не связанный с роутером. Для каждого скрытого сервиса используется уникальный ключ, поэтому сопоставление ключей от лизсетов различных скрытых сервисов одного администратора не дает почвы для предположений, что они находятся на одном роутере.

Байка номер три: туннели I2P можно перехватить. Под перехватом подразумевается не дешифровка трафика, а выявление хозяина туннеля. Для атаки требуется максимально возможное количество роутеров с хорошим аптаймом для постоянного их участия в транзитных туннелях. Суть атаки заключается в ожидании момента, когда туннель жертвы будет в большей части (или целиком) состоять из злонамеренных роутеров. Транзитные узлы ничего не знают об общем количестве роутеров в цепочке, однако длина туннелей по умолчанию составляет три хопа. Если допустить, что три роутера подконтрольных злоумышленнику сообщаются между собой в рамках одного туннеля, он может с большой вероятностью предположить, что конечное звено известной цепочки является хозяином туннеля.

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

Ресид

Самым простым способом борьбы с I2P является блокировка ресид-серверов, к одному из которых происходит обращение за начальным рисунком сети при первом запуске роутера. Ресид представляет из себя архив с некоторым количеством файлов routerInfo, по сути - пакет с информацией о случайных роутерах, через которые строятся первые пользовательские туннели и начинается автоматическое расширение локальной базы сети. Все ресид-серверы держат энтузиасты, а сами адреса ресидов имеются в общем доступе. Обращение к ним происходит по доменным именам и на известные IP-адреса, поэтому собрать всё в список и централизованно заблокировать - задача не из сложных. Однако, затруднить первый запуск вовсе не означает заблокировать работу сети I2P! На случай блокировки поддерживается использование прокси при обращении к ресиду, что с легкостью позволяет обойти ограничения локального провайдера. Помимо этого любой роутер может быть запущен с уже имеющейся базой сети, например, взятой с другого I2P-роутера. Новым шагом в борьбе с возможной блокировкой является использование дополнительных зашифрованных каналов связи. В настоящее время таким инструментом является Yggdrasil Network, который служит не только для обращения к ресиду, но и для полноценного использования сети I2P. Для стороннего наблюдателя активность Yggdrasil сравнима с подключением через VPN. На момент выхода статьи работа I2P через Yggdrsail и прокси реализованы только в i2pd, что является дополнительным аргументом против морально устаревшего роутера на Java.

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

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

Атака Сивиллы и Затмение

Атака Сивиллы (Sybil) и атака Затмение (Eclipse) имеют схожую реализацию. Их смысл заключается в наводнении сети узлами, подконтрольными злоумышленнику, которые будут работать ради одной цели: держать пользователя в песочнице. Изолирующие роутеры не сообщают информацию об обычных узлах, чтобы пользователь не вышел из блокады. Это позволяет мониторить список ресурсов, которые атакуемый пользователь размещает на своем роутере, а также список тех, которые он посещает. Чтобы получить информацию о входных туннелях скрытого ресурса, необходимо получить его лизсет от ближайшего флудфила, равно также как опубликовать лизсет своего ресурса, чтобы его могли найти.

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

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

Атака Сивиллы, нацеленная на мониторинг сети в общем, кажется более подходящей для только что описанной модели со злонамеренным ресидом. Но при подробном рассмотрении окажется, что профит фальшивого ресида не окупит средства, затраченные на его организацию. Во-первых, необходимо иметь большие мощности, чтобы ввести в сеть максимально возможное количество подконтрольных узлов. Во-вторвых, нужно разработать программное обеспечение, которое будет гибко объединять в одну базу данных информацию, собираемую с подконтрольных узлов. В-третьих, атака, направленная на анализ, подразумевает большую длительность, которой не получится, т.к. злонамеренный ресид будет скоро выявлен сообществом. Самый очевидный признак такой атаки - не увеличивающееся, или слишком малое количество известных роутеров, которое отображается в веб-консоли. В параноидальном случае следует удалить всю локальную базу роутера, которая хранится в папке netDb и перезапустить роутер, что спровоцирует новое обращение к случайному ресиду. Если у вас достаточно оснований полагать, что какой-то ресид скомпрометирован, обязательно сообщите об этом сообществу разработчиков. На момент выхода статьи не было зарегистрировано ни одной попытки подобной атаки.

Java router destination attack

Последняя модель атаки весьма сложная, но критически опасная в случае успешного исполнения. Проблема обнародована ведущим разработчиком I2Pd и в роутере на C++ отсутствует, однако в Java-роутере долгое время не исправляется. Модель позволяет определить факт нахождения двух и более конечных точек на одном роутере, т.е. фактически определить, что несколько анонимных сущностей физически расположены на одном компьютере. Возможность атаки заключается в том, что все лизсеты в Java-роутере хранятся в одном месте.

В рамках атаки осуществляется полноценное обращение к некоторой конечной точке (в англоязычной терминологии - destination), которая отвечает и сохраняет лизсет атакующего. Затем происходит обращение к другой конечной точке, однако лизсет для ответа не сообщается, и ответа по логике быть не должно. Если ответ приходит, атакующий с уверенностью заключает, что ответившая конечная точка, которой не был отправлен лизсет для ответа, находится на том же роутере, где и первый ресурс, которому был дан лизсет.

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

При детальном рассмотрении часто упоминаемых угроз оказалось, что уязвимостей в I2P гораздо меньше, чем об этом любят говорить псевдо-эксперты. Поддерживайте свободные проекты, сообщайте о багах и недочетах. Свободное ПО - это когда без финансирования и чаще всего без рекламы, но на совесть. Не забывайте, что СМС при регистрации - это не норма!

Материал составлен по тексту и иллюстрациям из видео. Оригинальная статья размещена в блоге дата-центра ITSOFT.

Тоталитаризм и диктатура имели место в любой исторический промежуток, о котором знает современная наука. Однако человек склонен к вольномыслию и недовольству всем, что этому препятствует. В наше время обе стороны вопроса по-прежнему актуальны: одни неустанно пытаются запрещать и карать за неугодные высказывания, другие эти высказывания постоянно генерируют.

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

Обольщение Луковичной сети

Самым популярным инструментом анонимности в сети является Tor. Для пользователя, далекого от темы сетей и процесса создания ПО в целом, Tor является ящиком Пандоры и священным Граалем анонимности. Такое мнение внушают многие источники, в том числе сам проект Tor, поддерживаемый главным образом не добровольными донатами, а Министерством обороны и Государственным департаментом США. Надо заметить, что Tor изначально является разработкой силовых ведомств этой страны (с 1995 года). Только в 2006 году для развития сети была создана некоммерческая организация Tor Project, которая по сей день является обложкой Tor-браузера, столь любимого юными искателями анонимности.

У проницательного читателя на этом месте может возникнуть легкий когнитивный диссонанс: Соединенные Штаты Америки, знаменитые по всему миру скандалами о тотальной слежке за населением планеты, разработали и отдали в общее пользование инструмент свободы слова!

К чести всех почитателей надо сказать, что Tor является проектом с открытым исходным кодом, что позволяет программистам по всему миру проверить качество программы и выявить возможные слабые места. Также в 2011 году Tor удостоился премии общественной значимости Фонда свободного программного обеспечения, а в 2012 году награды EFF Pioneer Award.

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

Tor имеет несколько задокументированных случаев сбоя работы. В основном такие новости связаны с атаками извне, а не архитектурными недочетами самого проекта. Большинство инцидентов гуглятся с большим трудом, либо вовсе отсутствуют в поисковой выдаче. Конечно возможная причина кроется в том, что сеть настолько никому не интересна, что о ней не утруждаются писать (вряд ли).

Последним крупным инцидентом с сетью Tor, который был непосредственно связан с уязвимой архитектурой сети, было отключение более половины консенсусных узлов в январе 2021 года, что удивительным образом совпало с беспорядками в Америке. В следствии атаки все внутрисетевые домены .onion v3 были недоступны в течение нескольких часов, т.е. получить доступ к анонимным ресурсам сети было невозможно.

Приведенной информации достаточно, чтобы предположить, что Tor является инструментом свободы слова не вообще, а где-то там, но, когда это где-то там начинается в США, правительство которой держит скрытую сеть под своим крылом, сеть может прекратить выполнять свои функции. Также в интернете можно найти мнение, согласно которому Tor в начале 2000-ых годов был выпущен в общий доступ с основным прицелом на Китай, который сохранял свой социалистический уклон в политике даже после распада СССР некогда главного идеологического врага Штатов.

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

Ситуацию спасет инкогнито

Вторым среди инструментов анонимности является сеть I2P. Меньшая известность обуславливается более высоким порогом вхождения для новичка, а также отсутствием рекламы, спонсированной правительством какой-либо страны. Существуют два независимых клиента сети: Java router и i2pd.

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

Вопросы вызывают решения, принимаемые при разработке Java-роутера, которые упираются в нелогичность и намеренное игнорирование выявленных уязвимостей. Для справки: Java-роутер это популярный клиент сети, разрабатываемый с начала 2000-ых годов (альтернативный роутер i2pd берет начало в 2013 году).

Разработку популярного клиента на протяжении более, чем десяти лет, курирует один человек с никнеймом zzz. Под его контролем находится самый авторитетный ресурс stats.i2p: каталог скрытых сайтов и (бесплатный) регистратор коротких доменных имен в зоне .i2p. В адрес stats.i2p неоднократно высказывались претензии из-за цензуры. Цензура на основном ресурсе анонимной не цензурируемой сети?! Когда в мире пошла волна #BlackLivesMatter, zzz начал еще более агрессивно игнорировать новые и удалять старые ресурсы с правой тематикой. В конечном счете споров сообществом был создан независимый регистратор reg.i2p.

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

Завесу загадочного поведения zzz, несоответствующее духу I2P, приоткрывает факт его публичности. Его личность гуглится не первой строкой поисковой выдачи, но весьма просто: он принимает личное участие на встречах, посвященных разработке.

Чтобы не увеличивать конспирологический градус статьи, не буду приводить предположения о характере взаимодействия zzz с правоохранителями. Чуткий читатель может сам представить уровень ответственности, которую общественность хочет взвалить на плечи человека, трудящегося над инструментом анонимности. В дело пойдет все: криминал, насилие, извращенцы и тому подобное. Лишь единицы трезво скажут, что подобный инструментарий используется в криминальных целях в меньшинстве случаев, однако позволяет пользователям делиться мнением на любые темы без оглядки на Большого брата.

Разработчик i2pd под никнеймом original в отличие от своего коллеги zzz остается скрытной личностью, и, по его словам, не намерен менять такое положение дел. Он открыт для критики и предложений, активно трудится над альтернативным I2P-роутером и смеется над цензурой. В большей степени он является идейным вдохновителем этого материала и примером для разработчиков схожих проектов: Если кому-то нужен хайп личности, или хоть какая-то медийность, ему не место в разработке средств коммуникации, которые являются уравновешивающей силой против деспотии политических режимов. В свою очередь никакой режим не может предоставить чистое средство борьбы, не предусмотрев собственную защищенность от него.

Оригинальная статья размещена в блоге дата-центра ITSOFT

Подробное изучение i2pd достойно уважения. Эта статья близка по духу навыкам администрирования роутера, но посвящена несколько другой, но важной теме: набору инструментов, который включает в себя ряд полезных утилит. i2pd-tools, дамы и господа!

1. keygen генерация ключей

2. vain генерация ключей по шаблону (майнер красивых адресов)

3. keyinfo информация о ключах

4. b33address получение адреса для зашифрованного лизсета

5. regaddr регистрация короткого домена в зоне .i2p

6. regaddr_3ld регистрация домена третьего уровня в зоне .i2p

7. regaddralias привязка короткого домена к новым ключам

8. offlinekeys использование временных ключей в целях безопасности

9. routerinfo информация о роутере

10. x25519 генерация ключей шифрования

11. i2pbase64 кодирование информации в base64 и ее декодирование

Компиляция утилит

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

Начнем со сборки бинарных файлов: для начала скачайте репозиторий к себе на устройство. Команда клонирования на всех операционных системах выглядит одинаково: git clone --recursive https://github.com/purplei2p/i2pd-tools. Чтобы установить зависимости, необходимо запустить скрипт dependencies.sh. Предполагается, что компилятор C++ и программа сборки make уже имеются, поэтому под зависимостями понимаются исключительно библиотеки boost и openssl.

Если вы только начинаете путь на поприще со сборкой программ из исходных кодов, поставьте git, компилятор g++ и систему сборки make командой вроде этой: sudo apt install git g++ make. Для пользователей Windows все немного сложнее требуется установить оболочку MSYS2, а затем из нее выполнить команду: pacman -S git make mingw-w64-x86_64-gcc. Скрипт для установки зависимостей также запускается в MSYS2 (если скрипт не хочет запускаться, нужно сделать его исполняемым простой командой chmod +x dependencies.sh). Когда все готово, запускаем сборку командой make.

Хорошая новость: с недавних пор для Windows публикуются готовые бинарные файлы, поэтому, если ручная сборка кажется неприподъемной задачей, воспользуйтесь ими.

keygen

При указании несуществующих ключей в конфигурационном файле туннелей, автоматически создаются новые. В большинстве случаев это удобно. Однако, если требуется заранее знать адрес, либо произвести какие-то дополнительные манипуляции с ключом, следует воспользоваться утилитой keygen. Использование крайне простое: запускаем keygen с указанием желаемого имени для новых ключей. По умолчанию используется актуальный тип подписи EDDSA-SHA512-ED25519 (кодовое обозначение 7), который также является типом по умолчанию при создании ключей самим I2P-роутером. Если требуется получить ключ с другим типом подписи, его следует указать при запуске после имени файла. Можно указать как имя типа, так и его номер. Обозначения приведены в файле README.

vain

Крайне редко можно увидеть хоть сколько-то читаемый адрес в выдаче keygen (потому что это просто хеш). Для адресов с человекочитаемым началом существует отдельная утилита vain (vanitygen). Говорящее название (vanity тщеславие) намекает на основное применение майнера адресов. Конечно помимо тщеславия адрес с запоминающимся началом имеет и практический профит: его проще распознать на глаз.

При запуске без параметров видим информацию об использовании. Поиск по строковому паттерну всегда осуществляется с начала адреса. Если нужен более гибкий поиск, или не с начала строки, стоит воспользоваться регулярными выражениями. Учтите, что поиск по регулярному выражению медленнее, чем по обычному строковому значению. Количество потоков по умолчанию совпадает с количеством ядер компьютера, но может быть вручную задано через параметр -t (--threads).

Шаблоны до 6 символов находятся почти моментально, но с увеличением строки поиска время растет экспоненциально. Небольшая табличка с примерным временем нахождения приведена в файле README. На момент выхода статьи vain поддерживает только ключи с типом подписи EDDSA-SHA512-ED25519 (7), используемый в сети по умолчанию.

keyinfo

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

Возможные параметры: -v от verbose, подробный вывод; -d от destination, вывод только полного адреса в кодировке base64, -b от b33 (bb32), вывод адреса для зашифрованного лизсета (подробно о зашифрованных лизсетах читайте в статье).

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

Обратите внимание на поле Destination Hash. Это ежедневно изменяемое значение, по которому конечная точка выбирает место для публикации информации о себе, а клиент определяет флудфил, к которому нужно за этим адресом обратиться. Подробнее о том, как хеш хранения адреса меняется каждый день и почему это критически важно с точки зрения безопасности, читайте в более ранней статье.

b33address

keyinfo с флагом -b высчитывает адрес для конечной точки с зашифрованным лизсетом. b33address делает то же самое, но принимает не файл с ключами, а полный адрес в кодировке base64. Для использования зашифрованных лизсетов (которые называются b33 или bb32, что одно и то же), рекомендуется использовать тип подписи 11. Утилита b33address работает только с ним.

На скриншоте генерируется ключ, затем его адрес bb32 запрашивается через keyinfo. Чтобы получить полный адрес, снова используется keyinfo. Вывод keyinfo был скопирован, а затем передан в b33address. Утилита сообщила адрес, который будет использован при зашифрованном лизсете, а также вывела сегодняшний хеш хранения. Как видно, значения совпадают с теми, которые предоставила утилита keyinfo, т.е. функционал b33address аналогичен keyinfo -b, но отличается форматом принимаемого значения.

regaddr

Для регистрации коротких человекочитаемых доменов вроде site.i2p необходимо посетить регистраторы reg.i2p и stats.i2p (первый от русскоязычного сообщества PurpleI2P, второй от англоязычной команды Java-роутера).

Оба регистратора работают по схожему принципу: вы предоставляете свой полный адрес, к которому будет привязан желаемый домен, а также криптографическую подпись заявленного желания. Подпись проверяется ключом из полного адреса. Такая заявка имеет стандартный вид и генерируется утилитой regaddr (с версии 2.37.0 i2pd поддерживает генерацию регистрационной строки через веб-консоль). Синтаксис утилиты простой: сначала файл с ключами, затем желаемый домен.

Работа утилиты regaddr проста, как и синтаксис регистрационной строки: сначала идет желаемый домен, затем полный адрес, к которому он будет привязан, а в конце строки подпись желаемого домена. Синим цветом на скриншоте выделен полный адрес. Для наглядности полный адрес также получен утилитой keyinfo с флагом -d. Красным цветом выделена подпись.

Получая подобную строку, регистратор проверяет валидность подписи и, если заявленный домен свободен, регистрирует его. Для примера можно воспользоваться утилитой verifyhost, которую использует reg.i2p. При использовании в bash необходимо экранировать восклицательный знак, чтобы он был интерпретирован как часть строки, и передан в утилиту (либо заключить всё выражение в ковычки).

Подпись верна, поэтому verifyhost не выдал ошибок и вернул значение, равное нулю.

regaddr_3ld

В I2P поддерживаются человекочитаемые домены третьего уровня. Их регистрация происходит аналогичным образом, но строка генерируется чуть сложнее в три шага. Генерация регистрационной строки для домена третьего уровня невозможна через веб-консоль и реализуется исключительно через утилиту regaddr_3ld.

Сначала ключом субдомена подписывается желаемый домен третьего уровня:

./regaddr_3ld step1 sub_domain.dat sub.domain.i2p > step1.txt

Затем ключом основного домена подписывается строка субдомена:

./regaddr_3ld step2 step1.txt domain.dat domain.i2p > step2.txt

В завершение подписанная ключом основного домена заявка на домен третьего уровня подписывается ключом домена третьего уровня:

./regaddr_3ld step3 step2.txt sub_domain.dat > step3.txt

В приведенном примере регистрационная строка находится в файле step3.txt.

regaddralias

Для смены ключей, к которым привязан короткий домен, воспользуйтесь утилитой regaddralias. Для реализации возможности необходимо, чтобы у вас на руках были старые ключи (а не только новые). В программу передается имя файла с новыми ключами, файл со старыми ключами и сам домен последним параметром.

На скриншоте выделены ключевые слова алиаса перепривязки домена к новым ключам: задается новый полный адрес с указанием прежнего полного адреса и ко всему этому прикладываются подписи.

offlinekeys

I2P имеет концепцию оффлайн-ключей (offline keys), которая позволяет хранить постоянные ключи в надежном месте. Другими словами, основной ключ хранится в безопасном месте, а на сервере используется временный, срок действия которого истекает через заданное количество дней. В случае его компрометации, спустя заданный срок действия, вы с полной уверенностью можете утверждать, что ваш сетевой адрес снова принадлежит только вам. Оффлайн-ключи подробно разобраны в отдельной статье.

На скриншоте красным цветом выделен основной ключ и его адрес, а синим временный ключ, который имеет пометку Offline signature и тот же адрес.

routerinfo

I2P-роутер складывает информацию об известных роутерах в директорию netDb. Затем эти роутеры используются при построении транзитных туннелей. Файл, являющийся идентификатором роутера, называется RouterInfo (RI). В него включается информация о криптографических ключах и IP-адрес (если он публикуется и является доступным извне).

Флаг -p отображает порт (по умолчанию выводится только IP-адрес). Флаг -f выводит правило для файервола iptables для разрешения исходящего подключения к конкретному I2P-роутеру (для параноидальных случаев, когда все исходящие соединения запрещены). Параметр -6 добавляет в выдачу IPv6 адрес, если он присутствует.

x25519

Утилита для генерации пары ключей шифрования x25519, выводящая результат в кодировке base64. На момент выхода статьи используется в зашифрованных лизсетах с авторизацией.

i2pbase64

Почти в каждом пункте этой статьи упоминалась какая-либо информация, которая по умолчанию является бинарной (двоичным, нечитаемым машинным кодом). Например, криптографические ключи и хеши. Чтобы двоичную информацию было проще воспринимать человеку, а также легко передавать в текстовом виде, в I2P почти повсеместно используется кодировка base64. Алфавит base64 в I2P отличается от общего стандарта на два символа: + заменяется на -, а / на ~. Это связано с использованием base64-строк в веб-браузере, где + и / являются специальными символами: человекочитаемые короткие домены записываются в локальную базу роутера через браузер посредством открытия специальных ссылок (addresshelper).

На скриншоте приведен пример кодирования текстовой информации, а затем ее раскодирование обратно в текст. Утилита аналогичным образом работает с любыми бинарными файлами вроде изображений или видео. Прямое практическое назначение у i2pbase64 в i2pd-tools отсутствует. Это сугубо специфичная утилита для экзотических задач, например, ручного кодирования сторонних ключей.

Утилита famtool не была освещена в статье по простой причине: family дополнительный опознавательный признак роутера. В концепции, в которую поверили лишь единицы, в том числе zzz (ведущий разработчик Java-роутера), family указывается добропорядочными пользователями для того, чтобы роутеры одного админа не появились вместе в одном туннеле. Как не трудно понять, эта опция никем и никогда не используется, а злонамеренными людьми, которые хотят захватывать как можно больше туннелей для попытки мониторинга сети, family не используется тем более. При практической бессмысленности, инструмент famtool не тривиален в использовании, поэтому в рамках этого материала упущен.

Оригинальная статья опубликована в блоге дата-центра ITSOFT.

Сталкиваясь с потребностью в скрытом сервисе I2P, большинство вынуждено пользоваться услугами хостинг-провайдеров. Например, потому что нет возможности обеспечить хороший аптайм ресурса на домашнем компьютере. Использование услуг дата-центра подразумевает доверие: мы надеемся, что персонал не будет злоупотреблять своим положением и кто-то не попытается украсть данные с дисков.

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

Образование внутрисетевого адреса I2P

Создавая серверный туннель, который выводит локальный сервис в скрытую сеть, необходимо указать файл с ключами (если указывается несуществующий создается новый файл со случайными ключами).

Файл с ключами содержит криптографические идентификаторы. Всего 391 байт публичной информации и секретные ключи, которые не публикуются. Хеш от блока публичной информации, содержащейся в файле с ключами, образует внутрисетевой адрес.

К полному адресу (391 байт публичной информации) осуществляется привязка как длинных адресов .b32.i2p, так и коротких доменных имен в зоне .i2p, поэтому заданный файл с ключами является критически важным: потеряв его, мы теряем и контроль над адресом. Если злоумышленник развернет с нашим ключом другой серверный туннель, работа изначального скрытого сервиса будет в лучшем случае нарушена, а в худшем злоумышленник сможет выдавать свой ресурс за оригинальный для части пользователей, чей роутер найдет его лизсет первым.

Лизсеты

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

Безопасное хранение ключей

I2P имеет концепцию оффлайн-ключей (offline keys), которая позволяет хранить постоянные ключи в надежном месте. Другими словами, основной ключ хранится в безопасном месте, а на сервере используется временный, срок действия которого истекает через заданное количество дней. В случае его компрометации, спустя заданный срок действия, вы с полной уверенностью можете утверждать, что ваш сетевой адрес снова принадлежит только вам.

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

Инструмент для создания временных ключей присутствует в наборе i2pd-tools. Утилита называется offlinekeys и имеет следующий порядок принимаемых параметров: <output file> <keys file> <signature type> <days>. Последние два параметра можно опустить, указав только выходной файл и существующие ключи.

Без явного указания типа подписи, по умолчанию используется ED25519-SHA512 (кодовое обозначение 7), а срок годности равен 365 дням, то есть году. Тип подписи можно указать как в кодовом варианте, так и словом.

После того, как файл с временными ключами создан, его можно выгрузить на сервер и использовать в привычном виде. Главное не забыть обновить ключи вовремя. Также можно написать скрипт, автоматизирующий процесс обновления ключей на удаленном сервере.

Оригинальная статья опубликована в блоге дата-центра ITSOFT.

Принцип анонимности I2P заключается в неизвестном месторасположении скрытого сервиса. Каждый скрытый сервис (например, сайт или пользователь, который его посещает) взаимодействует с другими ресурсами исключительно через анонимизирующие туннели. Туннели строятся через роутеры участников сети также, как другие пользователи строят туннели через наш роутер. Такая модель создает множество прямых соединений между I2P-роутерами, в которых нельзя определить на каком роутере начался или закончился тот или иной туннель: тысячи одновременных зашифрованных подключений не дают такой возможности.

Чтобы связаться с любым скрытым сервисом, необходимо получить его лизсет (LeaseSet), который содержит информацию о входных туннелях и криптографических ключах. Для этого все серверные конечные точки, ожидающие подключение, публикуют свои лизсеты на флудфилах (Floodfill) роутерах, выступающих в роли справочной книги или доски объявлений. Несмотря на то, что флудфил получает лишь информацию о первых узлах входных туннелей и криптографические ключи, т.е. никакой компрометирующей информации в лизсете нет, архитектура I2P предусматривает использование зашифрованных лизсетов. Это позволяет скрыть наличие конечной точки (она же скрытый сервис и destination) от возможного мониторинга на флудфилах.

Идентификатор незашифрованного лизсета обычный внутрисетевой адрес скрытого ресурса, только без окончания .b32.i2p. Это позволяет держателям флудфилов видеть в открытом виде адреса ресурсов, которые у них опубликовались. Если вы подняли в I2P личный ресурс и не хотите, чтобы о нем случайно узнал кто-то еще, зашифрованный лизсет специально для вас!

Сокрытие идентификатора лизсета в англоязычной терминологии называется blinding (ослепление). Отсюда происходит название адреса скрытого сервиса с зашифрованным лизсетом bb32 blinded-b32. В свою очередь b32 во всех доменах сети является сокращением от названия кодировки base32, которой кодируется информация, образующая домен.

Идентификатор лизсета типа bb32 (который видит флудфил) не соотносится с адресом, поэтому не может сообщить владельцу флудфила фактическое имя опубликованного у него ресурса. Также к адресу типа bb32 нельзя привязать короткий домен в зоне i2p. Единственный способ обратиться к подобному скрытому сервису иметь полную строку его адреса. Получая на вход bb32-адрес, I2P-роутер запрашивает у флудфила соответствующий зашифрованный лизсет, а затем расшифровывает его содержимое, используя дополнительную информацию, закодированную в домене.

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

Ознакомиться с криптографическими подробностями блиндинга, т.е. сокрытием идентификатора лизсета, а также с шифрованием его содержимого, можно в официальном документе. Согласно приведенной документации в зашифрованном лизсете поддерживается два типа подписи: EDDSA_SHA512_ED25519 (тип 7) и REDDSA_SHA512_ED25519 (тип 11), однако настоятельно рекомендуется использовать только второй из приведенных. В случае i2pd нерекомендуемый вариант вовсе не реализован, т.к. считается практически бессмысленным.

Это связано с тем, что, во-первых, тип подписи 11 алгоритмически является более оптимальным для использования в зашифрованном лизсете, во-вторых, тип подписи 7 применяется по умолчанию и допускает неумышленное использование уже существующего адреса в связке с зашифрованным лизсетом. Теоретически это является уязвимостью, т.к. позволяет флудфилу-злоумышленнику раскрыть очередной зашифрованный лизсет сервиса, который до этого с тем же ключом подписи использовал лизсет обычного типа. Это возможно из-за алгоритма вычисления блиндинга, который можно воспроизвести, заранее зная полный адрес конечной точки, включаемый в лизсет. Подразумевается, что пользователь, назначивший вручную тип подписи 11 наверняка сразу укажет и нужный ему тип лизсета, что предотвратит утечку.

Минимальная конфигурация туннеля конечной точки типа bb32 (которая иногда почему-то называется b33, что не имеет какой-либо логики) выглядит следующим образом (принципиальны последние две строки):

[SUPER-HIDDEN-SERVICE]type = serverhost = 127.0.0.1port = 8080inport = 80signaturetype = 11i2cp.leaseSetType = 5

Чуть раньше были упомянуты флаги, содержащиеся в первом байте адреса с зашифрованным лизсетом. Все, что нас интересует в контексте данной статьи, это флаг авторизации. Настраивается через дополнительный параметр конфигурации i2cp.leaseSetAuthType. Вкратце: это позволяет сделать доступ к приватному ресурсу еще более контролируемым, создавая список по ключам или парольным фразам для каждого пользователя, а в случае чего убрать конкретный идентификатор из списка, после чего соответствующий пользователь уже не получит лизсет, следовательно, и доступ к ресурсу. Подробнее об этом вы можете узнать из документации (параметры i2cp.leaseSetPrivKey, i2cp.leaseSetClient.dh.nnn, i2cp.leaseSetClient.psk.nnn).

Оригинальная статья опубликована в блоге дата-центра ITSOFT.

В прошлой статье я рассказал, какие выкрутасы можно сделать одним только браузером. Нам потребуются эти знания далее

Жаркий август 2020 показал, что базовые меры это слишком мало и неэффективно. Нужно что-то большее

Выбирая решение, я ставил перед собой несколько целей:

1. Решение должно быть открытым

2. Решение должно быть бесплатным только так оно может стать массовым

3. Решение должно быть децентрализованным не должно быть единой точки отказа

4. Бомж-VPN. Хотелось иметь возможность соединиться с любым узлом сети забесплатно

5. Бомж-хостинг. Следствие предыдущего пункта. Возможность выкатить тестовый ресурс забесплатно

VPN отвалился сразу: даже рабочий VPN умер. VPN требует централизованного внешнего сервера единая точка отказа. Наконец, VPN платный не назвал бы лично себя нищебродом, но это точно не массовый вариант

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

Я начал осваивать I2P. Идея мне показалась симпатичной. Особенно интересно, что сеть не просто выдержит резкий рост числа пользователей она от этого станет работать лишь надёжнее (но это не точно). На луркеочень вдохновляющее описание возможностей, а wikiспускает с небес на Землю и даёт понять, что I2P не серебряная пуля, и атаки по деанонимизации реальность. Сложно и дорого, но реально. Для сравнения, без I2P это как по паспорту представиться и приготовиться к обыску

Возможности, ограничения и болячки

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

I2P не ограничивает себя каким-то протоколом. Вместо этого сеть предоставляет среду передачи данных. Я пробрасывал через сеть I2P соединение с базой данных. Туннели I2P позволяют пробросить любой ресурс, таким образом сделав его доступным для использования любыми программами. Если кто-то не знаком с туннелями идея проста и состоит в том, чтобы для некоторого открытого порта на удалённом сервере открыть порт на своей машине, и в дальнейшем любой локальной программой подключаться к локальному порту, что точно умеет любая программа, а тонкостями переноса байтов на тот порт удалённой машины и обратно занимается уже туннелирующая программа (частный случай туннеля).

Следствия туннелей бомж-VPN и бомж-хостинг. Я счастлив я могу выкатить ресурс бесплатно. Я могу соединить 2 машины бесплатно. Любой другой участник сети может сделать всё то же самое бесплатно. Вкусно

Функционировать сеть сможет, даже если шаловливые ручки вновь потянутся к Большому Рубильнику белорусские реалии именно такие, онсуществует

Больным местом является изменение маршрутов (следовательно, dest hash). Но я надеюсь, что проблема решаема существует версия для Android, которая подразумевает переход между сетью оператора и разными точками доступа wifi, а в настройках роутера появился экспериментальный Laptop Mode

Ошибки и заблуждения

Я заметил несколько шаблонов заблуждений

Ой, мне по телевизору сказали, что в этом вашем i2p такое показывают! Это вообще законно?

Больше верьте слухам. Ничего там нет такого, чего нет в обычном интернете. I2P ставит своей целью среду передачи данных. Протоколы TCP и UDP, передают более чем 99% информации в интернете, включая незаконный контент. Давайте бороться с контентом, а не транспортом его доставки

Как интернет отключат обязательно установлю

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

Хорошо, я установил, запустил, что-то потыкал и выключил. Как только интернет выключат ух держите меня семеро! Включу I2P и всё у меня станет расчудесно!

Та же проблема. С высокой вероятностью, тебе не удастся найти вообще никого из тех, с кем ты ранее устанавливал соединение. Запусти I2P как службу пусть висит себе в фоне. Она есть не просит (ну кроме памяти). Только так ты встретишь час Ч в готовности

Я на минуточку. Туда и назад

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

Ну и совсем кошерная остановка службы I2P это в консоли роутера нажать кнопочку Shutdown / Выключить. Демон I2P остановися сам в худшем случае через 10 минут как только истекут уже установленные соединения с другими участниками сети i2p

Установка на desktop

Состоит из двух обязательных частей установки шлюза (inproxy) и настройки браузера (лайт или пожёстче выбираем сами на свой вкус). Важно выполнить оба этапа, по отдельности они не имеют смысла

Установка шлюза

Наоффициальном сайте проекта есть список загрузок можно взять оттуда

В этом же списке присутствует секция Пакеты для Debian/Ubuntu

После установки пытаемся открытьhttp://localhost:7657/ web-консоль роутера. Настоятельно рекомендую добавить страницу в закладки или даже закрепить (Pin Tab). Если страница открылась вы всё сделали правильно

Настройка браузера. Лайт

В данном случае мы исходим из предположения, что вы не делаете ничего плохого, и просто желаете получить доступ к информации, которая огорчила ваше правительство. А правительство, словно плаксивая девочка, склонно обижаться на любую информацию. Например, в России заблокирован linkedin. Жутко опасный и экстремистский ресурс, ага

В данном случае нас не пугают утечки информации. Например, сайт в сети i2p может запрашивать какой-нибудь jquery с CDN. Что такого в js-библиотеке, которую запрашивают миллионы, если не миллиарды раз в день?

Для настройки нам потребуется дополнениеSmartProxy. Настройка производится в 2 простых шага необходимо добавить входной шлюз I2P в список proxy-серверов и создать правило проксирования

Настройка браузера. Для любителей пожёстче

Паранойя может затребовать гарантий отсутствия утечек. Из наличия паранойи не следует, что мы кинемся смотреть упомянутый ранее сайт товарища майора Василия Мусорова. Настройка проводится в несколько простых шагов

У меня нет лишнего браузера в системе, чтобы полностью выделить его под I2P. Воспользуюсь уже установленным firefox. Следующий вариант работает в Linux:

FIREFOX_PROFILE="firefox-i2p"FIREFOX_HOME="${HOME}/${FIREFOX_PROFILE}"mkdir -p "$FIREFOX_HOME"env HOME="$FIREFOX_HOME" firefox

То есть идея проста: заставить firefox работать с полностью чистым профилем, который никак не повлияет на основной, и который мы сможем снести при первых же намёках на проблемы, как дедушке яичко. Какие бы мы туда дополнения ни ставили, какие бы настройки там не делали основным профилем можно будет продолжать пользоваться

У меня нет ни одной машины с Windows и MacOS. В комментариях, пожалуйста, расскажите, как сделать похожий финт ушами в Windows. А в MacOS этот фокус должен сработать, но я не тестировал

Установка на Android

Суть ровно та же, но инструменты немного другие

Установка шлюза

На всё той жестранице загрузок есть секция Android

Настройка браузера. Лайт

Рецепты по настройке

Я расскажу про несколько опциональных шагов

DNS-over-HTTPS

Для тех, что не читалпредыдущую статью: необходимо добавитьi2p иonion в исключения. Иначе браузер будет пытаться резолвить эти домены на Cloudflare с предсказуемым результатом

I2P + uBlock Origin

Мы умеем учиться на ошибках, поэтому добавим в исключения зоны i2p и onion, таким образом полностью отключив блокировщик рекламы для всех ресурсов i2p и onion

Стало лучше, чем было, но не идеально теряется контроль над загрузкой стороннего контента (3rd party). Хотелось бы только отключить резолв имён i2p и onion

Дополнительные подписки

В список подписок есть смысл добавить адреса:

1. http://identiguy.i2p/hosts.txt

2. http://inr.i2p/export/alive-hosts.txt

3. http://stats.i2p/cgi-bin/newhosts.txt

Покорми java памятью

Входной шлюз I2P написан на языке java. По умолчанию он стартует с ограничением в 128M. Этого хватит для знакомства и неспешного погружения в дивный новый мир невидимого интернета. Больше всего памяти потребляет компонент NetDB база данных о других хостах сети I2P. Чем их больше известно, тем выше надёжность и тем выше вероятность, что в час Ч, когда интернет снова сдохнет, Вам таки удастся найти лазейку доступный хост из списка известных. Правда, гарантий никаких

В случае Ubuntu/Debian:

sudo dpkg-reconfigure i2p

Как это сделать для Windows я не знаю и очень надеюсь на комментарии

Когда нельзя открыть порт меньше 1024, но очень хочется, то можно

Очень спорный рецепт. В общем случае, так делать не надо. Но если очень хочется, то можно. Я проделал это для прощупывания возможностей I2P. То есть just for fun

Приключения начались с вопроса так где же java?

which java | xargs file --mime-type/usr/bin/java: inode/symlink

Окей

which java | xargs readlink | xargs file --mime-type/etc/alternatives/java: inode/symlink

Больше симлинков богу симлинков!

which java | xargs readlink | xargs readlink | xargs file --mime-type/usr/lib/jvm/java-11-openjdk-amd64/bin/java: application/x-pie-executable

Следует понимать, что конфигурация у меня может не совпадать с конфигурацией у Вас. Идея проста добавлять в середину секцию xargs readlink до наступления просветления пока file не скажет application/x-pie-executable. Как только java нашлась из получившейся команды удаляем 2 последних слова file --mime-type, например, нажав ^W дважды, и вместо этого добавляем setcap 'cap_net_bind_service=+ep':

which java | xargs readlink | xargs readlink | xargs setcap 'cap_net_bind_service=+ep'

Возможно, потребуется добавить также возможность открытия сырого сокета setcap 'cap_net_raw=+ep':

which java | xargs readlink | xargs readlink | xargs setcap 'cap_net_raw=+ep'

Но в следующий раз я просто разверну docker с nginx

А что ещё там есть?

Очень рекомендую почитатьрусскоязычную wiki и полистать спискиidentiguy

А ещё естьтелеграмовские MTProto прокси. Идея сводится к созданию туннелей на указанные i2p-хосты. Инструкция на сайте

Ещё есть торренты и почта. Ничего из этого я ещё не пробовал использовать

Находилфлибусту иebooks.i2p последний выглядит вообще дорого-богато

Вместо заключения

Следует понимать, что I2P не самостоятельный ресурс, а в первую очередь фидер среда передачи данных. Поэтому область применимости технологии достаточно широка и упирается, скорее, в воображение

Я ни слова не сказал проi2pd. Проект достоин внимания: он производительнее и при меньшем потреблении ресурсов. Пока что у меня нет экспертизы

I2P (Invisible Internet Protocol) свободный инструмент организации анонимных коммуникаций через интернет. Является одноранговой сетью, в которой каждый пользователь по умолчанию является потенциальным звеном в анонимной цепочке других участников сети. Трафик I2P зашифрован и не поддается анализу. Понятие сторожевого узла в I2P, которое присутствует в сети Tor, нет: не существует никакого постоянного узла, через который осуществляется выход в сеть. Взаимодействие пользователя с I2P на стороне домашнего провайдера идентифицируется, как хаотичное подключение к случайным хостам. Количество подключений клиента с белым IP в среднем варьируется у отметки в четыре тысячи. Помимо полезной нагрузки, сюда входят обмен служебной информацией с другими роутерами сети и транзитный трафик.

Предпосылки

Существенное слабое место сети I2P заключается в необходимости обращения к одному из стартовых узлов через обычный интернет при первом запуске. Пакет с начальным рисунком сети в виде нескольких случайных роутеров и узел, который его отдает, называются ресидом. Стартовые узлы держат энтузиасты, их список имеется в общем доступе и нередко претерпевает изменения в силу обычных человеческих обстоятельств. Бутылочное горлышко заключается в возможности на стороне провайдера идентифицировать большинство обращений к ресиду через мониторинг DNS-запросов, а также в блокировке доменов стартовых узлов, что затруднит первый запуск для неопытного пользователя, т.к. потребует использование прокси или VPN.

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

Однако работа роутеров без выделенного адреса возможна: клиенту сети за NAT-ом приходится постоянно поддерживать активное UDP-соединение, резервируя на выходном сервере провайдера порт, обращения на который будут переданы клиенту. Этот сценарий весьма сложен, особенно, когда речь заходит про инициализацию соединения извне. Механика работы клиента за NAT-ом произведение инженерной мысли, которое заслуживает отдельной статьи.

Кратко об Yggdrasil

Yggdrasil один из немногих работоспособных протоколов меш-сетей. Основная концепция заключатся в автоматической маршрутизации во внутренней IPv6 подсети (200::/7) и абсолютной масштабируемости. Yggdrasil является полностью одноранговой сетью: не существует каких-либо мастер-узлов, которым делегируется какая-то глобальная ответственность. Является идеологическим продолжателем проекта CJDNS (Hyperborea).

Абстрактная идея меш-сети во главу угла ставит производительность, приватность и простоту использования: шифрование трафика и низкий порог вхождения новых пользователей. Yggdrasil не является инструментом анонимности, т.к. ближайшие к пользователю узлы видят его реальные сетевые интерфейсы в локальной сети, либо IP-адрес при подключении к публичному пиру через интернет. Меш-сети находят применение в организации псевдолокальных сетей, объединяя удаленные компьютеры в одну IPv6-сеть (по аналогии с Hamachi для игры в Minecraft и прочие мультиплеерные игры). Также служит для организации прочих внутрисетевых ресурсов вроде сайтов и VoIP-телефонии.

Первые попытки интеграции

I2P-роутер публикует свои адреса, в том числе IPv6, если он включен в конфиге и имеется фактически. Так как Yggdrasil предоставляет пользователю не локальный прокси, а полноценный сетевой интерфейс (туннель WireGuard), до недавних пор I2P-роутер публиковал адрес IPv6 из подсети Yggdrasil. Так как пользователей с включенным протоколом IPv6 в конфигурации I2P-роутера и установленным Yggdrasil было больше, чем один и даже два, периодически можно было видеть, что клиент I2P (роутер) сообщается с другими Yggdrasil-адресами.

Однако на лицо следующие недостатки:

1. обращение к ресиду в конечном счете должно осуществляться через обычный интернет;

2. опубликованный роутером адрес IPv6-Yggdrasil для подавляющего большинства пользователей I2P является неизвестным и недоступным;

3. успешный запуск I2P-роутера на Yggdrasil-Only устройстве маловероятен в силу возможного отсутствия в ресиде или локальной базе роутера узлов с адресом IPv6-Yggdrasil.

Начало полной совместимости

С версии 2.36.0 i2pd имеет несколько новых конфигурационных параметров, главный из которых meshnets.yggdrasil=true Этот параметр не зависит от конфигурации IPv4 и IPv6. В частности, реальные сетевые интерфейсы могут быть отключены. В таком случае I2P-роутер будет работать в режиме Yggdrasil-Only.

Также организован специальный ресид, доступный из Yggdrasil и отдающий пользователю пакет в первую очередь состоящий из известных роутеров с адресом IPv6-Yggdrasil. При каждом запуске I2P-роутера, работающего в режиме Yggdrasil-Only, проводится проверка наличия в локальной базе доступных узлов на транспортном уровне, т.е. наличие других узлов с IPv6-Yggdrasil. Если по каким-то причинам совместимых роутеров в локальной базе не оказалось, происходит повторное обращение к Yggdrasil-ресиду.

При современном использовании Yggdrasil по большей части через оверлейные подключения к публичным пирам через интернет, работа I2P-роутера в Yggdrasil сравнима со связкой Tor-over-VPN: подобный подход полностью скрывает факт использования скрытой сети от домашнего провайдера. В случае с I2P имеется еще одно специфичное преимущество: пользователю не нужно иметь выделенный IP от провайдера для беспроблемных внешних обращений, т.к. IPv6-Yggdrasil является глобально доступным в рамках сегмента сети Yggdrasil (физически соединенной группы участников, в том числе через публичные пиры в интернете).

Целостность сети

Описанное решение не является фактором фрагментации I2P. Построение туннелей скрытой сети весьма емкий и даже ювелирный процесс, в рамках которого в том числе происходит согласование транспортных возможностей узлов. Формируя чеснок - зашифрованное сообщение группе узлов, которые должны образовать туннель, - роутер проверяет их адреса на совместимость. Например, узел с единственным адресом IPv4 не получит инструкцию, согласно которой ему необходимо установить контакт с адресом IPv6, т.к. это заведомо невозможно.

Чтобы Yggdrasil-Only роутеру построить туннель до узла с адресом из обычного интернета, как минимум будет подобран транзитный роутер, имеющий два интерфейса: IPv6-Yggdrasil и, например, обычный IPv4. В свою очередь, другие Yggdrasil-Only роутеры также могут выступать транзитными звеньями туннеля, но только для сообщения с узлами совместимыми по транспорту, т.е. также имеющими сетевой интерфейс Yggdrasil. Чем больше в сети I2P количество роутеров с одновременно включенными IPv4, IPv6 и Yggdrasil интерфейсами, тем связнее сеть.

Перспектива

Пример с Yggdrasil является частным шагом в будущее, а не самоцелью. Описанный опыт успешной интеграции скрытой сети в меш-сеть является важным концептуальным шагом, который при надобности позволит интегрировать сеть I2P в другие меш-сети. Перспектива открывается при рассмотрении самоорганизованных сегментов меш-сети, например, в многоквартирных домах без централизованного провайдера. В локальной сети клиент Yggdrasil автоматически находит другие узлы и сообщается с ними, сам выступая при надобности транзитным. При подключении хотя бы одного узла в таком сегменте к другому сегменту сети (например, к глобальному через интернет), сети автоматически объединяются. Такой подход к организации сети стал еще реальнее, т.к. теперь имеет место быть и вторая сторона привычного интернета скрытая.

Для более детального ознакомления с I2P и Yggdrasil рекомендую видео: