id: Гость   вход   регистрация
текущее время 23:15 28/03/2024
Владелец: unknown (создано 06/09/2011 22:27), редакция от 16/04/2014 09:52 (автор: unknown) Печать
Категории: софт, анонимность, приватность, анализ трафика, инфобезопасность, прослушивание коммуникаций, tor, атаки, модель угрозы
http://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 След.
Комментарии [скрыть комментарии/форму]
— Гость (09/09/2011 19:38)   <#>
вокруг самого проекта произошла масса событий, которые заставили кое-кого поволноваться по поводу практической анонимности.

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

По ссылкам говорится, что
  • 4 сервера были полностью скомпрометированы (root access, скрытые сервисы удалены).
  • На 8 серверах удалось стереть содержимое, но root доступ получен не был (похоже на взлом http-сервера).
  • Ещё с 11 серверами не удалось сделать ничего (написали предупреждение, зарегистрировавшись как обычные пользователи ресурсов).

Hidden Wiki утверждает, что около половины всех скрытых ресурсов хостятся на Freedom Hosting (FH), т.е. физически на одном сервере. Как хорошо известно, домашний ПК даст очень слабую пропускную способность в качестве скрытого сервиса, поэтому пользователи предпочитают FH. На последнем хостятся множество сайтов порталов с ДП, имеющих очень высокую скорость загрузки. Одно время назад владелец FH показательно выпилил все такие сайты, написав уведомление на главное странице со словами "я за вас в тюрьму идти не собираюсь", но несколько дней спустя те же сайты воскресли там снова и живут по сей день. Истиная политика владельца FH в отношении таких сайтов не ясна.

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

Правды мы, конечно, не знаем, но всё это действительно походит на самый типичный взлом сайтов. Провести его мог кто угодно — быть полицией для этого не обязательно. То же самое можно сказать и про исчерпание списка бридж-узлов. Наоборот, странно, что всё это произошло только сейчас, а не года 2-3 назад.

Из новости и ссылок не ясно, что теперь с бриджами: весь список исчерпан, или исчерпан только тот пул, который был доступен через сайт? Что делают с теми бриджами, которые уже попали в чёрные списки? Перестают их раздавать пользователям вообще? Если бы интерпол/FBI прицельно присоединились к операции, не думаю, что им было бы трудно получить от гугла совокупный список бриджей, уже предоставленный пользователям gmail-аккаунтов.
— unknown (10/09/2011 06:51, исправлен 10/09/2011 07:10)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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


К раздаче бриджей через сайт обещали прикрутить нормальную капчу.


[off]


Агентство оборонных исследований готовит что-то вроде Tor'a нового поколения


SAFER Warfighter Communications, предназначенный для сокрытия пользователей в сети интернет и предназначенный для устойчивой связи в условиях попыток блокирования.


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


[/off]

— Гость (14/09/2011 04:24)   <#>
проект не смог проигнорировать публикацию о первой относительно успешной и малоресурсозатратной атаке на раскрытие анонимности в сети Tor.

Интересно теперь вернуться назад, увидеть пророчества и сливы :) Судите сами...

  1. Students at a university, have successfully breached Tor's security by working from the inside out. They determined that when traffic from a Tor user is sniffed, it is possible to link unencrypted activities with this user.
    /comment45529, 25/03/2011.
  2. нужно слить сигнатуры интересующих нас потоков трафика на все СОРМ сервера. Это смешной трафик. Каждый сервер самостоятельно просеивает свои базы и сливает в центр только отчеты о совпадениях.
    /comment45580, 27/03/2011.
  3. сейчас есть ряд научных статей, и это направление всё больше активизируется, как мне кажется, по теме фингерпринтинга шифрованного трафка, когда по типу трафка/пакетов можно определить и используемый протокол связи, и тип загружаемого контента.
    /comment40504, 05/07/2010.
  4. The German federal police use traffic classifiers at their ISPs searching for the profiles of CP, and likely other content. If you use a Tor entry node in Germany (large portion of Tor nodes) and have ever viewed CP over Tor with a German entry node, consider yourself identified. They don't need to break the encryption if they can show there is a high % chance that it would decrypt to CP if they could break the encryption.
    /comment40541, 06/07/2010.
  5. Путём перехвата Tor-соединений пользователя и сравнения их с базой данных отпечатков сайтов в автоматическом режиме группе Хермана удалось достичь 50-60% распознаваемости. Как он отмечает — это конечно недостаточно для судебного доказательства, но весьма некомфортно, для тех, кто ожидает для себя высокой степени приватности.
    "Потенциальные возможности пассивного анализа трафика Tor", 28/12/2010.
  6. Первая относительно успешная и малоресурсозатратная атака на раскрытие анонимности в сети Tor, 06/09/2011.
— Гость (14/09/2011 05:24)   <#>
Несколько вопросов по поводу новости:

  1. их эксперимент в “реальном мире” ... показывает правильность верного положительного определения около 55%.
    Значит, грубо говоря, из N кликов на отслеживаемые сайты примерно 0.55*N кликов будут идентифицированы правильно. А сколько тогда кликов на другие сайты будут ошибочно распознаны как попадающее в отслеживаемую категорию?
  2. Проще ли этим способом атаковать обычные интернет-сайты, чем скрытые сервисы, или нет? Если да, то насколько?
  3. не все вэбсайты поддерживают конвейеризацию
    Что можно сказать о проценте тех сайтов, которые её поддерживают? А о проценте таких скрытых ресурсов?
  4. Насколько реалистично скомпилить TorBrowser для других платформ (не Linux/Windows)? Достаточно ли попатчить сорсы стандартного firefox перед компиляцией? Или TorBrowser — что-то более сложное?
  5. Допустим, что между пользователем и каким-то скрытым сервисом поднят ssh-тунель, и весь трафик от пользователя на скрытые ресурсы транслируется через этот тунель. Поможет ли такая мера против атаки?
  6. Как обстоят дела с анонимностью самих скрытых ресурсов? Утверждалось, что они обеспечивают для себя существенно меньше анонимности, чем для своих посетителей. Есть ли какой-то прогресс (за исключением примочек для "приватных" скрытых ресурсов)?
— unknown (14/09/2011 17:21, исправлен 14/09/2011 17:32)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

1. Да правильно всё, вот их результаты по открытым спискам на примерно 4000 URL (Open-word datasets), "другие сайты" это False positives, естественно:

Page Set True Positives False Positives
Sexually explicit 56.0% 0.89%
Alexa top ranked 73.0% 0.05%
Alexa random 56.5% 0.23%

2. Изучались только обычные сайты. Скрытые сервисы не изучались в данной работе.
3. Можно предположить, что достаточно много. Иначе бы эту функцию в Torbrowsere не модифицировали для противостояния атаке.
4. По идее ничего сложного, сорцы там все есть. Если что, спросите у разработчиков. Если приложите подробный отчёт о своей попытке, им будет интересно.
5. Само по себе ssh-соединение и прочие туннели выравнивают профиль трафика заведомо намного хуже, чем сам Tor. Плюс п.2
6. См. п.2

— Гость (14/09/2011 19:47)   <#>
Можно предположить, что достаточно много. Иначе бы эту функцию в Torbrowsere не модифицировали для противостояния атаке.

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

Само по себе ssh-соединение и прочие туннели выравнивают профиль трафика заведомо намного хуже, чем сам Tor.

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

Есть и альтернативный подход: ходить в сам Tor через ssh-тунель (сам Tor — на клиентской машине, но реально трафик идёт сначала по ssh-тунелю, а потом выходит в Tor-сеть с какого-то ssh-сервера), считая, что противник не может контролировать трафик на последующих entry-нодах (а если может, то ему будет трудно понять кому принадлежит ssh-трафик).

Вот какие-то такие идеи.
— unknown (14/09/2011 22:10, исправлен 14/09/2011 22:12)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Как узнать для заданного сайта, поддерживает ли он эту фичу? Есть стандартный метод?


Не знаю, только как распарсить вывод. Может быть вот по такой строке:



См. вобщем здесь.


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

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

— Гость (14/09/2011 22:21)   <#>
SSH туннель не меняет паттерна трафика, даже если расчитывать на блочный шифр (но в настоящий момент рекомендован к использованию режим счётчика), или призрачный оверхед от дайджествов. Нужно вносить нелинейность, например запустить браузер на удаленной машине.
— unknown (14/09/2011 22:29)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Риторический вопрос: можно ли иметь доверяемую удалённую машину? Тогда на ней даже покрывающий трафик можно вносить — свой канал, жалко что-ли. А от однозначно связанной с вами удалённой машины вход в сеть Tor будет выглядеть также как и обычно. Нужны меры в самой сети Tor. Недаром авторы предусматривают возможность вносить рэндомизацию паттернов на экситах.

Вот ещё HTACR — визуализатор HTTP-запросов и примеры картинок.
— Eridan (08/08/2012 15:31, исправлен 08/08/2012 15:51)   профиль/связь   <#>
комментариев: 254   документов: 9   редакций: 753

Вот тут написано, что Firefox умеет http://kb.mozillazine.org/Network.http.pipelining HTTP pipelining но он отключен по умолчанию для совместимости с некоторыми серверами. То что реализовал Tor (там написано случайный размер, случайная последовательность связей). Это тоже, что в Firefox по умолчанию (но отключено) или они добавили что-то свое?

— unknown (08/08/2012 16:22)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
# Randomize HTTP pipeline order and depth:

As an experimental defense against Website Traffic Fingerprinting, we patch the standard HTTP pipelining code to randomize the number of requests in a pipeline, as well as their order.
— Гость (22/05/2013 16:37)   <#>
а разве privoxy не спасает ситуацию? Там же вроде всё режется и видоизменяется
— Гость (22/05/2013 23:29)   <#>
а разве privoxy
а разве он включается в стандартный пакет?
— Гость (23/05/2013 05:18)   <#>

Что-то про pipelining там пишут, да:

New directive tolerate-pipelining to allow client-side pipelining. If enabled (3.0.20 beta enables it by default), Privoxy will keep pipelined client requests around to deal with them once the current request has been served. ©

Polipo is a caching proxy with advanced features like pipelining, multiplexing and caching of partial instances. In many setups it can be used as Squid replacement. ©

но это скорее о другом — о том, что если браузер поддерживает pipelining, то чтобы прокси его не зарезали, как мне кажется. К тому же, думаю, если б было всё так просто с пофиксом pipelining'а (поставь HTTP-проксю и не мучайся), Tor Project'у не пришлось бы форкать firefox.
— unknown (23/05/2013 09:34)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Privoxy создаёт проблемы при использовании HTTPS, который ныне можно вставить в любую страницу и который фильтроваться им не будет.
На страницу: 1, 2, 3 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3