Звук в браузере
Зашел через заторенный огнелис с включенным торббаттоном (дефолтные настройки) и выключенными 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
комментариев: 9796 документов: 488 редакций: 5664
Для смены цепочек можно использовать видалию. Для смены "личины" можно рестартовать Torbrowser и менять размер окна при старте. Если он у вас отвязан от TBB и настроен на прозрачную торификацию, то можно зайти в 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 перестал спать ночами, к чему бы это?
Было бы хорошо, если бы вы упомянули об этой тонкости в своём тексте про прозрачную торификацию или хотя бы сделали кросслистинг, добавив комментарий к той новости на этот ваш пост. Если кто-то время спустя будет настраивать, он всех тонкостей, обсуждение которых имело место в разных ветках и в разное время, не припомнит.
комментариев: 9796 документов: 488 редакций: 5664
Изменения внесены.
Интересно, что какие-то сторонние разработчики делают сборки готовых пакетов для Red Hat с раздельным использованием TorBrowser, Vidalia, системного Tor и с SELinux-модулем для этого.
Спасибо.
Почему такие вещи не инвариантны по отношению к дистру? SeLinux — патчи к ядру, а ядро везде одно и то же, как и прикладной софт.
комментариев: 9796 документов: 488 редакций: 5664
SELinux — это давно уже часть мейнстримного ядра. А вот с прикладным софтом беда. Основные разработчики проекта в Ред Хэте и сторонние разработчики также поставляют патчи под него. Получается сразу несколько дистроспецифичных зацепок, которые не задуманы специально по дизайну и устранимы в каждых последующих обкатанных версиях.
В разных дистрах — разные версии обычных программ или по-умолчанию скомпилены немного иначе, а модули защиты программ и демонов могут поддерживать не все версии. Сконфигурировать, перекомпилировать и оттестировать версии модулей могут не все сборщики других дистров, поэтому даже проверенные и собранные в бинарном виде якобы стабильные модули работают не всегда.
Red Hat хочет безопасный десктоп со всевозможными SELinux-контейнерами, песочницами, псевдовиртуалками и пр. На основе понятно Гнома. В принципе, гвоздями это к нему не прибито, но пользовательские модули для защиты рабочего окружения работают только при входе в иксы через gdm, хотя запускать из него можно дальше не гном, а любой другой оконный менеджер и всё будет работать.
И таких непофиксенных мелочей остаётся много, потихоньку их выкорчёвывают, но сборщики других дистров обычно в этом плохо шарят. Даже кое-где в утилитах не вырезаны из манов рэдхатоспецифичные вещи и пр.
Возможно, на гугл можно зайти по какой-то специфической прямой ссылке, при возникновении на которой капчи, торкнопка её не перехватывает. Хотя немногочисленность такой тактики запросов из тора будет профилировать пользователя перед гуглом.
Вот не нравиться мне что они последние версии firefox для TBB берут. А они все фичастее и тяжелее. У меня на старом нетубке уже TBB с трудом запускается, выжирая почти весь процессор.
комментариев: 1060 документов: 16 редакций: 32
Это вынужденное. В старых дырки никто не правит.
Тут скорее всего дело в незаточенности под конкретное железо. Бывает так что на определенных видюхах или процах тормоза. Про linux в котором firefox в 3 раза медленнее (на разных машинах наблюдал) не говорю (перепробовал всё от debian до ubuntu, от lxde до KDE и разные пакеты облегченные для netbook и настройщики).
Который в TBB? Это потому, что он portable. :) Родной firefox побыстрее скачет.
комментариев: 450 документов: 10 редакций: 13
/comment50793:
Век живи – век учись? Нутром чувствую, что Тед Уангст был прав.
Я один такой, кто считал, что --list-sigs проверяет статус подписей, т.е. если подпись не скреплена нужным ключом, её PGP-пакетом не повесить на чужой ключ? Сами по себе keyid-ы, висящие на ключе в качестве подписей, оказывается, не имеют никакой валидности.
Анализируя старый ключ Tails, заметил аномалию:
Эти же подписи при --list-sigs показываются как самые обычные и ничем не примечательные:
Что такого могло произойти, что автор ключа при навешивании собственной подписи на свой же ключ сделал её невалидной? Есть простой способ посмотреть точное время навешния подписей с точностью до секунды?