Надежность TOR

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

Это не совсем возможно при корректной реализации DH на обеих сторонах и даже если возможно, было бы слишком заметно. Можно придумать лучше.

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

Пусть обычная честная нода A посылает честный g^a в протоколе Диффи-Хеллмана. Пусть злонамеренная нода B (c пропатченным Tor и/или OpenSSL) посылает нечестный g^b. Нечестность заключается в том, что b — не случайное, а сгенерированное шифрованием счётчика Ctr с секретным ключом K.

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

Дальше, злонамеренные ноды сливают логи соединений за какой-то период времени (только айпишники и время — без содержимого) в общее хранилище. Злонамеренные ноды B, C, D ищут пересекающиеся значения.

Они договариваются о торговле. Перед этим для доказательства владения они раскрывают кусочек выбранного по логам дампа шифрованого трафика, обмениваются им между собой и раскрывают свои ключи K_B, K_C, K_D и счётчики Ctr_B, Ctr_C, Ctr_D.

Если договорятся о цене, то они сливают друг другу весь общий пересекающийся шифрованный трафик на некий файлообменник и с помощью полученных ключей расшифровывают. Т.е. гонять и разбирать гигантские объёмы данных им не нужно — в их сети всё равно не так много общего попадёт. Всё можно делать сравнительно незаметно, сливая часть данных с узлов по VPN.

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

Нечто потенциально похожее на такую ситуацию возникало (псевдо?)случайно при ошибке в генерации псевдослучайных чисел Debian OpenSSL. Но, несмотря на достаточно большое число таких узлов в сети, вероятность выбрать все три таких узла в цепочке была небольшой, что-то около долей процента (правда только за короткий сеанс). Здесь будет также.

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

Единственным средством обхода блокировок ТОР-нод являются бриджи? Но ведь цензор может свободно получить список этих бриджей (по три штуки за раз) и заблокировать и их.

Про бриджи лучше в той теме.

Ссылки на багрпепорт есть?


Ссылки на багрепорты есть?


Дорогой хостинг получится. Где-то когда-то писали, что пропускная способность всей Tor-сети — 2 GB/sec, т.е. получаем около 5000 TB в месяц. Даже если предположить, что у ноды есть 10GB из них, и все расшифровываются, получим, что расшифровывается 0.0002% от всего трафика сети. Более того, атакующий никак не контролирует, что в эти самые 0.0002% попадёт.

Увы окружение девов стало невменяемо, багрепорт ничего не решает. Проект скурвился.

Это был фикс для CVE-2005-2643
Ослабление условий упоминается в changelog:

- Stop doing the complex voodoo overkill checking for insecure Diffie-Hellman keys. Just check if it's in [2,p-2] and be happy.

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

complex voodoo

не окупал себя (например — мнимая защита от атак ценой значительного увеличения оверхеда в протоколе). Если вы серьёзно разобираетесь в теме, где связный текст с критикой на этот счёт? Напишие хотя бы в tor-talk.

Причем тут бага 2005 года. Всё равно ключ таким образом не получить одинаковый.
Понятно, что не ваши.
Суть про баги связанные с сигнальной и сетевой частью кода. Ну и про "коммунити".
Хорошо что в тор не надо никому верить, есть код и спецификации. Хотя всех багов в одиночку не исправить. Битые экситы будут только множиться, значит придется с этим жить.

Внимание.
Обнаружена *китайская нода.* Живет уже несколько часов. Торопитесь увидеть это чудо. Возможно, ей осталось все те же несколько часов.
Вот единственная монгольская снова пропала:'(

Это не китай, а сингапур. Хваленная геоип база сфолила, они только прокси хорошо метят.

Это не совсем торговля, никто ж никому денег не платит. Просто если у нод оказываются ключи на некоторую часть трафика, всем им выгодно скооперироваться и расшифровать эту часть. Протокол нужен только для вычленения того, какая часть у них расшифровываемая при объединении усилий.


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


Зачем в одиночку? Попросите помощи у своего куратора, скажите "так и так, делать было нечего, разобрал весь сетевой код Tor на самом низком уровне, надо пофиксить, а то американцы наступают".

Куратора отозвали, довольствия лишили, финансирование разработок уменьшили. Это всё стало не нужно, в свете последних оперативных удач нашего командования NSA согласилось сотрудничать и предоставлять сырые данные без обработки.

Возможно, что достаточно, тогда дело ещё больше упрощается.

Анонимы совершенно не умеют разводить параною. Вот, смотрите, как надо:

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

Что можно сказать о проценте тех сайтов, которые её поддерживают? А о проценте таких скрытых ресурсов?

Можно предположить, что достаточно много. Иначе бы эту функцию в Torbrowsere не модифицировали для противостояния атаке.

Как узнать для заданного сайта, поддерживает ли он эту фичу? Есть стандартный метод?

/comment47958

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

Хоть кто-нибудь доразобрался, проверил, какие сайты поддерживают конвейеризацию (HTTP pipelining)? А если я злоумышленник и создал сайт, который принципиально не поддерживает конвейеризацию, примочки от TBB чем моим посетителям помогут? Сразу получим деанон с вероятностью близкой к 100%?

Да, это всё равно полумера. Радикально избавиться от фингерпринтинга это не поможет. Теоретически, был предложен ряд мер по модификации Tor-протокола с навороченным смешиванием трафика, но не было предложено решения по оптимизации до реальной возможности это внедрить.

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

Некоторые злонамеренные сайты могут вообще активно модулировать трафик. Например, периодически перезагружать страницу или её элементы в браузере; отгружать картинки с определёнными интервалами. Всё то же может делать и исходящий узел.

Понятно. Стоит ещё отметить, что деанонимизация Tor методом фингерпринтинга может быть, вероятно, сделана посредством добавления плагина к уже существующим DPI, т.е. противнику даже ни на что тратиться не надо будет.


Должна ли параллельная загрузка многих страниц в одном и том же TBB усложнять жизнь атакующему? Ещё можно придумать какой-то покрывающий трафик (параллельную загрузку чего-то ещё с веба), чтоб методы, разработанные для фингерпринтинга среднего пользователя, не работали для конкретного, от него защищающегося. И, да, это не просто полумеры, а это «анонимность через неясность» по типу того, как в Tor борятся с цензурой.