Прошу объяснить о Торе

А что делать с таким случаем? Как миддлман различит их, если G ему неподконтролен? К вашему другому случаю можно задать примерно тот же вопрос. Кстати, учитите, что между двумя Tor-нодами одно TCP-соединение, через которое идёт весь трафик всех цепочек, путь которых проходит между этими нодами, поэтому, сидя между ними, вы будете видеть только суммарный зашифрованный поток от множества клиентов. Что тут дадут логи netflow — совершенно непонятно.


Это неправда. В каждый момент времени у каждого Tor-клиента открыто несколько цепочек (зависит от нагруженности). И идти эти цепочки могут через разных guard'ов.

А что делать с таким случаем? Как миддлман различит их, если G ему неподконтролен?

Никак, для клиентов из неподконтрольной зоны это не работает, об чём было оговорено.

между двумя Tor-нодами одно TCP-соединение, через которое идёт весь трафик всех цепочек, путь которых проходит между этими нодами, поэтому, сидя между ними, вы будете видеть только суммарный зашифрованный поток от множества клиентов.

Если это так, то логи M_adv всё равно выделят разные цепочки внутри соединения между нодами. В крайнем случае его можно пропатчить.

Это неправда. В каждый момент времени у каждого Tor-клиента открыто несколько цепочек

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

Если по простому: IPstat засекает, допустим, цепочку, но эта цепочка идёт через G на другой M. А в это же время иной клиент (не C_ru) выбрал ваши же G и M_Adv. С точки зрения вашего анализатора, вы будете думать, что это цепочка от C_ru, а это не так.

А вообще, у вас слишком много допущений: контроль трафика на входной точке, трафика на выходной, да ещё и миддлман у противника. Это мало чем отличается от случая, когда все три ноды принадлежат ему.

Пассивное наблюдение: все отдельные цепочки на G_Adv и с E_Adv выделяются по TCP-соединениям и группируются попарно. Среди входящих (и обратно идущих к нему через M) на G_Adv и входящих на E_Adv выделяются пары цепочек, которые имеют наибольшее корреляции по времени-объёму.

Активное вмешательство («одной ячейки достаточно»): в подозреваемых цепочках портятся (задерживаются, удаляются, замещаются) отдельные ячейки и смотрят, как это приводит к порче трафика на другом конце соединения.

Активный способ может дополнять пассивный. Защиту от таких способов Tor не обеспечивает by design.

Если по простому: IPstat засекает, допустим, цепочку, но эта цепочка идёт через G на другой M. А в это же время иной клиент (не Cru) выбрал ваши же G и MAdv.

IPstat засекает связи между узлами, а цепочки потом проверяет программа анализирующая эти связи. Чтобы получилась цепочка, нужно совпадение всех связей в одно время.

между двумя Tor-нодами одно TCP-соединение, через которое идёт весь трафик всех цепочек, путь которых проходит между этими нодами, поэтому, сидя между ними, вы будете видеть только суммарный зашифрованный поток от множества клиентов.

В прошлом комменте ответил только для способа с M_adv. В другом способе, когда подконтрольные ноды отсутствуют и работает только IPstat, наличие нескольких связей внутри одного соединения между Tor-нодами приводит к неопределённости M между G и E. Гард и эксит известны точно для каждого пользователя. Количество их комбинаций 8000^2 = 64 миллиона. Значит для 2.5 миллиона пользователей Tor используемая пара G,E является почти уникальным идентификатором в каждый момент времени. Если сузить число пользователей до российских 90 тысяч, вероятность ложного срабатывания ещё ниже.

А вообще, у вас слишком много допущений: контроль трафика на входной точке, трафика на выходной, да ещё и миддлман у противника. Это мало чем отличается от случая, когда все три ноды принадлежат ему.

Допущения два: возможность корректировать маршрут пакетов внутри зоны и небольшое число подконтрольных нод в сети Tor. Оба достаточно реалистичны, в отличие от "все три ноды принадлежат ему". В первом способе даже подконтрольные Tor-ноды не нужны.

Гард и эксит известны точно для каждого пользователя.

Для пользователя и проверяемого веб-ресурса. Задача обычно состоит в вычислении пользователя по активности на веб-ресурсе, поэтому можно считать что последний задан.

Гард и эксит известны точно для каждого пользователя. Количество их комбинаций 8000^2 = 64 миллиона. Значит для 2.5 миллиона пользователей Tor используемая пара G,E является почти уникальным идентификатором в каждый момент времени.

Нашёл неточность, когда смотрел статистику по Tor. Большинство нод не имеет флагов guard или exit. Сейчас гардов 2300, экситов 1100, поэтому комбинаций G,E около 2.5 миллионов, как и пользователей Tor (в России 90 тысяч). Это снижает точность, но позволяет определить круг пользователей максимум до 2-3 человек. M точно не определён, но условие совпадения связей G — M и M — E ещё больше сужает круг пользователей. Т.е. для данных G и E должен существовать общий M. Это условие, а также совпадение по времени почти всегда сужают круг до одного пользователя. В исключительных случаях, когда это не так, к уже известному малому числу пользователей можно применить активное воздействие на трафик, о котором упомянул unknown. Но без предварительного пассивного наблюдения, позволяющего вычислить предполагаемую цель, оно практически бесполезно.

C_ru все свои цепочки строит через G. IPstat видит всё вместе. G принимает соединения от многих пользователей, а не только трафик от IPstat. У M_Adv не будет простой определённости на предмет того, где чьи цепочки. Грубо говоря, G тут работает как миксер. К тому же, цепочек много, и они постоянно меняются. И одно дело, если речь идёт о скачивании гигабайтов, потому что при обычном серфинге время от времени скачивается/закачивается мизерный объём. Этот как пушинка в довесок к основному трафику, который проходит через эти ноды. Чтобы не было false positive нужны довольно лабораторные условия.


Это всё общие слова, а не конкретные цифры. Вот когда начнёте делать атаку для реальных сценариев, писать и тестить код, так сразу все проблемы и вылезут. Как бы ни оказалось, что для надёжного подтверждения того, что юзер X ходит на сайт Y, потребуется пассивно наблюдать его трафик много лет, и даже это не спасёт от false positive/negative.

Не силён в методах статистической обработки, но интуиция подсказывает что информации достаточно. Можно совсем по-простому если подняться на уровень TCP: IPstat логирует только SYN-пакеты, остальные может игнорировать. Тогда однозначно получается цепочка в момент установления соединения, без всякой статистической обработки. Можно и целиком сеансы между C — G и E — S установить (начало и конец по времени), если отслеживать номера последовательности и подтверждения в заголовке TCP. Или воспользоваться готовым решением в виде NAT.

Мне не особо интересно исследовать детали возможной реализации этой системы, т.к. не собираюсь её создавать. Для меня очевидно что создать её можно в рамках имеющихся у государства ресурсов. Достаточно понимать концепцию и потенциал угрозы чтобы принять адекватные меры по снижению её эффективности. Очевидная мера – удлинение цепочки.

Если считаете, что открыли новую атаку на Tor, то создайте отдельную тему, где в начале заново разложите всё по полочкам. А то из разрозненных коментов не всё понятно. Может вы в чём-то окажетесь правы, а возможно и нет. Может ваша атака не работает, удлинение цепочки анонимность не повышает, а наоборот существует метод профилирования пользователей с искусственно завышенной длиной цепочки. Пока этот метод нельзя изложить так, что его нельзя даже донести в достойном для рассмотрения виде до торпроджекта, он так и останется гипотетическим и нерекомендуемым.

Насчёт логирования SYN-пакетов наверное был неправ. Между E и S это делается, т.к. соединение открытым текстом, но между C и G SYN-пакет идёт внутри шифрованного канала. Логировать его можно только если у него есть отличительные особенности (о чём мне неизвестно).

G принимает соединения от многих пользователей, а не только трафик от IPstat.

Пользователи различаются по IP-адресу C_ru. IPstat логирует пакеты для пары C_ru,G.

У MAdv не будет простой определённости на предмет того, где чьи цепочки.

В реальном времени M_adv определяет только сами цепочки G — M_adv — E. А кому они принадлежат, т.е. вычисление C_ru и S_ru, осуществляется после объединения его логов с логами IPstat.

В принципе, при возможности контролировать маршрут пакетов, т.е. иметь логи IPstat, достаточно корреляции по времени и объёму на входе-выходе Tor-сети (C_ru — G, E — S_ru). Если она удовлетворительная, то M_adv не нужен. Выглядит примерно так. Из логов сервера известно, что пользователь с 10 до 11 часов получил 5 МБ, отправил 300 КБ. Из логов IPstat находится нужная связь E — S_ru, причём точно, без привлечения статистики. Есть небольшая вероятность что ещё другой пользователь использует связь E — S_ru, в этом случае поможет логирование SYN-пакетов на этом участке. Т.е имеем фингерпринт трафика на выходе из Tor (10.00-11.00, 300КБ/5МБ). После этого ищем аналогичный фингерпринт на входе, между C_ru и G. Тут уже нужны статистические методы для вычисления корреляции по объёму, т.к. в отличие от E,S_ru, трафик C_ru,G зашифрован, что вносит погрешность в количество байтов. Кроме этого, Tor ставит своё ограничение в 512 байт на размер пакета, что тоже вносит дополнительную погрешность. Для большого количества мелких пакетов, типа ssh и jabber траффика, размер 512 байт может существенно осложнить корреляцию. Для http трафика эта погрешность меньше. Тем не менее, погрешность как от шифрования, так и от ограничения в 512 байт, может быть устранена, т.к. между E,S_ru трафик полностью известен с точностью до пакета. Между C_ru,G зашифрованная и искажённая тором (512 байт) копия этого трафика. Способы шифрования и искажения известны, поэтому по известному открытому соединению определяется его вид после шифрования. Т.е. по фингерпринту (время-объём) открытого трафика E,S_ru восстанавливается фингерпринт зашифрованного C_ru,G. После этого из логов IPstat находится пара C_ru,G и получается связь между C_ru — G и E — S_ru. Наличие M_adv облегчает нахождение этой связи, т.к. точно даёт G, сужая поиск C_ru. Без M_adv нужно определять корреляцию из всех пар C_ru,G для заданного интервала времени.

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

Если всё сводится к атакам пересечения и статистическим классификаторам, ссылки на которые проскакивали в новостях, то в принципе неважно, какой стране принадлежит гвард, если ISP знает статистику соединений своего клиента со всеми гвардами.

Так и есть, во втором способе (с M_adv или без него) это неважно. Это нужно в первом способе, когда территориальная принадлежность G и E заменяет необходимость M_adv. Но если нахождение M для цепочки не применяется, то различие между этими способами исчезает.

Там нет SYN-пакетов или других tcp/ip пакетов, внутри цепочек существуют потоки которые никакого отношения к tcp/ip стеку не имеют.
Tor это не tcp-over-tcp, а data-over-tcp.
(раньше и дальше не читал)