Всё о TBB (Tor Browser Bundle)
Извиняюсь, но за 10 минут перебора тем в форуме "Анонимность" не нашел всеобъемлющей темы о TBB (Tor Browser Bundle), только разрозненные.
Поэтому предлагаю обсуждать вопросы и проблемы, представляющие интерес для многих, в этой ветке, будет удобней.
комментариев: 9796 документов: 488 редакций: 5664
А можно чтобы входящий узел был одинаковый, а дальше цепочки разные?
Используйте опцию NumEntryGuards 1
Но это не исключит возможности ротации входящих узлов, с распределением новых и старых цепочек по разным гвардам.
Или можно статически ограничиваться каким-либо гвард узлом, через опцию EntryNodes или использование узла в качестве бриджа. Но возможно клиент ошибочно пометит узел как недоступный, если не дождался ответа, к примеру. Тогда не будет никакой ротации узлов и никакой связи.
А противник пронюхает это дело и поставит для вас невидимую ссылку на 5222/5223-ий порт по HTTP в веб-странице. Вот тут-то вы и спалитесь по полной.
Число входящих узлов в норме 3. Вроде можно прописать статически как больше, так и меньше, но это будет распространяться на все цепочки. Чтобы цепочка зависела от Guard'a — про такое не слышал. Думаю, это не лучшим образом могло бы сказаться на анонимности. В крайнем случае, можно запустить несколько Tor-клиентов, каждый — со своей политикой по Guard'ам, но это тоже будет плохо для анонимности, так делать не рекомендуют. Вы этим выделите себя из массы пользователей Tor.
В норме guard-узлы меняются раз в 2-3 месяца.
Пожалуй то что надо.
Не важно что идет ротация, важно, чтобы в каждый момент времени входящий узел был один.
Клиент может отказаться на некоторое время от использования узла, если ответ не уложился по времени. Максимальное время строительства цепочки клиентом расчитывается для конкретных сетевых условий, в целях выбора приемлимой цепочки. В нормальных сетях это значение пара секунд, а то и меньше, таймаут на ответ от первого узла может быть меньше секунды. Стоит гварду опоздать и клиент переключает все новые цепочки на другой гвард, все "старые" продолжают использовать "неработающий" гвард. Они старые лишь условно, к ним ещё может быть подключено множество новых потоков, которые связаны с соединениями на сокс порту. Всё зависит от правил у экситов в этих цепочках.
Это принудительная "ротация", во имя скорости.
Можете глянуть в state файл, там запомнено больше чем 3 гварда, но одновременно клиент считает живыми не более чем число из NumEntryGuards.
Это нужно затем, чтобы локальный провайдер не различал трафик от разных программы и пользователей. Локальный провайдер Guard'а будет конечно видеть все его связи и временнЫе корреляции трафика, но Guard'ы сильно загружены, трафики от разных клиентов у них сильно смешаны по времени.
Лучше всего, если в каждом узле трафик будет разделяться по разным цепочкам, тогда он лучше будет перемешиваться с чужим трафиком из-за уменьшения объема на одну цепочку. Это можно сделать и без обновления софта всей сети, расширив один тор-клиент который станет автоматически разбивать свой трафик по разным цепочкам. Но конечные сервера в свою очередь должны позволять загружать с себя информацию по "кусочкам". Иначе собирать куски пакета от одной программы или пользователя с разных тор-цепочек в один пакет должен будет выходящий узел (для разных программ и пользователей он будет назначен разным), а это уже требует обновления софта для всей сети.
Выделение себя на входящих узлах не так страшно, как деанон на выходящих. Ну пусть заносят в расстрельные списки, мне не жалко.
комментариев: 9796 документов: 488 редакций: 5664
Ссылки на обсуждение таких идей приводились в /comment78594:
Идея про смешивание, дополнение и зашумливание в том примитивном виде, как здесь предлагают, была во многом изучена и отвергнута ещё в лабораторных условиях, до запуска сети Tor. С тех пор вышло много исследований по улучшенным вариантам протоколов, пытающихся создать что-либо подобное. Но они либо оказываются теоретически непроработанными; либо выясняется, что они защищают от сложных и непрактичных атак, в то время как не защищают от более простых; либо такие улучшения, если их делать с попыткой реально защитить анонимность, оказываются непрактичными для реализации.
Paul Syverson,tor-talk:
На основании каких мотивов?
Что там собственно прорабатывать? Трясти надо!
Анализ корреляций глобальным наблюдателем – простая атака на Тор и основная угроза для его клиентов! Смешивание, дополнение от нее защищают. Смешивание можно усилить нулевым разглашением, когда узел сам не знает как он перераспределяет по заданным узлам-получателям пересылаемые от заданных узлов-отправителей отдельные 512-битные пакеты (могу расписать подробнее), как допзащита от сибил атаки.
Что там собственно непрактичного? Реализация несложная – строй больше каналов, разделяй трафик, пускай шум. Затраты трафика – не более того чем требуется для заполнения простаивающего канала связи.
Плюс это всегда можно сделать опционально.
Нужно расширять анонимизирующие возможности своего личного тор узла не требущие обновления софта у основной массы узлов сети, хотя понятно что АНБ так спроектировала Тор, чтобы усиление анонимности силами одиночного клиента было затруднено. Собирать выходящие из Тор цельные запросы из отдельных 512-битных пакетов пришедших по разным цепочкам нужно поручить отдельному js-сайту или софту на публичном сервере, который работает с Тор через цепочки прокси. Назначение js-сайта будет известно только его клиенту и только он будет использовать его. Конечно, если появится масса энтузиастов, можно будет передать функцию сборки запросов серверам расположенным на их локалках используя отдельный от торпрожекта софт, их работа будет публичной а пользоваться услугами сможет любой тор клиент. Дополнящий трафик надо оформить как запросы по случайным адресам и загрузка случайных данных по множеству цепочек, частично пересекающихся с цепочками и отвлетвляющихся от цепочек полезного трафика.
комментариев: 11558 документов: 1036 редакций: 4118
Перечитайте цитату Сайверсона. Смешение с задержками (как в микс-сетях) сделает Tor непрактичным для рилтайм-трафика; смешение без задержек и паддинг не защищают от flow fingerprinting'а (который тривиален в сетях с открытым членством).
И, опять же, какой смысл Вам ломать здесь копья? Сделайте свою реализацию, оцените её на модели сети, напишите статью, приведите графики, статистически подтверждающие эффективность предлагаемых мер. А пока это всё
диванныедосужие рассуждения, подкреплённые только битьём себя пяткой в грудь.Возможно ничего нового, но обычно на конференциях демонстрируют новые практические уязвимости в коде с дизайном, без всяких академических процентов.