Нет, вы не можете доверять сети в выборе пути.
Вредоносные узлы могут направить вас через своих друзей-сговорщиков.
Это даст злоумышленнику возможность отслеживать весь ваш трафик от начала до конца.
Это было бы удобно по ряду причин:
Это позволило бы Tor лучше справляться с новыми протоколами, такими как VoIP.
Это могло бы полностью решить проблему синхронизации приложений.
Выходным узлам также не нужно будет выделять много файловых дескрипторов для всех выходных соединений.
Мы движемся в этом направлении. Некоторые из сложных проблем заключаются в следующем:
IP-пакеты раскрывают характеристики операционной системы.
Нам все равно нужно будет выполнить нормализацию пакетов на уровне IP, чтобы остановить такие вещи, как атаки с использованием отпечатков TCP.
Учитывая разнообразие и сложность стеков TCP, а также атаки с использованием отпечатков устройств, похоже, что нам лучше всего использовать наш собственный стек TCP в пользовательском пространстве.
Потоки прикладного уровня все еще нуждаются в очистке.
Нам по-прежнему понадобятся пользовательские приложения, такие как Torbutton.
Таким образом, это не станет просто вопросом захвата пакетов и анонимизации их на уровне IP.
Некоторые протоколы по-прежнему будут допускать утечку информации.
Например, мы должны переписать DNS-запросы, чтобы они доставлялись на несвязанный DNS-сервер, а не на DNS-сервер у поставщика услуг Интернета пользователя; таким образом, мы должны понимать протоколы, которые мы транспортируем.
DTLS (датаграмма TLS) в основном не имеет пользователей, и IPsec, безусловно, большой.
После того, как мы выбрали механизм передачи, нам нужно разработать новый сквозной протокол Tor, чтобы избежать атак с тегами и других потенциальных проблем анонимности и целостности теперь, когда мы разрешаем падения, повторные отправки и т. д.
Политики исходящего трафика для произвольных IP-пакетов означают создание безопасной системы обнаружения вторжений (IDS).
Наши операторы узлов говорят нам, что политики исходящего трафика являются одной из основных причин, по которым они готовы запустить Tor.
Добавление IDS для обработки политик исходящего трафика увеличит сложность безопасности Tor и, вероятно, не будет работать в любом случае, о чем свидетельствует вся область IDS и документов counter-IDS.
Многие потенциальные проблемы злоупотребления решаются тем фактом, что Tor передает только допустимые TCP-потоки (в отличие от произвольного IP-адреса, включая искаженные пакеты и IP-потоки).
Политика исходящего трафика становится еще более важной, поскольку мы получаем возможность передавать IP-пакеты.
Нам также необходимо компактно описать политики исходящего трафика в каталоге Tor, чтобы клиенты могли предсказать, какие узлы позволят их пакетам выйти.
Клиенты также должны предсказать все пакеты, которые они захотят отправить в сеансе, прежде чем выбрать свой выходной узел!
Необходимо изменить внутреннее пространство имен Tor.
Мы поддерживаем адреса onion-ресурсов ".onion", перехватывая адреса, когда они передаются клиенту Tor.
Для этого на уровне IP потребуется более сложный интерфейс между Tor и локальным преобразователем DNS.
Было бы неплохо позволить операторам узлов говорить такие вещи, как reject www.slashdot.org в своих политиках исходящего трафика, вместо того, чтобы требовать от них изучения всего пространства IP-адресов, которое может быть охвачено сайтом (а затем также блокировать другие сайты по этим IP-адресам).
Однако есть две проблемы.
Во-первых, пользователи все еще могут обходить эти блоки.
Например, они могут запросить IP-адрес, а не имя хоста при выходе из сети Tor.
Это означает, что операторам все равно нужно будет узнать все IP-адреса для рассматриваемых пунктов назначения.
Вторая проблема заключается в том, что это позволит удаленным злоумышленникам подвергать цензуре произвольные сайты.
Например, если оператор Tor блокирует www1.slashdot.org, а затем какой-то злоумышленник отравляет DNS узла Tor или иным образом изменяет это имя хоста, чтобы устранить ip-адрес крупного новостного сайта, то внезапно этот узел Tor блокирует новостной сайт.
Требование, чтобы каждый пользователь Tor был узлом, помогло бы масштабировать сеть для обработки всех наших пользователей, а запуск узла Tor может помочь вашей анонимности.
Однако многие пользователи Tor не могут быть хорошими узлами - например, некоторые клиенты Tor работающие под ограничением брандмауэров, подключающиеся через модем или иным образом, не в состоянии ретранслировать трафик.
Предоставление услуг таким клиентам является важной частью обеспечения эффективной анонимности для всех, поскольку многие пользователи Tor подвержены этим или подобным ограничениям, и включение этих клиентов увеличивает размер набора анонимности.
Тем не менее, мы хотим побудить пользователей Tor запускать узлы, поэтому мы действительно хотим упростить процесс их настройки и обслуживания.
За последние несколько лет мы добились большого прогресса в легкой настройке: Tor хорошо умеет автоматически определять, доступен ли он и какую пропускную способность он может предложить.
Однако, прежде чем мы сможем это сделать, нам необходимо выполнить четыре шага:
Во-первых, нам все еще нужно научиться автоматически определять необходимую пропускную способность.
Возможно, переключение на UDP здесь самый простой ответ, но, увы, это совсем не просто.
Во-вторых, нам нужно работать над масштабируемостью как сети (как перестать требовать, чтобы все узлы Tor могли подключаться ко всем узлам Tor), так и каталога (как перестать требовать, чтобы все пользователи Tor знали обо всех узлах Tor).
Подобные изменения могут иметь большое влияние на потенциальную и фактическую анонимность.
См. подробности в разделе 5 документа Сложности.
Опять же, UDP-транспорт мог бы здесь помочь.
В-третьих, нам нужно лучше понять риски, связанные с тем, чтобы позволить злоумышленнику отправлять трафик через ваш узел, в то время как вы также инициируете свой собственный анонимный трафик.
Три разных исследования описывают способы идентификации узла в цепи путем пропуска трафика через узлы-кандидаты и поиска провалов в трафике, пока цепь активна.
Эти засоряющие атаки не так страшны в контексте Tor, если узлы никогда не являются клиентами.
Но если мы пытаемся побудить больше клиентов также включить функцию ретрансляции (будь то мостовые узлы или обычные узлы), тогда нам нужно лучше понять эту угрозу и научиться ее смягчать.
В-четвертых, нам может понадобиться какая-то схема стимулирования, чтобы побудить людей ретранслировать трафик для других и/или становиться выходными узлами.
Вот наши текущие мысли о стимулах Tor.
Пожалуйста, помогите со всем этим!