id: Гость   вход   регистрация
текущее время 23:23 17/11/2018
Владелец: unknown (создано 26/04/2013 13:09), редакция от 02/05/2013 16:55 (автор: unknown) Печать
Категории: криптография, софт, анонимность, алгоритмы, протоколы, tor, спецификации, аутентификация, стандарты
http://www.pgpru.com/Новости/2013/ПроектTorПриглашаетПомочьВРазработкеСкрытыхСервисов
создать
просмотр
редакции
ссылки

26.04 // Проект Tor приглашает помочь в разработке скрытых сервисов


Скрытые сервисы находятся в особенной ситуации. Несмотря на то, что у них есть преданные фанаты, никто из постоянных разработчиков Tor не занимается этим направлением. Это привело к накоплению массы особенностей, которые требуют изучения, реализации и разворачивания для увеличения безопасности и эффективности скрытых сервисов.


Цель блог-поста от Torproject на эту тему состоит из трёх пунктов:


  1. Ознакомить операторов скрытых сервисов с различными недостатками существующей архитектуры скрытых сервисов.
  2. Ознакомить исследователей с различными вопросами, связанными с изучением скрытых сервисов.
  3. Ознакомить разработчиков с изобилием задач по реализации кода, которые остались за пределами экосистемы скрытых сервисов.

Стоит отметить, что не всякая идея, перечисленная в этом блог-посте, является выдающейся. Это скорее наброски мыслей, чем серьёзная, хорошо обоснованная программа.


В любом случае, стоит начать знакомиться с проблемами.

Масштабирование скрытых сервисов


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


Одной из проблем с перегрузкой скрытых сервисов является то, что нагрузка от клиентов ложится на точки выбора соединения. Поскольку точки выбора соединения — это обычные узлы Tor-сети, то они не предназначены для обслуживания таких нагрузок.


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


Другая проблема со скрытыми сервисами — это нехватка возможностей балансирования нагрузки. Хотя вы можете делать балансирование нагрузки посредством TCP/HTTP-балансировщиков (таких как HAProxy), нет никаких возможностей балансировки, схожих с DNS-round-robin, когда балансировка осуществляется переотправкой клиентов на разные IP-адреса. Такая балансировка могла бы позволить иметь скрытым сервисам множество "подсервисов". Несмотря на некую привлекательность, такая архитектура вносит и множество проблем, таких как взаимные коммуникации между скрытыми сервисами, неясность места хранения долговременных ключей, назначения точек выбора соединения и др.

Защита от DoS-атак на точки выбора соединения


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


Для защиты от таких атак, Сайверсон и Овелье предложили Valet-узлы в своей работе для PETS-2006: "Valet Services: Improving Hidden Servers with a Personal Touch". Valet-узлы устанавливаются перед точками выбора сединения и работают как защитный слой. Это позволяет скрытым сервисам поддерживать ограниченное число точек выбора соединения, но при значительно большем числе точек контакта, без знания клиентами актуальных адресов точек выбора соединения.


Valet-узлы так до сих пор и не реализованы, в основном по причине больших затрат на их разработку и внедрение.

Длина ключа


Долговременная ключевая пара скрытых сервисов — это RSA-1024, что является малостойким по нынешним временам. Это означает, что в будущем, скрытые сервисы должны быть переведены или на другие величины ключей и/или на другой асимметричный криптоалгоритм.


Побочным эффектом такой миграции станет смена скрытыми сервисами своих onion-адресов. Для смягчения этого перехода возможно временное параллельное использование старых и новых ключевых пар с указанием клиентам необходимости обновления на новые адреса.


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

Атаки посредством директорий скрытых сервисов


Скрытые сервисы загружают свои дескрипторы на узлы Tor-сети, называемые директориями скрытых сервисов (HSDirs). Клиенты скачивают их дескрипторы и используют их для связи со скрытыми сервисами.


В текущей системе, HSDirs находятся в интересной позиции, которая позволяет им совершать следующие действия:


  • Собирать информацию об onion-адресах и соединяться с ними.
  • Изучать уровень популярности скрытых сервисов, отслеживая количество клиентов, которые запрашивают эти скрытые сервисы.
  • Отклонять запросы клиента и даже при достаточном содействии HSDirs, делать такой скрытый сервис временно недоступным.

Эти сценарии изучены в готовящейся к публикации IEEE S&P, озаглавленной "Вылавливание скрытых сервисов: детектирование, измерение, деанонимизация" (авторы: Алекс Бирюков, Иван Пустогаров и Ральф-Филип Вейнман). Обязательно прочитайте эту работу, как только она будет опубликована!


Рассмотрим некоторые предлагаемые исправления против атак, которые могут осуществлять директории скрытых сервисов:

Защита против сбора информации о количестве onion-адресов

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


Одним из возможных решений могло бы стать добавление симметричного ключа к onion-адресу и использование его для шифрования дескриптора перед отправкой на HSDir (по аналогии с тем, как сейчас работает аутентификация по cookie-дескрипторам). Клиент, знающий onion-адрес сможет расшифровать дескриптор, но HSDir, которая не знает onion-адреса, не сможет вывести его имя. Недостаток этой схемы в увеличении размера onion-адреса без увеличения его безопасности в отношении свойства самоаутентифицируемости. Помимо этого, HSDir всё ещё смогут извлекать открытый ключ скрытого сервиса из дескриптора, что позволит HSDir выслеживать дескриптор определённог скрытого сервиса.


Другое решение было предложено Робертом Рэнсомом:


Схема Роберта использует долговременную ключевую пару скрытого сервиса для выведения (односторонним способом) другой ключевой пары, которая и используется для подписи и шифрования дескриптора, загружаемого на HSDir. Эта конструкция позволяет HSDir без знания долговременных ключевых пар или содержимого дескриптора, проверять принадлежность загруженного дескриптора в связи с долговременным ключом скрытого сервиса. Клиент, который знает долговременный открытый ключ скрытого сервиса, может скачать его дескриптор с HSDir и проверить, что он действительно сгенерирован именно этим скрытым сервисом. См. предложение о более подробном рассмотрении этой идеи.


Идея Роберта увеличивает размер onion-адреса, но также делает его более стойким к атакам имперсонации (текущаяя 80-битная безопасность скрытых сервисов не даёт уверенности в защите от таких атак). Более того, такая идея не позволяет HSDir выслеживать дескрипторы скрытых сервисов и с течением времени.


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

Блокирование выслеживания популярности скрытых сервисов

HSDir могут выслеживать число пользователей, которые запрашивают скрытый сервис для изучения его популярности. Мы можем затруднить эту задачу, используя протокол приватного получения информации (PIR) для получения дескрипторов скрытых сервисов. Конечно, это не остановит точки выбора соединения от проведения выслеживания, но поскольку точки выбора соединения определяются самим скрытым сервисом, то риск снижается.


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

Создание сложности в установке вредоносной HSDir

Из-за влияния, которое HSDir оказывают на скрытые сервисы, мы начали разработку процедуры, усложняющей для узлов Tor получения статуса HSDir.


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

Улучшение производительности


Скрытые сервисы ооочеень меееедлееенныыыые и мы даже не можем ясно понять, почему. Они могут быть медленными из-за ресурсоёмкого процесса установления соединения в ходе создания цепочки, или потому что эта цепочка состоит из 6 узлов, или по каким-то другим причинам. Множество предложений было высказано для снижения задержек в скрытых сервисах, от настроек протокола скрытых сервисов, до трюков с javascript, и до радикальных решений о формировании цепочки до скрытых сервисов.


Давайте рассмотрим некоторые из этих предложений:


На конференции PETS 2007 Сайверсон и Овелье представили доклад "Улучшение эффективности и простоты установления цепочек в сети Tor, включая скрытые сервисы", где предложено упростить цепочки к скрытым сервисам за счёт избавления от необходимости раздельных соединений к точкам встречи.


Они отметили, что с использованием Valet-узлов, концепция точек встречи становится избыточной и такие цепочки скрытых сервисов могут быть сформированы только посредством Valet-узлов и точек установления соединения. Карстен Лёзинг составил предложение для Tor с вариантом этой идеи.


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

Анализ установления цепочек к скрытым сервисам посредством Torperf


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


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

Скрытые сервисы должны использовать старые точки установления соединения


Сейчас скрытые сервисы прекращают использовать цепочки до старых точек установления соединения после разрыва связи с ними. Хотя такое поведение имеет смысл, оно означает, что клиент, у которого остались старые дескрипторы скрытого сервиса, устанавливает свои соединения с неправильными точками. Это особенно неприятно при ситуации роуминга, частой смены сетей, потери существующих цепочек.


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

Шифрованные сервисы


Шифрованные сервисы — это корректный путь выполнения исходящих анклавов.


Шифрованные сервисы позволяют запустить неанонимный скрытый сервис, когда с серверной стороны цепочка встречи является однохоповой. Это имеет смысл, когда скрытый сервис не нуждается в собственной анонимности, но всё ещё хочет давать клиентам анонимный доступ и другие возможности, связанные с самоаутентификацией. См. оригинальное предложение Роджера о большем числе случаев использования и дополнительной информации.


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

Легкозапоминаемые onion-адреса


Треугольник Зуко описывает onion-адреса как безопасные и глобальные, но труднозапоминаемые. Набор решений по запоминаемости так и не оказался успешным по ряду причин.




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


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


Спасибо Роджеру, Роберту и другим людям за помощь комментариями и советами для этого блог-поста.


P.S. Не забывайте изучать публикации по анонимности, связанные с темами этого блог-поста.


Источник: The Torproject Blog


См. также: Основные изменения в системе Tor по сравнению с разработкой 2004 года, 10 способов раскрытия бридж-узлов Tor.


 
На страницу: 1, 2, 3, 4, 5, 6 След.
Комментарии [скрыть комментарии/форму]
— Гость (27/04/2013 09:16)   <#>
Unknown, огромное спасибо за перевод! Тема очень интересная, надо бы внимательно почитать и подумать над всем этим.
— Konstantine (27/04/2013 11:12)   профиль/связь   <#>
комментариев: 30   документов: 2   редакций: 12
unknown, я снимаю перед Вами шляпу.
— unknown (27/04/2013 16:13)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Спасибо, рад, что дословный нереферативный перевод относительно несложного материала оказался столь интересен.
— Гость (02/05/2013 02:31)   <#>

В оригинале:

This allows Hidden Services to maintain a limited number of Introduction Points, but many more contact points, without clients learning the actual addresses of the Introduction Points.

Что такое «contact points»? Создаётся впечатление, что к русским переводам надо прикреплять словарь, т.к. есть множество редких терминов, перевод которых не является устоявшимся.


Прям шизофрения какая-то: «HSDirs могут отклонять запросы клиента даже при достаточном содействии HSDirs». В оригинале:

Refuse to answer a client, and if enough HSDirs do this then the Hidden Service is temporarily unreachable

Т.е. «HSDirs могут не отвечать клиенту. Если множество HSDirs начинут так делать, HS станет временно недоступным».


Unknown, мы будем ждать анонса от вас. :)


Почитал ссылку, что-то понял, но впечатления всё равно остались мутными. Unknown, если вы уже разбирались с этим, могли бы на пальцах пояснить суть? Цель задачи ясна, но технические детали непонятны совсем. Например,
  1. В чём в данном случае (текущем протоколе) состоит «цикл вращения»?
  2. По какому примерно алгоритму HSы загружают свои дескрипотры на HSDir'ы?


Ссылку после копипасты вы забыли исправить: там должно быть это, а вы продублировали предыдущую.


Наговаривают на них. Они, как и всё за Tor'ом, сравнительно шустры, но имеют очень длинный пинг (время на установление первого коннекта). Если же коннект установлен, скорость вполне приличная*.


Никогда бы не подумал, что у людоедства могут быть и иные значения. :)


Их в разное время было уже несколько (тот же toogle, например). Тем не менее, пока число HS невелико, концепция wiki, классифицирующая их все по категориям, оказывается более удобной для поиска.


Это — если не ходить по ссылкам. А если ходить, то можно утонуть.

*Надеюсь, никто не начнёт её огульно сравнивать со скоростью соединения с интернетом напрямую, т.е. когда Tor'а нет вообще.
— unknown (02/05/2013 17:06)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Есть Introduction Points, есть Rendezvous Points. Что такое в протоколе «contact points», честно говоря самому неясно. Может это относится к каким-то типам из уже названных?

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


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

В чём в данном случае (текущем протоколе) состоит «цикл вращения»? По какому примерно алгоритму HSы загружают свои дескрипотры на HSDir'ы?

Подробно не разбирал, там плохое описание по ссылке. Также как и вы могу предположить в общем виде, что формируется псевдослучайный порядок выбора для размещения дескрипторов. После прокрутки всего цикла (разместили на наборе узлов, например x1, y1, z1, на втором шаге x2, y2, z2 и так до … xn, yn, zn до конца цикла), идёт новый псевдослучайный выбор узлов — или повторяется или меняется, непонятно; непонятно сделана ли там перестановка на основе каких хэшируемых данных и смена перестановки после завершения цикла или выбор с повторением.

Спасибо за конкретные замечания.
— SATtva (04/05/2013 10:15)   профиль/связь   <#>
комментариев: 11532   документов: 1036   редакций: 4082
Подробное описание hash ring было в соответствующем proposal'е, но сейчас не могу его нагуглить.
— Гость (04/05/2013 16:45)   <#>
Зачем гуглить, нужно сразу искать в proposal'ах. Distributed Storage for Tor Hidden Service Descriptors.
— Гость (04/05/2013 17:12)   <#>
Можно сразу читать спецификации на актуальный протокол. Tor Rendezvous Specification. Proposal это лишь proposal.
— SATtva (04/05/2013 22:26)   профиль/связь   <#>
комментариев: 11532   документов: 1036   редакций: 4082
Действительно. Благодарю.
— Гость (04/05/2013 23:48)   <#>

Можно было бы сказать «охранник», но это слово уже занято «охранными (guard) узлами». Остаётся разве что узел-постовой или узел-гардеробщик: встречает трафик, раздевает, проверяет обыскивает карманы, забирает всё ценное и пропускает дальше. :)


Прошёлся поиском, не увидел там ничего про contact points. По логике вещей они там должны быть. А про ring'и кое-что есть, да.


Может быть, это связано с вводом какой-то такой функциональности (?).
— Гость (03/06/2013 13:32)   <#>
Почему бы проекту pgpru не поддерживать свой скрытый сервис?
— unknown (03/06/2013 13:52, исправлен 03/06/2013 13:52)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Может имело бы смысл говорить об этом:

Шифрованные сервисы позволяют запустить неанонимный скрытый сервис, когда с серверной стороны цепочка встречи является однохоповой. Это имеет смысл, когда скрытый сервис не нуждается в собственной анонимности, но всё ещё хочет давать клиентам анонимный доступ и другие возможности, связанные с самоаутентификацией.


Кстати, упомянутая в посте работа, теперь fileдоступна, но ничего нового в ней не сказано. Более того, часть проблем решена или решается, часть давно висит в тикетах проекта.

— Гость (03/06/2013 14:09)   <#>
Это имеет смысл, когда скрытый сервис не нуждается в собственной анонимности, но всё ещё хочет давать клиентам анонимный доступ и другие возможности, связанные с самоаутентификацией

Я вообще не понимаю, какой смысл во всем этом. Зачем создавать скрытый сервис, если он неанонимный? Анонимный доступ клиентов осуществляется через тот же TOR, а самоаутентификация производится посредством https.
— Гость (03/06/2013 14:33)   <#>
Почему бы проекту pgpru не поддерживать свой скрытый сервис?

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

Зачем создавать скрытый сервис, если он неанонимный? Анонимный доступ клиентов осуществляется через тот же TOR, а самоаутентификация производится посредством https.

За тем, что клиенты скрытых сервисов получают для себя куда большую анонимность.
— Гость (03/06/2013 14:35)   <#>
Между прочим, оба вопроса есть в ФПП.
На страницу: 1, 2, 3, 4, 5, 6 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3