05.10 // Опубликованы материалы о методах АНБ по получению контроля за пользователями Tor
В новой порции приданых огласке документов, переданных СМИ Эдвардом Сноуденом, раскрыты сведения о попытках проведения Агентством Национальной Безопасности США (АНБ) атак по деанонимизации деятельности пользователей сети Tor. Имея возможность выделять запросы, отправленные пользователями Tor, в общем объёме трафика, АНБ построило сеть из точек внедрения вредоносного ПО, нацеленную на поражение клиентского ПО пользователя Tor, в том числе а именно развиваемого проектом Tor специализированного браузера Tor Browser.
В рамках проекта Quantam, АНБ удалось разместить серию своих серверов контроля трафика в сетях ряда крупных магистральных провайдеров. При выявлении обращения через сеть Tor к сайтам, представляющим интерес для спецслужб, трафик перебрасывается с подконтрольных АНБ транзитных узлов в на специальные серверы FoxAcid, предназначенные для проведения атаки на системы пользователей. Атака осуществляется путём применения эффекта гонки (race condition), через генерацию сервером Quantam фиктивного ответа с редеректом на сервер FoxAcid, который за счёт того, что оборудование АНБ находится ближе к клиенту, приходит раньше реального ответа сервера, к которому обращается пользователь. После успешного переброса на сервер FoxAcid, пользователю от имени сервера FoxAcid отображается страница с вредоносным ПО.
Уязвимости эксплуатируются в том числе и в Tor Browser, основанном на Firefox, что позволяет получить контроль за машиной пользователя Tor. Для пользователей Tor, не использующих Tor Browser, упоминается техника отслеживания активности пользователя через установку и контроль за Cookie, которые при использовании одного и того же браузера при работе через Tor и без Tor не меняются. Сама сеть Tor не была скомпрометирована, контроль за трафиком производился за счёт внедрения троянского ПО на систему клиента.
Более того, в документе указано, что АНБ никогда не обладало возможности деанонимизации всех пользователей сети Tor. Лишь в отдельных случаях ручной труд аналитиков мог раскрыть отдельных пользователей Tor, но деанонимизации на лету добиться не удалось. В качестве целей также отмечается получение контроля за шлюзами Tor, но на момент подготовки документа АНБ имело контроль лишь за несколькими шлюзами из тысяч.
Источник: http://www.opennet.ru/opennews/art.shtml?num=38087
– на фото видна LPC http://savepic.su/3472184.jpg, но джампер только на положения "Нормальный", "Конфигурирование" и "Восстановление", а блокировки записи нет. Т.е. требуется как минимум выпаивание одной ножки.
К тому же эта материнка уже засвечена при обычной работе, т.е. без Tor, поэтому полагаться на ее анонимность не приходится.
PS. Может, это и глупо, но через свою паранойю считаю, что настоящую анонимность под Tor можно обеспечить, если не выходить в Интернет с материнкой, хоть раз побывавшей в нем без Tor.
Это не глупо, если на кону стоит жизнь, свобода или нечто подобное. В менее драматичных ситуациях, пожалуй, глупо, нелепо и не нужно.
На мой взгляд, в любом случае желательно иметь парк машин. С связи с чем можно активно скупать
барахлостарые модели материнских плат, CPU и др. комплектующих первой половины-середины 2000-х, чтобы и производительность была более-менее и уши АНБ не торчали из-под шлейфов.Это удобно и для экспериментальных целей и для работы, тем более если
работахобби возня с железом.Есть. Имя ей — фаервол. Плюс опционально прямые руки.
i386 пойдет, или уже поздновато? :)
комментариев: 9796 документов: 488 редакций: 5664
2 /comment71493:
Во-первых, слайды могут действительно пересобираться/перепечатываться журналистами.
Во-вторых, есть и более поздние слайды (см. подборку на cryptome.org), они не похожи по содержимому на 2007 год. В 2007 TorBrowser отсутствовал или только появлялся. На слайдах обсуждается TorBrowser на основе FF-ESR-10 и более поздние версии, а это 2011-2012 годы.
Может быть уже встроено было тогда. Лучше собирать свой процессор на транзисторах, тише едешь теплее будешь.
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 9796 документов: 488 редакций: 5664
К этой новости с форума подходит появившийся за месяц до неё /comment70253, вроде его ещё не упоминали в этом треде:
В Tor-блоге вышла длинная новость не тему guard'ов, данные про «несколько недель» в качестве времени их жизни уже устарели:
Когда всплывали предыдущие новости от АНБ, народ заинтересовался, и выяснилось, что DH далеко не во всех SSL и не во всех VPN. А насколько надёжный DH/PFS в Tor? Читаю man к вышепроцитированной опции и не понимаю, что они этим хотят сказать.
FastFirstHopPK=0 ⇒ Tor генерирует симметричный ключ и отсылает его на first hop? Симметричный ключ не вырабатывается по DH в этом случае?
Если опция отключена, то это всё равно сравнительно безопасно, потому что PFS есть за счёт TLS? Там двойное шифрование и двойная атуентификация, где снаружи TLS, а внутри сам протокол Tor? Отключение опции точно не влияет на PFS? Skipping it: it — это что? Skipping опции в конфиге (не указывать) или skipping аутентификации по публичному ключу? Но ведь и при DH публичный ключ тоже используется, хоть и для заверения параметров сессии? Или всё не так?
Наверно, имелось в виду, что если надо вырабатывать общий симметричный ключ по DH, то это будет медленнее, чем если клиент просто шифрует им выбранный симметричный ключ и отсылает его первому хопу? Но это противоречит условию FastFirstHopPK=0 — т.е., дословно, не использовать публичный ключ с первым хопом.
Кто такой первый хоп, если Tor — это relay? Следующий узел в цепочке, куда ему нужно переслать трафик? И в этом случае никакого DH, получается, нет?
Казалось бы, при чём тут onion. Если это не onion-протокол и не роль IP/RP/ещё чего-то такого, то обычный сервер в цепочке вообще не знает, какой трафик он пересылает — идущий наружу или на onion'ы.
Иными словами говоря, что получит противник, скомпрометировавший ключ одной Tor-ноды? Туманное шифрпанковское изложение man'а намекает, что DH там далеко не везде.
комментариев: 9796 документов: 488 редакций: 5664
Они сильно оптимизировали протокол, но PFS был изначально, об этом неоднократно упоминалось в разных материвалах и сообщениях проекта. Например, при обнаружении дыры в Debian OpenSSL. Поскольку Tor устроен посложнее, чем просто TLS/SSL-соединение между хостами, то там могут быть разные нюансы насчёт PFS на разных шагах и PFS для шифрования и аутентификации нод.
В самом начале была ещё проблема согласования параметров DH, при которой противник мог навязать сторонам предопределённый ключ. Это исправили. Затем вышла работа, где протокол Tor был проанализирован с точки зрения доказуемой безопасности и задним числом показано, что если бы делали по этому подходу, то дырка бы выявилась сразу. В этой же работе было показано, как переводить Tor на ECC.
комментариев: 9796 документов: 488 редакций: 5664
Можно сказать, что он не получит. Он не получит возможность расшифровать ранее прошедший (до момента момента перехвата ключа или установления контроля над нодой) через эту ноду трафик, даже если он его где-то перехватывал и записывал. Не считая случаев, наподобие фатальных дырок в OpenSSL, когда всё PFS идёт лесом.
Даже если остальные 2 ноды полностью подконтрольны атакующему?