Звук в браузере
Зашел через заторенный огнелис с включенным торббаттоном (дефолтные настройки) и выключенными J, JS и Flah (через Flashblock и Quickjava) на один сайт, у меня начала воспроизводиться музыка на компе, что очень меня насторожило (с точки зрения возможной деанонимизации).
К сожалению, снифферы у меня не были включены, и я не смог выяснить, пошла ли утечка пакетов не через тор.
Каким образом может воспроизводиться звук при посещение веб-сайта, если указанные плагины выключены? Чем это угрожает для анонимности? И что за эксплойт там может быть?
P.S.Если я после этого безобразия снесу локальные пользовательские настройки огнелиса в хомяке этого пользователя, насколько это может спасти меня от возможного заражения эксплойтом? Что еще могло быть поражено им? (Какие папки локальных настроек в хомяке на всякий случай сносить?)
P.P.S. ОС – Debian Lenny AMD64,Iseweales 3.0.6, Tor v0.2.1.22, Privoxy version 3.0.9, Torbutton 1.2.0, Flashblock 1.5.11.2, Quickjava 0.4.2.1
Ссылки
[link1] https://www.torproject.org/torbutton/releases/
[link2] http://gitweb.torproject.org/tor.git?a=blob_plain;hb=HEAD;f=ChangeLog
[link3] https://www.torproject.org/about/corepeople.html.en
[link4] https://www.torproject.org/docs/signing-keys.html.en
[link5] https://trac.torproject.org/projects/tor/ticket/5412
[link6] https://trac.torproject.org/projects/tor/ticket/5417
[link7] https://www.pgpru.com/comment51384
[link8] https://blog.torproject.org/blog/new-tor-browser-bundles-firefox-1703esr
[link9] https://trac.torproject.org/projects/tor/ticket/7495
[link10] https://trac.torproject.org/projects/tor/ticket/3100
[link11] https://www.pgpru.com/biblioteka/rukovodstva/setevajaanonimnostj/prodvinutoeispoljzovanietorvunix/razdeljnoeispoljzovanietorbrowserssistemnymtoriprozrachnajatorifikacija
[link12] https://www.pgpru.com/comment50793
[link13] https://www.pgpru.com/comment95699
Дата релиза:
С музыкой скорей всего не связано, но в более свежих версиях были правки множества своих багов и "фичей" браузера.
Версии Torbutton, также как и Tor нужно использовать с сайта torproject, а не из дистра. В Debian не патчат security баги, связанные с анонимностью.
Это не эксплоит – скорей всего torbutton почему-то не отключил проигрывание музыки через браузер-расширения. Ну а что вы тогда мучаетесь? Пара строчек в конфиге iptables на блокирование трафика от нужного пользователя не в Tor и basta (не путать с прозрачной торификацией, что намного сложнее в настройке).
Tor у меня этот:
Т.е. с сайта торпроекта, а не из дистра.
А вот privoxy похоже из дебиановского дистра:
Ну и с torbutton получается такая же беда.
Какие надо сделать записи в соурс.листе, чтобы их с сайта торпроекта получать? Не могу найти что-то.
Privoxy некритичен. При использовании TB он лишь заворачивает трафик в Tor, а можно даже и без него, но это как подстраховка.
С TB ситуация хуже — пакет собран самой командой Debian, но торпроектом пакет не поддерживаются. Т.е. пакет с плагином нужно удалить, а плагин ставить вручную, через https://torproject.org. После взлома серверов проекта спохватились ещё, что gpg-подпись ставится только на исходники, но не готовую сборку плагина.
Буквально сейчас в рассылке обсуждается, что https — полумера, подпись на сертификат выдаётся коммерческими компаниями, при взломе сайта пакет могут подменить и сертификат тут не поможет (а вот gpg-подпись помогла бы), копии плагина на зеркалах мозиллы вообще модифицируются мозиллодержателями без ведома авторов — туда вставляются уведомления о совместимости с новыми версиями FF, так что подпись там не применить.
Пока с https://torproject.org и подпись сравнивать вручную, вот по этой ссылке[link1] можете увидеть, что они стали выкладывать подпись только вчера.
unknown, прошу прощения за тупость, а как сравнивать вручную?
У меня вот что выходит:
Гость (23/01/2010 22:39), скачайте по ссылке .asc-файл.
SATtva, я его скачал, а он не хочет импортироваться:
Там походу подпись какая-то неполная:
1. Скачайте .xpi и .asc нужной версии плагина.
2. Положите оба в один каталог.
3. Сделайте gpg -d filename.asc
И ключик ещё как-то надо проверить ;)
У меня такой отпечаток отображается:
BECD 90ED D1EE 8736 7980 ECF8 1B0C A30C DDC6 C0AD
И ключик где брать?!
Скачаем ключ
Никем из разработчиков его ключ кстати не подписан, придётся доверять по факту того, что скачали с https сайта. Мог бы автор TB (Майк) Роджера попросить подписать свой ключ. Похоже, нет его и среди разработчиков Debiana, иначе он бы получил кучу подписей из большой связки и входил в debian-keyring, что объясняет также отсутствие готовых актуальных пакетов с TB для Debian.
Теперь можно проверять, если оба файла лежат в одной директории:
Всё-таки подписывались плагины раньше. Это только даты у файлов на сервере вчерашним числом.
P. S. Гость, который ставит TB на Debian — успехов в дальнейшем изучении gpg. Читайте manы, задавайте вопросы в подходящих ветках форума.
Майк писал в рассылке, что ему было лениво выкладывать подписи. И это разработчики системы безопасности! Что мы после этого можем требовать от остальных? :-)
Вот потому у нас такие системы безопасности и вот такой оупенсорц, for fun. Для нас это – рабочий инструмент, а для них – искусство (читай развлечение или просто работа). OpenBSDшники писали тоже, чтобы не спамили PGP-подписями текста в рассылке, ибо annoying.
Чтобы каждый раз это не выслушивать, можно и подписать:
Лучше оставить как есть, просто спокойно относиться, зная что эта надпись означает. Вдруг при очередном обновлении этого ключа у вас к нему построится цепочка доверия?
Если вы в сети доверия на участвуете, то это не актуально, как я понимаю.
У автора топика личной сети доверия может и не быть, но он использует дистр Debian, поэтому может поставить пакет Debian-keyring, т.е. от ключа, которым заверен дистр (уж ему то так или иначе придётся доверять) через ключи всех разработчиков протянется большая сеть доверия. Если разработчик какого-то пакета пересечётся с коммандой Debian, то он может оказаться в этой сети доверия.
У Роджера такой отпечаток? Он им сырцы подписывает.
Команда, по ходу дела, не верная: единицу надо опустить. И ещё вопрос такой: если был выбран уровень сертификации 1 и им уже подписан ключ, то как потом сменить его в своей связке на 2ой?
Решил найти changelog для tor, чтобы поглядеть что поменялось при переходе от 22ой к 23ей версии. Задача оказалась отнюдь не тривиальной, в итоге нашлось гуглом, но доступ туда только по http: Tor ChangeLog[link2]. С основной страницы сайта проекта, я так понял, туда попасть нельзя :-( И то до конца не уверен, что это постоянный адрес changelog'а. Может быть стоит внести эту ссылку сюда на сайт? Всё же полезная штука, чтобы быть в курсе событий.
У меня на связке такой.
Что там мутят с ключами, используемыми для подписей Tor-Browser'а? Раньше всё было нормально:
Было бы хорошо иметь на pgpru.com подписанный ключами участников хэш от списка PGP-ключей, связанных с torproject'ом: доверять https'у в таких делах (первое получение ключа) нельзя, а так была бы хоть какая-то дополнительная проверка.
gpg --list-sigs показывает, что ключ Себастьяна заверен ключами таких людей[link3], как: Andrew Lewman, Jacob Appelbaum и собственно Erinn Clark. Верить или нет заявлению в блоге, что ему доверена сборка по причине отъезда Эринн (при том, что он и так собирает obfsproxy для TBB) — другой вопрос. Например, у меня ключи людей из этого списка[link4] уже были, кто они такие я уже знал до этого и только на SSL конечно полагаться не стоит.
Если используете Linux/Debian, то установите пакет с подписями всех дебьяновских разработчиков, среди них будет и Peter Palfrader, а от него по проверке подписей можно установить доверие ко всем ключам торпрожекта. Т.о. доверие ко всем пакетам в системе будет основано на доверии к вашей копии дистрибутива, т.к. они все проходят проверку gpg-подписи.
Средство обхода цензуры, блокирующей SSL-соединения (соединения с узлами сети Tor).
Спасибо! Это именно то, что хотелось услышать. Просто далеко не все регулярно читают блог torproject'а...
Согласен, но, кстати, наличие подписи на ключе не так-то много удостоверяет. В задумке подписи подразумевается, что её сделавший в той или иной степени поручился, что указанное в key id лицо (имя/фио/мыло) — действительно владелец им подписанного ключа. Само по себе это не делегирует каких-то дополнительных прав. К примеру, если лицо X имеет право на подпись какого-то минорного прикладного пакета в Debian, а оно вдруг внезапно подписало важный для меня пакет Y, у меня естественно возникнут вопросы, которые одним лишь фактом того, ключ X подписан главным ключом Debian, не разрешаются. Собственно, нечто подобное как раз и произошло в контексте TorProject :) К тому же, всегда есть параноя на предмет: допустим, злоумышленники похитили приватный ключ одного из разработчиков Tor, тогда как далеко они могут с ним зайти?
Вы правы. По-хорошему, ситуацию должен бы разрулить ещё и кто-то из лидеров проекта, заверив это уведомление.
На всякий случай, пользователи Debian/Ubuntu, подключившие репозитории торпроджекта могут поставить пакет deb.torproject.org-keyring и прописать в /.gnupg/gpg.conf опции:
Это для того, чтобы не следить за всеми обновлениями ключей в торпроджекте вручную.
Захожу в Tor через TB, пишет Сношу всё нафик, качаю новую версию tor-browser-gnu-linux-i686-2.2.35-8-dev-en-US.tar.gz, распаковываю, запускаю, а он снова при запуске пишет это же предупреждение. Думаю, может локальный глюк какой... снова перезапускаю, и снова это же предупреждение. Это у меня одного так?
Нет[link5], но обновиться до 2.2.35-9 прийдётся[link6] (но проще поправить скрипт)
Его же ещё нет :) Дело исключительно в предупреждении, или он в каком-то особом дебаг-режиме стратует? Есть чего бояться?
Это два разных бага, в первом случае бандл "думает" что на сайте есть какая-то более секурная версия, это косяк на сайте. Второй баг это включенный дебаг режим для видалии, вне зависимости от опций, это косяк в скрипте start-tor-browser. В дебаг режиме пишется всё что "думает" и "слышит" видалия, в том числе адрес запрошенный браузером. Теперь главный вопрос, у всех ли это пишется на шифруемый раздел (накопитель) или потом надо будет решать вопрос удалять или вайпить и если вайпить, то как это сделать надежно если у вас sdd (да и для hdd это всё равно вопрос). Фобос например заметил эти логи когда их размер перевалил за 2 гига, и то после того как модеря коменты к блогу заметил сообщение про это.
Получается что без вашего спроса и "тайно" пишут все посещенные вами адреса. Можно ёрничать про локалхосты, и ваш дом моя крепость, но факт — такие логи в вашей крепости это частичное разрушение свойств прямой секретности гарантируемых тором.
если ssd или hdd, то IMHO никак, кроме как RAMDISK в ОП. А можно ещё ACARD ANS-9010+VBox либо LiveCD.
С ныне последней 2.3.25-4 опять рецидив?[link8] Сегодня, кажись, уже исправили свой скрипт на сервере, а вчера весь день ругань шла, и это при том, что версия вышла далеко не вчера, а намного раньше. Оупенсырец такой оупенсырец... Более того, ввиду нововведения с анимацией иконки-луковицы [1[link8], 2[link9]]*, не заметить эту багу было нельзя. Как они вообще могли такое зарелизить? Сами ни разу не запускали TBB, который разрабатывают?
Ещё решили, что нечего давать народу много прав и убрали почти все настройки из вкладки security[link10]. Меня, например, категорически не устраивает качество альтернативных поисковиков, я предпочитаю рестартнуть цепочки или надеть на себя новую личину, чем видеть этот бред в поисковой выдаче. Как теперь пользователи будут решать эту задачу, когда нужная настройка исчезла? Или TBB-девы договорились с гуглом о незабанивании?
*Make Torbutton icon flash a warning symbol if TBB is out of date (closes: #7495).
Новый TBB надо распаковывать, снося старый, а не поверх, как можно было делать раньше. Тогда часть глюков исчезает.
Для смены цепочек можно использовать видалию. Для смены "личины" можно рестартовать Torbrowser и менять размер окна при старте. Если он у вас отвязан от TBB и настроен на прозрачную торификацию[link11], то можно зайти в about:config и во всех полях с адресом торпроджекта поставить about:blank*. Тогда он не будет искать и проверять автоматически наличие обновлений при старте. Добавьте адреса из этих полей в закладки для проверки вручную.
Проблемы со скриптами на сервере — это у них хроническое и по несколько суток не исправлялось и при других релизах.
Какие вкладки в security вам были нужны? Их кастомизация ничего полезного вроде не приносила.
У меня новый TBB тоже вызвал слегка недоумение, особенно при его потугах проверить работу в прозрачной торификации, но вроде настроил. Работает без глюков. Зато там много интересных штук в плане утечек потенциально деанонимизирующих сведений пофиксено.
*Персональное решение, неофициальная рекомендация. Пока не знаю, чем это может грозить.
Всегда только так и делал (снося старый).
Я сейчас писал про стандартный случай, т.е. когда всё искоробки, всё, как рекомендуется Tor Project'ом: скачал, распаковал начистую, запустил.
Security → Headers → Automatically use an alternative search engine when presented with a Google Captcha [снять галку]. В принципе, обходной манёвр потенциально есть [ещё не тестировал]: если произошёл редирект на alternative search engine, то меняем личину и пробуем снова [повторять до сходимости].
Тоже заметил в описании новости о релизе.
P.S. Unknown перестал спать ночами, к чему бы это?
Было бы хорошо, если бы вы упомянули об этой тонкости в своём тексте про прозрачную торификацию или хотя бы сделали кросслистинг, добавив комментарий к той новости на этот ваш пост. Если кто-то время спустя будет настраивать, он всех тонкостей, обсуждение которых имело место в разных ветках и в разное время, не припомнит.
Изменения внесены.
Интересно, что какие-то сторонние разработчики делают сборки готовых пакетов для Red Hat с раздельным использованием TorBrowser, Vidalia, системного Tor и с SELinux-модулем для этого.
Спасибо.
Почему такие вещи не инвариантны по отношению к дистру? SeLinux — патчи к ядру, а ядро везде одно и то же, как и прикладной софт.
SELinux — это давно уже часть мейнстримного ядра. А вот с прикладным софтом беда. Основные разработчики проекта в Ред Хэте и сторонние разработчики также поставляют патчи под него. Получается сразу несколько дистроспецифичных зацепок, которые не задуманы специально по дизайну и устранимы в каждых последующих обкатанных версиях.
В разных дистрах — разные версии обычных программ или по-умолчанию скомпилены немного иначе, а модули защиты программ и демонов могут поддерживать не все версии. Сконфигурировать, перекомпилировать и оттестировать версии модулей могут не все сборщики других дистров, поэтому даже проверенные и собранные в бинарном виде якобы стабильные модули работают не всегда.
Red Hat хочет безопасный десктоп со всевозможными SELinux-контейнерами, песочницами, псевдовиртуалками и пр. На основе понятно Гнома. В принципе, гвоздями это к нему не прибито, но пользовательские модули для защиты рабочего окружения работают только при входе в иксы через gdm, хотя запускать из него можно дальше не гном, а любой другой оконный менеджер и всё будет работать.
И таких непофиксенных мелочей остаётся много, потихоньку их выкорчёвывают, но сборщики других дистров обычно в этом плохо шарят. Даже кое-где в утилитах не вырезаны из манов рэдхатоспецифичные вещи и пр.
Возможно, на гугл можно зайти по какой-то специфической прямой ссылке, при возникновении на которой капчи, торкнопка её не перехватывает. Хотя немногочисленность такой тактики запросов из тора будет профилировать пользователя перед гуглом.
Вот не нравиться мне что они последние версии firefox для TBB берут. А они все фичастее и тяжелее. У меня на старом нетубке уже TBB с трудом запускается, выжирая почти весь процессор.
Это вынужденное. В старых дырки никто не правит.
Да не сказал бы что новые версии firefox тяжелы. На моем старом компе 28. гц 1 ядро, 440 MX 128 mb видюха новый firefox работает быстрее. Да и на нетбуке 1.3 гц 2 ядра все шустренько. Другое дело, что у меня дополнений много и от этого бывают микрозависоны.
Тут скорее всего дело в незаточенности под конкретное железо. Бывает так что на определенных видюхах или процах тормоза. Про linux в котором firefox в 3 раза медленнее (на разных машинах наблюдал) не говорю (перепробовал всё от debian до ubuntu, от lxde до KDE и разные пакеты облегченные для netbook и настройщики).
Который в TBB? Это потому, что он portable. :) Родной firefox побыстрее скачет.
/comment50793[link12]:
Век живи – век учись? Нутром чувствую, что Тед Уангст[link13] был прав.
Я один такой, кто считал, что --list-sigs проверяет статус подписей, т.е. если подпись не скреплена нужным ключом, её PGP-пакетом не повесить на чужой ключ? Сами по себе keyid-ы, висящие на ключе в качестве подписей, оказывается, не имеют никакой валидности.
Анализируя старый ключ Tails, заметил аномалию:
Эти же подписи при --list-sigs показываются как самые обычные и ничем не примечательные:
Что такого могло произойти, что автор ключа при навешивании собственной подписи на свой же ключ сделал её невалидной? Есть простой способ посмотреть точное время навешния подписей с точностью до секунды?