id: Гость   вход   регистрация
текущее время 21:32 28/03/2024
Владелец: unknown (создано 20/02/2014 11:27), редакция от 20/02/2014 12:19 (автор: unknown) Печать
Категории: софт, tor
https://www.pgpru.com/Новости/2014/CorridorПростойСпособФильтрацииУтечекTor-трафикаНаВнешнемРоутере
создать
просмотр
редакции
ссылки

20.02 // Corridor: простой способ фильтрации утечек Tor-трафика на внешнем роутере


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


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


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

Пользователь Rusty Bird предложил простое решение — набор скриптов corridor.


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


Принцип работы скриптов corridor состоит не в заворачивании трафика в сеть Tor на роутере, а в блокировании всего проходящего не-Tor трафика. Иначе говоря, такой роутер является не прокси, а фильтрующим узлом на основе белых списков:


  1. Для этого на роутере запущен клиент Tor, который собирает данные статистики (консенсуса) тор-узлов. Также могут обрабатываться данные бридж-узлов.
  2. Данные передаются в Linux ipset только для сторожевых и корневых узлов (при необходимости — ещё и мостовых).
  3. Файрволл iptables разрешает для проходящего трафика только TCP-соединения и только с узлами из п. 2.

Принцип работы corridor требует двух сетевых интерфейсов (одним из них м.б. Wi-Fi), при этом он не защищает от атаки, в которой злонамеренное ПО, внедрившееся на компьютер пользователя, передаёт его IP-адрес или идентифицирующие данные на злонамеренный сторожевой узел Tor, который сотрудничает с этим клиентом вредоносного деанонимизирущего ПО. Для этого пользователь может подстраховываться дополнительными средствами, например такими, как виртуальные машины.


Набор shell-скриптов проекта выглядит крайне простым. В будущем автор предлагает упростить расшаривание Wi-Fi соединений — все обращения к портам 80 и 443, не относящиеся к Guard, DA и bridge узлам, будут перенаправляться на страницу Torproject.org (или на страницы выбора tails.boum.org, guardianproject.info, f-droid.org). Возможно включение DHCP-сервера для внутренней сети, чтобы к роутеру без проблем могло подключаться множество пользователей. Также автор считает перспективным использование установочных пакетов для минисистем Raspberry Pi / BeagleBone Black.


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


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


Автор предупреждает, что Corridor является неотлаженной концепцией с возможно невыявленными уязвимостями и не имеет официальной поддержки со стороны Torproject.


Источник: Corridor, a Tor traffic whitelisting gateway, Tor-talks mailing list.


 
— Гость (23/02/2014 07:30)   <#>

Local root?! Уязвимости бывают разные.


По-моему, это неправда. Если у клиентских машин разные IP, то Tor раскидает их трафик по разным цепочкам. SOCKS там или прозрачная торификация — важно ли?


Тоже аноним? Похоже, аргументы популярны. :-)


Увы, wrong design, если позиционировать именно так. Я бы даже сказал, что мервторождённая идея. И в Tor-рассылке сплошной флуд не по делу вместо здоровой критики.


Они здесь не помогут.


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


Ценой того, что почти вся защита тоже улетучивается.

…………………………………………………………………………………………………………

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

Corridor не гарантирует ничего кроме того, что он режет трафик, идущий не на guard. Если в виртуалке, в браузере заведётся трой, который будет слать левый трафик на guard, corridor ничем не поможет. Можно посылать трафик не на тот порт guard'а, который используется Tor'ом. Если порт тоже фиксирован corridor'ом, можно сыграть на разнице в статистике: сейчас там запущен Tor, а через 5 минут уже нет. Corridor не сможет отслеживать эти изменения с идеальной точностью по времени. Можно подсунуть клиенту свой guard или взломать тот, который он использует, поставив там перенаправление трафика туда, куда хочется, в обход Tor. Зловред в виртуалке пошлёт любой TCP-трафик на указанный порт (да хоть SSH) вместо Tor-трафика, и corrdior это пропустит — он ведь не DPI, он по IP и порту не распознает, какой там протокол. Заметьте, что с традиционным Tor-роутером/проксёй на внешнем узле/хостовой системе ничего из перечисленного работать не будет, а тут уязвимость на клиенте + тонкости настройки или компрометация guard'а — и всё, приехали. Фактически corridor требует полного и безоговорочного доверия guard'у, в ином случае он ничего не гарантирует в плане защиты от утечек, особенно злонамеренных.


Вангую, что в текущем представлении и не заимеет. Подавать corridor как дополнительную фичу к уже работающему роутеру в качестве дополнительной защиты от уязвимостей самого Tor-клиента — уже другое дело, но и тут всё не очень хорошо с рекламой. Сейчас guard'ы живут долго, и в норме меняться не должны длительное время. Весь трафик в норме идёт только через guard'ы. А раз так, то вместо риска получить ещё одну дыру из-за чужих малоизученных костылей, куда проще прописать в файерволле разрешение трафика только на собственные guard'ы. Когда понадобиться через пару месяцев их сменить, процедуру можно будет повторить. Список guard'ов вроде не зависит от количества клиентов, требующих неперекрывающиеся цепочки, поэтому в локалках тоже применимо.
— unknown (23/02/2014 15:43)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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

Одно дело, когда на машине есть несколько профилей и только одному разрешено делать NEWNYM и можно закрыть окошки TBB и др. торифицированные программы, физически переключаясь между консолями. Другое дело — когда реально удалённые машины с разной степенью доверяемости.

Здесь фича в том, что поломать клиента проще, чем роутер. Так что будет скомпрометирован только один клиент со своим NEWNYM и коннектами для управления к своему тор-процессу. Остальные — не пострадают. А в прозрачной торификации — доступ к управлению общим тором давать опасно, а управлять им отдельно или вообще не пользоваться сбросом цепочек — неудобно.


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

Ну или, к примеру, расшаренный VPN только для пользователей тора — если тор где-то блокируют. Сам VPN можно тоже подо что-то анти-DPI замаскировать. Это вместо приватного бриджа, к примеру.


Нужно ухитриться подсунуть свой злонамеренный guard. Если нет ключей от гварда, то запрос клиента не расшифруется.


Какими бы стабильными они не были, все трое умолчальных гвардов могут в какой-то момент отключиться и/или временно потерять статус гвардов. И клиент будет выцеплять для себя из статистики новых гвардов. Как-то руками это всё запарно прописывать в файер, когда есть готовый скрипт.
— Гость (24/02/2014 09:31)   <#>

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


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


Да, для n профилей одного и того же пользователя это подходит, а для нескольких пользователей уже нет.


Вообще, плохо тем же, чем и «на каждый профиль по своему Tor-процессу»: каждый Tor-процесс использует свой набор guard-узлов, поэтому внешний атакующий сможет различать трафик одного профиля от трафика другого. Прописывание всем одних и тех же guard-узлов, думаю, тоже не поможет(?) — там же появятся дополнительные TCP-сессии до guard'ов, хотя в норме всё идёт через один поток(?).


Да, но цена того — лучшая защита от утечек + единый набор guard'ов для всех. На уровне домашней сети можно сделать единый переключатель: подошёл, дёрнул, и цепочки перестроились. Правда, это всё равно плохо: внешний атакующий будет видеть, что когда происходит смена выходных узлов, она почему-то происходит одновременно и у пользователя A и у пользователя B, из чего делается однозначный вывод о том, что они сидят за одним Tor-процессом. Из-за этих тонкостей сверхкритичные к анонимности профили лучше вообще не смешивать с посторонними профилями одновременной работой. Т.е., да, тот факт, что если запущен профиль A, то профиль B не работает, — тоже дополнительная информация, а, значит, утечка, но она, IMHO, менее критична, чем первая.


Т.е. так они хозяину роутера не доверяют, а подстраховку от деанона они ему доверяют? C VPN так же. Клиент согласен доверять чужому серверу управление своими подстраховками через предоставление списка собственных guard'ов, при этом не имея возможности проверить, работают ли эти подстраховки на деле вообще? А если каждый не будет подсовывать ему свои guard'ы, то corridor упростится до «разрешать трафик на все guard-узлы Tor'а», что обходится ещё проще.


Пусть атакующий — ISP. Пусть он смог установить мальварь в анонимный профиль Tor-пользователя. Пусть эта мальварь стучится на guard-узел по заданному протоколу, передавая какой-то предопределённый набор данных. Например, если guard принимает Tor-трафик на порту 9001, ISP настроит мальварь на стук по ssh на этот же порт 9001 этого же guard'а. Во время атаки ISP подсовывает собственный узел, выдавая его за выбранным Tor-юзером guard (IP не трудно прописать). Если профиль действительно заражён малварью, то понконтрольный ISP «guard-узел» получит ssh-траф, направленный на него. Если профиль незаражён, то подставной «guard-узел» получит или ничего или обычный Tor-трафик, который он не сможет расшифровать. Итак, мы нашли различитель. Схема с corridor неустойчива к сертификационному анонимность-анализу. Прошу снять с конкурса. При использовании традиционных Tor-роутеров такого различителя нет (хотя у них есть свои проблемы, на которые вы правильно указали, но если смириться с неудобством смены цепочек, то настолько зияющих дыр в защите анонимности не будет).


Fxd. ☺
— unknown (24/02/2014 10:25, исправлен 24/02/2014 10:52)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Эта схема действительно не защищает от описанной атаки на профиль. При отсуствии corridor всё будет также, только проще. Остаётся защита вида «поломали один профиль, но не поломали другие и не связали с ними». Если, к примеру, один профиль на виндовой машине или смартфоне может иметь эксплойт, а на линуксовой — нет.


В прозрачной торификации троян может запустить свой локальный тор-процесс и делать дважды торифицированные через внешний роутер тор-запросы. Это, конечно, сложнее и извращённее, но может тоже можно найти какой-то различитель?


Например, быстро перебирать кучу подобранных запросов по цепочкам вида [G'M'E'] и ждать, когда в результате внешней неподконтрольной торификации получится самообратимая цепочка вида [G'M'E'EMG]. Если при этом есть подконтольные экситы, которые одновременно являются гвардами (E = G), то ждать когда выпадет E' = E и/или G = G'. Тогда на таком эксите можно выделить запрос своего трояна и выяснить, с какого айпишника шлются запросы путём связывания троянского трафика с трафиком внешней торификации. И сделать деанон с раскрытием айпишника всех связанных в общую торификацию профилей.


Из-за этих тонкостей сверхкритичные к анонимности профили лучше вообще не смешивать с посторонними профилями одновременной работой. Т.е., да, тот факт, что если запущен профиль A, то профиль B не работает, — тоже дополнительная информация, а, значит, утечка, но она, IMHO, менее критична, чем первая.

Верно. В т.ч. при прозрачной торификации нельзя делать NEWNYM одновременно. Т.е. в одном профиле можно смотреть один сайт или группу тематически связанных, пусть цепочки только по таймауту перестраиваются. А в фоне в другом профиле можно скачать почту, апдейты, chat, bitcoin или нечто аналогичное ненадолго включить. Если нужно перейти к просмотру сайтов другой тематики, то перед тем как перезапустить торбраузер и сделать NEWNYM, придёться закрыть программы (убрать активность) во всех других профилях. Что как бы тоже небольшая утечка информации (антикорреляция).


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

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

— Гость (24/02/2014 13:58)   <#>

Различитель на экситах и различитель на стороне ISP разные по степени опасности. В первом случае до конечного пользователя ещё надо добраться (и простых путей нет), а во втором случае он уже на ладони.

В сценарии типа того, что имел место с FH, понятно, как воспользоваться вторым различителем на практике: раз внутри профиля guard известен (corridor используется, но Tor запущен на локальной машине), малварь знает, куда слать трафик. Остаётся только договориться со всеми ISP сделать у себя guard'ы-ловушки, и атака будет в действии.

Что же касается различителей на экситах, то всё намного проще: зачем дважды заворачивать трафик в Tor? Достаточно постоянно (или хотя бы иногда) посылать через Tor какой-то трафик на подконтрольный атакующему узел. Таким образом, заражённый мальварью профиль будет светиться на всех экситах, и, помимо этого, атакующий будет знать, какой именно эксит в какой момент он использует. Но, другое дело, найти пользователя Tor физически, зная его экситы — это ещё очень хорошо постараться надо, в общем случае.


Зачем ждать? Tor-клиент волен сам выбирать guard'ы, какие хочет. Их можно статически в конфиге задать:
UseBridges 1
UpdateBridgesFromAuthority 0
Bridge IP_OF_GUARD1:PORT1 FINGERPRINT1
Bridge IP_OF_GUARD2:PORT2 FINGERPRINT2
Bridge IP_OF_GUARD3:PORT3 FINGERPRINT3
FastFirstHopPK 0
Считайте, что E' = E сразу, только вот владелец эксита, даже если он подконтролен атакующему, не знает guard-узел от прозрачной торификации, поэтому найти G ему будет проблематично. Можно предположить, что guard-узел G тоже принадлежит ему, и тогда он по возникновению обратной цепочки каким-то образом по корреляциям сможет догадаться, что прямая цепочка такая же, но это всё уже совсем запредельные спекуляции. В конце концов, если ему принадлежат и guard и эксит, то есть множество куда более простых атак (те же атаки пересечения), так что прозрачная торификация тут ничуть не более уязвима, чем всё остальное.


IPшник вы получите локальный, куда его пришить? Единственный способ получить реальный IP — вызывать какие-то флуктуации в трафике и смотреть их возникновение в шифрованном трафике на стороне ISP/guard'ов.


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


Никакие там аномалии разбирать ненужно. У каждого Tor-процесса с каждым из своих guard'ов в норме, в стабильном режиме, работает только одна TCP-сессия. Все узлы между пользователем Tor и guard'ом, включая ISP, видят число открытых TCP-сессий. Вы их можете по netstat'у у себя посмотреть. Итак, если число открытых TCP-сессий между одним и тем же IP и каким-то guard'ом равно n, то это значит, что запущено n Tor-клиентов. Друг от друга, т.е., они отличаются элементарно.
— unknown (24/02/2014 14:24)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Пусть малварь шлёт какой-то специфический TCP-пакет. Тогда одна часть трафика в цепочке на эксите от других клиентов пойдёт наружу, а другая часть из этой же цепочки завернётся ещё раз в тор. Её начало надо будет поймать на другом эксите, который является общим для них гвардом. Этот злонамеренный узел и расшифрует TCP-пакет как явную метку, безо всяких там модуляций. Так мы узнаем IP гварда, а не внутренней сети.

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

В диком виде (без малварей) такие атаки пересечения будут заметны — узлы не могут незаметно разделять и заворачивать трафик. А отдельная от торбраузера малварь — может. В диком торе атаки пересечения могут массово существовать только в пассивном виде, где они действительно малоэффективны. А малварь может безнаказанно адаптивно подбирать узлы.
— Гость (03/03/2014 06:16)   <#>

Я долго думал, и у меня практически не получилось вас понять. Юзерская Tor-цепочка: Guard → Middleman → Exit. Малварная цепочка: Guard-M → Middleman-M → Exit-M. «Общий гвард» если у них, то как он может быть ещё и Exit'ом для малвари? А если гвард = Exit-M, то он не «общий для них».

Гадать — неблагодарная работа, но допустим, что мальварь пытается подобрать свой Guard-M таким, чтобы он совпал с юзерским Guard. Поскольку цепочку формирует малварь, никто ей не запретит выбрать любой Middleman-M и тот же самый Exit = Exit-M. Что мы заложили — то и получили, пакет пройдёт по узлам и выйдет на этом же Exit'е. Что это будет доказывать? Как вы узнаете, что Guard был угадан или не был? Ну, можно ещё блочить всю цепочку или всю за исключением её малварного трафика и смотреть, что получится, но я всё равно не могу свести концы с концами, чтобы получить простой способ атаки (во всяком случае, существенно более простой, чем без малвари). Гипотетически, если все узлы друг с другом общаются и обмениваются статистикой, то можно сделать всё, но это не секрет, и тут и без малвари можно обойтись.
— unknown (03/03/2014 11:18, исправлен 03/03/2014 14:28)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Юзерская Tor-цепочка: Guard → Middleman → Exit. Малварная цепочка: Guard-M → Middleman-M → Exit-M.

Допустим, то, что называется «юзерская цепочка» формируется на роутере с прозрачной торификацией и малвари недоступна. Малварь сидит на клиенте. Малварь посылает два запроса: прямой, без предварительного заворачивания в тор, котрый завернётся только на роутере (Guard → Middleman → Exit) и предварительно завёрнутый, с которого через роутер получится Guard → Middleman → Exit → Guard-M → Middleman-M → Exit-M.


Здесь возможны разные варианты, которые я подробно не разбирал, поэтому и путаница. Основной: если Guard — подконтрольный и является одновременно исходящим, то малварь должна ждать пока своя цепочка не получит [Exit-M = Guard], тогда такой узел расшифрует дважды завёрнутый запрос малвари; второе необходимое условие: чтобы Exit оказался тоже подконтрольным, тогда на нём можно расшифровать незавёрнутую цепочку с сигналом малвари.


Сопоставив расшифрованные метки в разделяющейся цепочки с двух подконтрольных узлов (Exit и [Exit-M = Guard] ) можно выделить эту цепочку не приблизительно, а доказательно точно (хоть электронную подпись в запрос можно встроить).


При этом выигрыш сильнее, чем от простого выбора злонамеренного гварда — гвард выбирается раз, долго не меняется, выбрать злонамеренный — вероятность сотые доли процента. А здесь вероятность его выбора — такая же как для эксита (т.к. злонамеренный гвард является одновременно экситом) и подтверждение выбора — 100%, а не то, как обычный злонамеренный гвард пытается что-то вычислить статистически про пользователя.


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


Можно иметь пару подконтрольных узлов Guard-M и [Exit-M = Guard].


Тогда, одиножды завёрнутый в тор трафик от трояна выходит через любой неподконтрольный эксит и стучится на некий порт в подконтрольном Guard-M, отсылая пакет с меткой или сливая этому узлу всю цепочку Guard-M → Middleman-M → Exit-M вместе с сеансовыми ключами. А на [Exit-M = Guard], отлавливается дважды завёрнутый в тор трафик, зная параметры цепочки и также извлекает после расшифровки метку трафика для точного подтверждения.


После получения такого доказательства, что [Exit-M = Guard] для роутера, аналогично вычисляется айпишник роутера, который подключился к Guard. Вариант лучше тем, что Guard-M троян может не ждать, пока он выпадет на роутере, а выбирать при построении цепочки сам.


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

— Гость (04/03/2014 20:58)   <#>
Двойное заворачивание в Tor ещё давно хотели прикрыть, и тогда в лоб работать не будет. Однако, никто не запрещает малвари поставить промежуточный узел между Exit'ом и Guard-M'ом.
— Гость (07/03/2014 08:04)   <#>

Да, это понятно.


Не согласен.


Тоже слишком упрощено.


Самопротиворечивое предложение. Если Guard уже является исходящим,* то ждать ничего не надо.

Ладно, не ограничивая общности, можно считать, что некоторый подконтрольный Guard-X (не обязательно совпадающий с истиным Guard) узнает всю подноготную малварной цепочки, включая то, какой был Exit у юзерской цепочки, но дальше-то что? Как он узнает, что он до этого пропускал эту цепочку через себя в шифрованном виде? Малварный трафик будет подмешан в юзерский трафик, разбит на пакеты, нормализован и отправлен общим потоком. Если не делать хитрые атаки пересечения и/или не моделировать трафик, я не вижу простых способов этому Guard-X узнать, он ли есть настоящий Guard. А раз так, прежде чем будет получено Guard-X=Guard, каждому подконтрольному Guard-X надо будет делать атаку пересечения. Однако, поскольку малварный трафик после выхода с Tor-роутера идёт внутри общего шифрованного тунеля, Guard-X будет вынужден прерывать всю цепочку для атаки пересечения, поэтому трафик других программ, а не только малвари, тоже будет испытывать проблемы. Т.е. большей скрытности, чем обычные атаки пересечения, тут не получить. Ну, или я вас совсем не понял.

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

P.S. Мы тут однажды уже натеоретизировались, а когда стали разбираться с матчастью, всё оказалось отнюдь не так просто, как казалось.

*Я так понимаю, речь идёт про Exit для малварной цепочки, поскольку юзерская цепочка никогда не выбирается так, чтобы её Guard и Exit были одним и тем же узлом.
— unknown (07/03/2014 10:23)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Согласен. Не готов всерьёз доказательно разбирать эту тему.
— Гость (27/03/2014 22:20)   <#>
Противник будет знать всё: кто, откуда, когда и что делал. Только клиент-провокатор потом смоется или прикроется полицейской защитой, которая решила устроить провокацию, а владелец Wi-Fi-роутера ответит за всё по полной
А для вас полиция – априори противник?
— unknown (28/03/2014 10:00, исправлен 28/03/2014 10:16)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Почему? Это м.б. любой представитель недоверенного круга, обладающий техническими возможностями и мотивами нарушения приватности/анонимности, как-то: представители спецслужб, властей, политических организаций, крупных коммерческих корпораций — всё это в равной мере справедливо для своего/зарубежного государства; хакеры-взломщики, как работающие на вышеперечисленных, так и на другие группировки; криминальные элементы; отдельные индивидуалы с непонятными мотивами и пр.


/comment38381:


Государство надо включать в качестве противника в любую модель безопасности. Не по политическим мотивам и не потому что оно по своей природе обязано быть плохим (спецам по ИБ на этом особо заморачиваться не стоит). Просто потому что безопасная система должна быть безопасна от всех.

Иначе получим коррумпирующий эффект — не только государство, но и крупные корпорации могут продвигать через госорганы свои интересы в слежке, сваливать друг на друга ответственность. В итоге из-за этих компромиссов получаем полный бардак с той же системой УЦ в мировом масштабе.

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

— Гость (11/06/2014 23:58)   <#>
Какими правилами при выборе входных нод следует руководствоваться? Принадлежность к разным странам наверное первое правило. Может существуют признаки по которым ноды нужно отбраковывать.

Если задавать входные ноды вручную и две из них перестанут работать, то весь трафик пойдёт через одну. Не снизит ли это анонимность?

Можно ли бриджи использовать как дополнение к основной трёхнодовой цепочке, а не вместо guard-ноды? Чтобы полная цепочка состояла из 4 нод.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3