Простой способ атаки "в обход" tor

Последние пункты следует читать так (опечатался):

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

SATtva

Ключи DA намертво вшиты в клиентскую программу, дистрибутивы которой заверяются в помощью PGP.

Это да, но здесь наполовину идёт речь о том чтобы изменить протокол :( Когда DA будет много, а степень доверия к ним будет разная, включать их все в программу не будут точно так же как сейчас не включают сертификаты всевозможных CA (очень точная аналогия), но... по желанию вы модете выбрать те DA (CA), которым доверяете, и впоследствии доверять только тем сертификатам которые подписаны не менее чем N различными DA (CA).

s/как сейчас не включают сертификаты всевозможных CA/как сейчас не включают сертификаты всевозможных CA в браузер/

soot

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

Следует понять почему нельзя доработать протокол до того что я предложил, и понять, даст ли это в итоге интегральное преимущество, и если нет – то почему (хотя бы примерно). Аргумент, что пользователям так много удобнее и "можно ни о чём не думать" не будет веским аргументом... для таких можно предложить какие-то умолчальные настройки по аналогии с умолчальными CA, встроенными в стандартные браузеры + дефолтные настройки барузеров.
Здесь tor-клиент = браузер достаточно точная аналогия.

SATtva

Ещё где-то видел софт для визуализации цепочек, которые строит клиент tor'а

Vidalia.

А если я не доверяю в полной мере Vidalia и предпочитаю что-то более близкое к ручному, нет ли альтернативы? Просто браузинг по инету в любом случае будет происходить без видалии... а потом ставить и разбираться с ней только ради этого не хочется.
P. S.: писать самому срикпт для визуализации цепочек не предлагать :)

Это всё уже лучше, но...

Вот SATtva уже нашёл существенную неточность формулировки:
сообщение не о том, что ключи DA поменялись (это абсурд – программа отвергнет их подписи),
а сообщение о событии, гласящее как минимум о том, что:

a) Почему то возможно скачать статистику только с DA – со всех других узлов или всё заблокировано,
или приходит что-то устаревшее или неверное.
b) Резко поменялись все или большая часть данных, подписываемых DA.

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

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

Короче не стоит торопиться и второй раз морочить им голову плохо читаемой белибердой в моём исполнении :-)

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

Все замороки с настройкой эвристик и доверия к сертификатам по умолчанию будут наверняка выключены и идти только
как advanced options, захотят ли разработчики таких сложностей, когда есть более прозаические задачи?

На самом деле, не до конца ясны возможные сценарии атаки, например Мэллори может используя фальшивые ключи DA
подписать левую статистику, в которой часть ключей серверов тора будет верной, но симулировать, перехватывая IP,
что они всегда в оффлайне или отказывают в соединении, если они входящие. Или не давать строить через них цепочки,
если они middle или exit. Т.е. банить те входящие узлы (а это просто, так как теперь есть guard'ы), у которых верные ключи
и давать на основе левой статистики возможность выбора только ущербных для пользователя (подконтрольных) цепочек.

Короче какие ещё могут быть трюки для поддержания у пользователя иллюзии того, что он работает в реальном tor'e, а
не в виртуальной сети?

Кстати, невидимый spinore, – вот Вамприходилось уже чистить кэш, потому что вас в торе "забанили", Вы проверяли что после этого
Вам пришло в качестве новой статистики?

А если я не доверяю в полной мере Vidalia и предпочитаю что-то более близкое к ручному...

можно воспользоваться tork, точнее его исходником, или почитать спецификации протокола управления Tor'a и получать всё нужное по telnet.

Всё это внятно формулируем по-русски, а уже затем пишем сообщение разработчикам на читабельном английском

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

Это "простая" атака только для очень "непростого" злоумышленника

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

Не забываем о том, что tor стараются сделать максимально прозрачным, простым для неподготовленных пользователей, автоматизированным

Где-то пробегал принцип о том, что реальная безопасность не может быть "автоматизированной, простой и элементарной для неподготовленных пользователей". Я к тому, что всё отличие между простыми пользователями и теми, кто будет использовать advanced options, будет на уровне клиента... со стороны всё будет выглядеть примерно одинаково.

Все замороки с настройкой эвристик и доверия к сертификатам по умолчанию будут наверняка выключены и идти только как advanced options, захотят ли разработчики таких сложностей, когда есть более прозаические задачи?

Какие, например?

На самом деле, не до конца ясны возможные сценарии атаки, например Мэллори может используя фальшивые ключи DA подписать левую статистику, в которой часть ключей серверов тора будет верной, но симулировать, перехватывая IP, что они всегда в оффлайне или отказывают в соединении, если они входящие. Или не давать строить через них цепочки,
если они middle или exit. Т.е. банить те входящие узлы (а это просто, так как теперь есть guard'ы), у которых верные ключи и давать на основе левой статистики возможность выбора только ущербных для пользователя (подконтрольных) цепочек.

Это тот случай, когда следует прибегнуть к формальной логике. Указанные здесь вами атаки применимы "на ура" и к текущему протоколу тора, а предлагаемая схема усложнит их проведение, и этот факт снимает поставленный вопрос. Разговор о конструировании ещё более идеального случая от защиты от подобных атак – это уже второй шаг...

Кстати, невидимый spinore,? Вот Вам приходилось уже чистить кэш, потому что вас в торе "забанили", Вы проверяли что после этого Вам пришло в качестве новой статистики?

Нет, не проверял :( Более того, могу сказать что меня удивляет некоторые моменты в поведении тора (возможно, я параноик, да).

• В этом топике среди прочего в логе проскакивала строчка:

Received http status code 403 ("Forbidden") from server '216.169.105.192:80' while fetching "/tor/server/d/A8E5024559C7DE57EBAB7217......
которая была зело длинной с подобной абракодаброй. Мне кажется, что подобное происходило не раз, а указанный IP был тем же (гарантий нет, не помню).

• При перестройке цепочек (может у нас так мало экситов?!) у меня чередовались IP из набора, как правило, 5ти штук. С течением времени они могли меняться. Мне бросилось в глаза что это постоянно были либо FR, либо DE, реже US, остальные страны – вообще редко.

Порой хочется визуализировать всю полученную статистику и видеть какой выбор предоставлен и что из всего этого выбирает клиент. Я всё могу понять, но если иногда доходит до того что pkill -1 tor не меняет экзит, то значит их действительно "мало" (!) либо выбор "странный". Всё это меня и смущает...
Разумеется, когда я кэш стёр, против меня можно было нахаляву провести описываемую атаку :)

Короче какие ещё могут быть трюки для поддержания у пользователя иллюзии того, что он работает в реальном tor'e, а не в виртуальной сети?

Ещё есть вот какая идея, по сути ваша же, но чуть доработанная :)
Предположим, что никто ни у кого серт не одалживал (не крал). Провайдер может закрыть доступ ко всем ентренс-нодам (точкам входа), которые не подконтрольны противнику. Тор будет попытается построить цепочки через них и у него ничего не получится, а вот через подконтрольные – получится. Далее есть 2 варианта:

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

Я тоже неоднократно замечал подобное. Такое ощущение что во всей сети есть всего лишь десяток ексит узлов.

Всё это внятно формулируем по-русски, а уже затем пишем сообщение разработчикам на читабельном английском,

Только писать не в or-talk, а на or-dev.

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

Алгоритм выбора такой что вероятностно будут выбираться чаще те узлы, чья скорость выше. Пример: Допустим за час работы, при заданной скорости смены цепочек раз в десять минуты (то есть всего 6 цепочек), вероятность заполучить один (из двух) достаточно скоростной узел в том же звене цепи (например 1МБ/c) дважды, трижды,... шесть раз, выше чем узел со скромными возможностями (например 100КБ/c). В действительности их больше чем два, и даже при двух, вероятность выбрать низкоскоростной узел остается. Такой алгоритм используется и для промежуточных и при отборе входящих охранных узлов (последние запоминаются и по возможности используются в дальнейшем). Плюс добавлен в алгоритм учёт длины цепочки. И в результате узел заявивший например 20КБ/c и будет выбираться пропорциональное его скорости число раз (в действительности очень редко) многотысячной армией клиентов и не будет причиной, теперь уже топиков про скорость. И если бы не качки терабайтов через Tor, искажающие картину, было бы всё совсем идеально.

Если хочется попробывать как это — когда совсем не взвешиваются скорости, можете попробывать исправить код и собрать (сохраните оригинал, наверняка на него вернётесь):

choose_good_exit_server(circ->_base.purpose, rl, state->need_uptime, state->need_capacity, state->is_internal);

на код:

choose_good_exit_server(circ->_base.purpose, rl, state->need_uptime, 0, state->is_internal);

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

Где-то пробегал принцип о том, что реальная безопасность не может быть "автоматизированной, простой и элементарной для неподготовленных пользователей".

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

захотят ли разработчики таких сложностей, когда есть более прозаические задачи?

Какие, например?

Борьба за расширяемость (scalability). Борьба с Великим Китайским и прочими возможными файрволлами с помощью бриджей.
Вероятно и над немецкой проблемой разработчики тоже думают, что предложить операторам кроме middleman'ов.
Просто пока ждут что будет после вступления закона в силу, чтобы не торопить события.

Ну и слишком усложнять протокол тоже не следует. Туда уже и так много всего сложного добавили.

Думаю, идею с фактически новым протоколом, с опциональными DA пока стоит запомнить, но отложить на будущее.

остановимся на самом простом: введением опции для блокирования атаки... эээ (объявляется конкурс на самое
красивое название атаки, "unknown attack" – не катит :-). М.б. "Multiple Directory Authority keys compromising attack".

Только писать не в or-talk, а на or-dev

правильно, там будет самое место.

Поскольку, кроме SATtv'ы все подписываются псевдонимами или только ключами, письмо отправляем только
как коллективную анонимку от нашего сайта. Кроме того, проект tor разрабатаывается под лицензией BSD,
так что никаких копирайтов, "Non-Commercial"- или "гнутых"-копилефтов. Все высказанные идеи уходят в проект
без ограничений на использование.

Черновик письма вроде по-минимуму простой, а уже длинноватый. Существенных дополнений думаю за один раз не влезет.

Замечания? Ляпы?

Надеюсь, не придётся дописывать и отправлять, когда у разработчиков новогодняя полночь :-)



//Multiple Directory Authority keys compromising: a partial solution for tor clients defence.

As we know from tor specification: "2. Every directory authority was a trust bottleneck:
if a single directory authority lied, it could make clients believe for a time an arbitrarily distorted view of the Tor network."

And "There is a small set (say, around 10) of semi-trusted directory
authorities. A default list of authorities is shipped with the Tor
software. Users can change this list, but are encouraged not to do so, in
order to avoid partitioning attacks."

Unfortunately, we have really small set of semi-trusted authority and more than half of it in one jurisdiction (US),
and we must believe: owners of this servers really protects their server keys from compromising and free from
any third party evil influence ;-)

Key security and trust problem improved in v3 authority protocol, but not completely.

If third party agent Mallory have >50% of semi-trusted DA keys,
and have an ISP level acces to user traffic, he still can makes a MITM-based virtual network simulation for that user,
like this:

Normal client activity:

Alice -> encrypted traffic -> [real tor] -> decrypted traffic from exit -> Bob

Intercepted client activity:

Alice -> encrypted traffic -> [virtual tor network simulation from Mellory] -> decrypted traffic for Mellory ->
-> [Mellory tor agent using Alice chains] -> [real tor] -> decrypted traffic from exit -> Bob

###

We propose a partial (very limited, but adequate) solution: tor client with active connection and relative "fresh" stats cache
may implement an analysis for suspicious activity of stats changes.

At most two criteria can be analysed:

1) If stats downloading from all of mirrors blocked or have invalid signatures and may be download only from semi-trusted DA.

2) Keys for tor nodes signed with DA changed significant (> 90% of all keys for example) in a very short interval of time
(suspicious for fake stats injection for user cache).

Open questions: How much keys it can be? How short interval?

...) Any other criteria of suspicious activity? Formal model for other possible attacks detection for tor clients?


After detect this type of activity tor client can log message:

-> Warning! Very significant part of tor nodes keys changed in a short interval of time!
-> If more then half of Directory Authority keys compromised, stats may be poisoned with a fake data.

Paranoidal settings for users in config file (client only section) may be:

StopTorIfTooMuchKeysChanged 0|1

Other open questions: only stop tor if user enables this setting and log suspicious event or do any other way to interaction?
What measures user can makes after that message? How to do with users with long period of inactive cache?

We have a long discussion and more noncompleted ideas on our site.

"OpenPGP in Russia Team"

Кстати, похоже разработчики думают вперёд нас,
возможно у них ещё много чего запланировано в новых фичах:

Tor 0.2.0.13-alpha is out

Tor 0.2.0.13-alpha adds a fourth v3 directory authority run by Geoff
Goodell, fixes many more bugs, and adds a lot of infrastructure for
upcoming features.

– Three new config options (AlternateDirAuthority,

AlternateBridgeAuthority, and AlternateHSAuthority) that let the
user selectively replace the default directory authorities by type,
rather than the all-or-nothing replacement that DirServer offers.

А если я не доверяю в полной мере Vidalia и предпочитаю что-то более близкое к ручному, нет ли альтернативы?

Tor прекрасно работает сам по себе, без всякой видалии и телнет-управления. :)

Вероятно и над немецкой проблемой разработчики тоже думают, что предложить операторам кроме middleman'ов.

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

М.б. "Multiple Directory Authority keys compromising attack".

tor-simulation attack? (атака симуляции тор-сети)
Термин зависит от того что нужно подчеркнуть: что ключи DA "позаимствовали" или тор-сеть эмулируют?

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

Мой ник (spinore), ключ и ФИО всем известны, но

• не я один принимал участие в разработке идеи
• перемешивать сущности в одном пиьме – тоже не в плюс

так что ваш вариант, по-моему, самый оптимальный.

we have really small set of semi-trusted authority

authorities

more than half of it

its

owners of this servers

these

and free from any third party evil influence

and keep them free from any third party evil influence

Key security and trust problem improved

Key security and trust problem are improved

If third party agent Mallory have

If the third party agent Mallory has

and have an ISP level acces

and has an ISP level acces

relative "fresh" stats

relatively "fresh" stats вроде бы

If stats downloading from all of mirrors blocked or have invalid signatures and may be download only from semi-trusted DA.

An attempt to download the stats from all of the mirrors is blocked or gives the stats with invalid signatures. As a result, it can be downloaded only from semi-trusted DAs.
(После исправления опечаток я бы переделал так).

suspicious for fake DA IP interception, authentificated with stolen keys

This case rises a suspicion about DA's IP interception authentificated with stolen keys
(Я бы написал так, но запятую перед authentificated уберите немедленно, это не русский язык. В английском запятая в этом месте эффективно играет роль начала нового предложения).

Keys for tor nodes signed with DA changed significant (> 90% of all keys for example) in a very short interval of time

Tor-nodes keys signed by DA are changed significantly (for example, >90% of all keys) during very short time interval.

suspicious for fake stats injection for user cache

This case rises a suspicion about fake stats injection for user cache.

How much keys it can be? How short interval?

How MANY keys have to be affected by this attack to rise a suspicion?
What's the minimal time per change?

Any other criteria of suspicious activity? Formal model for other possible attacks detection for tor clients?

What's about other criteria of suspicious activity or formal model of other possible attacks detection for tor clients?

After detect this type of activity tor client can log message:

We offer the next log messages for tor client as indication of attack involved:
(Лучше так)

Warning! Very significant part of tor nodes keys changed in a short interval of time!

Warning: a lot of tor-nodes keys were changed during a short time interval!

If more then half of Directory Authority keys compromised, stats may be poisoned with a fake data.

If more than one half of Directory Authoritiy keys are compromised, stats can be poisoned with a fake data.

Paranoidal settings for users in config file (client only section) may be:
StopTorIfTooMuchKeysChanged 0|1

As a paranoidal option listed in config file (client-only section) one can use
StopTorIfTooMANYKeysChanged 0|1
P. S.: Товарищ unknown, исчисляемые: many, а неисчисляемые: much. Если не влазить в тонкости, мой вам совет: забудьте про употребление слова may в научно-технической литературе...

Other open questions: only stop tor if user enables this setting and log suspicious event or do any other way to interaction?

As concerns other open questions: suppose, user enables this option. Then, is it sufficient to stop tor-clent when suspicious log event comes or any other things should be done also?

What measures user can makes after that message?

What are the right things to do for the users who get that evil log event?
(Ну типа английская фраза не есть русская с заменёнными словами, т.е. часто буквальный перевод невозможен либо звучит не по-английски). Кстати, make – это обычно "делать" в смысле конструировать, создавать.

How to do with users with long period of inactive cache?

What's the right procedure to run tor-client for users who have a long period of inactive cache to be safe from this attack?

We have a long discussion and more noncompleted ideas on our site.

There is a long discussion connected with this problem in our site where we continue to discuss a lot of ideas related with the topic.

"OpenPGP in Russia Team"

"OpenPGP-in-Russia Team" лучше, а то не так поймут :)

После ### ещё следует добавить:
We estimate that MITM tor-network simulator can be implemented simply as a program run on one mashine or claster. Thus, tor-network simulator can be used to deface selected tor-clients.

PPS: Под конец понял что проще было переписать с начала до конца и запостить сюда. Следующий раз, unknown, пожалуйста, пишите на русском, а я переведу. И... передайте той шифровальщице что вас учила английскому несколько ласковых слов от spinore.