Всё о TBB (Tor Browser Bundle)

Мне кажется, разделение по доменам могли не делать в том числе и потому, что некоторые сайты, владеющие сразу несколькими доменами, для корректной работы требуют, чтобы запросы на все домены пришли с одного IP и с корректными реферерами. Сможет ли TorBrowser корректно разрулить такую ситуацию? По крайней мере, отключать реферер по умолчанию не стали именно из-за этого («сломает много сайтов»).

Пусть противник 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-метку.

1. Легко выявляются все пользователи с разделением трафика по доменам.
2. Пользователей с разделением трафика гоняют по множеству разных параллельных цепочек с точкой инициирования Site и точками выхода на подконтрольные противнику домены d, потенциально увеличивая вероятность нахождения деанонимизирующих корреляций в десятки и сотни раз по сравнению с обычным Tor-соединением (в зависимости от того, сколько цепочек может построить клиент).
3. Атака м.б. малоресурсозатратна. Расходы на домены d и подконтрольные узлы Tor n невелики, по сравнению с потенциальным эффектом усиления деанонимизации.
4. Атаку можно осуществлять в любом из трёх мест: Exit, MiTM, Site. В случае Exit и MiTM можно использовать существующие сайты в качестве подставных, используя модификацию HTTP-трафика, хотя это потенциально более заметно и такой Exit могут вывести из Tor-сети.

При IsolateDestAddr — да, но не при таком патче:

Вроде есть патч, позволяющий для каждого HTTP-запроса с новым хостом в URL подставлять уникальные user:password для Tor (для встроенного контента веб-страницы подставляются те же самые)

Грубо говоря, я так понял, Tor хотят научить грузить всё, что открыто в заданной вкладке браузера, через одну редко меняемую цепочку (15 минут или сколько оно там сейчас). А всё, что открыто в другой вкладке (в общем случае, другой домен) — через другую цепочку.

crashfirefox.com Проверьте свой браузер (требуется js). Вы успеваете вырубить вкладку или приходится закрывать окно браузер, вы готовы закрыть браузер в таких случаях и не задеанониться?

При чём тут форкбомба к деанону? Разве что очень опосредованно.


На первых порах можно закрыть, потом вешается намертво. Ещё позже:

Кешировать реферер на домен начального 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-трафика отдельный сокс порт с дефолтными настройками.


Как это снижает анонимность? Скорей наоборот, запросы к разным серверам по одной цепочке связывают их в один профиль.

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

При IsolateDestAddr запрос DNS и собственно TCP-соединение для скачивания уже по идее идут через пару разных Exit'ов. А теперь представим, что оба таких эксита принадлежат Adversary и он заметил вот такую специфическую корреляцию. Теперь он знает, что даже по одному экситу, если идёт DNS-запрос имени почтового сервера, но почта не скачивается, то к этому почтовому серверу в данный момент может логиниться кто-то из немногих любителей поизвращаться с настройками.

Анализ трафика для профилирования, даже без его расшифровки и явной деанонимизации — штука увлекательная. Наверняка, АНБ кто-то на экситах или в MitM'е после них ищет, моделирует и классифицирует всякие аномалии трафика.

По-моему, это больше борьба с ветрянными мельницами, чем защита. Кажется, Tor Project настоятельно не рекомендовал ставить дополнительные прокси перед Tor'ом из-за того, что они понижают анонимность. Вроде даже был такой факт, что любая прокси, даже полностью нейтральная, всё равно оставляет отпечаток своего присутствия на трафике. Подтвердить это ссылками сейчас не могу, ничего сходу не припоминается, но была одна атака [1], которая заставиляет задуматься: по большому счёту, важно всё — и железо, и версия браузера, и ОС... т.к. всё это может вызывать отличия в трафике.


Pipelining простыми словами — это возможность провайдеру (ISP) определить, посещаете ли вы заданный сайт X (или некоторый предопределённый набор сайтов) или нет. Как по мне, это крайне критичная атака [2].


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


Не подумал бы о таком. Это точно так? DNS-запросы — нечто постороннее, и я не знаю, как Tor их толкует.

Парни, а выбранные настройки сохраняются? Или всегда нужно obfsproxy выбирать заново?

Кто-то пишет багрипорты создателям TBB? Хотелось бы передать два пожелания.

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

Как раз пожелания очень миролюбивые. Я бы написал, но разве они русский понимают?

Напишите через гугл-транслейт. Если пожелание хорошее, тогда поймут. Если нет, ну не судьба значит.

Наткнулся в альфе Orbot на кнопку vpn, т.е. каким то образом реализовано создание vpn-соеденения с каким то сервером. Собственно в чем вопрос, не слышно в TBB такое планируется?

Можно писать даже без создания аккаунта.