id: Гость   вход   регистрация
текущее время 02:09 29/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 След.
Комментарии [скрыть комментарии/форму]
— Гость (23/05/2013 16:56)   <#>
Privoxy создаёт проблемы при использовании HTTPS, который ныне можно вставить в любую страницу и который фильтроваться им не будет.

И что же тогда происходит? Я захожу на https через Privoxy, ведь он же открывается. Как же он тогда открывается?
— unknown (23/05/2013 17:19)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Проблема именно в том, что он открывается. Беспрепятственно и бесконтрольно. Privoxy его просто пропускает сквозь себя.
— Гость (24/05/2013 02:49)   <#>
Тогда можно попросту запретить https в браузере или файерволлом и получить различитель/профилирование.
— Гость (24/05/2013 05:57)   <#>
Проблема именно в том, что он открывается. Беспрепятственно и бесконтрольно. Privoxy его просто пропускает сквозь себя.

Я не могу понять чем же безопасней TBB? Там стоит тот же самый torbutton и noscript который я могу поставить в firefox и без TBB, при том что в noscript там по умолчанию не выключена возможность исполнения java-script, не отключена дажа сама Java и на Ютубе можно смотреть видеоролики и это безопасность?! Я могу без всякого TBB при помощи torbutton, noscript и privoxy настроить безопасность в разы лучше!
— Гость (24/05/2013 06:06)   <#>
Не ясно в чём деанонимизация. Даже если privoxy не фильтрует https, а пропускает через себя, ведь сам privoxy настроен на TOR, и значит https прежде чем попасть в privoxy проходит через TOR, так в чём проблема?
— Гость (24/05/2013 06:21)   <#>
http://www.privoxy.org/user-manual/installation.html

"The privoxy service will automatically start after a successful installation (and thereafter every time your computer starts up) however you will need to configure your web browser(s) to use it. To do so, configure them to use a proxy for HTTP and HTTPS at the address 127.0.0.1:8118"

сами разрабы privoxy рекомендуют пропускать через него HTTPS
— unknown (24/05/2013 10:04, исправлен 24/05/2013 10:43)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Название топика и содержание новости читали? Со списком патчей в TBB, отличающих его от FF, ознакомились?


Связка Privoxy+FF+TB вместо TBB давно уже устарела в этом плане и защиты не обеспечивает.


Я могу без всякого TBB при помощи torbutton, noscript и privoxy настроить безопасность в разы лучше!

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

— Гость (24/05/2013 16:42)   <#>
Связка Privoxy+FF+TB вместо TBB давно уже устарела в этом плане и защиты не обеспечивает.

unknown, аргументы, аргументы есть?! Аргументы в студию!
И не то что вам там кто то что то напел, а результаты Ваших собственных наблюдений! По моим наблюдениям, опираясь на тесты http://ip-check.info/?lang=en и http://whoer.net/ext это как раз таки абсолютную анонимность TBB с его сегодняшними настройками можно поставить под сомнение, а у связки Privoxy+FF+TB анонимность куда большая!
— unknown (24/05/2013 17:13, исправлен 24/05/2013 17:14)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Всё не так просто. Сами по себе показания определялок незначимы.


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



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

— Гость (24/05/2013 23:10)   <#>

В TBB есть JS, но нет Java. Видеоролики смотрятся не через Flash, а через html5-video, то есть оупенсорсно и всё хорошо.


Безопасность — да, анонимность — нет, в этом весь прикол и состоит.


Есть проблема профилирования с piplining. Её предложили решить, пропуская трафик через privoxy. На это было отвечено, что, даже если бы privoxy решала проблему с http, всё равно осталась бы проблема следующего характера. Privoxy пропускает https-трафик без модификаций, то есть, если там pipelining'а не было, после прохода через privoxy он там и не появится, поэтому получаем ещё один тип профилирования: у всех pipelining работает либо для всего (http и https), либо ни для чего (ни для http, ни для https), а у вас будет реализовываться редкий случай: http с pipelining'ом, а https без. Если вы попытаетесь наивно зарезать весь https-трафик на уровне браузера или файерволла, всё равно останется профилирование, поскольку все посетители сайта будут загружать все ссылки, а вы — только те, которые http. Понятно?


Аргумент прост и элементарен. TBB — форк самого браузера firefox, он не сводится к связке Privoxy+FF+TB. Без правки кода самого браузера того же не получить.


Анонимность — не та вещь, которую можно определить на глазок.


Снова: не анонимность, а безопасность. Анонимность определяется массовостью, безопасность — настройками. Одно может не способствовать другому, поскольку всё дело в умолчаниях, принятых для всех. Выбирайте по ситуации, что вам важнее. В предельных случаях может быть так, что деанонимизация следует как из очень низкой безопасности, так и из очень высокой. Правда, во втором случае получаем, точнее, не деанонимизацию, а идеальное профилирование — вас смогут легко отличить на фоне тысяч или даже миллионов других юзеров (но не обязательно узнать, кто вы).
— SATtva (25/05/2013 09:31)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Если вы попытаетесь наивно зарезать весь https-трафик на уровне браузера или файерволла, всё равно останется профилирование, поскольку все посетители сайта будут загружать все ссылки, а вы — только те, которые http.

Такие уникумы будут профилироваться за счёт того, что не смогут зайти на pgpru и не получат свежую порцию сакральных знаний.
— Гость (25/05/2013 11:18)   <#>
по поводу профилирования, так тут некоторые пишут по ночам. не значит ли это, что они живут в таких часовых поясах отличных от UTC+04:00?
— Гость (25/05/2013 11:25)   <#>
Неважно где живут, важно как пишут. Регулярно по ночам – дополнительные биты в профиль!
— Гость (25/05/2013 14:53)   <#>
А о какой вообще анонимности может идти речь если pgpru.com физически находится на сервере распложенном в России а сам SATtva сотрудничает со спецслужбами?
— SATtva (25/05/2013 15:04)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
...и силой мысли разворачивает Tor-цепочки за мелкий прайс.
На страницу: 1, 2, 3 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3