id: Гость   вход   регистрация
текущее время 09:15 18/09/2019
Автор темы: Гость, тема открыта 13/07/2008 22:43 Печать
Категории: софт, анонимность, tor, атаки
https://www.pgpru.com/Форум/АнонимностьВИнтернет/СравнениеСтепениАнонимностиПриПосещенииВнешнихИВнутреннихРесурсовTorАвторизацияКлиентов
создать
просмотр
ссылки

Сравнение степени анонимности при посещении внешних и внутренних ресурсов Tor


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


 
На страницу: 1, 2, 3, 4 След.
Комментарии
— unknown (14/07/2008 14:00)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Можно только рассмотреть какие факторы понижают/повышают анонимность.

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

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

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

В целом считается, что скрытые сервисы Tor обеспечивают не очень высокий уровень анонимности для себя и меньше подходят для анонимного распространения контента (по сравнению с сетью Freedom например).

Их применение: доступ к небольшим серверам для ограниченного круга лиц. (например ssh через tor к машине, находящейся за файрволом чисто в администраторских целях) или небольшие чат-серверы.
— Гость (14/07/2008 19:18)   <#>
Спасибо за обстоятельный ответ. В общем, я именно так и предполагал, как вы сказали.
— Гость (01/05/2010 21:37)   <#>
Оператор скрытого сервиса менее анонимен, чем его клиенты, которые могут посылать ему множество запросов на скачивание данных и пытаться отследить реакцию в разных участках сети.


А если речь идет не о "публичном" скрытом сервере, а на "приватном", на котором, например, расшарены файлы и т.п. для участников ограниченной группы людей и используется аутентификация юзеров, описанная в man tor?
Кстати, насколько эта аутентификация надежна?
— Гость (01/05/2010 23:14)   <#>
аутентификация юзеров, описанная в man tor?
Чито?

А если речь идет не о "публичном" скрытом сервере, а на "приватном", на котором, например, расшарены файлы и т.п.

Скрытый сервис хорошо анонимен, пока публично не известен его адрес.
/comment39038 Теперь будете в каждом топике задавать этот вопрос?
— Гость (02/05/2010 04:28)   <#>
аутентификация юзеров, описанная в man tor?

Чито?


Это:

/comment39038 Теперь будете в каждом топике задавать этот вопрос?


Не в каждом, я прошел по Вашей ссылке и спросил, как обстоят дела сейчас с сабжевым вопросом (применительно к каждому топику, там сабжи по-моему немного разные).
— unknown (02/05/2010 14:35, исправлен 02/05/2010 14:39)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

При посещении внутренних ресурсов Tor анонимность для клиента выше, чем при посещении внешних, сложнее делать атаки пересечения (это затрагивалось в /faq).


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


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


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

— Гость (02/05/2010 15:00)   <#>
При посещении внутренних ресурсов Tor анонимность для клиента выше, чем при посещении внешних, сложнее делать атаки пересечения (это затрагивалось в /faq).

Это всё замечательно, но разработчики экономят на цепочках при работе со скрытым сервисом. Вместо того, чтобы поменять цепочку, через опеределенное время клиент будет обнулять счётчик "загрязненности" цепочки, для любого запроса (для цепочек общего пользования, со счётчиком отмеряющим дефолтовые 10 минут, все новые запросы не будут подключаться к очень старым цепочкам). Цель такой экономии ускорить медленную работу скрытых сервисов, ибо от природы основные затруднения получаются при строительстве цепочек клиента и сервиса до их общей точки встречи.
— Гость (02/05/2010 15:36)   <#>
Хм, не знал про эту опцию. По сути она ничего не меняет. Рассмотрите угрозу как появление предателя в рядах. Что ему мешает выдать злоумышленникам не только адрес скрытого сервиса, но и правильные значения для HiddenServiceAuthorizeClient? Задача свелась к предыдущей, где используется публично известный скрытый сервис без авторизации. Именно это я и имел в виду.
— Гость (02/05/2010 15:44)   <#>
если всем клиентам раздавать разные имена, то посещение каждым из них можно будет определить как псевдоним на скрытом сервисе
Да, но имя скрытого ресурса-то одно у всех будет :-) Более того, если имя заведомо известно, то при обращении по нему трафик будет доходить до скрытого сервиса, ведь только он знает, каких клиентов надо обслуживать, а каких – нет. Тогда можно строить стандартные атаки на такой сервис, даже не обращая внимания на то, что там якобы 404, ведь трафик пойдёт как надо и все корреляции будут выцепляемы. Конечно, можно сразу предложить воркэраунд типа поднимать для каждого нового юзера новый инстэнс Tor'а со своим именем скрытого сервиса... но такое будет деанонимизировать уже по другой понятной причине ;)
— Гость (02/05/2010 16:49)   <#>
Рассмотрите угрозу как появление предателя в рядах. Что ему мешает выдать злоумышленникам не только адрес скрытого сервиса, но и правильные значения для HiddenServiceAuthorizeClient?


Предатель может выдать и параметры для ssh-доступа, и root-пароль, если он главный сисадмин или просто ты ему его сказал :-)
Это несколько другая модель угрозы, не техническая, а основанная на человеческом факторе.

Да, но имя скрытого ресурса-то одно у всех будет :-) Более того, если имя заведомо известно, то при обращении по нему трафик будет доходить до скрытого сервиса, ведь только он знает, каких клиентов надо обслуживать, а каких – нет. Тогда можно строить стандартные атаки на такой сервис, даже не обращая внимания на то, что там якобы 404, ведь трафик пойдёт как надо и все корреляции будут выцепляемы.

В идеале, если не сработал описанный человеческий фактор, откуда враг знает, что это за скрытый сервис и кому он принадлежит?
Разве только что устраивать налеты на квартиры и офисы, где установлены скрытые сервисы, в тотальном порядке.
А так, при аресте кого-то из товарищей, при нормальной организации об этом узнается гораздо быстрее, чем когда можно будет завершить атаку пересечения (и м.б. быстрее, чем он – под пытками ли, в порядке предательства или каким образом "сдаст" ресурс).
— Гость (02/05/2010 23:12)   <#>
Предатель может выдать и параметры для ssh-доступа, и root-пароль, если он главный сисадмин или просто ты ему его сказал :-)
Зачем передёргивать? Я вам сказал: любой, кто заходит на ваш скрытый ресурс, должен знать и его имя, и пароль.

В идеале, если не сработал описанный человеческий фактор, откуда враг знает, что это за скрытый сервис и кому он принадлежит?
Где я писал, что он узнает в таком случае? В этом случае и авторизация не нужна (если допустить что слив никогда происходить не будет). А вот насколько релевантна такая модель угрозы вашему случаю – решать вам, и я вам лишь сделал намёк, что, может быть, стоит расширить модель угрозы.
— unknown (04/05/2010 11:05, исправлен 04/05/2010 11:37)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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


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


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


Узлом встречи может быть любой публично доступный узел сети Tor, который имеет дескриптор.


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


Поскольку данные о цепочках до скрытого сервиса всё время меняются, достаточно исключить неблагонадёжного пользователя из списка аутентификации, пока он не успел провести гипотетическую атаку с поиском корреляций в сети Tor. Если он этого сделать действительно не успел, то после его исключения скрытым сервисом можно оперировать также безопасно как и до этого. Для такого пользователя этот скрытый сервис станет невидимым в сети Tor. Он не просто не сможет с ним соединиться, он даже не сможет в рамках протокола определить его наличие/отсутствие в Tor-сети (при том что само имя скрытого сервиса даже нет необходимости менять). Узлы встречи тоже ничего не знают о скрытых сервисах, данные о которых они раздают — они хранятся только в зашифрованном виде. Для того чтобы это всё расшифровалось и соединилось, нужны данные от клиента, узла встречи м сервера. Но одной точки, в которой происходило бы полное восстановление информации нет. Здесь секрет фактически тоже разбит на три части, как и при обычном построении цепочек, только более сложным образом.


P. S. Всё-таки неясно, зачем нужно было затевать обсуждение ещё и в этой теме. Лучше обсуждать скрытые сервисы здесь. Если созреет материал для FAQ, то он будет туда включён.
P. S. S.

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

Кстати, нужно понять, эти данные передаются с узла встречи на сервис или нет? Если нет, то для сервиса все имена в каждом отдельном сеансе анонимны, расшаривать общее имя не нужно.
P. S. S. S. По одному предложению в проект сначала была идея использовать цепочку 3 узла от клиента до точки встречи + 3 узла от точки встречи до скрытого сервиса. Итого шесть узлов. Было бы идеально не с точки зрения тех, кто примитивно рассуждает, что чем длиннее, тем лучше, а с точки зрения, что узел встречи не знает IP клиента. Сейчас вроде ? используются только 4 узла, что непонятно — на чём сэкономили.

— unknown (04/05/2010 14:24, исправлен 04/05/2010 14:52)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Предыдущее изложение не совсем верно так как не разделены и перепутаны "Introduction Points" и "Rendezvous Points"и цепочка до скрытого сервиса не лежит в IP зашифрованном виде, а установлена им как если бы он был клиентом, а IP — исходящим узлом в обычном случае :-(


Скрытый сервис выбирает IP (не путать с IP-адресом, здесь: Introduction Point, а не Internet Protocol), клиент выбирает RP и получает от него случайное значение "random cookie" по самостоятельно выбранной цепочке.
Затем по другой цепочке соединяется с IP и даёт запрос серверу. Скрытый сервис отвечает (если хочет) и даёт половину DH ключа для связи. Затем они Соединяются через RP. Причём RP не знает ни клиента, ни скрытый сервис.


Идея аутентификации в том, что она должна отсекать клиентов на уровне IP.


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




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


P. S. Из Tor-документации всё-таки скрытый сервис всегда получает запрос и решает:


Her message to Bob may include an end-to-end authorization token so Bob can choose whether to respond. The authorization tokens can be sed to provide selective access: important users can get uninterrupted access. During normal situations, Bob's service might simply be offered directly from mirrors, while Bob gives out tokens to high-priority users. If the mirrors are knocked down, those users can switch to accessing Bob's service via the Tor rendezvous system.

Если исходить из этого, то сам по себе IP ничего не отсекает :-(
Сервис конечно будет невидим, но запросы на него поступать будут даже при неверном пароле.

— Гость (04/05/2010 16:24)   <#>
Если исходить из этого, то сам по себе IP ничего не отсекает :-(
Типа, то, что я написал исходя из общих соображений и не зная протокола Tor, оказалось всё равно верным? :) Есть ли в природе внятная полная документация на весь протокол Tor (включая альфа-версии), или информацию можно почерпнуть только из обрывков рассылки и исходников?

Сервис конечно будет невидим, но запросы на него поступать будут даже при неверном пароле.
Интересно, они собираются что-то с этим делать или нет. Другой вопрос: это так в текущей версии, или и в альфе?
— unknown (04/05/2010 16:28)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
В исходниках можно почитать /doc/spec, а общие принципы — в (не всегда актуальной) обновляемой работе здесь.
На страницу: 1, 2, 3, 4 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3