LINUX.ORG.RU

История изменений

Исправление Moisha_Liberman, (текущая версия) :

Мне вот, что не понятно: о какой анонимности может идти речь, когда трафик канального уровня до точки входа в этот Тор не шифруется?

Точкой входа в сеть Tor может быть и Ваш localhost и сервер в Вашей локальной сети. Так что, шансов на перехват трафика внутри Вашей локалки уже немного, а уж если онион-роутер прямо на Вашем localhost, то и считайте что такие шансы стремятся к нулю.

Т.е. если принять за аксиому возможность государств прослушивать весь трафик абонентов, установление пары абонентов - это задачка на корреляцию IP пакетов, которую решит даже школьник…

ЕМНИП, профессор Перуанского Университета Анастасос Керамитос смог показать как он на территориально ограниченной сети кампуса искал 90 минут отправителя.

Но на реальной глобальной сети нет. Так не выйдет. Ваш онион-роутер должен покачивать чужой трафик, примешивая к нему свой. Максимум что Вы здесь увидите – флуктуацию трафика в отдельно взятой (Вашей локальной) сети. Глобальный баланс останется тем же. Подрастёт немного разве что.

Даже если выходной узел Tor применяет какую-то хитрую обфускацию трафика для какого-то кастомного транспортного протокола (разбивая IP пакеты и проч.), имея на руках весь трафик всех абонентов, м.б. можно как-то найти искомую пару отправителя и получателя методом исключения?

Нет. Основная опасность была в том, что точка выхода (exit-node) позволяла снять SSL и добраться до незащищённого протокола, того же http. Но во времена https everywhere процедура типа SSL strip|SSL split уже практически лишена смысла. Ну пошло малость больше трафика и что? Что там за трафик без DPI не выяснишь. А прогонять весь трафик через DPI, на это даже Echelon неспособен.

Гораздо больше проблем может вызвать использование socks5. Именно из-за необходимости резольвинга FQDN->IP для инициатора соединения. Т.е., запросы на разрешение имени будут либо улетать на DNS прова, либо на открытые кеширующие DNS (типа гуглёвого 8.8.8.8/8.8.4.4 или аналогичного, не гуглем единым). Хорошо вооружённый наблюдатель может их отследить и понять Ваш интерес к определённому ресурсу.

В этом случае используйте либо свой кеширующий DNS сервер, который будет разово резольвить адрес, а потом отвечать на Ваши реквесты из своего кеша. Либо прочтите наконец документацию и используйте socks4a, это socks4, но без резольвинга адресов. Как именно это работает в Tor, я могу конечно объяснить, но это звиздец как надолго, проще сами посмотрите как privoxy настроен. Вас должна заинтересовать строка forward-socks4a / localhost:9050 . из /etc/privoxy/config. Остальные forward-sock4 и forward-socks5 можете отрубить.

Залёты как раз случаются у дебилушек великовозрастных, которые не осиливают прочесть документацию и делают, например, one-hop onion router. Т.е., когда от отправителя до получателя всего один луковичный роутер.

«Контролировать тор» конечно же можно! Но только в горячих и влажных фантазиях пубертата, когда позывы к анонимности заменяют big tits. Проблема в том, что для контроля нужно знать все условные «ключи». Но тут увы и ах, генерация «ключа» производится узлами самостоятельно и с заданной периодичностью. Так что, тут тоже обломинго злая птица.

P.S. Вообще-то, вся «математика», на основе которой построен tor, хорошо была изложена на их же сайте. Правда, на английском, но вполне читабельно и проверяемо в коде. Код-то открытый.

Авторам этого кода, подразделению военно-морской разведки США, пришлось его открывать просто потому, что в этом случае процесс распространения становится максимально прозрачным и децентрализованным.

Конечно, «siloviki» USA (и остальных стран) тут проблем хапнули, но не настолько много, чтобы отказываться от неплохого инструмента.

Исправление Moisha_Liberman, :

Мне вот, что не понятно: о какой анонимности может идти речь, когда трафик канального уровня до точки входа в этот Тор не шифруется?

Точкой входа в сеть Tor может быть и Ваш localhost и сервер в Вашей локальной сети. Так что, шансов на перехват трафика внутри Вашей локалки уже немного, а уж если онион-роутер прямо на Вашем localhost, то и считайте что такие шансы стремятся к нулю.

Т.е. если принять за аксиому возможность государств прослушивать весь трафик абонентов, установление пары абонентов - это задачка на корреляцию IP пакетов, которую решит даже школьник…

ЕМНИП, профессор Перуанского Университета Анастасос Керамитос смог показать как он на территориально ограниченной сети кампуса искал 90 минут отправителя.

Но реальной глобальной сети нет. Так не выйдет. Ваш онион-роутер должен покачивать чужой трафик, примешивая к нему свой. Максимум что Вы здесь увидите – флуктуацию трафика в отдельно взятой (Вашей локальной) сети. Глобальный баланс останется тем же. Подрастёт немного разве что.

Даже если выходной узел Tor применяет какую-то хитрую обфускацию трафика для какого-то кастомного транспортного протокола (разбивая IP пакеты и проч.), имея на руках весь трафик всех абонентов, м.б. можно как-то найти искомую пару отправителя и получателя методом исключения?

Нет. Основная опасность была в том, что точка выхода (exit-node) позволяла снять SSL и добраться до незащищённого протокола, того же http. Но во времена https everywhere процедура типа SSL strip|SSL split уже практически лишена смысла. Ну пошло малость больше трафика и что? Что там за трафик без DPI не выяснишь. А прогонять весь трафик через DPI, на это даже Echelon неспособен.

Гораздо больше проблем может вызвать использование socks5. Именно из-за необходимости резольвинга FQDN->IP для инициатора соединения. Т.е., запросы на разрешение имени будут либо улетать на DNS прова, либо на открытые кеширующие DNS (типа гуглёвого 8.8.8.8/8.8.4.4 или аналогичного, не гуглем единым). Хорошо вооружённый наблюдатель может их отследить и понять Ваш интерес к определённому ресурсу.

В этом случае используйте либо свой кеширующий DNS сервер, который будет разово резольвить адрес, а потом отвечать на Ваши реквесты из своего кеша. Либо прочтите наконец документацию и используйте socks4a, это socks4, но без резольвинга адресов. Как именно это работает в Tor, я могу конечно объяснить, но это звиздец как надолго, проще сами посмотрите как privoxy настроен. Вас должна заинтересовать строка forward-socks4a / localhost:9050 . из /etc/privoxy/config. Остальные forward-sock4 и forward-socks5 можете отрубить.

Залёты как раз случаются у дебилушек великовозрастных, которые не осиливают прочесть документацию и делают, например, one-hop onion router. Т.е., когда от отправителя до получателя всего один луковичный роутер.

«Контролировать тор» конечно же можно! Но только в горячих и влажных фантазиях пубертата, когда позывы к анонимности заменяют big tits. Проблема в том, что для контроля нужно знать все условные «ключи». Но тут увы и ах, генерация «ключа» производится узлами самостоятельно и с заданной периодичностью. Так что, тут тоже обломинго злая птица.

Исходная версия Moisha_Liberman, :

Отчасти.

Мне вот, что не понятно: о какой анонимности может идти речь, когда трафик канального уровня до точки входа в этот Тор не шифруется?

Точкой входа в сеть Tor может быть и Ваш localhost и сервер в Вашей локальной сети. Так что, шансов на перехват трафика внутри Вашей локалки уже немного, а уж если онион-роутер прямо на Вашем localhost, то и считайте что такие шансы стремятся к нулю.

Т.е. если принять за аксиому возможность государств прослушивать весь трафик абонентов, установление пары абонентов - это задачка на корреляцию IP пакетов, которую решит даже школьник…

ЕМНИП, профессор Перуанского Университета Анастасос Керамитос смог показать как он на территориально ограниченной сети кампуса искал 90 минут отправителя.

Но реальной глобальной сети нет. Так не выйдет. Ваш онион-роутер должен покачивать чужой трафик, примешивая к нему свой. Максимум что Вы здесь увидите – флуктуацию трафика в отдельно взятой (Вашей локальной) сети. Глобальный баланс останется тем же. Подрастёт немного разве что.

Даже если выходной узел Tor применяет какую-то хитрую обфускацию трафика для какого-то кастомного транспортного протокола (разбивая IP пакеты и проч.), имея на руках весь трафик всех абонентов, м.б. можно как-то найти искомую пару отправителя и получателя методом исключения?

Нет. Основная опасность была в том, что точка выхода (exit-node) позволяла снять SSL и добраться до незащищённого протокола, того же http. Но во времена https everywhere процедура типа SSL strip|SSL split уже практически лишена смысла. Ну пошло малость больше трафика и что? Что там за трафик без DPI не выяснишь. А прогонять весь трафик через DPI, на это даже Echelon неспособен.

Гораздо больше проблем может вызвать использование socks5. Именно из-за необходимости резольвинга FQDN->IP для инициатора соединения. Т.е., запросы на разрешение имени будут либо улетать на DNS прова, либо на открытые кеширующие DNS (типа гуглёвого 8.8.8.8/8.8.4.4 или аналогичного, не гуглем единым). Хорошо вооружённый наблюдатель может их отследить и понять Ваш интерес к определённому ресурсу.

В этом случае используйте либо свой кеширующий DNS сервер, который будет разово резольвить адрес, а потом отвечать на Ваши реквесты из своего кеша. Либо прочтите наконец документацию и используйте socks4a, это socks4, но без резольвинга адресов. Как именно это работает в Tor, я могу конечно объяснить, но это звиздец как надолго, проще сами посмотрите как privoxy настроен. Вас должна заинтересовать строка forward-socks4a / localhost:9050 . из /etc/privoxy/config. Остальные forward-sock4 и forward-socks5 можете отрубить.