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


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

Комментарии
— unknown (14/07/2008 14:00)   
Можно только рассмотреть какие факторы понижают/повышают анонимность.

При посещении скрытых ресурсов анонимность повышается за счёт того, что отслеживать внутренний шифрованый и стандартизированный трафик в сети 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[link1] Теперь будете в каждом топике задавать этот вопрос?
Гость (02/05/2010 04:28)   
аутентификация юзеров, описанная в man tor?

Чито?


Это:

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


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

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


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


Можно ещё сделать 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)   

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


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


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


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


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


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


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

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

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

— unknown (04/05/2010 14:24, исправлен 04/05/2010 14:52)   

Предыдущее изложение не совсем верно так как не разделены и перепутаны "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)   
В исходниках можно почитать /doc/spec, а общие принципы — в (не всегда актуальной) обновляемой работе здесь[link4].
— SATtva (04/05/2010 16:31)   
В исходниках можно почитать /doc/spec

Прямая ссылка[link5] на репозиторий.
— unknown (04/05/2010 17:28)   
В описании скрытых сервисов[link6] вопрос аутентификации и авторизации ещё не внесён в документацию:

2. Authentication and authorization.

Foo.
Гость (04/05/2010 17:30)   
обновляемой работе здесь
Я там вижу в конце
File translated from TEX by TTH, version 3.59. On 18 May 2004, 10:45.
Это оно с тех пор и не обновлялось? Узнать дату последнего изменения этой статьи тоже нельзя?
— unknown (04/05/2010 17:57)   
На торпроджекте должна лежать более свежая версия: https://www.torproject.org/doc.....aper/tor-design.html[link7]
но нет доступа
— unknown (05/05/2010 09:12, исправлен 05/05/2010 09:40)   

Здесь изменения документации в svn[link8]. Там в основном опечатки пару лет назад исправляли.


В challenges.pdf в разделе "4.4 Location-hidden services":


First, our implementation of hidden services seems less hidden than we'd like, since they build a different rendezvous circuit for each user, and an external adversary can induce them to produce traffic. This insecurity means that they may not be suitable as a building block for Free Haven [11] or other anonymous publishing systems that aim to provide long-term security, though helper nodes, as discussed above, would seem to help.

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

— unknown (05/05/2010 10:07, исправлен 05/05/2010 10:52)   
Implement proposal 121: make it possible to build hidden services that only certain clients are allowed to connect to. This is
enforced at several points, so that unauthorized clients are unable
to send INTRODUCE cells to the service, or even (depending on the
type of authentication) to learn introduction points. This feature
raises the bar for certain kinds of active attacks against hidden
services. Code by Karsten Loesing.

Вот современный документ по аутентификации скрытых сервисов:
proposal 121[link9].


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


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


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


В 2008 году принят и стабилизирован только proposal. Пробел в обшей документации пока остаётся.


В proposal изложена масса вариантов авторизации (шифрование дескрипторов на уровне директорий, аутентификация на уровне RP и IP) и какой из них реализован и в какой мере неясно, вот например на основе этих общих идей описаны два протокола:


1. The first protocol allows a service provider to restrict access to clients with a previously received secret key only, but does not attempt to hide service activity from others.
2. The second protocol, albeit being feasible for a limited set of about 16 clients, performs client authorization and hides service activity from everyone but the authorized clients.

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

Гость (05/05/2010 14:54)   
Спасибо, unknown, что нарыли столько информации по теме. Хотел сказать, что бывают мысли "зачем читать эти спецификации, если ко времени когда разберёшься с протоколом он уже 10 раз успеет смениться". У них документация рассредоточена по куче страничек/ресурсов, вместо того чтобы поддерживать единую базу данных. Ну и насчёт пропозала – это только "пропозал", т.е. разработчики не обязываются их имплементить, у них же не статус "TODO in nearest future". Скажем так, стандартная политика разработчиков в отношении пропозалов известна?
— unknown (05/05/2010 15:50, исправлен 05/05/2010 16:10)   

Ну раз там стоит Status: Finished, да ещё и датой 01-Aug-2008, то выполнено (к тому же о выполнении 121 предложения объявлялось в блоге[link10]), но есть предупреждение, что часть идей, необходимых для выполнения первого протокола собирались перенести в proposal 142[link11], который имеет Status: Dead в том же 2008. Значит действует только протокол "2.2. Authorization for limited number of clients" из proposal 121[link9], что (непонятно как) согласуется с опцией в man.
В man намекается на оба протокола:

The auth-type can either be ’basic’ for a general-purpose authorization protocol or ’stealth’ for a less scalable protocol that also hides service activity from unauthorized clients.

А из принятого proposal 121[link9] без proposal 142[link11] выходит только второй вариант протокола авторизации, т.е. 16 паролей и полная невидимость скрытых сервисов:

2. The second protocol, albeit being feasible for a limited set of about 16 clients, performs client authorization and hides service activity from everyone but the authorized clients.

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

Вообще весь проект можно смотреть через https://svn.torproject.org/


Ведение документации torproject образцово-показательное именно как пример разработки открытого проекта (каждый может представить себя на месте разработчика), а не представления готового продукта. Это должно очень способствовать развитию. И всем интересующимся почитать очень полезно.


Вот ещё картинка для наглядного представления, чем заняты разработчики в текущий момент и каковы их ближайшие планы:
tracking-gantt.pdf[link12]. Про скрытые сервисы там ничего нет. А пробел в общей документации с авторизацией для скрытых сервисов так и незаполнен.

Гость (05/05/2010 22:49)   
Значит, всё движется вроде бы в правильном направлении, и Free Haven не за горами :) Понятно, что потенциал у скрытых сервисов с такой опцией велик для множества задач. С другой стороны, не ясно как это связано с той брешью, что центральные сервера директорий [я ничего не путаю?] знают полный список скрытых сервисов. Т.е. если все DA между собой согласятся, то они получат этот список (?).

[offtop]
Вот ещё картинка для наглядного представления, чем заняты разработчики в текущий момент и каковы их ближайшие планы: filetracking-gantt.pdf
Интересно, что они сейчас занимаются проблемой фингерпринтинга веб-страниц, что же они собираются на этот счёт придумать...

[/offtop]
— unknown (06/05/2010 09:08, исправлен 06/05/2010 10:47)   
С другой стороны, не ясно как это связано с той брешью, что центральные сервера директорий [я ничего не путаю?] знают полный список скрытых сервисов. Т.е. если все DA между собой согласятся, то они получат этот список (?).

Список обычных (неавторизующих) скрытых сервисов может быть легко извлечён из статистики и даже открыто публикуется гле-то в svn (для стабильных сервисов).


В первой версии протокола авторизации действительно подразумевалось onion-адрес в дескрипторе распространять в открытую, а для клиентов шифровать только точку IP (RAS-синдром, чтобы не путать с IP-адресом :-)


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


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


В статистике можно только подсчитать число таких скрытых сервисов, но без знания аутентифицирующих ключей различить их между собой ни по статистике, ни в момент установления соединения в точках IP или RP невозможно. Чем больше будет запущено таких скрытых сервисов в сети Tor, тем выше будет их безопасность (или имеются ввиду независимые директории статистики скрытых сервисов?):


(1) A hidden service directory could attempt to conclude presence of a service from the existence of a locally stored hidden service descriptor:
This passive attack is possible only for a single client-service relation, because descriptors need to contain a publicly visible signature of the service using the client key. A possible protection would be to increase the number of hidden service directories in the network
Гость (07/05/2010 16:53)   
Список обычных (неавторизующих) скрытых сервисов может быть легко извлечён из статистики и даже открыто публикуется гле-то в svn (для стабильных сервисов).
Это точно так? Т.е. там должны быть абсолютно все скрытые сервисы, включая те, авторы которых никогда публично не разглашали адреса? А также там все, кто пользуются torchat'ом? Было бы крайне интересно взглянуть на такой список!

В первой версии протокола авторизации действительно подразумевалось onion-адрес в дескрипторе распространять в открытую, а для клиентов шифровать только точку IP
Если я правильно понимаю, это значит для злоумышленника, что адрес ресурса известен, но детекция его местонахождения усложнена, т.к. запросы не дойдут до самого скрытого сервиса.
— unknown (07/05/2010 17:12, исправлен 07/05/2010 17:34)   

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


Да, в этом весь смысл.

Гость (07/05/2010 17:25)   
Сейчас перегуглил весь сайт и даже прошёлся по всем каталогам грубой силой — ничего не найти :-(
Очень жаль :-( Может быть, они туда попали по ошибке?
одни никнеймы без онионов
Это позволяет во всех случаях восстановить нормальный http-адрес сайта постороннему лицу?
— unknown (07/05/2010 17:36)   

В смысле http://.xxxxx.onion? Нет.
Гость (07/05/2010 18:13)   
В смысле http://xxxxx.onion? Нет.
Тогда владельцам "приватных" скрытых сервисов можно не беспокоиться, я-то думал...
Гость (07/05/2010 18:22)   
Ещё такой вопрос: можно ли насоздавать несколько разных onion-адресов [вне заботы об их приватности] для своих скрытых сервисов, запуская только один tor-клиент? Или на каждое новое имя дублировать процесс и конфиги?
— unknown (15/02/2013 13:11)   
Если кому-то ещё нужен ответ на этот оставшийся без внимания вопрос, то да. И разные порты для одного onion. И разные onion из одного Tor-конфига. А в будущем обещают и виртуальные onion's.
Гость (18/02/2013 00:38)   
Если кому-то ещё нужен ответ на этот оставшийся без внимания вопрос, то да

Спасибо. Это был[link13] мой вопрос.
Гость (07/05/2014 05:22)   
Вопросы на тему HiddenServiceAuthorizeClient[link14]:
  1. Можно ли сделать приватным onion-адрес, который уже был ранее публично известен, т.е. без перегенерации ключа HS?
  2. Можно ли менять пароли в конфиге torrc для одного и того же HS? Как только владелец HS сменил пароль, так сразу же трафик от клиентов со старыми паролями перестаёт доходить до сервера? Или там какой-то таймаут есть для смены маршрутов?
Гость (07/05/2014 05:27)   

Это какие? Что они будут иметь?


Была бы интересной опция, которая позволяет клиентам указывать пароль для HS на лету в браузере, чтобы не лезть руками в конфиг torrc. Можно было бы сделать отдельную вторую опцию «только для браузера» или добавить переключатель в конфиг torrc, регламентирующий, позволено ли клиентам указывать пароль через браузер или нет (ввиду соображений по безопасности это имеет смысл).
— unknown (07/05/2014 12:04, исправлен 07/05/2014 12:18)   

Хм. Не знаю. Можно проверить — запустить тестовый onion, затем ввести в него опции авторизации клиентов и посмотреть, перегенерируется его адрес или нет. Предполагаю, что адрес меняться не будет.



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


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


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



На одном скрытом сервисе можно завести несколько виртуальных хостингов, вида alice.abcdef0123456789.onion, bob.abcdef0123456789.onion и т.д.



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

Гость (07/05/2014 15:22)   
Где Вы вообще так тонко Tor настраиваете?
Гость (31/12/2014 02:04)   
Впродолжение старой истерии [1][link18], [2][link19], [3][link20]: на HS опять бочку катят «Tor: 80 percent of ??? percent of 1-2 percent abusive»[link21].
Гость (31/12/2014 09:16)   

Over 80 Percent[link22]
“It came as a huge shock to us,” Owen says of his findings. “I don’t think anyone imagined it was on this scale.”

ФБР как орехи колет SR, SR-2, скоро будет арест SR-3. Изымает сервера сотнями, а педофильское лобби победить не может? Или таки ответ проще чем кажется[link21].
PS: Law enforcement agencies use Tor to stay anonymous while they catch bad guys. Law enforcement agencies use and run hidden services, too.
Гость (31/12/2014 22:51)   

“[The study] could either show a lot of people visiting abuse-related hidden services, or it could simply show that abuse-related hidden services are more long-lived than others,” he writes. “We can’t tell from the data.”

Любой крупный сайт со своим коммунити будет жить дольше, чем любительская страничка ни о чём, у которой полтора посетителя — у автора нет мотивации заниматься её апдейтом. Исключения есть, но тренд какой-то такой.

it would require 18 new relays to be added to the Tor network to block any single site.

Мне кажется, он врёт. Не так там всё просто в протоколе. Было бы так просто — уже б давно заблокировали. Там или сивилоову атаку придётся делать для HSDir'ов или никак.
Гость (02/01/2015 12:19)   

В протоколе[link23] не всё просто, но в его тактика может сработать, если он правильно "сгенерирует" ID для своих узлов.
Для выбора узлов при публикации публичного дескриптора скрытого сервиса, расчитывается
descriptor-id = H(permanent-id | H(time-period | replica))
time-period опеределяет изменение descriptor-id во времени, а replica задает число реплик для распределения по сети.
Далее:
At any time, there are 6 hidden service directories responsible for keeping replicas of a descriptor; they consist of 2 sets of 3 hidden service directories with consecutive onion IDs. Bob's OP learns about the complete list of hidden service directories by filtering the consensus status document received from the directory authorities. A hidden service directory is deemed responsible for a descriptor ID if it has the HSDir flag and its identity digest is one of the first three identity digests of HSDir relays following the descriptor ID in a circular list. A hidden service directory will only accept a descriptor whose timestamp is no more than three days before or one day after the current time according to the directory's clock.

Но число необходимых узлов для продолжительного цензурирования в сети будет зависеть от общего числа HSDir'ов, и числа цензурируемых скрытых ресурсов. Если в сети есть ещё HSDir'ы тогда 18 узлов хватит лишь на 3 суток блокирования одного сервиса, при условии правильной подготовки к атаке.
Гость (03/01/2015 02:42)   
Так атакующему придётся хэш брутать, разве нет? Произвольные 18 узлов не будут достаточными.
Гость (03/01/2015 08:59)   

Ключи своих узлов ему надо брутать, так чтобы хеш (ID ключа) каждого был:
one of the first three identity digests of HSDir relays following the descriptor ID in a circular list.
, для обеих реплик.
Гость (04/01/2015 09:55)   

Тогда задача сводится к вопросу, насколько это реалистично.
Гость (04/01/2015 11:10)   

Фейсбук смог набрутать себе на адрес[link24]. Главное набрутать много-много ключей, а потом выбирать нужное.

Фейсбуку нужен был ключ для скрытого ресурса с красивым именем, где брут нужен несколько другой и не понятно сложней это или проще. Имя скрытого ресурса это base-32 от части (80-бит) хэша и нет ограничений на манипуляции с публичной экспонента ключа (если только фейсбук эту особенность использовал). Тогда как доктору-более-80-процентов нужен результат для всего хэша (160 бит) и у него нет возможности изменять фиксированную публичную экспоненту ключа, но с другой стороны не нужно кодировать в красивые и понятные человеку символы.

Успешность будет зависеть от собственных ресурсов и числа неподконтрольных HSDir'ов в сети. Ещё нужно будет учитывать процедуру назначения HSDir флага и спрогнозировать поведение чужих узлов. Вновь появившиеся могут заслужить HSDir флаг, а выглядевшие стабильными директории потерять его. Всё это поменяет условия и необходимые для цензор-узлов ключи.
Гость (04/01/2015 12:00)   
160 бит можно сбрутать?! Тогда кто вам мешает AES-128 взламывать? :-)


Это не облегчает атаку. В предположении, что хэш квазиидеален, подобрать "thesamplename" ничуть не сложнее чем предварительно зафиксированный "ksnfhbsdhfzpm".
Гость (04/01/2015 12:11)   

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



Это позволяет нагенерить чуть "больше" ключей за тот же промежуток времени.
— unknown (04/01/2015 14:23)   
Надо глянуть в описание, но вроде для onion-имени используется не полный 160-бит отпечаток.

Вот так навскидку, выглядел бы 160-битный отпечаток:


А в онион-имени используются только строчные буквы без спецсимволов.

Кроме того, полное имя пока никто не мог подобрать, если даже не хватает двух-трёх букв, а это минус бит 16 где-то.

Но опасения по поводу слишком коротких имён были. И в будущем их планируют заменять. Пока ещё спасает то, что мало сгенерить подставной ключ узла, надо как-то незаметно исключить подлинный узел из раздачи.
Гость (05/01/2015 02:51)   
Тут вопрос не в брутфорсе onion-имени, а в брутфорсе неких параметров HSDir, на которых будет лежать инфа для построения коннекта к introduction/rendezvous point. Я правильно понимаю, что сам HSDir совсем не обязан у себя хостить хоть какой-то HS?
Гость (02/02/2015 19:06)   
Подскажите пожалйста по следующей проблеме: есть желание дополнить веб-сервер tor hidden service – проксёй для входа на сайт через Tor сеть, как это сделал Facebook. При этом хочется обезопаситься от бот-нета. В настройках torrc есть параметр HiddenServiceAuthorizeClient, где можно перечислить пары login/password, но тогда при добавлении каждого нового пользователя сайта надо переписывать torrc и перезапускать Tor-процесс. Можно не использовать аутентификацию в torrc, а перенаправлять пользователя исключительно на страницу аутентификации самого сайта, чтобы не давать бот-нагрузки на сервер. Можно наверное еще капчу прикрутить.

Что подскажете?
Гость (02/02/2015 19:12)   

Если прописывание в torrc неприемлемо (это хороший способ для приватных Tor HS, а не публичных), то остаётся только такой способ, да. Более того, его многие высоконагруженные действительно HS используют, в т.ч. с капчей (не будем тыкать пальцем).

Ссылки
[link1] https://www.pgpru.com/comment39038

[link2] https://www.pgpru.com/faq

[link3] https://www.pgpru.com/forum/sodejjstvie/skrytyeservisyifaq

[link4] https://svn.torproject.org/svn/projects/design-paper/tor-design.html

[link5] https://gitweb.torproject.org//tor.git?a=tree;f=doc/spec;hb=HEAD

[link6] https://gitweb.torproject.org//tor.git?a=blob_plain;f=doc/spec/rend-spec.txt;hb=HEAD

[link7] https://www.torproject.org/doc/design-paper/tor-design.html

[link8] https://svn.torproject.org/cgi-bin/viewvc.cgi/tor/trunk/doc/design-paper

[link9] https://svn.torproject.org/svn/tor/tags/tor-0_2_1_9_alpha/doc/spec/proposals/121-hidden-service-authentication.txt

[link10] https://blog.torproject.org/blog/tor-0.2.1.6-alpha-released

[link11] https://svn.torproject.org/svn/tor/tags/tor-0_2_1_9_alpha/doc/spec/proposals/142-combine-intro-and-rend-points.txt

[link12] https://svn.torproject.org/svn/projects/todo/tracking-gantt.pdf

[link13] https://www.pgpru.com/comment39171

[link14] https://www.pgpru.com/comment39051

[link15] https://www.pgpru.com/comment79303

[link16] https://www.pgpru.com/comment39104

[link17] https://www.pgpru.com/comment79304

[link18] https://www.pgpru.com/comment72825

[link19] https://www.pgpru.com/comment51266

[link20] https://www.pgpru.com/comment78521

[link21] https://blog.torproject.org/blog/tor-80-percent-percent-1-2-percent-abusive

[link22] http://www.wired.com/2014/12/80-percent-dark-web-visits-relate-pedophilia-study-finds/

[link23] https://gitweb.torproject.org/torspec.git/plain/rend-spec.txt

[link24] https://blog.torproject.org/blog/facebook-hidden-services-and-https-certs