Регистрация26.04 // Проект Tor приглашает помочь в разработке скрытых сервисов
Скрытые сервисы находятся в особенной ситуации. Несмотря на то, что у них есть преданные фанаты, никто из постоянных разработчиков Tor не занимается этим направлением. Это привело к накоплению массы особенностей, которые требуют изучения, реализации и разворачивания для увеличения безопасности и эффективности скрытых сервисов.
Цель блог-поста от Torproject на эту тему состоит из трёх пунктов:
- Ознакомить операторов скрытых сервисов с различными недостатками существующей архитектуры скрытых сервисов.
- Ознакомить исследователей с различными вопросами, связанными с изучением скрытых сервисов.
- Ознакомить разработчиков с изобилием задач по реализации кода, которые остались за пределами экосистемы скрытых сервисов.
Стоит отметить, что не всякая идея, перечисленная в этом блог-посте, является выдающейся. Это скорее наброски мыслей, чем серьёзная, хорошо обоснованная программа.
В любом случае, стоит начать знакомиться с проблемами.
Масштабирование скрытых сервисов
Текущая архитектура скрытых сервисов масштабируется не слишком хорошо. В идеале, большие вебсайты должны иметь возможность полностью переместиться в скрытые сервисы 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.
Точно так же как публичные директории хранят открытые ключи gpg, и всем они доступны, хранились бы super-silk-road.onion + открытый ключ этого силк роуда, сквотеры разве что развели бы там огороды, но и это лишь +.
В нынешней скудности скрытых тор-сервисов(500+) как раз сквотеров и не хватает.
комментариев: 11558 документов: 1036 редакций: 4118
Почитайте про Zooko's triangle.
>>> Обязательно прочитайте эту работу, как только она будет опубликована!
>> Unknown, мы будем ждать анонса от вас. :)
> Кстати, упомянутая в посте работа, теперь доступна, но ничего нового в ней не сказано. Более того, часть проблем решена или решается, часть давно висит в тикетах проекта.
Спасибо Гостю за напоминание, вот новостной оригинал, а вот сама работа. Действительно страшно. Они подняли 58 своих серверов на Амазоне (то ли просто Tor-ноды, то ли HSDir'ы), после чего часть из них стали guard'ами. Для некоторых цепочек они были и HSDir'ы (вроде так называется?) и guard'ы, а потому элементарно выследили соответствие IP-адрес клиента ↔ onion-сайт, на который он обращается:
Для деанонимизированных IP построили карту. По характеру активности (регулярные посещения, нерегулярные) авторы предположили, что можно легко отделять клиентов от продавцов Silk'а.
Деанон проводили на примере клиентов ботнет-сетей (заражённых машин). Можно только догадываться,
что АНБкто ещё ранее использовал такую же методику, имея куда больше серверов, и отслеживая практически всех клиентов всех скрытых сервисов. Статья интересная, читается легко, советую прочитать полностью. Медведей, которые слишком много знают, прошу воздержаться и не показывать здесь свои глубокие знания при рассматривании таблицы на стр. 4.Статистика: уязвимые версии — все до 0.2.4.10-α. Какие версии уязвимы из стабильных не написано. Судя по некоторым страницам, 0.2.4.10-α — это времена типа февраля 2013, или я путаю? Когда был первый 0.2.4.10-α-релиз?
Число скрытых сервисов в сети — 39824, большая часть которых, по всей видимости, была создана автоматически и используется для ботнетов. Другие интересные моменты:
Кто-то таки удосужился обнаруживать попытки сканирования и делать из этого своевременные выводы.
Внутри onion'а есть даже свои фишинговые сайты(!).
Потрясающе. Это apache или самопал так себя повёл, что левым юзерам без всякой авторизации сервер выдал всю статистику о себе? Почему доступ к server-status-страницам легко получает любой, кто угодно? Корреляция по времени, аптайму, — и профилирование из количества перешло в качество.
Было ещё одно альтернативное исследование на эту же тему.
Немного об авторах:
Цитата из новой работы:
Работа [6], я так понимаю, — как раз та, про которую вы пишете «ничего нового в ней не сказано. Более того, часть проблем решена или решается, часть давно висит в тикетах проекта».
Казалось бы, 58 серверов — это же очень мало, да и от guard'а до rendezvous point(?), которая хранит дескриптор onion-ресурса, не один хоп. Как это у них так получилось? Звучит так, как будто посетители clearnet через Tor более анонимны, чем посетители скрытых ресурсов.
Статья ещё раз заставляет подумать о шифрпанковском подходе. Почему эта ошибка была просмотрена? 500k юзеров, и ни один не заметил, а тут пришли 3 человека с академическим бэкграундом, внимательно поковыряли спеки и нашли такое, что другим даже не снилось. Если бедная открытая наука способна на такое, то что говорить об АНБ... У них, наверно, весь Tor уже давно целиком и полностью под колпаком. Мы все умрём.
Это факт.
Они обманули пороги при которых происходит раздача флагов и исказили общую сумму по счетчикам, за счет чего смогли получить для 1-байтовых узлов флаги HSDir'ов. Главное в их работе было получение доступа к дескрипторам скрытых ресурсов и пересчет содержимого, а деанон клиентов это уже бонус. Более того там у них описан не правильный способ детектировать клиентов, так что возможно в живой сети никто из клиентов не был деанонимизирован.
Все исправления пока свелись лишь фиксам частей кода для управляющих директорий. Шансы получить флаги директорий уменьшены, поэтому задешево наводнить своими HSDir'ами сеть теперь сложно. Но рекомендуемые исследователями изменения дизайна скрытых сервисов не произведено. Схема доступа к скрытым сервисам прежняя, поэтому злонамеренный HSDir при участии Guard всё так-же способен сопоставить клиента и посещаемый скрытый сервис.
Но ему конечно должны улыбнуться удача хранить и обслуживать этот дескриптор, а это зависит от времени, дескриптора
и фазы луны. Одиночкам атаковать особо нечего.Хм, вот прям так сразу видите ошибку в их работе? А можно подробнее?
Сколько хопов между HSDir'ом и guard'ом? Наверняка ведь минимум 1. Вероятность того, что из 3-4k нод все 3 узла будут среди их 58 серверов, ничтожна мала. Ну, хорошо, если они хостили все дескрипторы, то один узел уже их, но надо ещё 2, причём 2 из 3k узлов.
Если они эффективно обманывали статистику, может, им и удалось перетянуть на себя существенную долю трафика, но слабо верится. Не факт, что их 58 узлов вообще имели выскокую полосу пропускания.
комментариев: 9796 документов: 488 редакций: 5664
Вроде ничего на это не указывает. Скорее наоборот, в атаке нет никакой новости, поскольку были известны ранние публикации, то и эта ничем не удивила. Разве что не расписан подробнее механизм атаки, но через "traffic signature" (т.е. активную модуляцию трафика) можно было атаковать и ранее. И только из-за карты с айпишниками это стало новостью? Новость как раз только в том, что раз HSDir раздаёт статистику скрытых сервисов, названия которых он может вычислить, то он может проводить и целевые атаки не только на деанон самих HS, но и их клиентов. Это прогресс, но ожидаемый. В clearner со стороны экситов это должно работать точно также.
Разработчики Tor'a годами предупреждали об этом и предсказывали эти атаки. Их мнение приводилось у нас в форуме. HS в текущем дизайне ненадёжны, на улучшения дизайна в годовых таймлайнах не выделялось вообще ничего и на них ожидались атаки. А шифрпанковским альтернативам тору от открытой науки ничего не угрожает, пока они не столь популярны (на уровне биткоина или /dev/random, к примеру), ковыряться в решете из дыр их кривого дизайна представители открытой науки не будут, неблагодарное это дело. Разве только АНБ-шники, которым открытые публикации не нужны, а выделить сколько-то человек на проработку ресурсы есть.
Есть много теоретических атак, которые очень трудно зазамлить, или которые требуют очень больших ресурсов (разработки своего сложного протокола, подконтрольность большого числа высокопропускных нод и т.д.), поэтому да, то, что 3 бедняка с 58-ю облачными низкопропускными узлами могут так много, оказалось большой неожиданностью. Извините, у них бюджет был, наверно, не миллионы, да и человеческих ресурсов тоже мало. Программную часть вообще, скорей всего, делал всего один человек.
По моим примитивным представлениям, в протоколе доступа к HS было какое-то различие: одни хранят дескрипторы, но не знают, чьи дескрипторы они хранят; другие хранят onion-имена, но не знают пути к ним. Ну, или что-то в таком духе. Короче, знать и onion-имя и путь к сервису и при этом участвовать в построении цепочки к нему — это всё вместе слишком много для одной Tor-ноды. Не зря они написали, что использовали уязвимость, выдав свои ноды за высокопропускные.
Главное — это то, что толковой альтернативы onion-ресурсам нет. Единственное, что могло бы ей быть — это сайты по Freenet, который вроде как появился раньше Tor'а (и его немало изучали в академической прессе), имеет защиту от глобального наблюдателя и всё такое... но внимания сообщества к нему несоизмеримо меньше, поэтому не факт, что для АНБ бороться с Freenet тяжелее, чем с onion-ресурсами. Плюс строить сеть friend2friend во Freenet тяжело (неоткуда взять надёжные пиры), а выбор пиров наобум может сильно ослаблять анонимность протокола... Какие-то такие сумбурные мысли.
Не факт.
комментариев: 9796 документов: 488 редакций: 5664
Насчёт этого очень сомнительно.
А я думал, вы про квантовое бессмертие.
По крайней мере, покрывающий трафик там есть изначально, и он генерируется всегда на уровне самого протокола.
Михайло Потапыч врывается в тред!
Так только этим и занимаемся, что воздерживаемся*. Все, как завещал великий дедушка
МорозЛенин!Тебе корешки, а мне
петушкивершки! А то заломаю!Интересный момент, на 4 стр. у adult-HS последние знаки в доменном имени заменены на звездочки, а у драгдилеров и прочих антисоциальных элементов получается "Добро пожаловать" — полный адрес. Как это понимать? Что авторы работы хотели этим сказать, чего добиваются?
Поучительная статейка и статистика, хотя концептуально не новая. Чем больше мы знаем, тем меньше знает о нас АНБ.
Умышленно
"панкошифрскую"i2p игнорируете?Представить себе ситуацию, когда Tor или другая анонимная сеть реального времени станет теоретически стойкой к различным (теоретическим и практическим) атакам на самом деле трудно. Поэтому
ежедневныепостоянные обнаружения дыр различной толщины и доклады об успехах той или иной атаки и уведомления о заплатках — это давно обыденность под попкорнсо сгущенкой. Раньше не видел и сейчас не вижу поводов для паники и паранойи, т.к. не стоит наивно полагаться на что-то одно. Tor — концептуально отличная штука, дающая приличные возможности для анонимных коммуникаций в реальном времени со всеми потенциальными уязвимостями отсюда вытекающими. Но, как говорится, не Tor'ом единым. Со временем сеть не становится слабее, попытки атак и анализа также принимаются к сведению и фиксятся, многими принимались и ранее без уведомительного порядка, т. к. не нужно семи пядей во лбу для понимания важности страховки на случай форс-мажора. Идти через дорогу за хлебом илина почтув подворотню за закладкой** — все-таки разные степени риска и модели угроз, хотя путь один и тот же в общем случае. То же самое касается походов онлайн.* Прошу обратить особое внимание на п. 1,2,3,4,5,6,7(?),8,9,10,11,12.
** А чего? Им можно указывать полные адреса и выкладывать в паблик, а мне тонко намекнуть нет?:)
"панкошифрскую"i2p игнорируете?Да. Лично я считаю, что I2P не добавляет мне практически никакой безопасности. Основная критика — управление статистикой и ключами, которыми подписывается эта статистика.
А на что ещё вы предлагаете полагаться помимо VPN до входа в Tor, анонимной связи с провайдером посредством неименных симок и 3g и т.п.? У вас есть какая-то другая, своя сеть Tor?
Первое и главное — полагаю, авторы хотели оградить неразумных читателей от излишнего любопытства зайти на те или иные сайты, не предприняв при этом надлежащих подстраховок. Если говорить о типичных юрисдикциях, то заход на сайт драгдиллеров [а часто и приобретение накроты в дозах меньших некоторой (это и в РФ так)] не являются нарушением закона. Т.е. чёткая криминализация есть только для продавцов. Соответственно, риски, которые несут посетители Silk'а, несоизмеримы с теми, которые несут посетители Adult-сайтов. Кроме того, публикация ссылок на такие Adult-ресурсы преследуется по закону во многих юрисдикциях. Чтобы не подставлять под уголовное преследование ни себя, ни читателей статьи, они их запикали звёздами, поэтому не вижу, чему здесь удивляться.