Всё о TBB (Tor Browser Bundle)

Допустим я торчу через тор в jabber или юзаю openssh, одновременно шарясь по www торбраузером. Исходящая нода сможет определить что в jabber и неком www ресурсе один и тот же я?

Время смены цепочки для новых подключений около 10 минут. Для уже установленного соединения цепочка не меняется, пока TCP-сеанс принудительно не закроется клиентом. Если все заторенные клиенты почти одновременно пошли на один порт Tor-клиента, то будут использовать одну цепочку. В этом случае на эксите их можно связать между собой, т.к. они к нему приходят от одинаковой middle-ноды.

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

Проще Tor перезагружать между запусками разных программ. Или установить флаг IsolateDestPort для SOCKSPort. Джаббер, ssh и торбраузер на разные порты ходят, так что флага достаточно.

А можно чтобы входящий узел был одинаковый, а дальше цепочки разные?

Используйте опцию NumEntryGuards 1
Но это не исключит возможности ротации входящих узлов, с распределением новых и старых цепочек по разным гвардам.
Или можно статически ограничиваться каким-либо гвард узлом, через опцию EntryNodes или использование узла в качестве бриджа. Но возможно клиент ошибочно пометит узел как недоступный, если не дождался ответа, к примеру. Тогда не будет никакой ротации узлов и никакой связи.

А противник пронюхает это дело и поставит для вас невидимую ссылку на 5222/5223-ий порт по HTTP в веб-странице. Вот тут-то вы и спалитесь по полной.


Число входящих узлов в норме 3. Вроде можно прописать статически как больше, так и меньше, но это будет распространяться на все цепочки. Чтобы цепочка зависела от Guard'a — про такое не слышал. Думаю, это не лучшим образом могло бы сказаться на анонимности. В крайнем случае, можно запустить несколько Tor-клиентов, каждый — со своей политикой по Guard'ам, но это тоже будет плохо для анонимности, так делать не рекомендуют. Вы этим выделите себя из массы пользователей Tor.

В норме guard-узлы меняются раз в 2-3 месяца.

Пожалуй то что надо.


Не важно что идет ротация, важно, чтобы в каждый момент времени входящий узел был один.

Клиент может отказаться на некоторое время от использования узла, если ответ не уложился по времени. Максимальное время строительства цепочки клиентом расчитывается для конкретных сетевых условий, в целях выбора приемлимой цепочки. В нормальных сетях это значение пара секунд, а то и меньше, таймаут на ответ от первого узла может быть меньше секунды. Стоит гварду опоздать и клиент переключает все новые цепочки на другой гвард, все "старые" продолжают использовать "неработающий" гвард. Они старые лишь условно, к ним ещё может быть подключено множество новых потоков, которые связаны с соединениями на сокс порту. Всё зависит от правил у экситов в этих цепочках.
Это принудительная "ротация", во имя скорости.
Можете глянуть в state файл, там запомнено больше чем 3 гварда, но одновременно клиент считает живыми не более чем число из NumEntryGuards.

Это нужно затем, чтобы локальный провайдер не различал трафик от разных программы и пользователей. Локальный провайдер Guard'а будет конечно видеть все его связи и временнЫе корреляции трафика, но Guard'ы сильно загружены, трафики от разных клиентов у них сильно смешаны по времени.

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


Выделение себя на входящих узлах не так страшно, как деанон на выходящих. Ну пусть заносят в расстрельные списки, мне не жалко.

Ссылки на обсуждение таких идей приводились в /comment78594:

No mixing, padding, or traffic shaping (yet)

Recent research [1] and deployment experience [4] suggest that this level of resource use is not practical or economical; and even full link padding is still vulnerable [33].

Thus, until we have a proven and convenient design for traffic shaping or low-latency mixing that improves anonymity against a realistic adversary, we leave these strategies out.

Идея про смешивание, дополнение и зашумливание в том примитивном виде, как здесь предлагают, была во многом изучена и отвергнута ещё в лабораторных условиях, до запуска сети Tor. С тех пор вышло много исследований по улучшенным вариантам протоколов, пытающихся создать что-либо подобное. Но они либо оказываются теоретически непроработанными; либо выясняется, что они защищают от сложных и непрактичных атак, в то время как не защищают от более простых; либо такие улучшения, если их делать с попыткой реально защитить анонимность, оказываются непрактичными для реализации.

Paul Syverson,tor-talk:

Tor is a flavor of onion routing not mixing. They have a different design, a different threat model, and a different basis for security. It is possible to combine them, as we did in the version of onion routing we did between the first version and Tor. But Tor does not use any mixing, and it did not evolve from mixing.

The main problem, besides the overhead, is that padding doesn't work
if an adversary can do something as trivial as very briefly delaying It is too easy for an adversary to put a traffic signature on a circuit in one place, and look for it elsewhere. If he owns, e.g., the first node and any of the last node, the link to the destination, or the destination it won't matter what kind of padding is done. There's lots of published work showing this in various ways. Some already alluded to in this thread. If nothing else the adversary can just kill the connection at the first node and see which connection exiting the network dies.

На основании каких мотивов?


Что там собственно прорабатывать? Трясти надо!


Анализ корреляций глобальным наблюдателем – простая атака на Тор и основная угроза для его клиентов! Смешивание, дополнение от нее защищают. Смешивание можно усилить нулевым разглашением, когда узел сам не знает как он перераспределяет по заданным узлам-получателям пересылаемые от заданных узлов-отправителей отдельные 512-битные пакеты (могу расписать подробнее), как допзащита от сибил атаки.


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

Нужно расширять анонимизирующие возможности своего личного тор узла не требущие обновления софта у основной массы узлов сети, хотя понятно что АНБ так спроектировала Тор, чтобы усиление анонимности силами одиночного клиента было затруднено. Собирать выходящие из Тор цельные запросы из отдельных 512-битных пакетов пришедших по разным цепочкам нужно поручить отдельному js-сайту или софту на публичном сервере, который работает с Тор через цепочки прокси. Назначение js-сайта будет известно только его клиенту и только он будет использовать его. Конечно, если появится масса энтузиастов, можно будет передать функцию сборки запросов серверам расположенным на их локалках используя отдельный от торпрожекта софт, их работа будет публичной а пользоваться услугами сможет любой тор клиент. Дополнящий трафик надо оформить как запросы по случайным адресам и загрузка случайных данных по множеству цепочек, частично пересекающихся с цепочками и отвлетвляющихся от цепочек полезного трафика.

Перечитайте цитату Сайверсона. Смешение с задержками (как в микс-сетях) сделает Tor непрактичным для рилтайм-трафика; смешение без задержек и паддинг не защищают от flow fingerprinting'а (который тривиален в сетях с открытым членством).

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

Давненько не было атак от хэкеров: анонс методов деанона, детали возможно в августе на конференции.

we've discovered that a persistent adversary with a handful of powerful servers and a couple gigabit links can de-anonymize hundreds of thousands Tor clients and thousands of hidden services within a couple of months

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