Регистрация07.12 // Опубликована спецификация новой версии скрытых сервисов Tor
Неделю назад Ник Мэтьюсон (Nick Mathewson), один из ведущих разработчиков Tor Project, опубликовал черновой вариант спецификации для новой версии HS — скрытых сервисов сети Tor, над которой он работал в последнее время, чтобы улучшить дизайн и сделать его описание более ясным.
Основным заметным для пользователей нововведением станет формат HS-адресов (разделы 1.2-1.4). Чтобы предотвратить пересчёт скрытых сервисов, новый протокол предписывает выработку адреса из ослеплённого ключа сервиса (открытого ключа и опционального дополнительного секрета), при этом операция ослепления должна производиться над всем ключом, а не над его сокращённым хэш-значением, как сейчас. Таким образом, в случае 256-битового ECC-ключа и при использовании 32-битной кодировки, новый HS-адрес может выглядеть примерно так: a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion. Возможно, будет использована более компактная кодировка, сохраняющая корректность для имени хоста.
Другим важным, но менее очевидным изменением станет отказ от криптографических примитивов RSA-1024, DH-1024 и SHA-1 в пользу алгоритмов на эллиптических кривых Ed25519, Curve25519 и хэш-функции SHA-256 (раздел 0.3).
Выбор HS-директорий, ответственных за хранение дескрипторов скрытых сервисов, будет зависеть от случайного значения, периодически и согласованно вырабатываемого корневыми узлами сети Tor. Это обеспечит непредсказуемость при выборе HS-директорий для предотвращения целенаправленных DoS-атак.
Кроме того, спецификация привносит возможность для хранения долговременного ключа подписи скрытого сервиса в офлайне (раздел 1.7).
Спецификация ещё не завершена и полна белых пятен. В частности, не закончен раздел (1.5), посвящённый развёртыванию скрытого сервиса одновременно на нескольких узлах. Данный вопрос ранее обсуждался, но окончательная схема так и не была выработана. Сложность этой задачи в том, что тривиальная схема приведёт к утечке сведений о числе используемых узлов к злоумышленным клиентам или introduction-нодам.
Ник Мэтьюсон просит читателей сообщать, какие части спецификации нуждаются в более детальных разъяснениях и доработке. Особенно приветствуются подробные комментарии с предложением исправлений.
Источник: Tor Weekly News
комментариев: 9796 документов: 488 редакций: 5664
Вот я одного не понимаю, ведь есть достойный пример анонимной самоорганизации, написания стандартов, кодекса и тд, я о варезе и демосцене в целом. А в Тор сидят академики и ладу дать не могут. Почему не написать правила для сайтов, хостящихся в анонимных сетях? Запретить использовать JS итд? На сколько я понимаю-Тор сам по себе безопасный, а утечки в основном из за скриптов и багов в браузере. Иеще один вопрос к Вам, как к пользователю Firefox: скажите, в каком направлении развивается браузер? Почему урезают функционал, почему новый интерфейс косит под Хром, они легли под гугл или я напрасно переживаю?
Спасибо.
комментариев: 9796 документов: 488 редакций: 5664
По объективной необходимости. Без этого всё равно никак. Причины обсуждались неоднократно.
Можно. Самое обидное, что честный разработчик (поставьте себя на его место) может легко сделать непреднамеренную ошибку, которая даст такой же эффект, как и закладка.
Не представляю, как это можно перенести на разработку криптософта.
Там больше людей с академическим бэкграундом, но не самых топовых и сильных, скажем так. Для создания стандартов они привлекают кого-то со стороны. опираются на чьи-то работы, честно предупреждают — что они не криптографы. Вообще, складывается впечатление, что они как раз сильно увязли в практике, кодинге, разборе багов и пр. Просто проект менее шифрпанковский, чем другие, но не чисто академический.
Это дело самих сайтов. Пока считается, что пользователь — в массе условно тупой, ему сделали готовое решение по анонимности их коробки в виде TorBrowser (хотя раньше надо было руками всё прикручивать). Сайтостроители считаются продвинутыми — для них пока изкоробочных решений и рекомендаций не дают. Т.е., для хостящих контент нет таких готовых решений как во Freedom или I2P.
Хоть прямо делай для скрытых сервисов отдельный урезанный браузер или как-то бы пропатчить FF в TorBrowser, чтобы он при посещении скрытых сервисов переходил в минималистичный режим. Это просто сложно и затратно в разработке.
В сторону фич, рюшек и коммерциализации. Иначе не выдержать конкуренции.
Не напрасно вы переживаете. Разработчики Tor'a на FF тоже сильно плюются, но пока это всё ещё оптимальный выбор при всех его негативных тенденциях развития.
Конкуренции со стороны кого? всяких "яндексбраузеров"? Вот так и рушатся последние нормальные проекты. То Thunderbird забросили, хотя нет, лучше пусть одну ветку FF сообществу передадут и все.
А в последней атаке с пересчётом скрытых сервисов как были учтены приватные скрытые сервисы? Использование опции HiddenServiceAuthorizeClient как-то помогло? И вообще не очень понятно, что происходит с хранением дескрипторов таких узлов. От «внутреннего» атаующего, который завладел долей узлов Tor (как в той атаке) это хоть как-то помогает или нет?
Кто такие «корневые узлы»? DA? Стабильные?
Т.е. для скрытого сервиса можно будет создавать временный ключ, который будет действителен, пока не истечёт срок его действия? Будет такая же связь между долговременным ключом и текущим, как между главным ключом PGP и подключами? Описание в спецификации прочитал, но толком не понял.
SATtva должен знать об особенностях отображений в движке ссылок, содержащих невосьмибитные символы. В данном случае там закралось тире посередине. Исправьте на вот такую ссылку.
По этой же ссылке есть фраза
Называется «пустили козла в огород...».
А из чего, из астрала что ли?
TorBrowser — форк FireFox. Уже 2 года как.
комментариев: 11558 документов: 1036 редакций: 4118
Разработка Tails — сторонний проект, не связанный непосредственно с Tor Project. Последний просто осуществляет ему информационную поддержку.
DA.
Спасибо, не заметил.
А чего далеко ходить? :)
комментариев: 9796 документов: 488 редакций: 5664
Пруфлинк сходу не приведу, но то ли в рассылке, то ли в самой работе отмечалось, что против приватных скрытых сервисов с такой опцией атака не действует.
DA. Они и сейчас выдают флаг HSDir узлам в соответствии с общей статистикой сети. Будут ещё и рэндом для распределения этих данных по узлам создавать.
Понятно, спасибо.
Чтобы дескриптор конкретного узла не хранился целиком на одном HSDir, а был размазан по нескольким HSDir'ам?
комментариев: 9796 документов: 488 редакций: 5664
Скорее, чтобы HSDir не знал, какие узлы ему достались в данный момент на хранение и не пытался дёргать соединения, глядя, какой HS при этом отвалится в специально построенных цепочках. Там ещё какие-то тонкости были, надо разбирать подробнее, если есть интерес.
комментариев: 9796 документов: 488 редакций: 5664