Сравнение степени анонимности при посещении внешних и внутренних ресурсов Tor
Допустим, что некто посредством тор-клиента посещает исключительно скрытые ресурсы тора, никогда или почти никогда не выходя в обычный интернет через тор. Насколько это анонимнее (и анонимнее ли?) браузинга обычного интернета через тор? Также интересно было бы знать сравнение защиты анонимности оператора скрытого ресурса сети Tor и его клиентов (тех кто к нему коннектится как к скрытому ресурсу) – анонимнее ли кто-то из них или это одинаково в силу протокола сети?
комментариев: 9796 документов: 488 редакций: 5664
При посещении скрытых ресурсов анонимность повышается за счёт того, что отслеживать внутренний шифрованый и стандартизированный трафик в сети Tor сложнее, чем выходящий наружу.
Но анонимность может понижаться из-за того, что скрытых ресурсов не так много. Однако нельзя легко определить, обращается ли клиент к скрытому ресурсу или просто недостаточно хорошо не отследили его коннект во внешнюю сеть.
Оператор скрытого сервиса менее анонимен, чем его клиенты, которые могут посылать ему множество запросов на скачивание данных и пытаться отследить реакцию в разных участках сети.
В целом считается, что скрытые сервисы Tor обеспечивают не очень высокий уровень анонимности для себя и меньше подходят для анонимного распространения контента (по сравнению с сетью Freedom например).
Их применение: доступ к небольшим серверам для ограниченного круга лиц. (например ssh через tor к машине, находящейся за файрволом чисто в администраторских целях) или небольшие чат-серверы.
А если речь идет не о "публичном" скрытом сервере, а на "приватном", на котором, например, расшарены файлы и т.п. для участников ограниченной группы людей и используется аутентификация юзеров, описанная в man tor?
Кстати, насколько эта аутентификация надежна?
/comment39038 Теперь будете в каждом топике задавать этот вопрос?
Это:
Не в каждом, я прошел по Вашей ссылке и спросил, как обстоят дела сейчас с сабжевым вопросом (применительно к каждому топику, там сабжи по-моему немного разные).
комментариев: 9796 документов: 488 редакций: 5664
При посещении внутренних ресурсов Tor анонимность для клиента выше, чем при посещении внешних, сложнее делать атаки пересечения (это затрагивалось в /faq).
Аутентификация должна быть вполне работоспособна. Получается такой дважды скрытый сервис. Правда, если всем клиентам раздавать разные имена, то посещение каждым из них можно будет определить как псевдоним на скрытом сервисе, а если расшарить между ними общее имя (как для всей группы) — больше вероятность утечки и попадания пароля аутентификации в руки врага.
Можно ещё сделать https со своим сертификатом на скрытый сервис, правда это слишком громоздко и всех проблем не решит и разработчики не рекомендуют так делать.
Другой вопрос — со стороны провайдера при тщательном анализе трафика, скрытый сервис, с которого больше качают данных, чем ему отправляют, будет заметнее, чем просто юзер, пользователь Tor. Плюс реакция на выключения электричества к примеру. Скрытый сервис в идеале должен бесперебойно работать 24 часа в сутки. Но если он "дважды скрытый", то так как противник не имеет к нему доступа через Tor, то это требование может быть и не так актуально.
Это всё замечательно, но разработчики экономят на цепочках при работе со скрытым сервисом. Вместо того, чтобы поменять цепочку, через опеределенное время клиент будет обнулять счётчик "загрязненности" цепочки, для любого запроса (для цепочек общего пользования, со счётчиком отмеряющим дефолтовые 10 минут, все новые запросы не будут подключаться к очень старым цепочкам). Цель такой экономии ускорить медленную работу скрытых сервисов, ибо от природы основные затруднения получаются при строительстве цепочек клиента и сервиса до их общей точки встречи.
Предатель может выдать и параметры для ssh-доступа, и root-пароль, если он главный сисадмин или просто ты ему его сказал :-)
Это несколько другая модель угрозы, не техническая, а основанная на человеческом факторе.
В идеале, если не сработал описанный человеческий фактор, откуда враг знает, что это за скрытый сервис и кому он принадлежит?
Разве только что устраивать налеты на квартиры и офисы, где установлены скрытые сервисы, в тотальном порядке.
А так, при аресте кого-то из товарищей, при нормальной организации об этом узнается гораздо быстрее, чем когда можно будет завершить атаку пересечения (и м.б. быстрее, чем он – под пытками ли, в порядке предательства или каким образом "сдаст" ресурс).
Где я писал, что он узнает в таком случае? В этом случае и авторизация не нужна (если допустить что слив никогда происходить не будет). А вот насколько релевантна такая модель угрозы вашему случаю – решать вам, и я вам лишь сделал намёк, что, может быть, стоит расширить модель угрозы.
комментариев: 9796 документов: 488 редакций: 5664
Опция HiddenServiceAuthorizeClient вообще-то новая, возможно сырая и протокол аутентификации плохо задокументирован даже в текущей альфа-версии.
Но потенциал у неё есть. Скрытый сервис как и обычно публикует дескрипторы через цепочки на корневые директории, а дескрипторы оттуда отзеркаливаются по узлам, которые поддерживают статистику (соответственно пользователь может скачать актуальный дескриптор с любого узла). В этих дескрипторах зашифрованы цепочки связи и узлы встречи. Часть параметров рэндомно меняется по таймауту, цепочки связи и узлы встречи в каждых новых, меняющихся и переопубликованных дескрипторах соответственно будут всё время разные.
Если клиент отправит неверный аутентификационный код, то аутентификация не пройдёт на узле встречи — он не сможет расшифровать данные для построения цепочки до скрытого сервиса.
Узлом встречи может быть любой публично доступный узел сети Tor, который имеет дескриптор.
В любом случае, узел встречи не знает, с каким скрытым сервисом и кого он соединяет, также как и не знает полной цепочки до скрытого сервиса (она расшифровывается послойно, на каждом узле — как луковица). Не знает её и клиент.
Поскольку данные о цепочках до скрытого сервиса всё время меняются, достаточно исключить неблагонадёжного пользователя из списка аутентификации, пока он не успел провести гипотетическую атаку с поиском корреляций в сети Tor. Если он этого сделать действительно не успел, то после его исключения скрытым сервисом можно оперировать также безопасно как и до этого. Для такого пользователя этот скрытый сервис станет невидимым в сети Tor. Он не просто не сможет с ним соединиться, он даже не сможет в рамках протокола определить его наличие/отсутствие в Tor-сети (при том что само имя скрытого сервиса даже нет необходимости менять). Узлы встречи тоже ничего не знают о скрытых сервисах, данные о которых они раздают — они хранятся только в зашифрованном виде. Для того чтобы это всё расшифровалось и соединилось, нужны данные от клиента, узла встречи м сервера. Но одной точки, в которой происходило бы полное восстановление информации нет. Здесь секрет фактически тоже разбит на три части, как и при обычном построении цепочек, только более сложным образом.
P. S. Всё-таки неясно, зачем нужно было затевать обсуждение ещё и в этой теме. Лучше обсуждать скрытые сервисы здесь. Если созреет материал для FAQ, то он будет туда включён.
P. S. S.
Кстати, нужно понять, эти данные передаются с узла встречи на сервис или нет? Если нет, то для сервиса все имена в каждом отдельном сеансе анонимны, расшаривать общее имя не нужно.
P. S. S. S. По одному предложению в проект сначала была идея использовать цепочку 3 узла от клиента до точки встречи + 3 узла от точки встречи до скрытого сервиса. Итого шесть узлов. Было бы идеально не с точки зрения тех, кто примитивно рассуждает, что чем длиннее, тем лучше, а с точки зрения, что узел встречи не знает IP клиента. Сейчас вроде ? используются только 4 узла, что непонятно — на чём сэкономили.
комментариев: 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-документации всё-таки скрытый сервис всегда получает запрос и решает:
Если исходить из этого, то сам по себе IP ничего не отсекает :-(
Сервис конечно будет невидим, но запросы на него поступать будут даже при неверном пароле.
Интересно, они собираются что-то с этим делать или нет. Другой вопрос: это так в текущей версии, или и в альфе?
комментариев: 9796 документов: 488 редакций: 5664