Раз уж я закрывал 2007 год в рассылке, то я же и открою 2008:

Вот исправленное по формату строк сообщение в качестве новогоднего поздравления:
http://archives.seul.org/or/dev/Jan-2008/msg00000.html

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

Хотя скорее всего это связано с ошибкой при введении третьей версии протокола и неправильно
обновлённым конфигом.

Это действительно ошибка владельца DA (он из США). И такие ошибки уже фиксировали ранее (для европейского DA). Кроме всяких технических ошибок с размещением сертификата и проблем на пути его доставки (вообще рано делать громкие выводы из поведения альфы), у клиента неудачно (это только мое мнение) выбран формат сообщения об этой ошибке, поскольку при отсутствии сертификата клиент не может знать signing_key (которым подписываются консенсусы), он знает только отпечаток долговременного identity ключа DA (которым подписывают сертификат). В результате и наблюдаются "пугающие" нули.

Но думаю более навязчивым быть смысла уже нет никакого, а то забанят ещё и в рассылке нафиг

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

• нас не поняли

либо

• мы не понимаем как работает тор.

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

По моему сеть i2p заслуживает не меньшего, чем Tor, внимания.

В новой нестабильной версии tor добавлена такая опция:

FallbackNetworkstatusFile FILENAME
If Tor doesn't have a cached networkstatus file, it starts out using this one instead. Even if this file is out of date, Tor can still use it to learn about directory mirrors, so it doesn't need to put load on the authorities. (Default: None).

Судя по описанию, позволяет подкладывать старую статистику, если tor к примеру долго не использовался, для того чтобы иметь возможность скачивать новую всё равно по зеркалам, а не с корневых узлов.

Если использовать при этом скачивание статистики с шифрованием через TunnelDirConns, то значение DA для прямой манипуляции падает.

Да, но не панацея.
Мне сам дух не нравится: нет никаких принципиальных запретов строить распределённую архитектуру для сети, однако не торопятся, а скорее считают нормальным положением дел ограничить себя предположением о непогрешимости DA.

Roger Dingledine извинился за задержку
с ответом, но дал полностью
развёрнутое мнение по вопросу.

http://archives.seul.org/or/dev/Feb-2008/msg00003.html

Пока моя первая реакция:

* Нам удалось их слегка удивить
своими изысканиями.

* Со сценарием атаки они
практически полностью согласны.
В целом, если отбросить наиболее
параноидальные моменты, они
подвердили все наши идеи

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

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

* Они открыты к конструктивному
диалогу и интересуются нашим
мнением

Предлагаю обсудить будущее письмо
спокойно, не торопясь.
Мои только пожелания: на форуме
можно свободно высказывать любые
и резкие, и недоверчивые точки
зрения,
но в письме они должны быть
отражены в конструктивном и
дипломатичном виде.

Пока общая идея такая: да опция
"не для всех", недефолтная, для
особо продвинутых, но и активно
привлекающих
в сеть других пользователей. Её
наличие будет иметь
дополнительный, сертификационный,
репутационный характер, для
поддержания доверия к проекту со
стороны "параноиков" и как пример
того, что надо думать о
максимально независимой
реализации .протоколов.

После этого будем совместными
усилиями опять также переводить
послание на English, ok?

В качестве меры противодействия "глобальному заговору против Tor" ещё бы опциональные задержки пакетов в протокол добавить...

Вполне понимаю Роджера в его оценке возможных последствий от реализации подобной схемы. Здесь порочный круг. Реализация опции и её включение по умолчанию способны в ряде случаев привести к существенному наплыву обеспокоенных пользователей, не знающих как реагировать на сообщения, возникающие в логе. (Эти опасения особенно обоснованы, учитывая экспериментальность всей сети Tor и её перманентный бета-статус.) Если же реализовать опцию, но не включать по умолчанию, это снижает саму ценность схемы — обнаружение атак через DA. Тогда какой смысл её вообще реализовывать? Думаю, у разработчиков достаточно пунктов, требующих внимания.

Может быть стоит оценить предложение: написать скрипт, наблюдающий за состоянием кэша и сигнализирующий о его аномальных изменениях? Какие преимущества это даст:

• быстрая реализация, существенно более быстрая, чем даже появление механизма в экспериментальной ветке Tor'а;
• возможность "поиграть" с эвристиками, чтобы выбрать наиболее разумный баланс между false positives и false negatives;
• установка скрипта добровольна, так что можно предположить, что пользователь понимает, что делает, и в случае странных результатов не побежит с криками в or-talk.

При успешном результате эксперимента на скрипте нам будет куда проще убедить разработчиков Tor в действенности данной меры и в необходимости её включения в программу.

Я поначалу как глянул... подумал: unknown захотел описать ситуацию стихами! А только потом вижу что рифмы нет – лишь форматирование полетело :)

В качестве меры противодействия "глобальному заговору против Tor" ещё бы опциональные задержки пакетов в протокол добавить...

Поскольку оппонент всегда сможет понизить скорость передачи данных, задержки, имхо, не помогут. Идея хороша, если у вас есть гипотетический канал строго выдерживающий скорость передачи, которая не падает ниже минимума, и тогда вы что-то мостите... Хотя может я вас не так понял. Это типа полумеры в стиле закоса на покрывающий трафик или что?

После этого будем совместными усилиями опять также переводить послание на English, ok?

Я предлагаю на будущее, чтоб текст переводил Зелёный :) Он иняз знает существенно лучше меня, судя по предыдущим правкам к тексту, а я потом скажу опечатки каких он не увидел. Больше у нас желающих кадров вроде нет.

Если же реализовать опцию, но не включать по умолчанию, это снижает саму ценность схемы ? обнаружение атак через DA. Тогда какой смысл её вообще реализовывать?

Можно для начала принять аргумент "пусть только для параноиков будет" – это увеличит при прочих равных систему защиты. Далее судя по опыту её использования, отладки, можно будет в будущих версиях придумать и грамотную эвристику и азщиту уже "для всех". Порочного круга, то есть, нет. Это не окончательное мнение, если что придумаем разумное-умолчальное, то можно будет предложить и сразу как дефолт.

Может быть стоит оценить предложение: написать скрипт, наблюдающий за состоянием кэша и сигнализирующий о его аномальных изменениях?

Аргумент очень разумный, но один момент меня оталкивает: кэш будет нас извещать постфактум, то есть после включения такого скрипта мы только начнём накапливать опыт по статистике завязанной на функцию, но не получим сразу же инструмент хоть какой-то мануальной защиты. Собственно, я выдвинул предложение больше с целью как можно быстрее обезопаситься от, и получить гарантии, а не только заниматься "научными исследованиями" статистики.

Я предлагаю на будущее, чтоб текст переводил Зелёный :)

Новая конспиративная кличка? :-)

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

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

Новая конспиративная кличка? :-)

Да ладно, у нас ещё Красный есть! Ценный кадр :)

Мой ответ пожалуй распадётся на следующие 2: предложения по будущему дизайну сети тор и предложения по усилению защиты клиентов тор. Начну с более простого (прочитал снова весь топик, попытался сжать покопактнее всю идею):

Предложения по дизайну самой сети тор

Для рассмотрения эффективной надёжности анонимных сетей определим понятие "секрета сети", которым условимся называть минимальное число публичных ключей, обладание которыми позволяет полностью скомпрометировать сеть. В случае тор-сети секретом является совокупность ключей DA-нод. Мы понимаем правильный дизайн надёжной анонимной сети как тот, который

• обладает свойством как можно более равномерной распределённости "секрета" по хостам сети (принцип максимальной децентрализации), и который
• при разрастании сети имеет своим пределом случай "интернета поверх интернета".

В контексте тора мы имеем ситуацию с сотнями хостов, принадлежащих сети, но "секретом", распределённым лишь среди малой части его узлов – DA-нод. Возникает перманентное желание повысить надёжность сети, распределив её секрет по всем включённым в неё хостам. Аутентификация хоста происходит на основе асимметричной криптографии, для которой известны только два метода проверки валидности: "принцип доверия корневому сертификату" и участие в "сети доверия". Поскольку мы заинтересованы в максимальной децентрализации сети, возникает естественное желание организовать сеть доверия среди всех узлов сети. Здесь можно воспользоваться аналогией с сетью FreeNet, в которой все хосты равноправны между собой, и каждый доверяет только своим соседям. Предлагается организация схемы PGP-доверия в которой бы были обязаны участвовать владельцы нод сети тор, загружая свои подписанные ключи на DA-ноды. Условимся называть связку ключей PGP-сети доверия, в которых участвуют владельцы тор-нод, "статистикой ключей", чтобы отделять её от "статистики статуса", показывающей списки онлайн- и оффлайн-нод. Если опция проверки изменения статистики ключей и статуса, основанная на реальных эвристиках сети тор, будет встроена в тор-клиенты [примечание: смотрим секцию по предложениям для клиентов сети-тор, которая будет ниже], компрометация сети будет ограниченна только случаем атаки со стороны оппонента, так или иначе получившего контроль над большинством обычных тор-нод.
Число DA-нод может быть сколь угодно велико при большом разрастании сети тор, при этом владелец каждой тор-ноды может иметь возможность сам выбирать свой список и число DA-нод, которым периодически сообщать свой онлайн-статус в сети, как и каждый тор-клиент может выбирать свой список и число DA-нод, с которых обновлять статистику статусов и ключей. В конечной перспективе такой тип сети будет напоминать "интернет поверх интернета", где каждый пользователь сам выбирает список CA-центров, подписи которых он доверяет, и список PGP-ключей, глубина доверия которых (в PGP-сети доверия) считается им удовлетворительной. Заметим, что сейчас доверие к ключам тор-нод основано лишь на единственной подписи, созданной DA, в то время как в предложенной схеме весь файл статистики будет представлять собой связку PGP-ключей сети доверия для тор, а сам DA будет играть роль и локального сервера PGP-ключей в общепринятом смысле.

Поскольку оппонент всегда сможет понизить скорость передачи данных, задержки, имхо, не помогут. Идея хороша, если у вас есть гипотетический канал строго выдерживающий скорость передачи, которая не падает ниже минимума, и тогда вы что-то мостите... Хотя может я вас не так понял. Это типа полумеры в стиле закоса на покрывающий трафик или что?

Простейшей мерой может быть возможность указать, сколько пакетов пропустить вперёд себя перед отправкой. Это не потребует дополнительных ресурсов, и увеличит скорость у тех, кто предпочитает скорость, за счет тех, кто предпочтёт большую безопасность – затруднение корреляции. На случай малой нагрузки на узел, когда долго нет пакетов, имеет смысл указывать максимальную допустимую задержку. Задержку можно указывать относительной к времени передачи между узлами – для предотвращения указанной вами атаки искусственного понижения пропускной способности сети. Может быть имеет смысл указывать и минимальную задержку, которую можно будет и не соблюдать при переполнении очереди.

Да, самое важное найти правильное решение. Но надо ещё думать о том, как его представить разработчикам, что верно подметил SATtva.

1. Надо убедить (отчасти это удалось), что проблема реальна. Да, разработчики не сталкивались с такими атаками, да такой атакующий может быть слишком гипотетичен. Но если он появится, то это будет плохо. А поскольку часть пользователей об этом уже знает, то есть недостаток доверия. Пусть разработчики покажут пользователям, что они делают какие-то шаги в сторону прозрачности и децентрализации.
2. Решение ограничено, это ясно с самого начала. Вопрос "это лучше чем ничего?" или "Защита хуже чем сама опасность?". Как бороться с эффектом ложных срабатываний сигнализации, когда злоумышленник нарочно изводит пользователя ложными срабатываниями, а затем ждёт, пока он отключит или станет игнорировать сигнализацию? (это как редкий, но иногда эффективный способ ограбления или угона авто).
3. Опция для параноиков не имеет ценности? Параноики могут предупредить остальных. Правда их можно перед этим многократно дискредитировать по пункту 2. Как этого избежать? Если у них не было перед этим работы с контентом, подрывающим их анонимность, они могут сохранить подозрительный кэш для проверки и последующего предъявления и доказательства того, что кто-то ставит левые подписи. Кроме того, есть же отключенные в некоторых дистрибутивах по умолчанию или ограниченные опции в ядре Linux (boot selinux=0), чтобы не смущать большинство пользователей. А есть наоборот укреплённые версии для защиты от особо сильных атак. и они тоже дают много ложной тревоги в логах. Если есть "hardened kernel", почему не может быть "hardened tor"?
4. Что делать пользователю? При малейшем сбое в сети выдёргивать шнур и думать о конспирологическом заговоре против сети TOR, как иронизирует Роджер? Или действовать по принципу "Вроде опять какая-то атака. Нажмём OK и продолжим работу". Это зависит от уровня параноидальности пользователя. Например в первых протоколах квантовых каналов связи считалось нормальным при обнаружении аномалий в канале, подозревать худшее – атакующего и прекращать согласование ключа. Затем были разработаны более сложные протоколы: можно без риска согласовывать ключ при потере или умышленном искажении параметров части фотонов, только снизив пропускную способность канала – "квантовое согласование ключа в присутствии злоумышленника". Почему бы не ввести пока первый вариант для желающих?
5. Вынести это всё в виде сторонней утилиты? Получать данные по статистике через контрольный порт tor? Но у параноиков он выключен. тем более, после уязвимости с ним связанной. Выключен он и в конфиге по умолчанию (кроме установки в связке с Видалией на Windows).

Анализировать кэш скриптами? Во первых, после того как изменили формат статистики и разбросали её по разным файлам это сложно, во вторых он большой и анализ всех файлов (их около 3 Mb) будет проиходить медленно, даже если написать утилиту парсер-анализатор. С чисто исследовательской точки зрения это конечно полезно. Но возможно ещё более непрактично. А вот сам клиент получает данные порциями, которые и может анализировать по частям, сопоставляя с тем, что уже получено.

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

Похожее решение есть в дистрибутиве Debian GNU/Linux:

пакеты можно скачивать с сотен зеркал, проверяя их подписи. Зеркала иногда взламывают, иногда они падают и т.д., но security обновления можно скачать только с центрального кластера. Если с ним что-то случиться, больше шансов это заметить.

В TOR аналогично: DA удостаиваются чести намертво вшить свои сертификаты в пакет. И можно пытаться отловить ситуацию если с ними что-то не так.
От чего строить доверие, если каждый может быть DA? Злонамеренный exit-node может что-то делать с проходящим трафиком, это ещё можно как-то пережить, но DA может участвовать в атаках на раскрытие анонимности. Сколь угодно много этих DA бы ни было, но рано или поздно на такого DA пользователь наткнётся.

Если проблему доверия DA вынести ещё на один виртуальный уровень, можно сконструировать новую атаку, наподобие изначальной, тоже на новом уровне. "Reflection on Trusting Trust" problem.