id: Гость   вход   регистрация
текущее время 12:10 29/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 След.
Комментарии [скрыть комментарии/форму]
— unknown (15/09/2013 19:29)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Ни I2P, ни Freedom не являются чем-то принципиально отличающимся от сетей реального времени (с наследованием всех их принципиальных недостатков). Скорее всего, они даже формально к ним относятся, несмотря на дополнительные навороты в протоколе.
— Гость (15/09/2013 22:43)   <#>
I2P — да, но во Freenet есть, по кр. мере, покрывающий трафик, да и реалтаймовость там достаточно условная.
— unknown (15/09/2013 23:28)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Тормознутость не означает отсутствие реалтаймовости. Отсутствие реалтамовости — это когда по запросу что-то начинает происходить в анонимносй сети без участия пользователя (без наличия его трафика в реальном времени), скачиваться с одного узла на другой, затем передаваться далее на другой и только потом передаётся запросившему пользователю с задержками (иногда многочасовыми) на каждом шаге таким образом, что он может отключиться и скачать переданное ему с ближайшего к нему узла сообщение позднее. Т.е. связь между запросом на данные и их получением совсем разорвана и замаскирована по времени.

С покрывающим трафиком всё также непросто. Против глобального наблюдателя в сетях там практически нереализуемый объём такого трафика должен быть из-за экспоненциального роста по какому-то числу параметров (узлов сети?). Дальше идут трюки с упрощением и сокращением — от инф.-теоретической в сторону неидеальной анонимности. Возможно, что во Freenet, покрывающий трафик реализован лишь для защиты от какого-то класса атак, даже несвязанных с глобальным наблюдателем.

В независимости от отношения к текущему состоянию дел с Tor — P2P-сети могут быть перспективнее и интереснее теоретически, но там ещё на теоретическом уровне удовлетворительно не решена масса проблем с вбросом узлов, с прицельным окружением пользователя подставными узлами, искажением статистики и последующим выделением трафика пользователя в сети и пр.
— Гость (16/09/2013 00:16)   <#>

Лично я так не считаю. Может вам и не добавляет, а мне добавляет. Именно практически. Возможны обоюдные заблуждения, в т. ч. перекрывающие друг друга. Скорее всего, на практике, i2p обеспечивает безопасность и анонимность на приемлемом среднем уровне и теоретически подвержена атакам, которые описаны в т. ч. и на официальном сайте проекта.


Все верно. И перечень далеко не полный. Протоколы одни для всех, принцип работы также, софт и железо тоже, всегда есть выбор. Остальное за юзверем, как это совместить и сконфигурировать под те или иные задачи.
Своя сеть тор с блекджеком — неплохая идея. Неплохо бы внести изменения в протокол, где каждая машина будет одновременно клиент-сервером. Сейчас тоже нет препятствий для поднятия своей ноды. Если только вы не за NAT.


Охота на ведьм. Миллениум.
Да мы в большинстве своем и не в США. Свой беспредел есть везде, но даже по закону в России ходи по любым сайтам, кликай куда хочешь, храни что хочешь, кроме литературы по марксизму-ленинизму экстремизму-терроризму, в т. ч. и предмет зацензуренных сайтов на 4 стр.
Ссылки на вопиющие и дикие единичные случаи – это еще не повод пользоваться порноскопом в офлайне. Если посмотреть НТВ, то на улицу страшно будет выйти, но ведь в реале все не так.


Если исходить из того, что юрисдикций по разным критериям от 190 до 240, то авторы, принимая во внимание всеобщую доступность статьи, должны были либо все цензурировать, либо ничего, а не лишать медвежат мёда. Котов валерьянкой не обделили. Да и спорить не о чем, ссылки со звездами или без дохлые уже месяц-полтора.
R.I.P.
— Гость (16/09/2013 00:51)   <#>

Вам известна хоть одна сеть (пусть теоретическая или реально существующая), которая удовлетворяет этому принципу и при этом не является шифрпанковской сетью ремейлеров?


Во Freenet есть аналог Tor-статистики? Мне казалось, что Freenet меньше изучается, чем Tor, поэтому в её коде и протоколе вероятность фатальных дыр может быть выше. Я прав?


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


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


Русскоязычной диаспоры хватает везде.


Вроде пока да, хотя за законами плохо слежу.


Авторы физически в Люксембурге. Публикуя ссылки открыто, они могли бы сами нарушить закон и подпасть под люксембургскую уголовную статью. Я думаю, они обсуждали, что запикивать, а что нет, и какие могут быть последствия. Это не идеологический, а формальный акт. Кто сильно хочет, он и так найдёт все адреса, воспользовавшись википедическими фактами.
— unknown (16/09/2013 01:02, исправлен 16/09/2013 01:07)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
неплохо бы внести изменения в протокол, где каждая машина будет одновременно клиент-сервером. Сейчас тоже нет препятствий для поднятия своей ноды. Если только вы не за NAT.

В архитектуре Tor — очень плохо. Настолько плохо, что сам Роджер уже публично жалеет об этом в рассылке. Если каждую машину сделать узлом, то анонимность упадёт (это не считая проблем с масштабированием). Была какая-то ссылка на теоретическую работу. Более того, в текущем протоколе Tor с ростом числа даже честных и независимых узлов она в какой-то мере падает уже сейчас. Якобы посчитали на основе собранной статистики, что нет смысла пускать в сеть узлы со скоростью меньше 1 Mb/s и малостабильные. Но пока приходиться их не выкидывать, чтобы соблюдать разнородность сети. Иначе ещё больше усилится перекос по числу узлов, размещённых в странах с развитым и доступным интернетом. А малостабильным и медленным узлам рекомендуют быть бриджами, т.к. пользователям бриджей важнее уклонение от блокирования и цензуры, чем анонимность. Вот такой компромисс, которому сами разработчики уже не рады. Это в I2P жизнерадостно утверждают, что чем больше узлов — тем лучше и в плане скорости, и анонимности. В Tor нужен рост количества узлов одновременно с качеством. Гвардов также не хватает как и экситов. Упреждая возможный вопрос — дело не в концепции гвардов. Также возможно, что ботнет, который наводнил Tor левым трафиком, также подкосил анонимность пользователей Tor из-за частого обрыва цепочек и не только. Как и то, что разные узлы с разными версиями Tor и разной криптографией — это был кошмар, который разработчики раньше хотели отсрочить и продумать, как проскочить фазу смены протоколоы быстро и гладко, а теперь они делают это под влиянием текущих обстоятельств.

— unknown (16/09/2013 01:23)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Вам известна хоть одна сеть (пусть теоретическая или реально существующая), которая удовлетворяет этому принципу и при этом не является шифрпанковской сетью ремейлеров?

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

Вообще, такой сети неизвестно. Вроде как перспективнее миксы поверх DC-сетей, наподобие Dissent. Группа из n участников что-то слила в общий пул, перемешала там, каждый вытащил какой-то кусок, а кто кому что передал и каким трафиком кого покрывал — постороннему внешнему и ограниченному внутреннему наблюдателю (контролирующему менее n – 2 узлов) — не видно.

Во Freenet есть аналог Tor-статистики?

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

Мне казалось, что Freenet меньше изучается, чем Tor, поэтому в её коде и протоколе вероятность фатальных дыр может быть выше. Я прав?

Да, по практическим исследованиям Tor перетянул на себя почти всех исследователей. А остальные варианты анонимных протоколов изучают больше не на реальных сетях, а на сферических моделях в вакууме.

На самом деле, анонимные P2P нужны для файлообмена, для чего Tor концептуально не предназначен. Хорошо теоретически проработанный и реально работающий проект уровня Tor не помешал бы.
— Гость (16/09/2013 01:39)   <#>

У Эдварда Сноудена это классно получается. Надо у него перенять опыт применения стикеров.


Возникает время от времени вопрос, почему нет развития альтернативных сетей? Полноценного развития. Работы по ним, по сетям, читал, и далеко не одну, но почему они не привлекают ни внимания, ни финансирования? При том, что известный факт — правильно организованный флешмоб в Интернете может собрать необходимую сумму в считанные секунды дни. Неужели кроме сетей, которые на слуху у всех, больше нечего и некому развивать? Есть флагман, допустим, это Tor, но должна быть и очередь на его место, а этого, увы, пока нет, как мне видится.


Давно еще где-то читал, что Tor'у необходимо 10 тыс или более нод, это когда еще общее их количесвто было что-то около 1000. Интересно понять, почему каждая машина, ставшая клиент-серверной ухудшит анонимность?


Но это вопрос качества, а не архитектуры или количества. Сейчас около 40% нод имеют скорость 1 Мбит/с и ниже. И только около 900 нод с 1 Мбайт/сек и выше. Интересно выходит, Tor'ом пользуются миллионы человек, ежедневно сотни тысяч, но нод всего несколько тысяч, из которых реально загружается примерно только четвертая часть. И судя по всему, если что-то менять, мгновенно нарисуется новая теоретически моделируемая угроза. Если развернуть обратно, возникнет еще какая-то угроза с другой стороны.
— Гость (17/09/2013 07:28)   <#>

А про Freenet не знаете?


Анонимных сетей (дохлых, полуживых, уже сдохших и др.) штук 10-15. Был форк Freenet — сеть Entropy. Была японская анонимная сеть (JAP или кто там). Были сеть ремейлеров. Есть Gnunet. Есть I2P. Вывести проект на массовое использование сложно, да и интерес у масс к анонимным сетям не сравнить с их интересом, допустим, к торрентам. Массовых анонимных сетей сейчас, пожалуй, три: Tor, I2P и Freenet. Это уже немало.


pgpru, судя по опросам, читает минимум полторы сотни человек, а хотя бы иногда пишут на pgpru человек 5-10 (что не может не радовать, иначе бы все утонули в низкопробных сообщениях). И это во всём так.
— Гость (17/09/2013 07:36)   <#>

faq:
Другие анонимные сети. Среди них наиболее известны Mnet, GnuNet, Mute, Gift, Entropy и Rshare.


Сайты её, похоже, уже не открываются.
— SATtva (17/09/2013 13:21)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
В Tor понятно куда вынесена эта проблема (со всеми минусами и плюсами такого подхода), в P2P сетях она тоже должна быть как-то проработана

А про Freenet не знаете?

Freenet и есть P2P-сеть. Посмотрите их design-doc, там протокол описан на общем уровне.
— Гость (17/09/2013 16:17)   <#>

JAP не японский, а немецкий. ja ja :)
— Гость (19/06/2014 22:38)   <#>
Когда я захожу на большинство HS, внешне ничем не примечательных, у меня firefox в TBB начинает жрать 100% процессора, и часто так продолжается очень долго. Если сайт в дауне или долго не отвечает, то это может продолжаться хоть до бесконечности, пока принудительно не нажмёшь ESC или не закроешь страницу. Это у меня одного так? Оно потому, что firefox не понимает, что есть длительные таймауты при соединении c SOCKS-портами?
— SATtva (20/06/2014 07:56)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
У меня такое бывает даже без HS — с обычным FF на обычных сайтах. Закономерности выявить не удалось, при этом, если проблема возникает, то, как правило, устраняется только перезапуском программы.


Речь, наверное, всё-таки о 100% одного потока, а не всех потоков/ядер?
— Гость (20/06/2014 10:14)   <#>
Тикет. Возникает только для http транспорта, с https транспортом этого не происходит. Особенно заметно на сайтах которые долго не отвечают, но в цикл браузер уходит всегда.
На страницу: 1, 2, 3, 4, 5, 6 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3