Инструкция для чайников. Криптоанонимный IM TorChat
В продолжение чайниковой темы.
Tor Chat – децентрализованная анонимная криптозащищенная система обмена мгновенными сообщениями, построенная на базе анонимизирующей сети Tor. В отличие от аськи и других подобных систем, в Tor Chat нет никаких посредников (окромя технической инфраструктуры самого Tor), не надо нигде регистрировать номера и логины и зависеть от каких-то внешних центральных IM-серверов. Связь устанавливается непосредственно между собеседниками, причем изначально гарантируется анонимность и полная криптозащита переписки. Все это вместе с простотой использования должно понравиться анонимным домохозяйкам.
Децентрализованная криптоанонимная система обмена мгновенными сообщениями TorChat. Инструкция для windows
http://xmail.net/teapot/torchat/
Скачать zip-архив инструкции
комментариев: 450 документов: 10 редакций: 13
Это ж до какой степени надо быть слепым, если даже на этой странице несколькими постами выше упомянут ricochet:
В любой заметке в tor-блоге про tor-messenger ricochet также, как правило, упомянут. На форуме есть отдельный топик на эту тему. Ничего этого не видеть, не гуглить, не искать, не читать, но постоянно с упорством, достойного лучшего применения, задавать один и тот же вопрос 5 раз? Ломиться в открытые ворота?
Не всё так просто. TorChat и ricochet имеют один существенный минус.
Обычный джаббер-сервер на скрытом сервисе.
Это больше упущение разработчиков, но остаётся надеяться, что когда-нибудь и это доведут до ума. Разработчики SubgraphOS не зря решили сделать свой TM-подобный мессенджер — CoyIM, намертво вбив ассоциацию между доменными именами и onion-сервисами джаббер-серверов, убрав все "лишние" настройки. Местами переборщили или ещё не доделали – в CoyIM выбор из нескольких предзаданных джаббер-серверов (свой не указать), нельзя включить запись истории, нельзя поменять IP:порт своего Tor-сервера. Тем не менее, это близко к тому, что хотят юзеры: скачал, запустил, указал пару настроек, и всё заработало. CoyIM можно установить на сторонний Linux.
Tor browser – это не просто firefox, запущенный через тор. Точно так же TM – это не просто instantbird, запущенный через тор. Это отключение множества потенциально опасных и деанонимизирующих XEP-ов и настроек, а также так необходимая унификация всех пользователей. Кроме этого, многие джаббер-клиенты (включая Psi и gajim) частично посылают трафик (DNS, но, возможно, не только) в обход тор, а потому без надёжно настроенного фаервола, который заблокирует утечки, их не рекомендуют использовать.
комментариев: 39 документов: 4 редакций: 1
Что ж вы так нервничаете-то?
Да, действительно этот Ricochet мне попадался несколько раз. Но не столь часто, как TorChat, который везде на слуху, его и ругают, и некоторым образом сравнивают с ним другие проекты, и по нему даже сделали аудит безопасности.
Популярность и известность Ricochet существенно ниже, имхо.
Не слишком старый обзор о нем сообщает:
Так чем же этот Ricochet лучше, что на него стоит обратить внимание?
Я ведь не просто интересуюсь "Что там создали в мире из P2P через Tor?", а ищу надежный, зарекомендовавший себя продукт.
Хотя в последнее время возникли сомнения в безопасности чата по P2P.
Поскольку, кмк, стоит одному из участвующих в чате клиентов изменить свой клиент, или заразить его зловредом, как безопасность всех участников накроется медным тазом.
Хотя это только мои догадки, возможно, я и неправ.
комментариев: 450 документов: 10 редакций: 13
Что же тогда молчите?
Проект TorChat заброшен. Забудьте о нём. С последними версиями тора он вообще работать не будет, насколько я слышал.
Хотя бы тем, что тор-проект его официально признаёт напару с tor messenger-ом и пиарит, в то время как отношение разработчиков тора к торчат было таким:
Тогда идите в другую галактику, в этой надёжных и зарекомендовавших себя продуктов нет. Начнём с того, что до недавнего времени (а, может, и до сих пор) в логах тор постоянно писалось при старте:
То, что это формальное предупреждение номинально убрали, ещё ни о чём не говорит. Дальше можно не продолжать.
И это тоже, но и без уязвимости в самом клиенте проблема остаётся. Обсуждалось более подробно. Хороший выход – проект типа pond. Сам pond практически заброшен, и он не для мгновенной передачи сообщений.
комментариев: 39 документов: 4 редакций: 1
Ясно. Спасибо за столь развернутое пояснение.
По Рикошету молчал по причинам, которые уже описал, впрочем, это не столь неважно.
Так чем вы порекомендуется воспользоваться на данный момент – Tormesenger, или Ricochet, и почему? :)
Кстати, замечания к TorChat в основном базируются на том, что он заброшен. Но это как бы субъективный фактор, и если найдется настойчивый разработчик, который поднимет упавший флаг, то появится надежда, что часть недостатков будет устранена.
Хочу спросить по упомянутому вами недостатку:
Я его нейтрализовал (во всяком случае надеюсь, что это так) таким приемом:
– сначала обмениваюсь с собеседником ID, пускай даже по открытому каналу
– затем соединяемся уже по этим ID (по TorChat или ему подобным)
– по торчатовому каналу обмениваемся новый ID, и уже по нему ведем реальную беседу.
Таким образом, неприятель знает только первую пару ID, которая не используется, и пусть ее атакует сколько заблагорассудится.
Как вам такой прием?
комментариев: 450 документов: 10 редакций: 13
У каждого своя ситуация, свои модели угроз и свои требования. Единую универсальную рекомендацию дать затруднительно. Анонимное общение с полностью двоеренным абонентом – это одно, анонимное общение с котом в мешке – другое.
Критика систем с промежуточным сервером сводится к проблемам отказа и сбору метаданных. Проблема отказа решается заведением подстраховчных аккаунтов на других серверах. Проблема сбора метаданных частично решается заведением анонимных аккаунтов, по одному на каждого собеседника. Всё, что видит промежуточный сервер – это то, что два анонима в такие-то моменты времени общаются с такой-то интенсивностью, но он не может сказать, ни где они находятся, ни кто они такие. Это XMPP на onion через tor messenger.
Системы без центрального сервера (ricochet) теоретически изящней и проще, но делать из своего ПК сервер – такой удар по анонимности, который трудно чем-либо оправдать, особенно в случае непредсказуемого абонента с другой стороны. Теоретически можно запускать такой клиент на удалённом сервере, доступном как onion, и пересылать сообщения себе и от себя на этот удалённый сервер по иному каналу. Это подстрахует от случая лёгкой деанонимизации onion-сервера, но в плане настройки и нужных ресурсов выглядит громоздко. Кроме этого, через удалённый сервер переписка будет проходить в расшифрованном виде, что тоже нехорошо.
Однако, последняя схема при желании доводится до ума, заодно решая и проблемы с VPN, которые все мутят, кто во что горазд. Суть проста: анонимно покупается сервер на хостинге, на нём запускается приватный скрытый сервис (onion). Связь с этим сервером делается только через этот скрытый сервис. Можно сделать так, что он будет доступен как SOCKS-прокси. Всё, что будет завёрнуто в этот SOCKS, будет передано по onion-протоколу на этот сервер и отослано в сеть оттуда. В частности, так можно запустить ещё один тор-клиент, уже второй, через этот же SOCKS. Второй тор-клиент будет зашифровывать и расшифровывать трафик локально, но в сеть он будет выходит через означенный приватный onion-сервис. Получается двойное заворачивание в тор, но без традиционных присущих ему проблем, когда такой трафик светится на всех экситах. Путь трафика выглдяит так:
ПК -> Тор-сеть через первый тор-клиент -> Приватный onion -> Тор-сеть через второй тор-клиент -> Интернет.
Основной минус – создание точки в сети, пусть и анонимной, через которую проходит весь трафик. Сама точка при дефолтных настройках будет немного специфична, потому что с точки зрения сетевой активности она будет выглядеть так, будто на ней запущено 2 разных тора, т.е. больше гуард узлов и больше служебных соединений. В реальности на ней будет только один тор, а второй – просто проксирование чужого трафика.
Однако, по крайней мере, эта схема страхует от типовых фейлов тор-протокола. В частности, атака от 2014-го против этой схемы не сработала бы: при атаке на гуарды первого тора – то, что видит ISP, – если и можно что вычислить (для приватного сервиса это значительно трудней), то только то, что трафик идёт на IP, где крутится приватный onion. Само по себе это мало что даст, т.к. весь трафик на последнем шифрован вторым тором, идущим внутри первого. Аналогично при атаке со стороны удалённого сайта можно только выяснить, что трафик идёт с IP, где крутится приватный onion-сервис. Легко соединить всю цепочку из двух торов воедино не получится никак. Во всяком случае, при атаках, применяемых массово, никто такие схемы раскручивать не будет.
На втором торе можно спокойно крутить ricochet. Даже если через него будет деанонимизация, она приведёт атакующего с приватному onion-сервису. Шифрование будет оконечным, всё ОК.
При потеряной голове о волосах не плачут. Нормальный проект, не мёртворождённый, делается совершенно иначе: сначала публикуется теоретическая академическая работа со всеми обоснованиями протокола, потом пишутся спецификации на протокол и только потом код. Разработка ведётся открыто, есть публично доступные планы, roadmap проекта и багтрекер. Так ведётся нормальная разработка. По крайней мере, с чего бы автор ни начинал, он должен сделать всё из вышеперечисленного. Это требует определённой квалификации и некоторого опыта. Нужны как фактические знания, так и умение их представлять в конвенционально принятом формате – академических работах.
Всё остальное не хочется даже обсуждать. Надежды, что кто-то возьмёт кулхацкерский проект и доведёт его до ума ни на чём не основаны. Людям со знаниями будет значительно проще написать свой проект со своим обоснованным протоколом с нуля, чем тащить за собой обратную совместимость с сомнительной поделкой. Например, сам тор худо-бедно нормальной схеме разработки соответствует, а торчат и рикошет – нет. Однако, в силу вышеозвученных причин, если выбирать между этими двумя, то лучше выбрать рикошет.
С точки зрения хорошего подхода – очередное нагромождение, возможно, иногда оправданное в этом слишком неидеальном мире. Как миниум, при обмене по открытому каналу возникает риск MITMа, а тогда может быть отMITMен и второй ваш канал. Советуют иметь PGP-ключи и обмениваться шифрованными и подписанными данными об ID для таких сервисов. Однако, PGP требует установления доверия, что не всегда можно сделать, и в целом вредит анонимности. В общем случае у задачи нет хорошего решения, так что ваш метод может быть оправдан. По крайней мере, хуже это нагромождение не сделает.
комментариев: 39 документов: 4 редакций: 1
Из него делаю вывод, что нужно заканчивать с метаниями между ними и остановится на TorMessenger как наиболее надежном и перспективном.