Регистрация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.
Это векторная графика, для браузера это картинка.
Уязвимость, которая всегда рядом. Настигает из любого движка (в том числе этого форума) где возможна вставка изображений или ссылок на них. Буквально любая страница.
И бага то не новая, а самое смешное, что отключить индивидуально svg невозможно, все опции выпили. Видимо скоро мазилла будет советовать установить антивирус для исправления уязвимостей в их браузере.
В багзилле. Вариантов такой графики много, переловить всех по хешу или паттерну не возможно.
Не бага значит, можно не исправлять.
По-настоящему удалённый DoS, а не уязвимость. Деанон в TBB так не сделать.
Если бы падал только браузер, но там же всё завязано, процесс тора мониторит наличие браузера и отключается если тот падает.
Пользователям TBB такие отключения могут помочь сделать деанон. Атакующему не нужно иметь контроля за экситом или сайтом или даже запускать гвардом, если может наблюдать ваш сегмент сети, в том числе вайфай. Для подтверждения трафика достаточно вставить картинку на вашем любимом форуме и смотреть аномалии в эфире.
Ещё немножко паранои в тему. Некоторое время назад было решено посмотреть, не коннектится ли кто левый к скрытому сервису, адрес которого нигде не публиковался. Оказывается, коннектится! Был обнаружен сканировщик на определённом onion-адресе. Удалось на него даже зайти и утянуть его БД, что он там насканил. Там было два списка: адреса, которые в оффлайне (около 5k) и адреса, которые в онлайне (около 1.4k). По глупости оффлайновая база не была забрана, а на следующий день скнировщики, видать, засекли, что их тоже "отсканировали", и тут же закрыли сайт. Те 1.4k onion адресов можете загрузить. Внутри текстовый файл из двух полей: адрес и название главной страницы, что для большинства адресов является информативным описанием сервисов. В принципе, там много интересного. Оказывается, много сайтов также доступны, как скрытые сервисы, но не афишируют этого. В списке также есть, конечно, те адреса, которые никогда нигде не публиковались.
Однако, и это не всё. Позже был обнаружен скан со стороны TorSearch. Он работает в точности по такому же принципу. Видимо, он выдёргивает onion-адреса из тех, что ему удалось получить через подконтрольные HSDir'ы, а потом пытается их проиндексировать.
/comment70336:
Да всё там просто. Место хранения дескриптора меняется по заданному закону, потому можно заранее сказать, какие ноды когда будут его хранить. Грубые оценки (пишу по памяти) таковы: стабильный узел (или группа узлов?) даже без требований высокой пропускной способности хотя бы какой-то период времени будет хранить дескриптор любого onion-адреса за двухнедельный промежуток времени. Если скрытый сервис в онлайне 2 недели, как и вам подконтрольный HSDir, то вы узнаете его onion-адрес. Кстати, в момент, когда будете его хранить, можете его не отдавать клиентам, сделав его на этот промежуток времени недоступным (точнее, там адрес хранится на нескольких HSDir'ах, близких в смысле Хэмминга, но смысл в этом).
По сути протокол никак не защищает тайну непубликовавшихся адресов. Приватные скрытые сервисы — это другое дело, там HSDir'ы могут их разве что ранжировать по популярности, но адреса не узнают, он достаточно хорошо защищён.
В логах отмечается такое:
Наверно, грепанье дескрипторов HS уже много кто делает.
комментариев: 511 документов: 2 редакций: 70
Такое уже было, но теперь снова и на ещё более широкую ногу: склонированы 255 скрытых сервисов, доменные имена совпадают с оригиналом в первых пяти символах адреса. Атака, наверно, рассчитана на тех, кто ищет адреса через Tor-поисковики. Правда, если где-то в онлайн-списке HS'ов тайком подменить адрес скрытого сервиса его клоном, это тоже может никто не заметить.
комментариев: 12 документов: 0 редакций: 0
Статья
Анонс
Скрытым сервисам конец или они ещё послужат?
комментариев: 511 документов: 2 редакций: 70
Интересно, это как? Патчить сам Tor? Штатно ручной выбор HSDir'ов, насколько я помню, не предусмотрен.
комментариев: 511 документов: 2 редакций: 70
В протоколе назревают кардинальные изменения:
Это говорит о том, что протокол скрытых сервисов ещё очень сырой, а разработчики сами не очень понимают, как делать правильно.
комментариев: 12 документов: 0 редакций: 0
Статья