Введение
Тоr и Onion Routing это анонимные сети прокси-серверов, позволяющие пользователям туннелировать данные через их сеть с низкими задержками. Два основных отличия Тог и I2Р основаны на разнице в моделях угроз и дизайне выходных прокси-узлов (хотя Тог и поддерживает скрытые сервисы, как и I2Р). Кроме того, Тоr реализует централизованную точку для управления видимостью сети, а так же для сбора статистики, в отличие от распределенной модели сети I2Р, базы сети и выбора пира.
Функция выходных узлов в I2Р/Тоr обладает несколькими явными проблемами как только данные покидают сеть, глобальные наблюдатели легко обеспечивают мониторинг этого траффика. В добавок, выходные узлы имеют доступ к незашифрованным данным в обе стороны, а также легко выявляются и подвержены разного рода атакам реального мира. И это все в добавление к обычным проблемам безопасности, которые мы знаем.
Тем не менее, многим людям не стоит беспокоиться на этот счет, т.к. они за пределами угроз модели. Они также вне (формальной) границы I2Р (если людям нужно сделать выходной узел, они могут его сделать). На самом деле, ряд пользователей I2Р в качестве выходного узла используют Тоr.
Сравнение терминологии Тог и I2Р
Хотя Тоr и I2Р во многом похожи, у них значительно отличается терминология.
Тоr/ I2Р
Ячейка / Сообщение
Клиент/ Маршрутизатор или Клиент Цепочка / Туннель
Справочник/ NetDb
Сервер справочников / Floodfill маршрутизатор
Входные стражи / Быстрые пиры
Входные узлы / Входной прокси
Выходной узел / Выходной прокси
Скрытый сервис/ Eepsite или Назначение
Дескриптор скрытого сервиса / LeaseSet
Введение/ Входной шлюз
Узел / Маршрутизатор
Onion Proxy / I2РTunnel клиент (более менее)
Relay/ Маршрутизатор
Точка встречи / что-то вроде Входной шлюз + Выходная точка
Дескриптор маршрутизатора / RouterInfo
Сервер/ Маршрутизатор
Преимущества Тог перед I2Р
• Значительно большая пользовательская база; Большее внимание со стороны науки и хакерского сообщества; выгоды от формальных исследований анонимности, сопротивления и производительности;
• известен не анонимный, видимый, связанный с университетом лиде
• Уже разрешили ряд проблем масштабирования, к которым I2Р еще просто не подошел
• Имеет значительное финансирование
• Больше разработчиков, включая ряд оплачиваемых
• Более устойчивый к блокировкам на уровне государств, благодаря транспорту поверх TLS и мостам (I2Р имеет предложения по "полностью закрытым путям", но они еще не реализованы
•Достаточно большая сеть, чтобы адаптироваться к блокировке и попыткам DOS
• Разработан и оптимизирован для выхода трафика, с большим числом выходных узлов
• Лучше документация, есть исследования и спецификации, лучше вебсайт, гораздо больше переведенных данных
• Более эффективен в использовании памяти
• Клиенты Тоr работают с очень небольшими затратами на протокол
• Централизованный контроль уменьшает сложность каждого узла и может эффективно работать с атаками Sybil
• Набор высокопроизводительных узлов обеспечивает высокую производительность и меньшие задержки
• Реализация на С, не Java
Преимущества I2Р перед Тоr
• Разработан и оптимизирован для работы скрытых сервисов, что гораздо быстрее, чем в Тоr
• Полностью распределенная и самоорганизующаяся сеть
• Пиры выбираются на основе постоянного профайлинга и замеров по производительности, нежели по объявленной пиром пропускной способности
• Пиры Floodfill ("справочные сервера") постоянно меняются и не обладают доверием, в отличие от явно прошитых в Тоr
• Достаточно небольшая, чтобы ее сильно блокировали или DOS'или.
• Обеспечивает пиринговые сервисы
• Коммутирует пакеты, нежели соединения
• Явная прозрачная балансировка сообщений по многим пирам, в отличие от использования одного пути
• Надежность и отказоустойчивость за счет поддержания нескольких параллельных туннелей и обеспечения ротации туннелей соединения каждого пользователя масштабируются как О(1) вместо О(N) (например, Алиса держит 2 входящих туннеля, которые может использовать любой пир, с которым Алиса общается, а не держим по цепочке на каждый пир)
• Односторонние туннели, вместо двусторонних цепочек, удваивая число узлов, которые пир должен скомпроменировать, чтобы получить ту же информацию
• Защита против детектирования клиентской активности, даже если атакующий участвует в туннеле, так как туннели используются не только для передачи сообщений, но и для работы NetDb, управления туннелями, проверки работоспособности туннелей)
• В I2Р реализованы короткоживущие туннели, что уменьшает количество примеров, которые атакующий может использовать для атаки, в отличие от цепочек в Тоr'е, которые как правило живут долго.
• АРI I2Р спроектированы под анонимность и безопасность, тогда как SOCKS сделан для функциональности
• За редким исключением, все пиры участвуют в маршрутизации трафика для других.
• Затраты на работу в полном режиме довольно низки, тогда как в Тоr, если клиент сам по себе не требует много полосы, но они еще и не полностью используют сеть.
• Встроенный механизм автоматических обновлений
• Используется как ТСР, так и UDP транспорт
• Реализация на Java, не С
Другие потенциальные, но еще не
реализованные преимущества I2Р
...и возможно никогда не реализуемые,
так что не рассчитывайте на них
Защита от количественного анализа
сообщений за счет заворачивания нескольких сообщений в одно
Защита от статистического анализа за счет добавления задержек на разных хопах (где задержки не зависят от других хостов)
Разные стратегии имитовставки на уровне туннелей (например создание туннеля, который будет обрабатывать 500 сообщений в минуту, где эндпойнт посылает случайные данные, если полезный трафик не передается и т.д)
