Voice over TOR
Предлагаю для тестирования кипто VOIP-утилиту для работы через TOR (в режимах TOR -> доменное имя и TOR->скрытый сервис). Переделал с старого PGPFone: заменил транспорт на TCP и добавил адаптивный буфер для компенсации высокого jitter в TOR-туннеле. Также добавил обмен сообщениями и файлами.
Win98-XP-7-8. Полностью портируема. Работает peer-to-peer (звонить на доменное имя или TOR-hidden service). Использует DH4096+3DES.
Приветствуются замечания и пожелания.
Сайт проекта http://torfone.org (англ./рус.), там же доступны исходники (Visual C 6).
комментариев: 393 документов: 4 редакций: 0
Никто не рад, но их умение решить вопрос оптимально с практической точки зрения, отделяя на данный момент основное для пользователя от второстепенного, заслуживает уважение. Например, мне гораздо приятнее пользоваться телефоном Donod C+ за $12, чем фирменным Samsung того же класса. Софт лучше, хотя по железу, конечно, гораздо хуже.
Я выше писал, что не разбирал подробно криптографию версии 7.6. Но, думаю, что в общем можно ответить "нет". Но это актуально при прямом соединении, т.к. при работе через Tor обеспечивается оконечное шифрование средствами Tor. Думаю, повода не доверть Tor нет?
В любом случае, я прикручу современную криптографию к Linux-версии вместе с возможность перехода на прямое UDP с автоматическим проходом NAT (Tor в качестве SIP).
У SpeakFrealy длинная история: сначала она развивалась автором на офсайте. В 2004 автор (John Walker) объявил об окончании поддержки проекта, и проект перешел на sourceforge.net в статусе коллективной разработки. Там же доступны исходные коды версии 7.6, более поздние патчи и т.д. Собственно, моя поддержка TCP и Tor – просто патч этой версии (ведь проекты подобного уровня не делаются за неделю с нуля).
В отличие от Циммермановского PGPFone, забытого почти сразу (он опередил время – ни пользователи, ни сети тогда были не готовы ни к VIOP, ни к шифрованию), SpeakFreely нашла практическое применение, и до сих порт используется в специфических коммьюнити как средство VOIP, хотя по уровню защиты уступает PGPFone (последний проектировался как часть пакета PGP, изначально заточен на безопасность).
Сразу после релиза Торфона ко мне начали обращаться с просьбой сделать поддержку TCP+SOCKS5 в SpeakFreely, причем практическая публика, думаю, связанная с какими-то политическими движениями.
Ну, и на других форумах были просьбы торификации именно SpeakFreely.
ПС: есть еще один незаслуженно забытый и раскритикованный Qt-проект I Hear U под Linux, работающий в т.ч. и через TCP. Я не пробовал его, но по идее статически линкованная версия должна работать и на Tails.
И когда это можно ожидать?
Забавный топик. Файловая система, тогда тоже должна быть аппаратной. Как марчить файлы, что бы они аппаратно были не стрираемы. В противном случае, защита на стороне файловой системы, программно делается. В любом получается случае, надо вокруг файловой системы плясать, и что бы её Windows/Linux читать умели. Зачем такой велосипед?
@gegel, а зачем этот Raw UDP/TCP, если название уже позиционирует разработку как прикладную к Tor – TorFone? Или здесь Tor – это что то другое?
А учитывая уже имеющуюся криптографию в Tor-e, Вы лишний слой добавляете? Связь между двумя onion доменами, для передачи видео, может лишь потребовать грандиозной работы в области сжатия этого видео.
комментариев: 393 документов: 4 редакций: 0
Понятие "аппаратный" относительное. Например, шифрование на ПЛИС – аппаратное? Но ведь ПЛИС все равно программируется. Тем более в данном случае – ведь используется микроконтроллер. Реализуется FAT. Защита программная, но не силами ОС, а в прошивке микроконтроллера, и написанной собственноручно, а не производителем флешки.
Tor дает ощутимые (пару секунд) задержки, и это весьма напрягает при общении. В серьезной модели угроз это оправдывается, но в большинстве практических случаев предпочтителен переход на p2p соединение после установки Tor-соединения, согласования ключей в нем и обмена инвайтами для прохода NAT. Естественно, p2p не дает анонимности, но в отсутствии сервера невозможно собирать метаданные и контролировать все в одной точке. Другой вариант – DHT, но Tor HS предоставляет коробочное решение.
К сожалению, не все так просто. В своих экспериментах с HS-соединением я заметил четкую корреляцию между потоком трафика и латентностью. Алгоритм Нагла на узлах продолжал работать, и TCP-пакеты переформатировались произвольно, буферизируясь сокетами узлов. Т.к. сжатие видео не бесконечно, то в любом случае единичной HS-соединие будет перегружено и даст значительную латентность, что вызовет неудобства в общении, особенно у той публики, кто в этом больше всех заинтересован.
Единтственный выход – использовать множество цепочек (и Tor-клиентов), разбивая видеопоток на небольшие фрагменты, маршрутизируя их отдельно и собирая на приемной стороне. Но тут повышается вероятность отказа всей системы в случае отказа всего одной цепочки. Поэтому придется использовать соответствующее кодирование видео (потеря или задержка фрагмента данных должна приводить к потере только одного фрагмента кадра), а также предусмотреть алгоритм исключения медленных цепочек, т.к. самая медленная и будет определять общую латентность. Для уменьшения вероятности отказа надо предусмотреть дублирование проблемных (вновь созданных, нестабильных) цепочек.
Только таки способом можно получить то, что ожидает пользователь.
:)))
А под Linux полностью через Tor оно уже работает? Т.е., чтобы не только согласование параметров, но и весь трафик шёл через Tor.
комментариев: 393 документов: 4 редакций: 0
Да, под Linux именно так (и пока только так) оно и работает:
Скачиваем последний TBB, распаковываем в папку. Открываем файл \tor-browser_en-US\Data\Tor\torrc и добавляем строку:
HiddenServicePort 17447 127.0.0.1:17447
Запускаем ./start-tor-browser, дожидаемся подключения. Открываем появившийся файл \tor-browser_en-US\Data\Tor\hidden_service\hostname и копируем созданный ваш onion-адрес.
Скачиваем патченую SpeakFrealy7.6, распаковываем в отдельную папку. Запускаем ./start
Для исходящего звонка вводим onion-адрес абонента с восклицательны знаком вначале и жмем ввод. Для приема входящего звонка жмем ввод.
Для тестирования жмем ввод и слышим себя.
Если что-то не так, опишите ошибку, посоветую.
2 gegel: а под Ubuntu Touch заработает?
комментариев: 393 документов: 4 редакций: 0
Я же не ясновидец. Для того и выложил, чтобы попробовали на разных ОС.
Не заработать может только звук. Просто запустите ./start (без никакого Тора) и затем нажмите ввод, и еще раз ввод. Или услышите себя, или получите ошибку. И в том, и в другом случае отпишите. Если будет ошибка, укажите, я попробую подсказать, как поправить ситуацию.
А можно кадры поочерёдно по цепочкам распределять, тогда будет просто пропуск каждого n-ого кадра, в плохом случае слайд-шоу.
комментариев: 9796 документов: 488 редакций: 5664
Если пропускать много трафика по множеству параллельных цепочек, то анонимность будет падать, да и сеть будет перегружаться. А для скрытого сервиса критически важными являются его гвард-узлы. Для правильного функционирования сколько бы дополнительных цепочек не запустили, узким местом останется фиксированный набор гвард-узлов скрытого сервиса, через которые трафик со всех цепочек и будет проходить. Можно, конечно и над этим набором узлов поиздеваться в ущерб анонимности, но трудно оценить к каким последствиям это приведёт, с учётом того, что протокол скрытых сервисов и так не слишком надёжен. Пока что он расчитан на малые нагрузки и не предусматривает масштабирования.
комментариев: 393 документов: 4 редакций: 0
На сколько я помню из теории кодирования видео (могу ошибаться, не занимался досконально), периодически передаются опорные кадры, а остальные в виде дельты. Так что для реализации предложенного алгоритма все равно понадобится специфический кодек, устойчивый к потерям. Наверное, такие существуют, надо смотреть теорию.
Год назад я несколько раз поднимал этот вопрос и здесь, и на TorProject, но ответа не получил. Хотя у меня с самого начала были сомнения аналогично вашим.
Об этом тоже где-то я упоминал. Практически это подтверждается при активировании экспериментальной функции Торфона: создаются две встречные цепочки, пакеты передаются по обоим, накапливается статистика за определенный интервал, и более медленная перезапускается. Я тщательно тестировал это в прошлом году: выше головы прыгнуть не удается из-за гвардов.
Отказаться от гвардов, уменьшить цепочки (наверное, это возможно в современной реализации Тор, не в курсе) можно в ущерб анонимности, все зависит от модели угроз.
Кроме того, я не зря упомянул об множестве экземпляров Tor на обеих концах, соответственно, наборе независимых HS. Конечно, надо думать о возможности корреллирования и т.п. потенциальных деанонимизаторах.
Вышеприведённые вопросы говорят о том, что я сам до конца не понимаю, как работает фильтрация на lo. Обычно правила (для системного Tor'а) пишутся исходя из того, что Tor, как локальный сервер, должен отвечать на запросы клиентов, но сам соединенения никогда не инициирует. Тут не так. Может быть, дело во всяких PluggableTransport и т.п. наворотах бандла.
Правила, конечно, ни от чего по сути не страхуют (особенно, если у кого-то на машине белый IP), но слегка сужают манёвр атакующему в случае, если будет уязвимость (соединения в сеть напрямую зарезаны, придётся отсылать трафик во вне через Tor или ждать, когда попадётся подконтрольный Guard). Список Guard'ов и их портов для конфига выцепляется из netstat -apn |grep ВАШ_IP. Если у кого исходящий не eth0, пусть поправит для своего случая.
комментариев: 393 документов: 4 редакций: 0
Проверил – подключается без проблем.
Убедитесь в правильность установки системного времени и соответствии его часовому поясу. Обновите tor.exe, заменив файлом из последнего TBB.
А вообще такое было в последний раз во время августовской атаки, тогда в первую очередь пострадали HS. Сейчас, судя по торовскому мейл-листу, все спокойно.