Прошу объяснить о Торе
Здравствуйте, уважаемые. Как я понял, входящие пакеты расшифровываются с первой ноды и приходят ко мне уже в незашифрованном виде. Неужели мой провайдер никак не увидит эти уже расшифрованные пакеты и тем самым не может определить их содержимое?
Ссылки
[link1] https://gitweb.torproject.org/tor-launcher.git/blob/HEAD:/src/chrome/content/network-settings.xul
[link2] https://www.torproject.org/docs/debian.html.en
[link3] https://www.pgpru.com/biblioteka/osnovy/fondpoleznyhpostov/anonimnostj#fppCC3
[link4] https://www.torproject.org/docs/tor-doc-relay.html.en#torrc
[link5] https://www.torproject.org/docs/faq.html.en#LimitTotalBandwidth
[link6] https://www.torproject.org/docs/faq.html.en#EverybodyARelay
[link7] https://lists.torproject.org/pipermail/tor-talk/2013-April/027874.html
[link8] https://trac.torproject.org/projects/tor/ticket/5903
[link9] http://torstatus.blutmagie.de/index.php
[link10] http://torstatus.blutmagie.de/router_detail.php?FP=d64366987cb39f61ad21dbcf8142fa0577b92811
[link11] http://torstatus.blutmagie.de/router_detail.php?FP=548537e4d2b1adfdf0e2aa3a9ce71902feb4579d
[link12] https://trac.torproject.org/projects/tor/ticket/9386
[link13] https://trac.torproject.org/projects/tor/ticket/7144
[link14] https://lists.torproject.org/pipermail/tor-talk/2012-May/024378.html
[link15] https://www.torproject.org/docs/faq#AlternateDesigns
[link16] https://www.torproject.org/docs/faq.html.en#ChoosePathLength
[link17] http://www.pgpru.com/novosti/2011/koncepcijapostroenijacepochekvtorsetivzavisimostiotdoverijakuzlam
[link18] http://www.pgpru.com/novosti/2011/10sposobovraskrytijabridzhuzlovtor
[link19] http://www.pgpru.com/comment27294
[link20] http://www.pgpru.com/comment27370
[link21] http://www.pgpru.com/comment42879
[link22] http://news.techworld.com/security/3505255/tor-network-used-to-hide-900-botnets-and-darknet-markets-says-kaspersky-lab/
[link23] http://www.pgpru.com/comment80340
[link24] http://www.pgpru.com/comment80361
[link25] http://www.pgpru.com/comment80370
[link26] http://www.pgpru.com/comment80371
[link27] http://www.pgpru.com/comment77044
[link28] http://www.pgpru.com/comment80465
[link29] http://www.pgpru.com/comment80505
[link30] http://www.pgpru.com/biblioteka/statji/principypostroenijaanonimnyhsetejj
[link31] http://www.pgpru.com/forum/anonimnostjvinternet/setjszaschitojjotglobaljnogonabljudatelja
[link32] http://www.pgpru.com/comment80504
[link33] http://forum.kaspersky.com/index.php?showtopic=252529
[link34] https://www.torproject.org/docs/faq.html.en#SendPadding
[link35] http://www.pgpru.com/comment23426
[link36] http://www.pgpru.com/comment70557
[link37] https://www.pgpru.com/comment80504
[link38] https://www.pgpru.com/comment80465
[link39] http://www.pgpru.com/comment80573
[link40] http://www.pgpru.com/comment52201
Вы поняли неправильно. Исходящий трафик зашифровывается Tor-клиентом, а расшифровывается экзит-узлом. Входящий, аналогично, идёт зашифрованным от экзит-узла непосредственно до Tor-клиента.
Если Tor-клиент установлен локально на Вашей машине, то никак.
Ясно. Благодарю вас. И еще вопрос. Вот я скачал тор-браузер, зашел под ним в инет... Я при этом являюсь каким-нить узлом для какого-то другого человека, использующего Тор? С экзит-узлом все понятно, а вот entry node, middle node и bridge relay я не разобрал. Ими становятся по умолчанию или же на это нужно мое согласие? спасибо
Нет, только клиентом. В существующем на сегодня тор-браузере нет даже возможности запустить бридж или публичный узел, только клиент. Для запуска узла нужно приложить некоторые усилия по конфигурации, и делать это надо самостоятельно вне браузерных бандлов.
Если в файл Data/Tor/torrc добавить строку с ORPort, TBB не станет релеем?
при первом запуске ТВВ появляется окно с двумя кнопками "Connect" и "Configure", т.е. настраивать можно. В дальнейшем, при загрузке можно так же в окне выбрать кнопку настройки.
Понятно. Спасибо за ответ.
Интересно, какой резон держать экзит-нод? Желание пощекотать себе нервишки, чистый альтруизм или все-таки сниф трафика...
Получить футболку с надписью.
Я так и думал. На дворе лето, пора запустить
Станет, возможно, если опции с "ClientTransportPlugin" не помешают. Но лучше настраивать узел отдельно вне связки с браузером.
Там нет опций[link1] для настройки узла.
Так же прошу помощи. Подскажите пожалуйста, как мне настроить TOR на сервере. Имею сервер с Debian, как мне там поднять тор и пустить свое соединение с моего компьютера через тор на мой сервер, где стоит тор. Тот же вопрос хочу спросить про i2p.
Спасибо
Маны[link2] почитай по Tor сначала.
Добавляешь в sources.list строку:
Вместо DISTRIBUTION вставляешь версию дебиана своего.
Затем ключи:
Ну и как обычно на последок apt-get update && install tor.
По поводу нод – читай ФПП, там есть категория Tor-ноды[link3].
Спасибо, сделал все по инструкции. Прописал в ФФ ip_server:9050 – не открывает сайты.
Попробовал пингануть через SSH – не работает:
Перезапустил Tor – тоже самое:
Перезагрузил сервер – тоже.
Что я делаю не так?
С тором нужно использовать только TorBrowser, а не обычный FF.
SOCKS-порт тор-сервера по умолчанию слушает только на локалхосте. Давать слушать ему откуда-то ещё можно, но небезопасно. Для это надо всё огородить через файрволл (iptables) и пустить трафик для своего подключения через VPN или SSH-туннель. Если пускать свой трафик через удалённый сервер, то потребуется ещё активировать и управляющий порт, а также выбрать для него систему аутентификации. Умолчальные методы аутентификации расчитаны только на локальную работу, так что придёться выбирать парольный метод.
Я готов выбрать парольный метод. Как это сделать? Здесь обсуждений я не нашел.
Задача простая: отовсюду иметь возможность серфить и вести переписку через мой удаленный сервер, на котором запущен Tor.
А если в torrc прописать IP сервера?
#SocksPort ip_server:9050
По-моему, настройки локального клиента и удалённого сервера (VPS) никак не связаны между собой. Согласно документации[link4], чтобы удалённый сервер работал как релей, нужно
1. Открыть на нём OR-порт с помощью опции:
Желательно указать свой адрес, если у смотрящих за сетью возникнут вопросы
Если не хотите чтобы он стал exit, нужно запретить:
2. Разрешить в файрволе внешние TCP-соединения с IPaddr:443
После этого подождать, когда в логах появится сообщение о доступности OR-порта извне. По умолчанию будет использоваться вся пропускная способность на VPS. Если это не подходит, нужно ограничить скорость[link5].
Советуют ещё опцию Nickname указывать, кто знает обязательна ли она? Собираюсь тоже запустить свой Tor-релей, так что написанное выше пока не проверял.
В принципе можно совместить сервер (релей) с локальным клиентом если есть белый адрес, либо пробросить OR-порт с VPS на localhost. Но это делать не рекомендуют[link6], т.к. появляется возможность для деанонимизации. Противник может пропускать трафик через ваш релей и наблюдать за спадами во время вашей собственной сетевой активности. Поэтому лучше клиент и релей держать отдельными процессами, даже если они оба на локальном хосте.
Извиняюсь, похоже что неверно воспринял тему. Самый простой спосооб подключиться к Tor-клиенту на удалённом сервере это выполнить команду
В браузере должен быть указан SOCKS-сервер locahost:9050 (по умолчанию). VPN-туннели и пароли к Tor-клиенту в данном случае не нужны.
Супер! Ведь таким образом мало того, что ВЕСЬ трафик торифицирован, так еще его нельзя отснифить, да?
Ну т.е. DPI не распознает трафик Tor, т.к. задействован еще и SSH.
Да, но надо ещё позаботиться о том, чтобы ничего не шло мимо Tor.
А чем это лучше заворачивания трафика локального тор-клиента в SSH и выпускания такого трафика на удалённом сервере? На котором при этом может вообще не стоять Tor-сервер.
Всё верно, это ничем не лучше, просто человек видимо хочет установить Tor-клиент на VPS и безопасно подключаться к нему с разных мест.
У меня тоже появился вопрос. Можно ли ограничить список сторожевых (guard) узлов, исключив из них принадлежащие определённой территории. Если использовать опцию
то запрет распространится на все узлы, включая exit, что может понизить анонимность. Если среди ограниченного числа entry-узлов окажется противник, это даст ему много возможностей для анализа трафика.
То есть сделать тоже самое, только при условии, что Tor стоит локально на компьютере? А если еще и на удаленном сервере, это повысит безопасность?
Да, Вы правы, я хочу иметь доступ к моему шифрованному каналу отовсюду, без плясок с установкой VPN и тд. Так как порой важна скорость и из задач просто проверить почту.
Если там нет поддержки регулярных выражений, то придёться забивать в конфиг все country-коды кроме желательных.
Вообще, всё это условно. Никто не мешает противнику из одной страны держать сервер в другой.
В какой конкретно конфигурации? Я вроде перечислил основные соображения.
Будет ли такое работать
Или возможно явно указать нужные входные узлы. Или бридж на подходящей территории использовать?
Чтобы контролировать трафик на своей территории, ему даже сервера не надо держать.
Не в курсе про поддержку регулярных выражений, образец которого вы привели. В доках это явно не указано.
Они же могут меняться и исчезать.
Бридж снижает и анонимность, и стабильность связи в обмен на обход блокировок.
Для атак анализировать внутреннее состояние пропатченного подконтрольного сервера всё-таки легче, чем парсить только входящий и исходящий трафик узла, наблюдая его снаружи как чёрный ящик. Хотя, при максимальных допущениях о возможностях противника — разница несущественна.
У меня так:
Всё работает, иногда ноды чуть-чуть французкие, иногда чуть-чуть германские, а в остальном прекрасно.
Подскажу, если ! – нету, то никто не мешает исправить чуть-чуть исходный код. Он открыт, https://git.torproject.org/tor.git
Такой синтаксис не поддерживается поскольку это будет идентично
Но эту опцию из кода убрали[link7].
Тикет про ExcludeEntryNodes[link8]
есть гарантия, что в какой то момент vps не будет контролироваться?
имхо, лучше как предлагает unknown (04/06/2014 09:52)
Это не регулярное выражение, обычный шаблон. В общем ясно, видимо придётся использовать
В зоне ru около 4% узлов от всей Tor-сети. Исключение этих узлов скорей всего компенсируется затруднением атаки для противника. Если в сторожевые узлы попадёт хотя бы один из ru, вероятесть гарантия, что в какой то момент vps не будет контролироваться?ность получить exit тоже из ru равна 4%[link9] (хотя экситов в ru наверное меньше, чем в среднем), теоретически это почти гарантированная деанонимизация. Понятно, что противник в настоящее время вряд-ли располагает такими возможностями по анализу подконтрольного трафика, но в принципе задача решаема. Если только один промежуточный узел на стороне, то котролируя трафик через entry и exit можно вычислить пользователя.
Ещё попутно такой вопрос: можно ли удлинить цепочку до 4 узлов и не скажется ли это на анонимности
Кстати, обнаружил подозрительные узлы kasperskytor01[link10], kasperskytor02[link11].
Почему снижает, из-за того, что бридж принадлежащий противнику видит соединения постоянно, а не эпизодически, как если бы он был обычным entry-узлом?
Никакой гарантии, человеку был просто дан ответ на интересующий его вопрос. Когда наиграется с ssh, возможно перейдёт на более правильный способ.
Узлы выбираются ещё и пропорционально пропускной способности.
Она не повысится.
middle видит, что трафик через него на эксит идёт не от гарда и может отфильтровывать такие соединения, как исходящие от бриджей. Это, кстати один из лёгких способов вычисления бриджей и блокирования их через злонамеренных миддлеманов.
Если брать отношение экситов к общему числу узлов из определённого региона, то для зоны ru оно скорей всего будет меньше среднего по сети Tor. Поэтому процент потерь среди экситов ещё меньше, чем среди всех релеев для данной зоны. По пропускной способности вряд ли российские узлы находятся на уровне европейских и американских. В итоге, для зоны ru опция ExcludeNodes по своему действию почти равнозначна ExcludeEntryNodes, если бы последняя существовала.
Если в гардах оказался подконтрольный узел (4% это немало), злоумышленник гарантированно вычисляет пользователя, мониторя экситы. Миддл известен, сравнивая соединения с ним от подконтрольных гарда и эксита, находится вся цепь. Если миддла два, то цепочка не вычисляется. Среди миддлов конечно тоже может оказаться противник, но вероятность что всё совпадёт (гарды и экситы) очень мала по сравнению с 4%.
Промежуточный узел фильтрует (блокирует) соединение от бриджа, цепочка обрывается, клиент выбирает новую, но при чём тут анонимность?
Откуда middle может точно знать что он middle, а не первая нода в цепочке (за исключением случая, когда у middle нет guard флаша)? Нода с exit флагом может быть в том числе и промежуточной.
Очевидное решение – заставить выбирать в качестве middle только ноды с guard флагом.
Это как раз понятно, если предыдущий узел отсутствует в списке Tor-нод, значит это бридж, после него может идти только мидл.
Зачем? Да и нет в torrc такого выбора.
Или клиент. Собственно бридж выступает как клиент и по посылаемому содержимому не отличим от клиента.
Отличить бридж от клиента может только по настоящему промежуточный узел, который никогда не получал guard флага. Клиент, по умолчанию конечно, не будет подключаться к такому узлу напрямую.
Да, кстати, вспомнил одно отличие, которое может выдать различие бриджа и клиента. Клиент при строительстве цепочек использует упрощенный механизм согласования ключей (CREATE_FAST cell) для первого узла, а бридж лишь транслирует запросы поэтому таких ячеек от него не будет. Впрочем, эти упрощенные механизмы планируют убрать, клиент тогда точно будет похож на бридж.
Тикет про отмену CREATE_FAST[link12], который сделает неразличимым клиенты от бриджа в плане содержимого.
Тикет про обнаружение бриджей[link13], в целом, а главное про предотвращение обнаружения бриджей промежуточными узлами.
Мнение насчёт анонимности пользователей бриджей в плане уязвимостей[link14].
Бридж это лишняя сущность и ещё одна точка контроля трафика, с точки зрения анонимности.
Полно таких узлов. Для этого достаточно не соблюдать положенный для получения гвард-флага аптайм.
You should let people choose their path length[link15].
Пока не доказано обратное, считается, что противнику достаточно контролировать входящий и исходящий узел. Число промежуточных узлов между ними (если их один или больше) не имеет значения. Для проведения атаки пересечения и её аналогов смотрятся только корреляции на входе в сеть и выходе из неё.
Манипуляция с числом узлов в цепочках — это самый примитивный вариант изменения протокола, над которым думали ещё в самом начале, ещё более десяти лет назад. Если есть идея, то доказывайте её теоретически и предлагайте в проект в оформленном виде, чтобы её рассмотрели на уровне возможности внедрения в протокол. А если пытаться нестандартным выставлением опций улучшить анонимность персонально для себя, то можно добиться ухудшенного результата. Причём, ещё и незаметно для себя. Кто-то может собирать статистику в сети Tor даже не для атак, а просто для исследований. И обратить внимание на нестандартные типы соединений, чтобы попытаться их отпрофилировать на фоне общей массы и внимательнее посмотреть, а что там такое.
Если контролирует гард и эксит, то вычисляет миддл. Т.е. вход и выход становятся связанными не какими-то корреляциями трафика, а однозначано, по практически уникальной middle-ноде. Понятно что корреляция работает всегда, а тут нужно чтобы подконтрольный узел стал гардом. Но 4% это разве мало? Для Германии и США это уже подядка 25% (почти половина Tor-нод находятся в Германии и США).
Если контролируется только вход на гард и выход с эксита, тогда да, количество middle-узлов значения практически не имеет. Но когда гард и эксит на территории контролируемой противником, это не так.
Возможно так и сделаю, просто хотелось бы узнать обоснование вашей категоричной фразы о том что анонимность не повысится. Не ссылкой на цитату умных людей из торпроджекта, а собственными соображениями. В Tor FAQ, кстати, основной аргумент против удлинения цепочки это повышение нагрузки на сеть. Признаётся[link16], что добавление хопов может повысить анонимность.
В теоретической модели, используемой торпроджектом считается, что вся территория Земли одинакова в плане угроз для анонимности. Не учитывается что в реальности ноды, расположенные на одной территории с пользователем, обладают более высоким потенциалом угрозы.
При удлинении нод до четырёх, первый миддл будет видеть что далее тоже миддл, а не эксит. Кроме этого, если первый миддл не имеет гард флага, это будет замечено вторым миддлом. Извлечь какую какую-то информацию из этого можно только при компрометации шифрования. Если это так, то эксплуатация данной аномалии представляется мелочью по сравнению с катастрофой из-за взлома криптографии.
Ваш вопрос уже прорабатывался[link17] в теоретических работах.
И по поводу бриджей была подробная информация[link18], сейчас она уже отчасти устарела.
В первой ссылке рассматривается использование некой доверенной сети, которой обычные пользователи не обладают. Влияние длины цепи на анонимность не рассматривается.
Во второй ссылке способы раскрытия бриджей, а не анализ их влияния на анонимность.
В общем оба ваши утверждения пока ничем не обоснованы, даже ссылками.
1. Удлинение цепи не повышает анонимность
2. Использование бриджей понижает анонимность
Я конечно понимаю, что мне тут никто не обязан объяснять, но и кидать нерелевантные ссылки с большим объёмом текста тоже наверное неправильно. Всё-таки тратится время на их чтение.
Кстати, правильней вероятность попадания в гарды контролируемых нод рассчитывается так: Р=1-(1-a)^N, где а – процент нод данной зоны, N=3 количество гард-нод (по умолчанию).
Для зоны ru: а=0.04, Р=12%
Для зоны us: a=0.25, P=58%
Так что вероятность больше, чем утверждалось ранее.
Там рассматривается алгоритм оптимизированного выбора между своими (доверенными) и враждебными узлами. От заведомо враждебных узлов не отказываются.
При выборе учитывается не просто количество узлов, но и удельный вес по пропускной способности. Вопрос обсуждался где-то в районе /comment27294[link19], /comment27370[link20], /comment42879[link21].
Плюс еще такое соображение: это наблюдение ничего не стоит, можно поставить сервера-шпионы и забыть. Если, допустим, за сутки деанонимизируется 1% посетителей наблюдаемого ресурса (pgpru.com, например), то за 300 дней... Было бы странно, если бы это не делалось.
Например нода kasperskytor01[link10] одна из самых высокоскоростных.
Я уже понял что содержательного ответа на те два вопроса не будет. Поэтому просто напишу здесь ещё некоторые соображения, может кто прокомментирует. На них наводит вышеупомянутая нода, которая обладает очень высокой скоростью. Вряд ли касперский и компания держат её для повышения нашей анонимности, учитывая что торбраузер распознаётся как malware в их антивирусной программе. Скорей всего это злонамеренный узел для сбора статистики. Видимо преследует две цели – нахождение брижей для возможной блокировки в будущем и раскрытие анонимности. Он не является экситом, поэтому в основном работает как мидл. Теоретически это позволяет полностью раскрыть цепочку, если он находится в сговоре с государством контролирующим трафик (в случае касперского очевидно что это так, поскольку он кегебист). Гард и эксит могут располагаться где угодно, главное чтобы посередине цепи оказался этот узел. Трафик ищущий на гард и идущий с эксита (если целевой сайт находится в государстве) контролируются системой слежения. В принципе весь Tor-трафик на магистральном уровне можно направлять на специализировнные сервера статистики. Список узлов Tor известен, в пакетах идущих на/с них модифицируется поле Options в заголовке IP и указывается маршрут проходящий через эти сервера. Так можно создать единый центр мониторинга всех пользователей Tor внутри страны. Если это делать только для TCP-пакетов, то с помощью traceroute не обнаружить, т.к. он работает по ICMP. Сервера Tor-статистики имеют связи: пользователь-гард и эксит-сайт. Злонамерный мидл имеет проходящие через него связи: гард-эксит. Путём сложения этих данных, получается полная информация для вычисления цепи: пользователь-гард-эксит-сайт. Таким образом, для деанонимизации нужно
1. Цепочка проходит через злонамеренную мидл-ноду. Рано или поздно это случается с каждым пользователем, высокая пропускная способность ускоряет процесс.
2. Интернет-ресурс находится внутри государства, с которым нода сотрудничает. В данном случае это очевидно Россия.
Этот способ дополняет тот, что описан выше.
Увеличение длины цепочки до 4 узлов снижает эффективность этих двух способов на порядки.
А еще было бы здорово, если б Tor генерировал рандомный шумовой трафик. Количество помех не снижает уровень сигнала, в данном случае, плюс есть корреляция по времени запроса. То есть математически / статистически информация всё равно поддается анализу, но задача усложняется, а при нерегулярных соединениях с одного IP не решается.
Раньше являлся, а теперь пропускает только трафик по accept 80, 8080, 3128 и 21 портам. Очевидно снифают пароли, другие порты убрали чтобы пропускать больше интересного им плейнтекст трафика. Есть еше kasperskytor02, раньше были kasperskytor03 и kasperskytor04 на другом IP.
Значит и есть эксит — узел который транслирует не только тор траффик. Не смотрите на флаг эксит из статистики, необходимый только для балансировки трафика. Эксит флаг как маркер, "берегите меня" и если экситов мало тогда исключите из гвардов и прочее. Для получения флага нужно разрешить как минимум 2 из 3 портов (80, 443, 6667) на как минимум /8 подсеть.
Можно подробностей? Разработчики всегда беспокоятся об таких ложных срабатываниях. До сих пор при проверке на virustotal не было срабатываний.
Эти узлы им могут быть нужны в том числе для таких публикаций[link22]. Тема модная, касперски всегда умел пиариться на любом удобно случае. Сервера не скрывают, выделили отдельную сетку (37.221.171.232 – 37.221.171.239), в описании "Kaspersky Lab Research TOR exit node".
Tor не поддерживает ICMP.
Не «ещё и», а «только». Минусы такого решения уже были озвучены другими участниками.
Guard-узлы меняются раз в 2 месяца. Вы всегда можете посмотреть, какие были выбраны, и если не нравится, принудительно сменить. Когда был выбран нужный вам набор, соединение со всеми остальными узлами можно отключить посредством firewall'а.
Можно[link27]. Это, кстати, самый практичный способ.
Только не забывайте, что всё это пока что чистая теория с массой экстраполяций. Через каждый узел проходят десятки, если не сотни, соединений, в норме каждые 15 минут меняются цепочки. И никто заранее не скажет противнику, какая конкретно цепочка проходит как через его entry-, так и exit-ноду. Если противник будет активно влиять на трафик в попытке это отследить, он, подозреваю, как минимум, спалится, и, как максимум, превратится в настолько нестабильный и глючный узел, что через него толком ничего идти не будет. Часто бывает, что когда сеть начинает глючить, делаешь pkill -1 `pidof tor` и забываешь. А вдруг это вот такие «умные» узлы?
Кажется, были новости на эту тему, в которых было сказано, что покрывающий трафик сильно понизит пропускную способность, но даст сомнительную выгоду для анонимности. Сходу не гуглится (unknown бы лучше подсказал), но что-то обсуждалось здесь: [1][link30], [2][link31].
Unknown привёл конкретные ссылки с жаркими дискуссиями прошлых лет на эту тему. Никто не обязан за вас перечитывать все эти топики по 10-ому разу, чтобы найти конкретный пост-ответ на ваши вопросы. Всё, что вы предлагаете, лежит на поверхности, и обсуждалось уже миллион раз. Кроме того, судя по вашей манере (см. выше) делать выводы, к грамотному анализу вы вообще неспособны.
Для начала, чем длиннее цепочка, тем больше вероятность, что хотя бы часть вашего трафика пройдёт через узлы противника. Последнее облегачает ему атаку на деанонимизацию. Есть и много других атак, которые облегчаются. Есть те, которые усложняются. На предмет золотой середины сказано, кажется, даже в Tor-faq, с объяснением, почему взяли именно 3 для данных размеров сети. Можете доказанно опровергнуть — пишите исследовательскую статью.
Если б всё было так просто, как у диванных теоретиков, компартия Китая, как и Иран, не стояли бы раком от Tor'а и не блокировали бы его. Даже у АНБ далеко продвинуться не получилось, из-за чего они сосредоточились на атаках на браузер как самых перспективных.
Ссылка[link33] Хотя возможно по вине пользователя. Не вникал, т.к. не пользуюсь антивирусом.
В Tor FAQ приводится[link34] ещё два недостатка, кроме дополнительной нагрузки на канал. Это необходимость поддерживать шум круглосуточно от пользователя до сервера (за Tor), что обычно не поддерживается последним. А также уязвимость к отслеживанию реакции при активной блокировке трафика.
Против описанного выше способа нахождения связей зашумление не поможет.
Нет никакой теории, одна реализация. Если добавить подробностей, может сойти за проект ТЗ. Вы очевидно не поняли сути, это статистическая атака, которая за определённое время гарантирует раскрытие анонимности. Всего нод около 8 тысяч, высокоскоростных с большим приоритетом на порядок меньше. Предположим что злонамеренная нода с толстым каналом попадается с вероятностью 1/1000. Нужно вычислить пользователя который активно пользуется сайтом в контролируемой зоне (ru). Если за день он заходит на сайт несколько раз, то вычисляется в течение года. Когда таких нод десяток, он вычисляется в течение месяца.
Достаточно сохранять логи связей в одну базу данных. Для поиска задать интервал времени и веб-ресурс, чтобы получить список связей которые совпали и образовали целую цепочку.
В России сейчас 90 тысяч пользователей Tor, это уровень одного Интернет-провайдера крупного города. При этом для поддержания такой системы не нужны техподдержка и дорогое оборудование, т.к. нет NAT-ов, DNS и прочего, что требовало бы больших ресурсов. Поднять десяток нод в разных странах это вообще копейки.
Модификация IP-пакетов – стандартное действие для любого маршрутизатора. На каждом хопе меняется TTL. Запись нужного IP-адреса в поле Options аналогична, тоже производится на уровне IP и дополнительной нагрузки почти не создаёт. Это просто корректировка маршрута, пакет на пути к Tor-ноде должен пройти через узел с заданным IP-адресом. Для пользователя совершенно незаметно.
Практически любой ответ можно сформулировать в двух-трёх предложениях. Если нельзя, значит человек сам его не знает. В незнании нет ничего зазорного, но упёртость при отсутствии аргументов достойна лучшего применения.
Трафик любого пользователя пойдёт через злонамеренные узлы, независимо от длины цепочки, это лишь вопрос времени. Вероятность попадания противника в короткую цепочку меньше, но и возможности по раскрытию анонимности выше. Попадание в длинную цепочку вероятней, но воспользоваться этой позицией сложнее, нужно совпадение других обстоятельств. В результате, удлинение цепочки ускоряет момент прохождения трафика через враждебную ноду, но снижает её эффективность. Снижение эффективности связано с расположением нод и комбинаторикой, поэтому определяется по-видимому степенной зависимостью. Уменьшение времени почти линейно по длине цепочки, если процент злонамеренных нод невелик. Так что скорей всего при удлинении цепочки вероятность попадания враждебной ноды растёт слабей, чем убывает её эффективность. В итоге, для совпадения всех факторов, необходимых для раскрытия анонимности, нужно намного дольше ждать, несмотря на то, что злонамеренные ноды в длинной цепочке попадаются чаще. Всё это эвристические рассуждения, оценки нужно делать для конкретных атак. Для способа, изложенного выше, удлинение цепочки всего на одну ноду сильно снижает его эффективность.
Недостаточно. TCP-сессия каждый раз пересоздаётся на новом узле, нет никакого сквозного доступного противнику TCP-потока. Даже если у противника есть подконтрольный guard и exit, через которые в данный момент идёт цепочка пользователя, ему, чтобы убедиться в этом, надо делать активную атаку пересечения или модуляции трафика. Конечно, если он заранее знает, какие из межнодовых TCP-потоков принадлежат одной и той же цепочке, он таким вмешательством может легко и доказательно подтвердить гипотезу. А если не знает? Тогда ему придётся вмешиваться во все цепочки. Далее см. вышеозвученные аргументы.
Да пусть пакет идёт хоть через астрал между нодами, что толку-то? Все ваши модификации над пакетом будут тут же сняты миддлманом. Единственное, что не снимается — временные задержки и модуляция полосы пропускания.
Вопрос об оптимальном количестве нод в цепочках (с учётом всех возможных атак) сложный. Это утверждение полутривиально, потому что до сих пор вроде как нет всестороннего описания всех возможных атак и объяснения, какие из них эффективнее других. К тому же, могут быть несколько разные модели противника, и то, что сравнительно легко сделать одному, может оказаться практически нереальным для другого. Соответственно, от того, каких противников вы сочтёте более опасными для вас, зависит, защита от каких конкретно атак для вас более приоритетна.
То, что Tor принципиально выносит некоторые из своих известных слабостей за скобки — известный факт. К примеру, сейчас нет ни одной сети с защитой от глобального наблюдателя, даже Freenet не попадает в эту категорию [1][link35], [2][link36]. Зная всё это, разработчики Tor требуют конкретной исследовательской работы, а не «эвристических соображений». Однако, исходя из своих «эвристических соображений» они взяли число 3 как более-менее оптимальное. Возможно, за этим когда-то стояли простые расчёты и «пальцевые» соображения. А теперь приходит Гость (09/06/2014 19:22) и говорит, что всё просто, ничего исследовать не надо, а оптимальность более длинных цепочек очевидна. Кто не согласен, пусть доказывает. Но, извините, тяжесть доказательства (а не общих рассуждений) лежит на том, кто предлагает.
Чтоб совсем было просто: есть три типа цепочек:
- GAdv → M → Eother
- Gother → M → EAdv
- GAdv → M → EAdv
Guard GAdv и exit EAdv принадлежат противнику (adversary), миддлман M ему неподконтролен. Как последнему отличить случай 3 (для него полезный) от случаев 1 и 2?Т.е. противнику.
Сейчас речь идёт о способе описанном в comment80504[link37]
C_ru — IPstat — G — M_adv — E — IPstat — S_ru
C_ru и S_ru – клиент и конечный сервер в контролируемой зоне (например ru), IPstat адрес через который идут IP-пакеты в Tor и из него. G и E – гард и эксит (любые), M_adv – враждебный мидл.
Для всех пакетов с IPdst = G и IPsrc = E (все ноды известны) корректируется маршрут через IPstat, с которого собирается статистика по связям.
На IPstat логируются связи C_ru — G и E — S_ru. На M_adv связи G — M_adv и M_adv — E. Эти логи объединяются в базе данных.
Количество нод 8000, возможных цепочек 8000^3 = полмиллиарда. Каждый из 2.5 миллиона пользователей Tor имеет уникальную цепочку в каждый момент времени. Всё цепочки, проходящие через M_adv вычисляются.
Видимо речь идёт о первом способе, описанном в comment80465[link38] и выше.
C_ru — IPstat — G_ru — IPstat — M — IPstat — E_ru — IPstat — S
G_ru и E_ru – гард и эксит в контролируемой зоне, где и IPstat. M – любой мидл, S – любой сервер. На IPstat собираются все связи. В отличие от 1-го способа, через IPstat пропускаются все пакеты, связанные с Tor, а не только на/с G/E.
IPany = G и IPany = E, т.к. пакеты ходят в обе стороны. Если смотреть глубже, на уровень TCP, то можно определить направление по SYN-пакетам. Но это потребует дополнительных аппаратных ресурсов. Другой вариант – определять направление первого пакета для рассматриваемой связи, тогда можно ограничиться уровнем IP.
Это неправда. В каждый момент времени у каждого Tor-клиента открыто несколько цепочек (зависит от нагруженности). И идти эти цепочки могут через разных guard'ов.
Никак, для клиентов из неподконтрольной зоны это не работает, об чём было оговорено.
Если это так, то логи M_adv всё равно выделят разные цепочки внутри соединения между нодами. В крайнем случае его можно пропатчить.
Имелось в виду, что по цепочке определяется клиент. То что их несколько не имеет значения. Существует ничтожная вероятность что разные клиенты имеют одну цепочку, но есть ещё один различитель – момент времени. Вероятность одновременного совпадения цепочек ещё меньше.
Если по простому: IPstat засекает, допустим, цепочку, но эта цепочка идёт через G на другой M. А в это же время иной клиент (не Cru) выбрал ваши же G и MAdv. С точки зрения вашего анализатора, вы будете думать, что это цепочка от Cru, а это не так.
А вообще, у вас слишком много допущений: контроль трафика на входной точке, трафика на выходной, да ещё и миддлман у противника. Это мало чем отличается от случая, когда все три ноды принадлежат ему.
Пассивное наблюдение: все отдельные цепочки на GAdv и с EAdv выделяются по TCP-соединениям и группируются попарно. Среди входящих (и обратно идущих к нему через M) на GAdv и входящих на EAdv выделяются пары цепочек, которые имеют наибольшее корреляции по времени-объёму.
Активное вмешательство («одной ячейки достаточно»[link40]): в подозреваемых цепочках портятся (задерживаются, удаляются, замещаются) отдельные ячейки и смотрят, как это приводит к порче трафика на другом конце соединения.
Активный способ может дополнять пассивный. Защиту от таких способов Tor не обеспечивает by design.
IPstat засекает связи между узлами, а цепочки потом проверяет программа анализирующая эти связи. Чтобы получилась цепочка, нужно совпадение всех связей в одно время.
В прошлом комменте ответил только для способа с M_adv. В другом способе, когда подконтрольные ноды отсутствуют и работает только IPstat, наличие нескольких связей внутри одного соединения между Tor-нодами приводит к неопределённости M между G и E. Гард и эксит известны точно для каждого пользователя. Количество их комбинаций 8000^2 = 64 миллиона. Значит для 2.5 миллиона пользователей Tor используемая пара G,E является почти уникальным идентификатором в каждый момент времени. Если сузить число пользователей до российских 90 тысяч, вероятность ложного срабатывания ещё ниже.
Допущения два: возможность корректировать маршрут пакетов внутри зоны и небольшое число подконтрольных нод в сети Tor. Оба достаточно реалистичны, в отличие от "все три ноды принадлежат ему". В первом способе даже подконтрольные Tor-ноды не нужны.
Для пользователя и проверяемого веб-ресурса. Задача обычно состоит в вычислении пользователя по активности на веб-ресурсе, поэтому можно считать что последний задан.
Нашёл неточность, когда смотрел статистику по Tor. Большинство нод не имеет флагов guard или exit. Сейчас гардов 2300, экситов 1100, поэтому комбинаций G,E около 2.5 миллионов, как и пользователей Tor (в России 90 тысяч). Это снижает точность, но позволяет определить круг пользователей максимум до 2-3 человек. M точно не определён, но условие совпадения связей G — M и M — E ещё больше сужает круг пользователей. Т.е. для данных G и E должен существовать общий M. Это условие, а также совпадение по времени почти всегда сужают круг до одного пользователя. В исключительных случаях, когда это не так, к уже известному малому числу пользователей можно применить активное воздействие на трафик, о котором упомянул unknown. Но без предварительного пассивного наблюдения, позволяющего вычислить предполагаемую цель, оно практически бесполезно.
Cru все свои цепочки строит через G. IPstat видит всё вместе. G принимает соединения от многих пользователей, а не только трафик от IPstat. У MAdv не будет простой определённости на предмет того, где чьи цепочки. Грубо говоря, G тут работает как миксер. К тому же, цепочек много, и они постоянно меняются. И одно дело, если речь идёт о скачивании гигабайтов, потому что при обычном серфинге время от времени скачивается/закачивается мизерный объём. Этот как пушинка в довесок к основному трафику, который проходит через эти ноды. Чтобы не было false positive нужны довольно лабораторные условия.
Это всё общие слова, а не конкретные цифры. Вот когда начнёте делать атаку для реальных сценариев, писать и тестить код, так сразу все проблемы и вылезут. Как бы ни оказалось, что для надёжного подтверждения того, что юзер X ходит на сайт Y, потребуется пассивно наблюдать его трафик много лет, и даже это не спасёт от false positive/negative.
Не силён в методах статистической обработки, но интуиция подсказывает что информации достаточно. Можно совсем по-простому если подняться на уровень TCP: IPstat логирует только SYN-пакеты, остальные может игнорировать. Тогда однозначно получается цепочка в момент установления соединения, без всякой статистической обработки. Можно и целиком сеансы между C — G и E — S установить (начало и конец по времени), если отслеживать номера последовательности и подтверждения в заголовке TCP. Или воспользоваться готовым решением в виде NAT.
Мне не особо интересно исследовать детали возможной реализации этой системы, т.к. не собираюсь её создавать. Для меня очевидно что создать её можно в рамках имеющихся у государства ресурсов. Достаточно понимать концепцию и потенциал угрозы чтобы принять адекватные меры по снижению её эффективности. Очевидная мера – удлинение цепочки.
Если считаете, что открыли новую атаку на Tor, то создайте отдельную тему, где в начале заново разложите всё по полочкам. А то из разрозненных коментов не всё понятно. Может вы в чём-то окажетесь правы, а возможно и нет. Может ваша атака не работает, удлинение цепочки анонимность не повышает, а наоборот существует метод профилирования пользователей с искусственно завышенной длиной цепочки. Пока этот метод нельзя изложить так, что его нельзя даже донести в достойном для рассмотрения виде до торпроджекта, он так и останется гипотетическим и нерекомендуемым.
Насчёт логирования SYN-пакетов наверное был неправ. Между E и S это делается, т.к. соединение открытым текстом, но между C и G SYN-пакет идёт внутри шифрованного канала. Логировать его можно только если у него есть отличительные особенности (о чём мне неизвестно).
Пользователи различаются по IP-адресу C_ru. IPstat логирует пакеты для пары C_ru,G.
В реальном времени 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.
(раньше и дальше не читал)
Да, SYN-пакеты есть только между экситом и сервером назначения. Между клиентом и гардом имелось в виду первое обращение пользовательского приложения к конечному серверу.