Сравнение степени анонимности при посещении внешних и внутренних ресурсов Tor
Допустим, что некто посредством тор-клиента посещает исключительно скрытые ресурсы тора, никогда или почти никогда не выходя в обычный интернет через тор. Насколько это анонимнее (и анонимнее ли?) браузинга обычного интернета через тор? Также интересно было бы знать сравнение защиты анонимности оператора скрытого ресурса сети Tor и его клиентов (тех кто к нему коннектится как к скрытому ресурсу) – анонимнее ли кто-то из них или это одинаково в силу протокола сети?
комментариев: 9796 документов: 488 редакций: 5664
Спасибо. Это был мой вопрос.
Это какие? Что они будут иметь?
Была бы интересной опция, которая позволяет клиентам указывать пароль для HS на лету в браузере, чтобы не лезть руками в конфиг torrc. Можно было бы сделать отдельную вторую опцию «только для браузера» или добавить переключатель в конфиг torrc, регламентирующий, позволено ли клиентам указывать пароль через браузер или нет (ввиду соображений по безопасности это имеет смысл).
комментариев: 9796 документов: 488 редакций: 5664
Хм. Не знаю. Можно проверить — запустить тестовый onion, затем ввести в него опции авторизации клиентов и посмотреть, перегенерируется его адрес или нет. Предполагаю, что адрес меняться не будет.
Менять пароли можно и нужно, чтобы отключать одних пользователей, добавлять других.
Таймаут наверняка есть, т.к. авторизация происходит на этапе образования цепочки в точке встречи, параметры для которой хранятся в узлах с опцией HS-directory. Пароль позволяет сформировать правильный запрос и расшифровать параметры для правильного соединения. Поскольку распределение информации о скрытом сервисе расходится по узлам HS-директорий с задержкой, отсюда м.б. и таймаут. Не знаю, есть ли ещё проверка пароля непосредственно на самом HS. Подробнее обсуждалось здесь. В последующем коменте вроде как аргументы за то, что есть.
При этом, при опции аутентификации base, скрытый сервис будет виден тем, кто знает его адрес, но без пароля. В том плане, что он работает, но соединиться с ним будет нельзя. При использовании опции аутентификации stealth факт работы скрытого сервиса не будет виден даже знающим его адрес, но не знающим пароля. При этом опция base достаточно масштабируема, а stealth — примерно только на десяток пользователей.
На одном скрытом сервисе можно завести несколько виртуальных хостингов, вида alice.abcdef0123456789.onion, bob.abcdef0123456789.onion и т.д.
Раньше можно было имя или отпечаток исходящего узла выбирать через домен '.exit' в браузере, но вроде как по соображениям безопасности это и отключили — через любую страницу можно было встроить такой код для перенаправления пользователя на подконтрольный exit. Здесь могут также решить не давать возможности рисковать, чтобы пароли не утекали.
Over 80 Percent
ФБР как орехи колет SR, SR-2, скоро будет арест SR-3. Изымает сервера сотнями, а педофильское лобби победить не может? Или таки ответ проще чем кажется.
Любой крупный сайт со своим коммунити будет жить дольше, чем любительская страничка ни о чём, у которой полтора посетителя — у автора нет мотивации заниматься её апдейтом. Исключения есть, но тренд какой-то такой.
Мне кажется, он врёт. Не так там всё просто в протоколе. Было бы так просто — уже б давно заблокировали. Там или сивилоову атаку придётся делать для HSDir'ов или никак.
В протоколе не всё просто, но в его тактика может сработать, если он правильно "сгенерирует" ID для своих узлов.
Для выбора узлов при публикации публичного дескриптора скрытого сервиса, расчитывается
time-period опеределяет изменение descriptor-id во времени, а replica задает число реплик для распределения по сети.
Далее:
Но число необходимых узлов для продолжительного цензурирования в сети будет зависеть от общего числа HSDir'ов, и числа цензурируемых скрытых ресурсов. Если в сети есть ещё HSDir'ы тогда 18 узлов хватит лишь на 3 суток блокирования одного сервиса, при условии правильной подготовки к атаке.
Ключи своих узлов ему надо брутать, так чтобы хеш (ID ключа) каждого был: , для обеих реплик.
Тогда задача сводится к вопросу, насколько это реалистично.
Фейсбук смог набрутать себе на адрес. Главное набрутать много-много ключей, а потом выбирать нужное.
Фейсбуку нужен был ключ для скрытого ресурса с красивым именем, где брут нужен несколько другой и не понятно сложней это или проще. Имя скрытого ресурса это base-32 от части (80-бит) хэша и нет ограничений на манипуляции с публичной экспонента ключа (если только фейсбук эту особенность использовал). Тогда как доктору-более-80-процентов нужен результат для всего хэша (160 бит) и у него нет возможности изменять фиксированную публичную экспоненту ключа, но с другой стороны не нужно кодировать в красивые и понятные человеку символы.
Успешность будет зависеть от собственных ресурсов и числа неподконтрольных HSDir'ов в сети. Ещё нужно будет учитывать процедуру назначения HSDir флага и спрогнозировать поведение чужих узлов. Вновь появившиеся могут заслужить HSDir флаг, а выглядевшие стабильными директории потерять его. Всё это поменяет условия и необходимые для цензор-узлов ключи.