[Из песочницы] Почему Bittorent через Tor — плохая идея
Добрый день. Не помню как и когда, но однажды я задался вопросом: что если использовать Bittorrent клиент через сеть Tor? Поискав в интернете информацию на эту тему, наткнулся на интересную статью «Bittorrent over Tor isn’t a good idea», опубликованную на torproject.org. Решил перевести для читателей «Хабрахабра». Исправления приветствуются.
Растет число людей, которые спрашивают нас о последней публикации, вышедшей в INRIA во Франции относительно Bittorent и уязвимостей личной информации. Та статья пытается объяснить эти уязвимости и рассказать, что они из себя представляют.
Есть три вида уязвимостей (или три разных уязвимости, которые основаны одна на другой, если вам так будет понятнее).
Первая уязвимостьВозникает у людей, которые настраивают свой битторент-клиент на работу через прокси, когда их трафик проксируется через Tor. Эти люди надеются, что их ip-адрес будет в секрете от кого-то, кто смотрит список пиров на трекере.Проблема в том, что несколько популярных битторент-клиентов (авторы называют в основном uTorrent и, я думаю, Vuze тоже можно сюда отнести) просто игнорируют настройки socks proxy.
Выбор игнорировать настройки прокси довольно понятен, так как современный трекер использует UDP-протокол для соединений, а socks proxy, такие как Tor, поддерживают только TCP-протокол — разработчики этих приложений стоят перед выбором между «пусть работает, даже если юзер настраивает прокси, который нельзя использовать» или «сделать так, чтобы оно мистически валилось с ошибкой, запутывая пользователя». В результате битторент-приложения используют сценарии реализации безопасности, отличные от тех, какие ожидает пользователь этих приложений.
Уязвимость в целом хуже, чем описанное выше: оказывается, в некоторых случаях uTorrent, BitSpirit и libTorrent просто пишут свои ip-адреса прямо в пакетах, которые они отсылают трекеру и/или другим пирам. Тор делает свою работу: он «анонимно» отсылает ваш ip-адрес трекеру или пиру. Никто не знает, откуда именно вы отсылаете свой ip-адрес, вот так. По всей вероятности, это совсем не то, что ожидалось.
Это была первая уязвимость.
Вторая уязвимость Основывается на первой. Она состоит в том, что воинственно настроенный пир может точно идентифицировать вас. Так выходит, потому что битторент-протокол (по крайней мере как сделано в популярных битторент-приложениях) общается через произвольный порт и говорит этот произвольный порт трекеру, а так же и другим пирам, которые с ним контактируют.Именно это и составляет уязвимость: трекер запоминает ваш реальный адрес и порт. Так что если ваш uTorrent-клиент выбирает произвольный порт 50344 как свой порт и затем «анонимно» (через Tor) общается с другим пиром, который есть на трекере, тот самый пир может пойти на трекер, посмотреть всех, кто опубликовал в листинге трекера порт 50344 (с высокой вероятностью это будете только вы) и — вуаля — другие пиры знают ваш реальный ip-адрес. В качестве бонуса, если битторент-пир общается через не зашифрованный канал связи, то «exit relay» Тора, который вы выбрали, так же сможет просматривать трафик и производить атаки на пользователей.
Это был второй вид уязвимости. Суммируя, они показывают различные причины, почему использование Bittorent поверх Tor не скроет вас.
Так как же это исправить? Есть несколько ответов. Первый — «не запускайте Bittorent поверх Tor». Мы годами говорим об этом, потому что Tor не выдерживает такой нагрузки. Возможно, эти виды атак вправят людям мозги и они прислушаются. Второй ответ в том, что если вы хотите, чтобы ваш битторент-клиент был безопасным при использовании прокси, вам нужно связаться с разработчиками вашего приложения, чтобы те поправили протокол и свои приложения. Tor не защитит вас от утечки личной информации в этом конкретном случае.
Третий вид уязвимости Третий вид уязвимости из их доклада — это то место, где становится действительно интересно. Для эффективности Tor направляет несколько потоков приложений поверх каждой цепи. Этот подход увеличивает эффективность, поскольку нам не нужно тратить время и иметь оверхед, делая новую цепь для каждой мелкой картинки. Это увеличивает анонимность, так как каждый раз, когда вы создаете новый путь через Tor-сеть, вы увеличиваете вероятность того, что этот путь отслеживает злоумышленник. Недостаток этого в том, что «exit relay» может создавать мелкие снапшоты пользовательских профилей, включая все потоки, выходящие из конкретной цепи.Если один из этих потоков идентифицирует пользователя (например, битторент-клиент), «exit relay» знает, что остальная часть этих потоков принадлежат этому пользователю тоже, таким образом, идентифицируется трафик от других приложений.
Как это исправить? Используем старые советы: не используйте Bittorent поверх Tor-сети и/или заставьте разработчиков пофиксить свои приложения.
Есть ли способ, при котором мы, как часть сети Tor, можем сократить опасность от использования небезопасных приложений в Tor? Мы не можем решить проблему, когда вы отстреливаете себе ногу, используя Bittorent через Tor, но, возможно, мы все еще можем сохранить вам оставшуюся часть ноги.
Адресуя проблему к инфраструктуре сети Tor, можно заставить каждое приложение использовать различные цепи. В Linux и UNIX мы, возможно, можем хакнуть что-то подобное — есть способы просматривать идентификатор процесса приложения, подключающегося к сокету.
Я полагаю, это сложнее в Windows. Это так же становится сложнее, так как множество приложений Tor используют промежуточный http proxy, вроде Polipo ли Privoxy. Мы должны были бы обучить эти промежуточные прокси как распределять данные между различными приложениями и затем отсылать эту информацию через Тор.
Другой вариант в разделении потоков по конечным портам. Все потоки, которые идут на порт 80, находятся в цепи, и поток для другого конечного порта идет через другую цепь.
Мы луркали эту идею в бэкграунде достаточно долгое время, но все снова упирались в то, что если клиент BT попросит нас сделать 50 потоков на 50 различных портов назначения, клиент Tor попытается сделать 50 различных цепей. Это слишком большая нагрузка на сеть.
Я думаю, мы могли бы внести разделение поведения для »80» и «не 80» портов, но я не уверен, насколько это эффективно на практике, поскольку есть множество других портов (IM, SSH, и т.д.). В таком случае они тоже должны были бы обрабатываться отдельной логикой, а во-вторых, брандмауэры сегодня все больше и больше контролируют 80-й порт.
Нам следует и дальше думать об этих проблемах — даже несмотря на то, что мы не можем контролировать приложения, которые могут отсылать личную информацию по сети. В то же время я рад, что выпускаются такие исследования, которые позволяют посмотреть более широко на возможные уязвимости.
