Всё о TBB (Tor Browser Bundle)
Извиняюсь, но за 10 минут перебора тем в форуме "Анонимность" не нашел всеобъемлющей темы о TBB (Tor Browser Bundle), только разрозненные.
Поэтому предлагаю обсуждать вопросы и проблемы, представляющие интерес для многих, в этой ветке, будет удобней.
комментариев: 9796 документов: 488 редакций: 5664
Пусть противник Adversary контролирует веб-ресурс Site. Пусть также он контролирует n узлов сети Tor, среди которых относящиеся и к разным Exit, и к Middleman, и к Guard. Adversary также владеет d уникальными доменами. На Site он создаёт страницу, которая по возможности незаметно подгружает данные с веб-страниц d, например ссылки на однопиксельные картинки. Tor-клиент пользователя попытается построить d цепочек, которые пойдут через его Guard через d Exit'ов, т.е. клиент будет строить цепочки так, что все Exit'ы будут по возможности разными. Так на стороне Site Adversary будет выявлять факт использования разделения трафика по доменам (профилирование).
Пусть d — велико (сотни). Вероятно, клиент пользователя не сможет построить столько цепочек и не догрузит страницу (это лимитируется в т.ч. в самом клиенте). Однако, если в самом конце страницы Site использована какая-нибудь полоска прозрачных пикселов (один в высоту, сотни в ширину, назовём её d-метка), то её недогрузка не будет сильно заметна. Хотя браузер и будет показывать, что что-то грузится, хотя страница вроде как полностью загрузилась, но в Tor такие подвисания бывают часто и выглядят естественно. К тому же, d-метку можно вбрасывать пользователю не каждый раз. Кстати, для любого не https-site это может делать не только непосредственный владелец сайта, но и злонамеренный Exit и Exit ↔ MiTM-er ↔ Site. Т.е., Adversary может контролировать подставной веб-ресурс http-Site опосредовано, просто вклиниваясь в трафик с Exit.
Все d-соединения к одному ресурсу Site пойдут через множество цепочек, а не через одну как обычно. Это увеличивает возможность противника найти корреляцию Exit ↔ Middleman ↔ Guard и установить Guard пользователя. А если выпадет, что этот Guard (или отчасти, линк [пользовательский ISP] ↔ Guard) окажется подконтрольным противнику, то ему не составит труда установить и IP-адрес пользователя.
Это только первое, что приходит в голову. Можно усовершенствовать, вбрасывая пользователям индивидуализированные d, а также уводить часть d не в открытый интернет, а на подконтрольные онионы: для связи с ними не нужен Exit, противник может искать корреляции и по своим Middleman. Можно соединять с другими атаками и т.д.
Скорее всего, команда Torproject'а что-то такое прикинула, может даже конкретные значения и затраты на атаку посчитала и оставила эту опцию не для использования по умолчанию. Единственно, где она м.б. оправдана — не веб-трафик, лучше какой-то специфичный, стойко аутентифицированный, например — проверка почты с множества POP3S почтовых адресов, хотя и там это может снижать анонимность, но такой трафик и сам по себе выделяется и плохо смешивается.
Что интересно — в скрытых ресурсах (HS-onion) аналогичная опция используется по умолчанию: цепочка до каждого onion строится индивидуально. В принципе, можно и там заманить пользователя на компрометирующий onion (например, взломанный и/или подконтрольный), который будет гонять трафик пользователя по множеству цепочек, как внутри HS, так и наружу.
Что мы имеем в итоге: некая мультидоменная полоска пикселов или других элементов (d-метка) никак не мешает обычным пользователям Tor. Она может быть и составной: сначала она содержит несколько пикселов или элементов (мини-d-метка), а при выявления разделении трафика по доменам — вызывать вторую, уже полноценную d-метку.
При IsolateDestAddr — да, но не при таком патче:
Грубо говоря, я так понял, Tor хотят научить грузить всё, что открыто в заданной вкладке браузера, через одну редко меняемую цепочку (15 минут или сколько оно там сейчас). А всё, что открыто в другой вкладке (в общем случае, другой домен) — через другую цепочку.
При чём тут форкбомба к деанону? Разве что очень опосредованно.
На первых порах можно закрыть, потом вешается намертво. Ещё позже:
Кешировать реферер на домен начального url и посылать тору одинаковые user/pass для всей цепочки кликов тоже планируется в будущей версии.
Tor Browser should set SOCKS username for a request based on first party domain
Для этого и нужен прокси, в котором подобное поведение может быть обнаружено. Можно и в arm заметить большое количество цепочек, но куда они ведут он информации не даёт.
В целом понятно, подставляются веб-маркеры, которые распознаются в шифрованном трафике, а отсутствие pipelining облегчает эту задачу (даже если он есть, для малых сообщений не успевает подействовать). Что позволяет злонамеренному экситу улучшить корреляцию, миддлу – вычислить гард, а гарду вычислить IP-адрес пользователя. В последнем случае даже не требуется распознавать шифрованный маркер, достаточно самого факта резкого роста числа цепочек, коррелирующего с запросом к сайту.
Атака безрезультатна когда весь встроенный контент с third-party доменов отфильтровывается, в privoxy можно создать такой фильтр. Но для HTTPS сайтов он не работает, т.к. privoxy не умеет фильтровать шифрованный трафик.
Убедили, завёл для HTTP-трафика отдельный сокс порт с дефолтными настройками.
Как это снижает анонимность? Скорей наоборот, запросы к разным серверам по одной цепочке связывают их в один профиль.
комментариев: 9796 документов: 488 редакций: 5664
Снижает относительно, по сравнению с вариантом, когда вы проверяете почту с разных ящиков из под разных торифицированных пользователей, которые строят свои цепочки. Или из под одного, но после проверки каждого ящика по отдельности сбрасываете цепочки вручную. Т.е., ваш трафик выглядит как у обычного пользователя.
При IsolateDestAddr запрос DNS и собственно TCP-соединение для скачивания уже по идее идут через пару разных Exit'ов. А теперь представим, что оба таких эксита принадлежат Adversary и он заметил вот такую специфическую корреляцию. Теперь он знает, что даже по одному экситу, если идёт DNS-запрос имени почтового сервера, но почта не скачивается, то к этому почтовому серверу в данный момент может логиниться кто-то из немногих любителей поизвращаться с настройками.
Анализ трафика для профилирования, даже без его расшифровки и явной деанонимизации — штука увлекательная. Наверняка,
АНБкто-то на экситах или в MitM'е после них ищет, моделирует и классифицирует всякие аномалии трафика.По-моему, это больше борьба с ветрянными мельницами, чем защита. Кажется, Tor Project настоятельно не рекомендовал ставить дополнительные прокси перед Tor'ом из-за того, что они понижают анонимность. Вроде даже был такой факт, что любая прокси, даже полностью нейтральная, всё равно оставляет отпечаток своего присутствия на трафике. Подтвердить это ссылками сейчас не могу, ничего сходу не припоминается, но была одна атака [1], которая заставиляет задуматься: по большому счёту, важно всё — и железо, и версия браузера, и ОС... т.к. всё это может вызывать отличия в трафике.
Pipelining простыми словами — это возможность провайдеру (ISP) определить, посещаете ли вы заданный сайт X (или некоторый предопределённый набор сайтов) или нет. Как по мне, это крайне критичная атака [2].
Если нужно проверять много ящиков, всё равно будут корреляции хотя бы времени их проверок. Чтобы этого избежать, надо создавать скрипт с выбором рандомного времени проверки, да ещё и привязанного к тому или иному часовому поясу (чтобы имитировать нормальную активность пользователя).
Не подумал бы о таком. Это точно так? DNS-запросы — нечто постороннее, и я не знаю, как Tor их толкует.
комментариев: 1079 документов: 58 редакций: 59
Звучит угрожающе. Передавайте пожелания сразу, не ждите подтверждений. Писать репорты могут все, а выяснять тут пожелания захочет не каждый.
Напишите через гугл-транслейт. Если пожелание хорошее, тогда поймут. Если нет, ну не судьба значит.
Можно писать даже без создания аккаунта.