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).
Экстраполируя это на TorFone, получаем не очень хорошую штуку. Просьбы переименования проекта были озвучены разработчиками Tor год или сколько там назад? С тех пор ничего не поменялось: сайт, домен, всё под старым именем.
1. Если оба абонента в Виндовс – качество весьма приемлемое.
2. Один абонент в Wine 1.4.1 под PulseAudio, второй в Виндовс.
Абонент в Виндовс слышит хорошо, а который в Вайне, слышит голос с треском и хрипением, так что Linux в данный момент использовать нельзя.
3. Один абонент в Виндовс, второй в гостевой виртуальной Виндовс.
Абонент в физической Виндовс слышит хорошо, в виртуальной тоже неплохо.
Есть мнение использовать вариант 3, но тут возникает несколько вопросов, связаных с тем, что Виндовс доверять нельзя.
Первое желание – запускать Виндовс в линуксовой виртуалке.
Второе желание – добавить использование OpenVPN, по которому пропускать трафик Torfone.
По идее, это дополнительно зашифрует трафик и уменьшит паразитные утечки Винды и ее приложений/сервисов "налево".
Как тут лучше поступить, где запускать OpenVPN-сервер и OpenVPN-клиент – в базовом Linux или гостевой Виндовс?
И как, если это повысит информационную безопасность, закрыть с помощью Iptables все адреса/порты, не участвующие в разговоре по Torfone?
комментариев: 9796 документов: 488 редакций: 5664
Так это можно использовать и другой подходящий голосовой клиент без шифрования. Проблема только в том, что расход трафика при таком подходе возрастает примерно в 10 раз по сравнению с тем, когда шифрование правильно встроено в сам клиент.
В любом случае пусть лучше будет сыроватый Torfone, зато известно, что он сделан нашим человеком для нас же, а не для какого-нибудь АНБ.
10-кратным расходом трафика нас не запугать, особенно, если это существенно повышает криптостойкость.
Поэтому, пожалйста, покритикуйте вышенабросанную схему, если есть за что, и если особых возражений нет – помогите с решением заданных в ней вопросов.
комментариев: 9796 документов: 488 редакций: 5664
Так что табличку "Comparison of VoIP software" мы видели давно, но кто подпишется под ихними продуктами?
Правильно, никто. А тов. Gegel'а, который живет на Украине, если что, найдем и поставим ему для начала... нет, не синяк, а на на вид :)
Так что хотелось бы с вашемй помощью определить оптимальное размещение OpenVPN-сервера клиента и правила iptables для данной ситуации по типу "запретить все, кроме".
комментариев: 9796 документов: 488 редакций: 5664
Поскольку решение любой проблемы в части касающейся уменьшает потенциальный риск сами знаете чего.
комментариев: 393 документов: 4 редакций: 0
BTC: 19kUeFQsh72oPzSmGKF5Wny4Jp495NBFcg
LTC: LZaogEahLPFJE5CYrCuXSroVCvHz8NowR9
Со вторым пунктом проблем нет, но распознавание голоса на сегодня эффективно не решено, на сколько я в курсе.
Я сам не пробовал, при первой возможности потестирую. Но предполагаю, что качество распознания не удовлетворит практические запросы.
Идентификация по стилю (стилометрия), конечно, останется после распознания-синтеза, но это совсем другой уровень. Доказать что-то с помощью такой идентификации нереально, т.к. стиль всегда можно подделать под человека. Другое дело – идентификация по формантам, которые больше зависят от анатомии глотки, языка, связок и т.д., чем от желания говорящего. Поэтому распознание-синтез было бы почти идеальным решением, если бы существовали надежные средства перевода голос-текст.
Вы не верно меня поняли, я ничего против Linphone не имею, это совсем другое приложение и для других целей.
Можно выделить три проблемы:
– поиск нужного абонента (это может быть выполнено с помощью собственных серверов (Skype), SIP-серверов (Linphone, Jitsi, OSTN), DHT (наш ZAS и другие проекты), Tor (Torfone), I2P (пока нет) или непосредственно по доменному имени/IP-адресу (PGPFone, SpeakFreely). Беда серверных решений – возможность собирать метаданные на сервере (кто к кому когда звонит). Главная проблема, требующая сервера – проход NAT. С переходом на IPV6 все варианты кроме последнего отпадут сами по себе. Торфон делает это так: устанавливает соединение с другим абонентом посредством Tor, используя его DHT. Это соединение уже защищено и односторонне аутентифицировано. Внутри происходит обмен ключами и добавляется дополнительный слой шифрования "точка-точка". По установленному соединению передается инвайт, содержащий онион-адрес вызывающего. Вызываемый параллельно устанавливает встречное соединение с вызывающим. Голосовые пакеты дублируются в оба канала, используется тот пакет, который получен раньше. Накапливается статистика и, скажем, раз в 3 минуты (задается) более медленное соединение переустанавливается. Для работы данного механизма необходимо указать свой онион-адрес на вкладке настроек Торфона.
При желании перейти на прямое соединение используется следующий механизм: абоненты посылают запросы на любые STUN-сервера (задается на вкладке настроек) и получают ответ, где указывается их внешний IP-порт (до NAT). Т.к. STUN могут быть разные для абонентов и могут периодически меняться, то коррелировать запросы они не могут, т.е. зафиксировать факт прямого звонка от Алисы к Бобу могут только их интернет-провадеры. Затем абоненты формируют инвайты, в которых указывают свои внешние адрес:порт и обмениваются ими через Tor-соединение. Затем оба начинают слать UDP-пакеты друг другу согласно полученных инвайтов. Как только кто-то принимает корректный пакет, то тотчас начинает отправлять пакеты по адресу отправителя. Таки образом, "пробивается" NAT (кроме симметричных) и устанавливается прямое соединение. Tor-соединение поддерживается в качестве резерва, но неактивно до обратного переключения с прямого соединения на анонимное.
– оконечное шифрование. Все клиенты, которые поддерживают ZRTP (включая Торфон, в котором ранний вариант ZRTP от того же Циммермана), создают защищенное соединение. С этим сейчас проблем нет. Первичная аутентификация обычно осуществляется или голосом, или общим секретом, в следующий раз – с помощью сохраненных публичных ключей друг друга.
– анонимность (вы хотите скрыть факт разговора и адрес собеседника от всоего провайдера). Тут без Tor не обойтись. Проблема состоит в том, что Tor маршрутизирует только TCP-пакеты, а подавляющее большинство звонилок работает по UDP.
Решение: или адаптировать звонилку, переведя ее на TCP (что я и сделал), или завернуть трафик звонилки в VPN и пустить последнюю по TCP через Tor. Это реально работает (пробовал), но трудно настраиваемо, нестабильно из-за таймаутов при задержках в Tor и вызывает большой перерасход трафика. Последнее важно, т.к. существует корреляция между потоком Tor-трафика и латентностью (не знаю, из-за чего, но в определенных пределах весьма выраженная).
Поэтому выбор звонилки в первую очередь зависит от модели угроз.
Подтверждаю, есть такая проблема в Wine, но, к сожалению, я не могу определить причину. Для интереса попробуйте переделанную под Tor SpeakFreely с моего сайта под Wine, отпишите результат. И за одно потестируйте нативную версию SpeakFreely под Linux
PS: Наконец-то Вы раскачали меня на порт под Linux :)
Я только что установил Linux-SpeakFreely на моей скромной Ubuntu, пришлось доустановить библиотеку и изменить название фукнции в файлах \lpc10\round.c и lpc10lib.h (она не используется, но почему-то при компиляции конфликтовала с одноименной в DES). Код собрался (с кучей предупреждений, но все же), сейчас попробую соединиться с моей патченной Win32-версией в стандартном UDP-режиме. Если все будет ОК, прикручу TCP и попробую через Tor с кодеком LPC10. Если все ОК, то можно постепенно перенести все рюшечки (шифрование (+Keccak), DH (+EC25519), новые кодеки (MELP/MELPE, CODEC2, OPUS), подавитель шума, голосоменялку, дублирование цепочек для снижения латентности, переход на прямое UDP-соединение), т.е. практически все, что сегодня есть в Торфоне.
комментариев: 301 документов: 8 редакций: 4
Во-первых, ознакомьтесь с http://wiki.winehq.org/Sound
На игровых форумах проблемы со звуком под wine – частый предмет обсуждения. Возможно, придется доустановить или наоборот удалить какие-то пакеты. Программу можно запустить так:
$ padsp wine программа.exe
Или так:
$ aoss wine программа.exe
Не забывайте об утилите winecfg.
Отправил вам лайты, ловите. Надеемся, что вы продолжите свою архиполезную работу.
Пусть и не глобально по всем пожеланиям, а хотя бы косметически, для юзабельности.
Например, добавить в мануал описание всех фич, используемых в интерфейсе Torfone, и практические советы по их использованию, т.е. какие оптимальные значения следует выбирать.
Да и интерфейс бы неплохо бы перевести на русский – огромный стимул по освоению Torfone для новичков.
И прошу советов по заданным выше вопросам:
А то тов. unknown, на которого возлагались большие надежды, вроде заинтересовался ими, но потом, к сожалению, исчез.
Кстати, почему о сих пор PGPfone.exe, а не Torfone.exe?
Что, нельзя было наскрести жалких восемь с половиной лямов за Skype? Для такого государства, как Россия, это не деньги, шелуха.
Да и в 10 раз больше стоило бы заплатить – и теперь бы не АНБ, а Россия слушала бы весь мир – обычных граждан, бизнес, наркобизнес и террористов.
Полученная информация по стоимости в тысячи раз больше уплаченных лямов.
Тов. Gegel, вас еще не пытались купить спецслужбы? ;)
$8,500,000 не деньги даже для такого супергосударства, как Монако или Лихтенштейн ;))
Нахрена столько?
Гугл поднимался с 100,000$.
комментариев: 393 документов: 4 редакций: 0
Не-а, никто не пытался :(
Да и Торфоном, судя по гугланалитике, интересуются лишь честные люди: с r2d2, runion, pedoimperia и т.д., ну и штурмовики с разных лагерей еще.
Если покупать, то не меня, а проект, но тут есть проблема. Торфон – самодостаточная система, его безопасность зависит только от исполняемого файла и от Tor (нет сервера, который можно взять под контроль). Кроме того, не предусмотрено автоматического обновления, как в Skype или даже в хваленном Jitsi (который мало того, что под обновляемой Java, но и сам лезет на свой сервер тотчас после первого запуска).
Так что только если я начну активно петь об новой улучшенной версии или, наоборот, об страшной уязвимости, требующей немедленного обновления, значит, можете поздравить – таки купили :)
PS: SpeakFreely под Linux проверил, все функционирует ОК, как Linux-Linux, так и Linux-Win32. Чистая консоль, минимум библиотек, относительно простой код на С (всего два потока для двух направлений передачи). Сейчас разбираюсь в коде, найду время пропатчить и ввести добавочный TCP-транспорт и поддержку SOCKS5, вычищу от утечек DNS, и можно будет пробовать через Tor.
Прямое соединение можно пробовать и сейчас с нативной версией (там есть поддержка AES-128 в CBC на предрасшаренных ключах, но, похоже, без MAC – голос как аутентификаитор, Шнаер допускает такой вариант). Заодно подскажите, что можно убрать/добавить для удобства практического применения.