id: Гость   вход   регистрация
текущее время 17:04 28/03/2024
Владелец: unknown (создано 26/04/2013 13:09), редакция от 02/05/2013 16:55 (автор: unknown) Печать
Категории: криптография, софт, анонимность, алгоритмы, протоколы, tor, спецификации, аутентификация, стандарты
https://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 След.
Комментарии [скрыть комментарии/форму]
— Гость (21/07/2013 18:18)   <#>
Почему они не использую хьюман ридабл адреса, в паре с открытым ключем.

Точно так же как публичные директории хранят открытые ключи gpg, и всем они доступны, хранились бы super-silk-road.onion + открытый ключ этого силк роуда, сквотеры разве что развели бы там огороды, но и это лишь +.

В нынешней скудности скрытых тор-сервисов(500+) как раз сквотеров и не хватает.
— SATtva (21/07/2013 18:31)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Как бы в этом случае выполнялось связывание адреса и ключа? Если домен и ключ — просто две записи в одной строке БД, то оператор БД может по своему желанию заменить ключ скрытого сервиса. Если в БД HS Dir'а хранится подписанный скрытым сервисом пакет, содержащий его адрес и ключ, то, опять же, ничто не мешает оператору HS Dir'а подменить адрес/ключ и подпись.

Почитайте про Zooko's triangle.
— Гость (12/09/2013 03:54)   <#>
/comment65373:
>>> Обязательно прочитайте эту работу, как только она будет опубликована!
>> Unknown, мы будем ждать анонса от вас. :)
> Кстати, упомянутая в посте работа, теперь доступна, но ничего нового в ней не сказано. Более того, часть проблем решена или решается, часть давно висит в тикетах проекта.

Спасибо Гостю за напоминание, вот новостной оригинал, а вот сама работа. Действительно страшно. Они подняли 58 своих серверов на Амазоне (то ли просто Tor-ноды, то ли HSDir'ы), после чего часть из них стали guard'ами. Для некоторых цепочек они были и HSDir'ы (вроде так называется?) и guard'ы, а потому элементарно выследили соответствие IP-адрес клиента ↔ onion-сайт, на который он обращается:

Whenever it receives a descriptor request for that hidden service, it sends it back encapsulated in a specific traffic signature which will be then forwarded to the client via its Guard node. With some probability, the client's Guard node is in the set of Guards controlled by the attacker. Whenever an attacker's Guard receives the traffic signature, it can immediately reveal the IP address of the client.

Для деанонимизированных IP построили карту. По характеру активности (регулярные посещения, нерегулярные) авторы предположили, что можно легко отделять клиентов от продавцов Silk'а.

Деанон проводили на примере клиентов ботнет-сетей (заражённых машин). Можно только догадываться, что АНБ кто ещё ранее использовал такую же методику, имея куда больше серверов, и отслеживая практически всех клиентов всех скрытых сервисов. Статья интересная, читается легко, советую прочитать полностью. Медведей, которые слишком много знают, прошу воздержаться и не показывать здесь свои глубокие знания при рассматривании таблицы на стр. 4.

Статистика: уязвимые версии — все до 0.2.4.10-α. Какие версии уязвимы из стабильных не написано. Судя по некоторым страницам, 0.2.4.10-α — это времена типа февраля 2013, или я путаю? Когда был первый 0.2.4.10-α-релиз?

Число скрытых сервисов в сети — 39824, большая часть которых, по всей видимости, была создана автоматически и используется для ботнетов. Другие интересные моменты:

The full coverage could not be achieved since we scanned different port ranges on different days and in a number of cases hidden services which we partially scanned on one day went off-line the day of the next scan

Кто-то таки удосужился обнаруживать попытки сканирования и делать из этого своевременные выводы.

At least one of these addresses is a a phishing site imitating the real Silk Road login interface.

Внутри onion'а есть даже свои фишинговые сайты(!).

As a next step, we tried to retrieve server-status pages, which succeeded. By analysing these pages we noticed that traffic to these servers remained constant at about 330 KBytes/sec and had about 10 client requests per second, almost exclusively POST requests. Looking at other hidden services we discovered another 4 onion addresses with the very same characteristics: they had port 80 open, they were returning 503 server errors, and had server-status page available. They also had similar traffic and client request rates. By looking at the uptime of the Apache server on the server-status pages we noticed that they could be divided into two groups with exactly same uptime within each group. From this we assumed that different hidden services lead to two physical servers.

Потрясающе. Это apache или самопал так себя повёл, что левым юзерам без всякой авторизации сервер выдал всю статистику о себе? Почему доступ к server-status-страницам легко получает любой, кто угодно? Корреляция по времени, аптайму, — и профилирование из количества перешло в качество.

Было ещё одно альтернативное исследование на эту же тему.

Немного об авторах:
  1. Иван Пустогаров: выпускник МИФИ-2009, дилом в этой лабе ИППИ, сейчас — аспирант в Люксембурге. Не исключено, что он где-то здесь среди нас и читает этот форум.
  2. Алекс Бирюков: известен много чем, в/о и PhD — в Технионе, работал в институте Вайцамна и в Лювене, сейчас в Люксембурге.
— Гость (12/09/2013 04:16)   <#>

Цитата из новой работы:

In order to overcome the above mentioned limitations, we exploited a flaw which was discovered in [6] and was present in Tor versions before 0.2.4.10-alpha.

Работа [6], я так понимаю, — как раз та, про которую вы пишете «ничего нового в ней не сказано. Более того, часть проблем решена или решается, часть давно висит в тикетах проекта».

Казалось бы, 58 серверов — это же очень мало, да и от guard'а до rendezvous point(?), которая хранит дескриптор onion-ресурса, не один хоп. Как это у них так получилось? Звучит так, как будто посетители clearnet через Tor более анонимны, чем посетители скрытых ресурсов.

Статья ещё раз заставляет подумать о шифрпанковском подходе. Почему эта ошибка была просмотрена? 500k юзеров, и ни один не заметил, а тут пришли 3 человека с академическим бэкграундом, внимательно поковыряли спеки и нашли такое, что другим даже не снилось. Если бедная открытая наука способна на такое, то что говорить об АНБ... У них, наверно, весь Tor уже давно целиком и полностью под колпаком. Мы все умрём.
— Гость (12/09/2013 04:54)   <#>

Это факт.
— Гость (12/09/2013 05:20)   <#>

Они обманули пороги при которых происходит раздача флагов и исказили общую сумму по счетчикам, за счет чего смогли получить для 1-байтовых узлов флаги HSDir'ов. Главное в их работе было получение доступа к дескрипторам скрытых ресурсов и пересчет содержимого, а деанон клиентов это уже бонус. Более того там у них описан не правильный способ детектировать клиентов, так что возможно в живой сети никто из клиентов не был деанонимизирован.
Все исправления пока свелись лишь фиксам частей кода для управляющих директорий. Шансы получить флаги директорий уменьшены, поэтому задешево наводнить своими HSDir'ами сеть теперь сложно. Но рекомендуемые исследователями изменения дизайна скрытых сервисов не произведено. Схема доступа к скрытым сервисам прежняя, поэтому злонамеренный HSDir при участии Guard всё так-же способен сопоставить клиента и посещаемый скрытый сервис.
— Гость (12/09/2013 05:24)   <#>

Но ему конечно должны улыбнуться удача хранить и обслуживать этот дескриптор, а это зависит от времени, дескриптора и фазы луны. Одиночкам атаковать особо нечего.
— Гость (12/09/2013 08:29)   <#>

Хм, вот прям так сразу видите ошибку в их работе? А можно подробнее?


Сколько хопов между HSDir'ом и guard'ом? Наверняка ведь минимум 1. Вероятность того, что из 3-4k нод все 3 узла будут среди их 58 серверов, ничтожна мала. Ну, хорошо, если они хостили все дескрипторы, то один узел уже их, но надо ещё 2, причём 2 из 3k узлов.

Если они эффективно обманывали статистику, может, им и удалось перетянуть на себя существенную долю трафика, но слабо верится. Не факт, что их 58 узлов вообще имели выскокую полосу пропускания.
— unknown (12/09/2013 20:35)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Вроде ничего на это не указывает. Скорее наоборот, в атаке нет никакой новости, поскольку были известны ранние публикации, то и эта ничем не удивила. Разве что не расписан подробнее механизм атаки, но через "traffic signature" (т.е. активную модуляцию трафика) можно было атаковать и ранее. И только из-за карты с айпишниками это стало новостью? Новость как раз только в том, что раз HSDir раздаёт статистику скрытых сервисов, названия которых он может вычислить, то он может проводить и целевые атаки не только на деанон самих HS, но и их клиентов. Это прогресс, но ожидаемый. В clearner со стороны экситов это должно работать точно также.


Статья ещё раз заставляет подумать о шифрпанковском подходе. Почему эта ошибка была просмотрена? 500k юзеров, и ни один не заметил, а тут пришли 3 человека с академическим бэкграундом, внимательно поковыряли спеки и нашли такое, что другим даже не снилось. Если бедная открытая наука способна на такое, то что говорить об АНБ...

Разработчики Tor'a годами предупреждали об этом и предсказывали эти атаки. Их мнение приводилось у нас в форуме. HS в текущем дизайне ненадёжны, на улучшения дизайна в годовых таймлайнах не выделялось вообще ничего и на них ожидались атаки. А шифрпанковским альтернативам тору от открытой науки ничего не угрожает, пока они не столь популярны (на уровне биткоина или /dev/random, к примеру), ковыряться в решете из дыр их кривого дизайна представители открытой науки не будут, неблагодарное это дело. Разве только АНБ-шники, которым открытые публикации не нужны, а выделить сколько-то человек на проработку ресурсы есть.
— Гость (13/09/2013 03:53)   <#>

Есть много теоретических атак, которые очень трудно зазамлить, или которые требуют очень больших ресурсов (разработки своего сложного протокола, подконтрольность большого числа высокопропускных нод и т.д.), поэтому да, то, что 3 бедняка с 58-ю облачными низкопропускными узлами могут так много, оказалось большой неожиданностью. Извините, у них бюджет был, наверно, не миллионы, да и человеческих ресурсов тоже мало. Программную часть вообще, скорей всего, делал всего один человек.


По моим примитивным представлениям, в протоколе доступа к HS было какое-то различие: одни хранят дескрипторы, но не знают, чьи дескрипторы они хранят; другие хранят onion-имена, но не знают пути к ним. Ну, или что-то в таком духе. Короче, знать и onion-имя и путь к сервису и при этом участвовать в построении цепочки к нему — это всё вместе слишком много для одной Tor-ноды. Не зря они написали, что использовали уязвимость, выдав свои ноды за высокопропускные.

Главное — это то, что толковой альтернативы onion-ресурсам нет. Единственное, что могло бы ей быть — это сайты по Freenet, который вроде как появился раньше Tor'а (и его немало изучали в академической прессе), имеет защиту от глобального наблюдателя и всё такое... но внимания сообщества к нему несоизмеримо меньше, поэтому не факт, что для АНБ бороться с Freenet тяжелее, чем с onion-ресурсами. Плюс строить сеть friend2friend во Freenet тяжело (неоткуда взять надёжные пиры), а выбор пиров наобум может сильно ослаблять анонимность протокола... Какие-то такие сумбурные мысли.
— Гость (13/09/2013 05:11)   <#>
>Мы все умрём.

Это факт.

Не факт.
— unknown (13/09/2013 16:53, исправлен 13/09/2013 16:56)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Насчёт этого очень сомнительно.



А я думал, вы про квантовое бессмертие.

— Гость (14/09/2013 00:21)   <#>

По крайней мере, покрывающий трафик там есть изначально, и он генерируется всегда на уровне самого протокола.
— Гость (14/09/2013 00:54)   <#>

Михайло Потапыч врывается в тред!
Так только этим и занимаемся, что воздерживаемся*. Все, как завещал великий дедушка Мороз Ленин!
Тебе корешки, а мне петушки вершки! А то заломаю!

Интересный момент, на 4 стр. у adult-HS последние знаки в доменном имени заменены на звездочки, а у драгдилеров и прочих антисоциальных элементов получается "Добро пожаловать" — полный адрес. Как это понимать? Что авторы работы хотели этим сказать, чего добиваются?

Поучительная статейка и статистика, хотя концептуально не новая. Чем больше мы знаем, тем меньше знает о нас АНБ.


Умышленно "панкошифрскую" i2p игнорируете?
Представить себе ситуацию, когда Tor или другая анонимная сеть реального времени станет теоретически стойкой к различным (теоретическим и практическим) атакам на самом деле трудно. Поэтому ежедневные постоянные обнаружения дыр различной толщины и доклады об успехах той или иной атаки и уведомления о заплатках — это давно обыденность под попкорн со сгущенкой. Раньше не видел и сейчас не вижу поводов для паники и паранойи, т.к. не стоит наивно полагаться на что-то одно. Tor — концептуально отличная штука, дающая приличные возможности для анонимных коммуникаций в реальном времени со всеми потенциальными уязвимостями отсюда вытекающими. Но, как говорится, не Tor'ом единым. Со временем сеть не становится слабее, попытки атак и анализа также принимаются к сведению и фиксятся, многими принимались и ранее без уведомительного порядка, т. к. не нужно семи пядей во лбу для понимания важности страховки на случай форс-мажора. Идти через дорогу за хлебом или на почту в подворотню за закладкой** — все-таки разные степени риска и модели угроз, хотя путь один и тот же в общем случае. То же самое касается походов онлайн.


* Прошу обратить особое внимание на п. 1,2,3,4,5,6,7(?),8,9,10,11,12.

** А чего? Им можно указывать полные адреса и выкладывать в паблик, а мне тонко намекнуть нет?:)
— Гость (15/09/2013 17:43)   <#>

Да. Лично я считаю, что I2P не добавляет мне практически никакой безопасности. Основная критика — управление статистикой и ключами, которыми подписывается эта статистика.


А на что ещё вы предлагаете полагаться помимо VPN до входа в Tor, анонимной связи с провайдером посредством неименных симок и 3g и т.п.? У вас есть какая-то другая, своя сеть Tor?


Первое и главное — полагаю, авторы хотели оградить неразумных читателей от излишнего любопытства зайти на те или иные сайты, не предприняв при этом надлежащих подстраховок. Если говорить о типичных юрисдикциях, то заход на сайт драгдиллеров [а часто и приобретение накроты в дозах меньших некоторой (это и в РФ так)] не являются нарушением закона. Т.е. чёткая криминализация есть только для продавцов. Соответственно, риски, которые несут посетители Silk'а, несоизмеримы с теми, которые несут посетители Adult-сайтов. Кроме того, публикация ссылок на такие Adult-ресурсы преследуется по закону во многих юрисдикциях. Чтобы не подставлять под уголовное преследование ни себя, ни читателей статьи, они их запикали звёздами, поэтому не вижу, чему здесь удивляться.
На страницу: 1, 2, 3, 4, 5, 6 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3