Всё о TBB (Tor Browser Bundle)

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

Можно поставить Tor узел на сервере провайдера, но только в очень ограниченном числе и только западных стран, по пальцам одной руки пересчитать. В Китае например вы не то что Tor узел, свой сайт на сервере открыть не сможете, даже если вы китаец и предъявили паспорт.

Посольства обычно расположены в столице, а город узла указан на сайте статистики Тор (видалия его не кажет), но кроме них в любых городах могут быть западные фирмы и западные спецслужбы под их ширмой. Даже в тех нескольких суверенных станах где есть интернет, западные фирмы работают по всей стране, единственное исключение – КНДР, но там вы вообще ничего открыть не сможете, даже для чисто внешнего пользования, Северная Корея в противостоянии Западу давно не торт, не то что при Ким Ер Сэне.

Для установки злонамеренного узла, целью которого является съём трафика в надежде кого-то в нём выловить путём подсчёта корреляций, такие предосторожности не нужны. Большинство тор-узлов вообще стоит на хостинг-площадках, так что их владельцы физически их не контролируют. Не надо быть посольством для запуска злонамеренного тор-узла. И вообще, сам сервер может находиться в одной точке планеты, а его айпишник випиэниться на другую. Сила тор-сети в её разнообразии, а не в том, что можно отличить «хороший» узел от «плохого» и получить себе больше шансов в этой лотерее.

В новом стабильном TBB действительно не работает предпросмотр в форуме. Более того, у меня все коменты теперь отображаются как прочитанные, как будто кто-то украл пароль и регулярно смотрит форум под моим логином. Возможно это проблема в исходном FF — он тоже на других сайтах выдаёт некоторые глюки.

Может, проблема в NoScript?

Это 4.0.6?

Это паронойя) Она такая..

Да, но важно, что под Гостём эта проблема у меня вообще не наблюдается.


Не замечал такого.


Это был я.


Пока не замечал других глюков.

А теперь заметил (впервые). Проблему подтверждаю.

Идёте на сайт https://torstatus.blutmagie.de, там всё можно отсортировать не только по странам и скорости, но и по ряду других параметров.

Есть замечательные файлы /etc/machine-id и /var/lib/dbus/machine-id. В них содержится уникальный идентификатор машины. Это уже само по себе лол, но ещё больший лол в том, что они зачем-то нужны TBB через dbus. Если контент этих файлов стереть, при старте tor browser пишет

process xxxxx: D-Bus library appears to be incorrectly set up; failed to read machine uuid: UUID file '/etc/machine-id' should contain a hex string of length 32, not length 0, with no other text See the manual page for dbus-uuidgen to correct this issue.

Сам dbus не установлен, от него только либы стоят зависимостями. Ворнинг не мешает TBB запускаться.

Привет от мистера Поттеринга. Удалить эту гадость нельзя — dbus и ПО, у которого он в зависимостях, могут попадать, — но можно перезаписывать на этапе перезагрузки или вообще по крону (только в последнем случае придётся ещё и dbus перезапускать):

UUID_FILE=/etc/machine-id rm -f $UUID_FILE && dbus-uuidgen --ensure=$UUID_FILE

В /var скорее всего лежит симлинк на реальный файл в /etc, но следует проверять — могут быть нюансы между дистрибутивами.

Про историю этого говнеца можно почитать здесь:

I am certainly not a Poettering fan, but I must say that this idea of a machine-id file came from Havoc Penninton, not LP. What I can see from the commit messages in the git repository is that LP made it so that dbus would read from /etc/machine-id if /var/lib/dbus/machine-id is not available. More systemd "joy". Havoc! What an appropriate name.

<...> in the absence of an /etc/hostid file, which is almost certainly not present, glibc defaults to returning the IPv4 address of the machine. Seems pretty reasonable to use that value and call it a day — but they don't.

Да, может быть проблема с жирными десктопными приложениями, но вот мне, например, удалось dbus удалить, от него только либы остались, поэтому указанный файл никем не перегенерируется. Не заметил, чтоб что-то перестало работать из того, что работало раньше.

Там вот это интересно:

When Intel came out with their cpuid, there was outrage (and workarounds), but when an open source project does something similar, everyone just accepts it like sheep.

Ага, но никто не говорил, что GPL-код влечёт за собой GPL-политику.

Arch did it on every boot i.e. generates new machine-id for every new session.
On shutting Arch down this file truncated (zero-lenght)

Потом:

This is what Havoc should have done: make it so that all instances of dbus-daemon remember the machine ID so they they have to obtain it only once. What they do the first time they are asked for the value depends on whether the instance of the daemon is the system instance or not. The system instance would generate a new random value when it has no value stored, and the other instances would query the system instance when they are first asked for the value. This way all the instances of dbus-daemon on a machine would report the same machine ID—just as they are supposed to do. This would also avoid the perils of relying on a file:

1. Exposure of the machine ID to anyone who happens by a file containing it (now in multiple locations—yay!)
2. Protection from inadvertent problems when, contrary to the intent of the dbus maintainers, two hosts share the same /etc directory (my way ensures each host generates its own ID even when files are shared)
3. Elimination of the failures that happen when both those machine-id files go missing

There would be one more benefit: no need to have a dbus-uuidgen or a systemd-machine-id-setup binary.

но:

What I found by testing confirms what I found by inspection of the code: dbus re-reads the machine-id file every time a client requests the value. It does not memorize it at all. There are two implications from this.

1. You can change the machine ID on the fly whenever you want without having to restart dbus.
2. If the machine-id file goes away when dbus wants to read it, there is a problem.

Не поймёшь, кому верить.

У меня не симлинк.

Автор исходит из своего представления о том, как должны работать системы: анонимность должна быть по умолчанию, а тем, кому это действительно нужно, создадут свой /etc/hostid, чтоб система, как говорится в man machine-id, оставалась однозначно идентифицируемой при смене IP-адресов, железа и множества софтварных модификаций.

Автор machine-id исходят из иных представлений: всё должно работать и быть включенным по умолчанию, чтобы разработчики не ломали себе голову, настроил ли юзер соответствующий софт корректным образом, а те, кому нужна такая экзотика, как «анонимность», находятся в меньшинстве — вот пусть они, как меньшинство, и ломают себе голову, как это сделать, а не большинство будет подстраиваться под них. Однозначная идентификация системы — полезная фича для межпрограммного взаимодействия, а чем больше фич, упрощающих жизнь программисту, тем лучше. Что сейчас делает трояноподобный Linux-софт, чтобы отзвониться домой зафиксировать тип системы, на которой запущен? Все занимаются костылестроением: взять те-то файлы в /etc, похэшировать это с такой-то инфой... каждый городит свой идентификатор (в сети можно найти обсуждения разработчиков на тему). Но теперь пришёл ЛП («Л» — от слова «леденящий») и сделал всё хорошо: вместо массы доморощенных костылей по слежке за пользователями теперь будет использоваться стандартный ИНН идентификационный код системы, который будут вносить в паспорт. Главное — что всё стандартизировано, всё под GPL, а политика использования кода неважна.

Note that the machine ID historically is not an OSF UUID as defined by RFC 4122, nor a Microsoft GUID; however, starting with systemd v30, newly generated machine IDs do qualify as v4 UUIDs.

В MS же не дураки сидят, просто так устроен мир, что то, что хорошо для широких масс, никогда не будет хорошо для параноиков.

Снова вопросы с ExitNodes.
Если я пропишу в torrc что-нибудь типа ExitNodes {kr} то будет возможно профилирование по входному и выходному конфигу и всех кто с kr (а тем более если с конкретным айпи)?
++зы:
По мне так если по уму, то опция ExitNodes должна срабатывать только при выборе конечных нод самим софтом, методом перебора (хотя бы как опцию) и не как условие, а как "переинициация цепочки" до момента пока внешняя нода не будет удовлетворять прописанному в этом параметре. Тогда нельзя будет точно сказать, что это железная конфигурация, а не может быть кто-то жмет кнопку "обновить цепочку".++

Любые специфические настройки сужают множество поиска, т.е. ведут к профилированию. Насколько это ухудшение анонимности оправдано другими возможными плюсами — решать вам.


Есть указание Exit-ноды на лету через псевдодомен .exit [1], [2], [3], [4]. Судя по всему, опция до сих пор поддерживается в Tor'е, но для её включения, возможно, нужны какие-то ручные действия с конфигом torrc.

P.S. Для исправления потока сознания, чтобы вас хоть кто-то здесь понимал, в шапке последнего вашего поста в треде всегда есть ссылка правка.

А если machine-id найти в исходном коде и посмотреть что дальше с ним делается?
Еще я обнаружил что в новом 5.0.2 TB check.torproject.org, auditmypc.com и другие похожие сайты показывют разные айпи, в своем большенстве айпи принадлежат tor, но бывает и свосем неизвестно какие. Каждая новая вкладка создает новое соединение tor?

Поищите, узнайте. Потом нам заодно расскажете.

Последняя стабильная версия — 5.0.3.

Не помню точно. Кажется, там более хитрая изоляция с делением по цепочкам, но какая-то изоляция есть точно [1], [2]. Если два одинаковых домена в разных вкладках открываются, то цепочки вроде будут одинаковыми(?).