id: Гость   вход   регистрация
текущее время 18:34 03/08/2020
Владелец: unknown (создано 06/09/2011 22:27), редакция от 16/04/2014 09:52 (автор: unknown) Печать
Категории: софт, анонимность, приватность, анализ трафика, инфобезопасность, прослушивание коммуникаций, tor, атаки, модель угрозы
https://www.pgpru.com/Новости/2011/ВTorBrowserПомещенаЭкспериментальнаяЗащитаОтСерьёзнойСтатистическойАтаки
создать
просмотр
редакции
ссылки

06.09 // В Tor Browser помещена экспериментальная защита от серьёзной статистической атаки


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


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


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



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


fileРанние работы быстро выявили то, что простые схемы шифрования пакетов (такие как шифрование беспроводных сетей и VPN) были бесполезны в качестве меры предотвращения распознавания паттернов (характерных образцов) трафика, создаваемых популярными вэбсайтами в шифрованном потоке. Позднее fileмаломасштабное исследование определило, что масса информации может быть извлечена из HTTPS-потоков с использованием таких же подходов против конкретных вэбсайтов.


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


Однако, в текущем месяце, группа исследователей fileдостигла успеха в исполнении данной атаки, там где другие терпели неудачу. Их успех в большой степени опирается на использование упрощённого, но хорошо подобранного множества опций для тренировки классификаторов. Там где другие исследователи просто сохраняли дампы размера пакетов и времени в своих классификаторах и закономерно получали неудовлетворительные результаты против трафика Tor, эта группа извекала время, количество и направление трафика и отбрасывала несущественную служебную информацию, такую как TCP ACK.


В то время как методология исследователей в представлении атакующей стороны в их работе достаточно показательна (особенно за счёт своевременного получения профилей сайтов), их результат всё ещё неудовлетворителен для разворачивания в сети и выслеживания людей одноразово посещающих запретные сайты. В таком сценарии, даже с учётом довольно низкого ошибочно положительного значения распознавания, это приведёт к большому числу срабатываний при разворачивании против больших объёмов трафика. Конкурирующее использование множества AJAX-ориентированных сайтов и/или приложений, также создаст трудности атакующему. Даже без использования конкурирующей активности, их эксперимент в “реальном мире” (наиболее реалистичном сценарии сетевого просеивания Tor-трафика) показывает правильность верного положительного определения около 55%.


Однако, повторящиеся наблюдения в течении долгих периодов времени вероятно будут удовлетворительными для создания уверенности. Также возможно, что извлечение фактической длины данных из Tor TLS-заголовков придаст этому дополнительную точность.


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


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


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


Вместо этого мы выполнили экспериментальную защиту в текущем выпуске Tor Browser Bundle, которая специально предназначена для уменьшения информации, доступной для продвинутого извлечения без того, чтобы вносить дополнительные накладные расходы. Защита основана на параллельном выполнении HTTP-запросов в одном потоке-конвейере и использует рэндомизацию размера конвейера также как и порядка запросов. Исходный код исполнения можно посмотреть в gitweb.


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


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


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


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


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


Альтернативно или вероятно дополнительно, защита может быть развёрнута на уровне obsfproxy plugin layer. Защиты, которые не помогут против атакующего на уровне мостового или сторожевого узла, но смогут помочь против региональных файрволлов.


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


© Mike Perry / Torproject.org




См. также “Потенциальные возможности пассивного анализа трафика Tor”.


Источник: Torproject Blog


 
На страницу: 1, 2, 3 След.
Комментарии [скрыть комментарии/форму]
— Гость (25/05/2013 15:12)   <#>

Не мудрено. Если даже эксплоиты для тора на рынке имеют отрицательную стоимость.
— SATtva (25/05/2013 15:52)   профиль/связь   <#>
комментариев: 11548   документов: 1036   редакций: 4094
В Советской России эксплоиты покупают тебя?
— Гость (25/05/2013 23:58)   <#>
...и силой мысли разворачивает Tor-цепочки за мелкий прайс.

Если человек стал объектом наблюдения и пользуется тором, то сопоставляя одновременно его трафик и наблюдения за пгпру можно понять, авторство постов. И то и другое доступно российским "пацанам в погонах".
— Гость (26/05/2013 00:44)   <#>
наблюдения за пгпру можно понять
а пацаны строго уверены, что наблюдаемый появится на пгпру.ком?
— Гость (26/05/2013 00:46)   <#>
а сам SATtva сотрудничает со спецслужбами?
просим уточнить на какие спецслужбы? логично думать что на импортные )) раз сервер в россии.
— Гость (26/05/2013 03:17)   <#>
просим уточнить на какие спецслужбы?

"не верь, не бойся, не проси".
— Гость (27/05/2013 06:12)   <#>
Такие уникумы будут профилироваться за счёт того, что не смогут зайти на pgpru и не получат свежую порцию сакральных знаний.
Имелось в виду, что для тех случаев, где https нужен, они заведут отдельный профиль браузера/TBB.

Если человек стал объектом наблюдения и пользуется тором, то сопоставляя одновременно его трафик и наблюдения за пгпру можно понять, авторство постов.
Только если плотность анонимов, ходящих на ресурс под Tor'ом, невелика. Иначе получим, что постоянно кто-то что-то здесь делает под Tor'ом, поэтому настолько лёгкой корреляции не прослеживается.

тут некоторые пишут по ночам. не значит ли это, что они живут в таких часовых поясах отличных от UTC+04:00?
Или им не спится, или у них режим сбитый, или бессонница или они спят весь день, а ночью бодрствуют. Шустро вы всё Россию до одной Москвы ужали. Слава Медведеву в РФ пока ещё >1 часового пояса.

Регулярно по ночам – дополнительные биты в профиль!
Благодарствую за бонусы!
— Гость (14/04/2014 20:10, исправлен 16/04/2014 12:03)   <#>

Перенос обсуждения из другой темы.



А какое отношение к firefox имеет эта бага? Пакеты идут в сеть непосредственно от Tor, а не от firefox. Tor это ведь proxy-узел. Почему Tor не шифрует фактическую длину данных в TLS-заголовках? Почему в TLS-заголовках вообще присутствует нешифрованная длина данных? Ясно что это сделано по приказу АНБ. Теперь "внезапно" Tor-разработчики увидели багу, но исправили не сам Tor, а коктейль из Tor и firefox. Ясно что и Tor и firefox по отдельности много кто исследовал на закладки, а их связку напротив проверяли мало, туда можно запихать новые ошибки закладки.

— unknown (15/04/2014 09:50, исправлен 15/04/2014 11:20)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

И сами разработчики, и сторонние исследователи об этом давно предупреждали. Этот недостаток протокола не такой примитивный и не так легко исправляется, как вы описали.



Tor шифрует пакеты стандартным размером:

Traffic passes along these connections in fixed-size cells. Each cell is 512 bytes, and consists of a header and a payload. The header includes a circuit identifier (circID) that specifies which circuit the cell refers to (many circuits can be multiplexed over the single TLS connection), and a command to describe what to do with the cell's payload.

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


Более сложные изменения Tor-протокола исследовались, но оказались и сложно реализуемыми, и непрактичными:

No mixing, padding, or traffic shaping (yet): Onion Routing originally called for batching and reordering cells as they arrived, assumed padding between ORs, and in later designs added padding between onion proxies (users) and ORs [27,41]. Tradeoffs between padding protection and cost were discussed, and traffic shaping algorithms were theorized [49] to provide good security without expensive padding, but no concrete padding scheme was suggested. Recent research [1] and deployment experience [4] suggest that this level of resource use is not practical or economical; and even full link padding is still vulnerable [33]. Thus, until we have a proven and convenient design for traffic shaping or low-latency mixing that improves anonymity against a realistic adversary, we leave these strategies out.

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

— Гость (16/04/2014 01:40)   <#>

Причем здесь размер самих пакетов? Фальсифицироваться должно только значение реального объема данных в пакете(-ах), о нем шла речь. Подлинное значение должно быть спрятано в данных и шифровано вместе с ними. Число пакетов в конкретной серии тоже должно прятаться в данных.

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

В любом случае firefox нипричем. Он никак не облегчает корреляционный анализ противнику. А TLS-шифрование если и используется firefox, то только для https соединений и только под шифрованным Tor-трафиком. У меня в firefox вообще отключен TLS, что-то слышал его ненадежности, разрешен только SSL 3.0.

Профилирование выходящего трафика это отдельный вопрос. И эта проблема не оправдывает объединение firefox и Tor в одну мутную программу – TBB. Того же эффекта можно было добиться предустановленными в firefox стандартным файлом конфигурации (с настроенной безопасностью) и стандартным набором дополнений.


Но заголовок TLS-пакета раскрывает реальные параметры пересылаемых данных.
— Гость (16/04/2014 02:51)   <#>
Но заголовок TLS-пакета раскрывает реальные параметры пересылаемых данных.
Точно? Вы лично проверяли? Есть пруфы? Если так, то это дыра требующая немедленного фикса.
— Гость (16/04/2014 08:05)   <#>

Так сказано здесь
про "фактическую длину данных в TLS-заголовках"
— unknown (16/04/2014 09:59, исправлен 16/04/2014 12:06)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
It is also possible that extracting actual application data lengths from Tor TLS headers would add additional accuracy.

© Mike Perry.


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


Того же эффекта можно было добиться предустановленными в firefox стандартным файлом конфигурации (с настроенной безопасностью) и стандартным набором дополнений.

Не всё (практически ничего) из этого конфигами и дополнениями не решается.


Подробнее про кое-что из патчей здесь.


И комментарии Майка к той новости.


Например,

The original about:config options for pipelining don't allow the randomization we implemented.

The pipeline size is randomized for each batch of requests.
For example, let's say www.torproject.org has 15 images, and supports pipelining. The request processing looks like this:


As you can see, a new random number P is chosen for each batch of requests. It is not a property of either Jack or Jill's computer. It does not persist. The sequence of P's come from the NSS cryptographically secure random number generator via PK11_GenerateRandom().

The full patch is here:


On September 8th, 2011 mikeperry said:


If Panchencho didn't publish, we would probably set our packet size to a fixed amount (say, 512 bytes), and multiplex all of the client data on a single TLS stream. This should provide some obfuscation for most protocols (remember, Tor supports more than just HTTP) without too much overhead, complexity or protocol-specific craziness. Oh wait, we did that. And it did. For a decade.


We want the trust in Tor to come from the fact that we are open source and transparent, and that we do Real Science. Everything in Tor is built upon decades of public research. We don't want trust in Tor to come from us doing secret defenses and looking into a crystal ball and guessing what the most devastating imaginary attacks might be, and developing broken pretend defenses against imaginary attacks that probably don't work in reality.


There are plenty of other tools that will sell you magical secret sauce to defend against everything from the future and beyond. We don't do that, because there's another name for that magical secret sauce: Snake Oil.

P.S.: Если есть содержательные дополнения по поводу новости, то можете продолжать её обсуждение непосредственно в ней самой, а не распыляться по другим темам, чтобы не собирать по отдельности сюда все комментарии.

— Гость (30/05/2014 08:07)   <#>

Жаркие обсуждение этого вопроса было в соответствующих темах [1], [2], [3], которые набрали десятки страниц комментариев, троллинга и претензий к разработчикам Tor, так что один топик пришлось вообще закрыть на комментирование. Короткий смысл в том, что между удобством для гиков и домохозяек разработчики выбрали вторых, немало подзабив на первых. Типа ресурсов у них мало, распыляться не хочется, а анонимность требует массовости и распространения, поэтому пусть будет one click program в виде TBB, где всё вместе, уже собрано и работает искаробки (скачал → запустил → пользуйся).
На страницу: 1, 2, 3 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3