Предложение от weko, orignal, Anonymous и zzz.
Обзор
Этот документ предлагает изменения в SSU2 после атаки на I2P, которая использовала уязвимости в SSU2. Основная цель - усиление безопасности и предотвращение атак типа отказа в обслуживании (DDoS) и попыток деанонимизации.
Модель угроз
Злоумышленник создает новые фальшивые RI (роутер не существует): это обычный RI, но он указывает адрес, порт, ключи s и i от реального роутера Боба, затем он затапливает сеть. Когда мы пытаемся подключиться к этому (как мы думаем, реальному) роутеру, мы, как Алиса, можем подключиться к этому адресу, но мы не можем быть уверены, что это сделано с помощью реального RI Боба. Это возможно и использовалось для атаки типа отказа в обслуживании (создайте большое количество таких RI и затопите сеть), также это может облегчить атаки деанонимизации путем подставы хороших роутеров и не подставы злоумышленнических роутеров, если мы забаним IP с множеством RI (вместо того чтобы лучше распределить построение туннеля к этим RI как к одному роутеру).
Возможные решения
1. Исправление с поддержкой старых (до изменения) роутеров
.. _overview-1:
Обзор ^^^^^
Обходное решение для поддержки соединений SSU2 со старыми роутерами.
Поведение ^^^^^^^^^
Профиль роутера Боба должен иметь флаг ‘verified’, который по умолчанию ложный для всех новых роутеров (у которых еще нет профиля). Когда флаг ‘verified’ ложный, мы никогда не подключаемся с SSU2 от Алисы к Бобу - мы не можем быть уверены в RI. Если Боб подключился к нам (Алисе) через NTCP2 или SSU2, или мы (Алиса) подключились к Бобу через NTCP2 однажды (мы можем проверить идентификатор роутера Боба в этих случаях) - флаг устанавливается в true.
Проблемы ^^^^^^^^
Таким образом, существует проблема с фальшивым затоплением только SSU2 RI: мы не можем сами его проверить и вынуждены ждать, когда реальный роутер установит соединения с нами.
2. Верификация RouterIdent в процессе создания соединения
.. _overview-2:
Обзор ^^^^^
Добавить блок “RouterIdent” для SessionRequest и SessionCreated.
Возможный формат блока RouterIdent ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1 байт флаги, 32 байта RouterIdent. Флаг_0: 0, если идентификатор Routers получателя; 1, если идентификатор Routers отправителя.
Поведение ^^^^^^^^^
Алиса (должна(1), может(2)) отправляет в данных блок RouterIdent Flag_0 = 0 и RouterIdent Боба. Боб (должен(3), может(4)) проверяет, является ли это его идентификатором Routers, если нет: завершает сессию с причиной “Неправильный RouterIdent”, если это его идентификатор Routers: отправляет блок RI с 1 в Flag_0 и RouterIdent Боба.
С (1) Боб не поддерживает старые роутеры. С (2) Боб поддерживает старые роутеры, но может стать жертвой DDoS от роутеров, пытающихся наладить соединение с фальшивыми RI. С (3) Алиса не поддерживает старые роутеры. С (4) Алиса поддерживает старые роутеры и использует гибридную схему: Исправление 1 для старых роутеров и Исправление 2 для новых. Если RI сообщает новую версию, но во время соединения мы не получаем блок RouterIdent - завершить и удалить RI.
.. _problems-1:
Проблемы ^^^^^^^^
Злоумышленник может замаскировать свои фальшивые роутеры под старые, и с (4) мы в любом случае ждем ‘verified’, как в Исправлении 1.
Заметки ^^^^^
Вместо 32-байтного RouterIdent, мы можем, вероятно, использовать 4-байтный siphash-от-хеша, какой-то HKDF или что-то еще, что будет достаточно.
3. Боб устанавливает i = RouterIdent
.. _overview-3:
Обзор ^^^^^
Боб использует свой RouterIdent как i ключ.
.. _behavior-1:
Поведение ^^^^^^^^^
Боб (должен(1), может(2)) использует свой собственный RouterIdent как i ключ для SSU2.
Алиса с (1) подключается только если i = RouterIdent Боба. Алиса с (2) использует гибридную схему (исправления 3 и 1): если i = RouterIdent Боба, мы можем установить связь, иначе мы должны сначала его проверить (см. исправление 1).
С (1) Алиса не поддерживает старые роутеры. С (2) Алиса поддерживает старые роутеры.
.. _problems-2:
Проблемы ^^^^^^^^
Злоумышленник может замаскировать свои фальшивые роутеры под старые, и с (2) мы в любом случае ждем ‘verified’, как в Исправлении 1.
.. _notes-1:
Заметки ^^^^^
Чтобы сохранить объем RI, лучше добавить обработку если i ключ не определен. Если он определен, то i = RouterIdent. В этом случае, Боб не поддерживает старые роутеры.
4. Добавить еще одну MixHash в KDF для SessionRequest
.. _overview-4:
Обзор ^^^^^
Добавить MixHash(хеш идентификатора Боба) в состояние NOISE сообщения “SessionRequest”, например: h = SHA256 (h || хеш идентификатора Боба). Это должна быть последняя MixHash, используемая как ad для ENCYPT или DECRYPT. Необходимо ввести дополнительный флаг заголовка SSU2 “Проверка идентификатора Боба” = 0x02.
.. _behavior-4:
Поведение ^^^^^^^^^
- Алиса добавляет MixHash с хешом идентификатора Боба из RouterInfo Боба и использует его как ad для ENCYPT, и устанавливает флаг “Проверка идентификатора Боба”.
- Боб проверяет флаг “Проверка идентификатора Боба” и добавляет MixHash с собственным хешом идентификатора, и использует его как ad для DECRYPT. Если AEAD/Chacha20/Poly1305 терпит неудачу, Боб закрывает сессию.
Совместимость со старыми роутерами ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- Алиса должна проверить версию роутера Боба, и если она соответствует минимальной версии, поддерживающей это предложение, добавить эту MixHash и установить флаг “Проверка идентификатора Боба”. Если роутер старый, Алиса не добавляет MixHash и не устанавливает флаг “Проверка идентификатора Боба”.
- Боб проверяет флаг “Проверка идентификатора Боба” и добавляет эту MixHash, если она установлена. Старые роутеры не устанавливают этот флаг, и эту MixHash не следует добавлять.
.. _problems-4:
Проблемы ^^^^^^^^
- Злоумышленник может выдавать фальшивые роутеры как старые. В какой-то момент старые роутеры должны использоваться с осторожностью и после того, как они будут проверены другими способами.
Обратная совместимость
Описана в исправлениях.
Текущий статус
i2pd: Исправление 1.