Принцип анонимности I2P заключается в неизвестном месторасположении скрытого сервиса. Каждый скрытый сервис (например, сайт или пользователь, который его посещает) взаимодействует с другими ресурсами исключительно через анонимизирующие туннели. Туннели строятся через роутеры участников сети также, как другие пользователи строят туннели через наш роутер. Такая модель создает множество прямых соединений между I2P-роутерами, в которых нельзя определить на каком роутере начался или закончился тот или иной туннель: тысячи одновременных зашифрованных подключений не дают такой возможности.
![](https://habrastorage.org/getpro/habr/upload_files/661/7ee/255/6617ee25543366d32c36f55fc4546518.jpg)
Чтобы связаться с любым скрытым сервисом, необходимо получить его лизсет (LeaseSet), который содержит информацию о входных туннелях и криптографических ключах. Для этого все серверные конечные точки, ожидающие подключение, публикуют свои лизсеты на флудфилах (Floodfill) – роутерах, выступающих в роли справочной книги или доски объявлений. Несмотря на то, что флудфил получает лишь информацию о первых узлах входных туннелей и криптографические ключи, т.е. никакой компрометирующей информации в лизсете нет, архитектура I2P предусматривает использование зашифрованных лизсетов. Это позволяет скрыть наличие конечной точки (она же «скрытый сервис» и «destination») от возможного мониторинга на флудфилах.
![](https://habrastorage.org/getpro/habr/upload_files/72f/974/b43/72f974b438242abad6df26675fe6acbb.jpg)
Идентификатор незашифрованного лизсета – обычный внутрисетевой адрес скрытого ресурса, только без окончания «.b32.i2p». Это позволяет держателям флудфилов видеть в открытом виде адреса ресурсов, которые у них опубликовались. Если вы подняли в I2P личный ресурс и не хотите, чтобы о нем случайно узнал кто-то еще, зашифрованный лизсет – специально для вас!
![Незашифрованный лизсет на флудфиле Незашифрованный лизсет на флудфиле](https://habrastorage.org/getpro/habr/upload_files/e37/b1c/170/e37b1c17003f4c06b676e98cf8f81efa.png)
Сокрытие идентификатора лизсета в англоязычной терминологии называется blinding («ослепление»). Отсюда происходит название адреса скрытого сервиса с зашифрованным лизсетом: «bb32» – blinded-b32. В свою очередь «b32» во всех доменах сети является сокращением от названия кодировки base32, которой кодируется информация, образующая домен. Важно заметить, что bb32 – всего лишь термин. Фактически такое написание в адресах не используется.
Идентификатор лизсета типа bb32 (который видит флудфил) не соотносится с адресом, поэтому не может сообщить владельцу флудфила фактическое имя опубликованного у него ресурса. Также к адресу типа bb32 нельзя привязать короткий домен в зоне «i2p». Единственный способ обратиться к подобному скрытому сервису – иметь полную строку его адреса. Получая на вход bb32-адрес, I2P-роутер запрашивает у флудфила соответствующий зашифрованный лизсет, а затем расшифровывает его содержимое, используя дополнительную информацию, закодированную в домене.
Доменное имя обыкновенной конечной точки целиком состоит из хеша полного адреса (набор криптографических ключей, который затем приходит вместе с лизсетом), а адрес с зашифрованным лизсетом – это публичный ключ подписи скрытого ресурса, а также три байта специальной информации: флаги, тип подписи и тип зашифрованной подписи.
![](https://habrastorage.org/getpro/habr/upload_files/471/a8e/c78/471a8ec788c40dfa9ea830e78b04e77d.png)
Ознакомиться с криптографическими подробностями блиндинга, т.е. сокрытием идентификатора лизсета, а также с шифрованием его содержимого, можно в официальном документе. Согласно приведенной документации в зашифрованном лизсете поддерживается два типа подписи: EDDSA_SHA512_ED25519 (тип 7) и REDDSA_SHA512_ED25519 (тип 11), однако настоятельно рекомендуется использовать только второй из приведенных. В случае i2pd нерекомендуемый вариант вовсе не реализован, т.к. считается практически бессмысленным.
![](https://habrastorage.org/getpro/habr/upload_files/d53/1f4/b16/d531f4b1680b26979a7ad0d23ab52583.png)
Это связано с тем, что, во-первых, тип подписи 11 алгоритмически является более оптимальным для использования в зашифрованном лизсете, во-вторых, тип подписи 7 применяется по умолчанию и допускает неумышленное использование уже существующего адреса в связке с зашифрованным лизсетом. Теоретически это является уязвимостью, т.к. позволяет флудфилу-злоумышленнику раскрыть очередной зашифрованный лизсет сервиса, который до этого с тем же ключом подписи использовал лизсет обычного типа. Это возможно из-за алгоритма вычисления блиндинга, который можно воспроизвести, заранее зная полный адрес конечной точки, включаемый в лизсет. Подразумевается, что пользователь, назначивший вручную тип подписи 11, наверняка сразу укажет и нужный ему тип лизсета, что предотвратит утечку.
Минимальная конфигурация туннеля конечной точки типа bb32 (которая иногда почему-то называется b33, что не имеет какой-либо логики) выглядит следующим образом (принципиальны последние две строки):
[SUPER-HIDDEN-SERVICE]
type = server
host = 127.0.0.1
port = 8080
inport = 80
keys = site.dat
signaturetype = 11
i2cp.leaseSetType = 5
![Ответ на вопрос "где смотреть адрес созданного сервиса с зашифрованным лизсетом" Ответ на вопрос "где смотреть адрес созданного сервиса с зашифрованным лизсетом"](https://habrastorage.org/getpro/habr/upload_files/aa1/32e/dbd/aa132edbd5bc9abf684f2b05905235ea.jpg)
Чуть раньше были упомянуты флаги, содержащиеся в первом байте адреса с зашифрованным лизсетом. Все, что нас интересует в контексте данной статьи, это флаг авторизации. Он настраивается через дополнительный параметр конфигурации i2cp.leaseSetAuthType
. Вкратце: это позволяет сделать доступ к приватному ресурсу еще более контролируемым, создавая список по ключам или парольным фразам для каждого пользователя, а в случае чего – убрать конкретный идентификатор из списка, после чего соответствующий пользователь уже не получит лизсет, следовательно, и доступ к ресурсу. Подробнее об этом вы можете узнать из документации (параметры i2cp.leaseSetPrivKey
, i2cp.leaseSetClient.dh.nnn
, i2cp.leaseSetClient.psk.nnn
).
kai3341
Спасибо за статью!