SSU2 — транспортный протокол I2P нового поколения на базе UDP15.01.2023 02:01

КДПВ

SSU — протокол I2P, являющийся криптографической оберткой UDP из стека TCP/IP, то есть это низкоуровневый транспортный протокол наравне с NTCP2, который является аналогичной зашифрованной обёрткой TCP. Этот уровень логики I2P обеспечивает первый слой безопасности всей информации, передаваемой между участниками сети.

SSU является первым транспортным протоколом I2P в буквальном смысле, он был создан до NTCP и тем более до NTCP2. С бородатого 2003 года анонимусы гоняют по сети пакеты SSU! С тех пор появился транспорт NTCP и даже его вторая версия, а SSU в течение без малого двадцати лет не получал каких-либо обновлений кроме незначительных исправлений реализации и, как говорят разработчики, костылей вроде поддержки IPv6.

Без этого протокола невозможно полноценное функционирование сети, в особенности на устройствах без выделенного IP-адреса, поэтому, несмотря на оптимизированную работу по TCP (NTCP2), сети I2P был необходим SSU2 — новое поколение транспорта на базе UDP. Спустя девятнадцать лет существования Проекта невидимого интернета (полное название I2P) появилось официальное обсуждение второй версии протокола SSU.

Важная роль SSU в практическом контексте весьма подробно рассмотрена в отдельной статье, поэтому опустим робкое введение и перейдем к сути.

SSU2 появился в i2pd версии 2.42 (22.05.2022), его стабильная реализация — в 2.43 (21.08.2022), в 2.44 (20.11.2022) SSU2 включен по умолчанию, а с версии 2.45 (04.01.2023) SSU первой версии вовсе удален (релиз того же периода I2P-роутера на Java нумеруется как 2.1.0). Практически двадцатилетняя история SSU завершена!

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

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

SSU2 это не тот же SSU, который работает поверх QUIC вместо голого UDP, а принципиально новый протокол I2P, вобравший в себя многие механизмы QUIC и даже пару деталей от WireGuard.

Причины появления SSU2

1. Медленная криптография. SSU использует старый алгоритм Diffie-Hellman, который требует много вычислительных мощностей, что влечет дополнительные задержки и нагрузку на процессор;

2. Уязвимость для подмены адреса. Протокол UDP не подразумевает контроль сессий, вся входящая информация валится в один сетевой сокет и принимается без полноценной проверки валидности;

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

Производительность

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

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

Старый, или как еще его называют «медленный» Диффи-Хеллман в I2P-роутере заметно грузил систему, а для мелких виртуальных серверов он был вовсе критическим, вплоть до 100% ЦП в момент вычисления общего ключа! Получение общего ключа необходимо для создания зашифрованного канала связи и до тех пор, пока операция не закончились, передача полезной нагрузки не начинается. Очевидное узкое место, препятствующее быстрой передаче данных.

В качестве решения проблемы, SSU2 использует криптографический фреймворк Noise, который базируется на криптографии на эллиптической кривой Ed25519. Согласование ключей на этой кривой по схеме x25519 — самая скоростная схема асимметричного шифрования на сегодняшний день. Скорость обусловлена малым объемом требуемых вычислений в штатном варианте использования. Однако, по криптостойкости x25519 не уступает альтернативным решениям, так как по своей сути является тем же DH, но на базе кривой — ECDH. В общем, не путайте старый DH и новый ECDH на эллиптической кривой. Первый — легаси, второй — база, тру и современный бро.

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

Защита от спуфинга

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

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

Для осуществления атаки наблюдателю необходимо перехватить настоящий пакет SSU (то есть UDP-датаграммы), содержащий криптографические идентификаторы I2P-роутера отправителя, задержать его, а получателю передать информацию в изменённом виде: подменить адрес и порт источника в заголовках UDP-пакетов. В следствие этой манипуляции конечный получатель, имея ложный адрес, отошлет ответ на запрос мимо реального роутера, ждущего ответ. Ощущаете привкус DDoS-атак с использованием ничего не подозревающих I2P-роутеров, которые невинно шлют ответы «не туда»? Правда, зарегистрировано таких атак не было. И теперь уже не будет.

В SSU второй версии (SSU2) управление сессиями происходит без использования незащищенной информации из заголовков UDP. Теперь вся важная информация читается из тела пакетов и имеет необходимую криптографическую защиту (шифрование и подпись). Помимо того, что SSU2 не руководствуется адресом отправителя из UDP-заголовка, он позволяет сохранять сессию при неожиданной смене IP-адреса одной из сторон благодаря специльному механизму path challenge.

Про DPI

Большая уязвимость SSU перед системами анализа трафика была в характерном сообщении HolePunch. Hole punch или пробитие окна — это возможность UDP, позволяющая абонентам без выделенного IP-адреса принимать внешние обращения, зарезервировав на пограничном роутере порт, вся информация с которого адресуется конкретному абоненту. Старая реализация SSU подразумевала сообщения HolePunch нулевой длины, что при наблюдении за трафиком со стороны является очень специфичным и узнаваемым поведением: кому нужно слать пустое сообщение, т.е. голые заголовки UDP-пакета? Правильно, I2P-роутеру. Со слов одного из ведущих разработчиков, подобные вещи в I2P сложились по историческим причинам. Порой эти причины скрываются в анналах истории под грифом секретности «так сделал jrandom». К счастью, по мере развития скрытой сети, на смену легаси приходят современные решения с подробными обсуждениями и документацией.

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

Архитектурно, SSU2 позаимствовал систему блоков из NTCP2 (транспорт I2P на базе TCP) в качестве неотъемлемой части транспортной логики. Эта система подразумевает дополнительную обертку для всех служебных и пользовательских сообщений, формируя из них блоки, передаваемые по сети в виде единого целого. Таким образом тот же запрос HolePunch может передаваться в одном сообщении с сопутствующими данными, которые в SSU первой версии неизбежно шли отдельно и подряд, создавая узнаваемый паттерн. Помимо непредсказуемого наполнения, сообщения с блоками имеют произвольный паддинг, который при наблюдении со стороны напрочь сбивает все попытки предположить содержимое.

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

Еще больше про DPI

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

Предлагается разделение анализа на два типа: онлайн и оффлайн.

• Онлайн DPI проверяет все потоки сетевого трафика в режиме реального времени. Силами такой системы соединения могут быть заблокированы или как-то испорчены (как это происходит с запросами к заблокированным сервисам и сайтам). Системой онлайн DPI данные о каждом конкретном соединении могут быть сохранены для анализа в автономном (оффлайн) режиме.

  Предполагаются следующие возможности онлайн DPI:

  • Возможность просматривать все данные, отправленные или полученные целью;

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

  • Возможность хранить и сравнивать с ранее отправленными сообщениями;

  • Возможность изменять, задерживать или фрагментировать пакеты.

  Однако предполагается, что DPI в реальном времени наблюдатель имеет следующие ограничения:

  • Невозможность сопоставить IP-адрес с хешами I2P-роутеров (RouterInfo). Хотя это тривиально при доступе к базе данных сети (netDb) в реальном времени, но для этого потребуется система DPI, специально разработанная для I2P;

  • Невозможность взаимодействия с I2P для создания ханипотов (honey pot, «медовых ловушек»), чтобы прозванивать абонентов на предмет наличия I2P-роутера.

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

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

Задача перед SSU2 состояла в том, чтобы предотвратить или критически затруднить идентификацию протокола в реальном времени, тем самым препятствуя блокировке трафика I2P.

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

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

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

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

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

P.S.

© Habrahabr.ru