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

В исходниках можно почитать /doc/spec

Прямая ссылка на репозиторий.

В описании скрытых сервисов вопрос аутентификации и авторизации ещё не внесён в документацию:

2. Authentication and authorization.

Foo.

обновляемой работе здесь

Я там вижу в конце

File translated from TEX by TTH, version 3.59. On 18 May 2004, 10:45.

Это оно с тех пор и не обновлялось? Узнать дату последнего изменения этой статьи тоже нельзя?

На торпроджекте должна лежать более свежая версия: https://www.torproject.org/doc.....aper/tor-design.html
но нет доступа

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

В 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.

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

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.

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

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

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

В 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, но скрывать факт наличия сервиса от всех остальных.

Спасибо, unknown, что нарыли столько информации по теме. Хотел сказать, что бывают мысли "зачем читать эти спецификации, если ко времени когда разберёшься с протоколом он уже 10 раз успеет смениться". У них документация рассредоточена по куче страничек/ресурсов, вместо того чтобы поддерживать единую базу данных. Ну и насчёт пропозала – это только "пропозал", т.е. разработчики не обязываются их имплементить, у них же не статус "TODO in nearest future". Скажем так, стандартная политика разработчиков в отношении пропозалов известна?

Ну раз там стоит Status: Finished, да ещё и датой 01-Aug-2008, то выполнено (к тому же о выполнении 121 предложения объявлялось в блоге), но есть предупреждение, что часть идей, необходимых для выполнения первого протокола собирались перенести в proposal 142, который имеет Status: Dead в том же 2008. Значит действует только протокол "2.2. Authorization for limited number of clients" из proposal 121, что (непонятно как) согласуется с опцией в 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 без proposal 142 выходит только второй вариант протокола авторизации, т.е. 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. Про скрытые сервисы там ничего нет. А пробел в общей документации с авторизацией для скрытых сервисов так и незаполнен.

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

[offtop]

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

Интересно, что они сейчас занимаются проблемой фингерпринтинга веб-страниц, что же они собираются на этот счёт придумать...
[/offtop]

С другой стороны, не ясно как это связано с той брешью, что центральные сервера директорий [я ничего не путаю?] знают полный список скрытых сервисов. Т.е. если все 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

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

Это точно так? Т.е. там должны быть абсолютно все скрытые сервисы, включая те, авторы которых никогда публично не разглашали адреса? А также там все, кто пользуются torchat'ом? Было бы крайне интересно взглянуть на такой список!

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

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

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

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

Сейчас перегуглил весь сайт и даже прошёлся по всем каталогам грубой силой — ничего не найти :-(

Очень жаль :-( Может быть, они туда попали по ошибке?

одни никнеймы без онионов

Это позволяет во всех случаях восстановить нормальный http-адрес сайта постороннему лицу?

В смысле http://.xxxxx.onion? Нет.

В смысле http://xxxxx.onion? Нет.

Тогда владельцам "приватных" скрытых сервисов можно не беспокоиться, я-то думал...