id: Гость   вход   регистрация
текущее время 00:04 29/03/2024
создать
просмотр
ссылки

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).


 
На страницу: 1, ... , 35, 36, 37, 38, 39, ... , 50 След.
Комментарии
— Гость (05/01/2015 21:48)   <#>
Сорри, увидел свою ошибку в строках, исправляю
— Гость (05/01/2015 22:02)   <#>
Извиняюсь, получил новые уточненные данные:
– при дефолтовых аудионастройках (программное управление) запаздывание голоса соствляет 6 секунд;
– при аппаратном управлении звуком запаздывание составляет десятые доли секунды, голос в наушниках следует практически сразу за микрофоном, как быстрое эхо.

Раньше запаздывание голоса составляло 30-40 секунд видимо из-за того, что был включен Pidgin и Jitsi.
Отключил сначала один, затем и второй, и получил вышеказаные данные.

Гослос, правда, очень глухой – это из-за AMR?
— gegel (05/01/2015 22:16, исправлен 05/01/2015 22:23)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Гослос, правда, очень глухой – это из-за AMR?

Скорее всего, да. Или из-за гарнитуры. Но Вы можете перебрать все кодеки по очереди, вводя прямо во время теста команды от -С1 до -С18
Первая соответствует военному стандарту NATO 1200bps, предпоследняя – скайповскому SILK, а последняя – популярному SPEEX (он практически везде: Jitsi, Tox, ZAS). Но для Tor он чуть тяжеловесен. AMR 4750bps (-С7) – золотая середина, тем более он работает в режиме DTX, заменяя безголосые участки в 20 mS на короткие описатели, так что в среднем получается 2500-3000 bps. Это не VBR, реконструкция по зашифрованному потоку вряд ли возможна, тем более, что в одном пакете передается сразу аж 200 mS, и невозможно определить, какие из 10 фреймов голосовые, а какие – нет.


Также можете поиграться с вокодером. Включается командой -Q3 в режиме шепота, и командами от -Q30 до -Q150 в режиме робота. Отключается -Q-3


PS: только что тестировали текущую версию в виде сборки на 64 битах.
вылезли баги:
– кодек LPC10 на передачу с 64-битной сборки искажает pitch (женский голос);
– глюк с переключением на прямое UDP-соединение с использованием внешнего STUN.
Правим.

— Гость (05/01/2015 22:35)   <#>
Гарнитура хорошая, по ней другие мессенжеры работ звонко.
Здесь же даже при SILK звук заметно глуховатый.
Может, в Скайпе искусствено поднимаются высокие?

Попробовал вокодеры от -Q30 до -Q150.
Да, голос не узнать, но и слова тоже не разобрать :)

Хорошо. Что же дальше? Мы остановились на алгоритме действий пользователя по Веб-интерфейсу для проведения связи.

И можно ли сделать команды регистронезависимыми? Будет намного удобнее.
— gegel (05/01/2015 22:51, исправлен 05/01/2015 22:53)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
И можно ли сделать команды регистронезависимыми?

Можно, конечно. Записал на будущее.


Проведение связи: (считаем, что пп.1-14 коммента выполнены).
Вставляем онион-адрес абонента (без суффикса .onion) в строку "Команда" и жмем кнопку "Вызов". Видим, что онион-адрес преобразован в команду (добавлен -O). Жмем кнопку "Вызов" повторно, ждем соединения (ход соединения отображается в поле лога).
После установки соединения слышим вашего собеседника. Для передачи жмем-отпускаем кнопку "Речь-пауза" в режиме полудуплекса. Для активации дуплекса жмем эту кнопку и, не отпуская мышь, убираем указатель с нее, затем отпускаем. Онионфон остается в режиме передачи и приема (дуплекс).


Можете позвонить сейчас мне, я как раз тестирую: gegelcy5fw7dsnsn

— Гость (05/01/2015 23:08)   <#>
Разговарием с приятелем- класс!!!
Задержка конечно агроменная, но можно приспособиться.
— gegel (05/01/2015 23:11, исправлен 05/01/2015 23:19)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

Я только что разговаривал – пинг около 600mS. Жмете кнопку "Пинг" для получения. Жмете кнопку "Инфо" для дополнительной информации.

но можно приспособиться

Если уж совсем напрягает, используйте полудуплекс. Звуковой сигнал по окончанию передачи избавляет от необходимости произносить слово "Прием". Если жать лень, можете включить голосовой детектор (кнопка "VAD"). В этом случае передача активируется только при Вашем разговоре. Но для исключения срабатывания от голоса собеседника нужна гарнитура на обоих сторонах. И, возможно, придется подстроить чувствительность микрофона средствами ОС. Детектор отключается при нажатии кнопки "Речь/пауза".


ПС: попробуйте так же переключиться на прямое UDP-соединение (оба должны нажать кнопку "UDP"). В новой версии пока глючит, но в старой может работать. Возврат в Tor – нажатием кнопки "Tor" любым участником разговора.


Следующим этапом пойдет работа с ключами, разные виды аутентификации и защиты.

— Гость (05/01/2015 23:56)   <#>
Да – оказалось что большая задержка была обусловленна "программной" настройкой своего аудиоканала.
Суммарная задержка звука состоит из задержки в сети Tor, в буфере OP и аудиканале, и оказалось, что моя аудикарта&драйвер вносит наибольшую лепту.
Высставил "аппаратное" управление аудиоканалом, т.е.



и задержка стала очень даже небольшой, разговаривать стало совсем комфортно!

Все эти достижения по следам общения с автором проекта :)

А то, что разговор начинается после второго нажатия на <Enter> – это действительно очень правильно! Не ляпнешь чего нибудь ненужного :)
— Гость (06/01/2015 03:01)   <#>

Круто. Как руки дойдут, надо будет тоже заценить.
— Гость (06/01/2015 11:58)   <#>
Да, вот что мануал животворящий делает! :)
Теперь совсем другое дело, даже в консоли можно вполне сносно общаться.
И сразу вопрос по ней: в ней "забиты" предопределенные команды, и только? Потому что она не запоминает вводимые юзером команды, включая вызов собеседника по -O

И теперь по связке OP & TorChat.
Если судить по https://github.com/prof7bit/TorChat, то развитие программы остановилось 3 года назад. Между тем развитие сети Tor активно продолжается.
Как влияет "отсталость" TorChat на функционирование и безопасность OP?

Еще случайно обнаружился форк под названием JTorChat, хотя тоже староват:
https://github.com/jtorchat/jtorchat
зацените, пожалуйста, его пригодность для OP.
— Гость (06/01/2015 21:02)   <#>
В свете этих успехов меня заинтересовал симбиоз OnionPhone и Raspberry. Как думаете, взлетит?
— gegel (06/01/2015 21:55, исправлен 06/01/2015 22:11)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
по следам общения с автором проекта

задержка стала очень даже небольшой

По следам нашего вчерашнего сеанса, и моих тестов перед этим: адаптация к каналу таки происходит, уже через 5-10 минут разговора задержка уменьшается (отмечается пинг 300-400 мсек вместо 600-800 в начале). Это практически граничит с режимом комфорта и где-то эквивалентно задержкам в геостационарных спутниковых системах или в VOIP через GPRS.


Потому что она не запоминает вводимые юзером команды

Я даже не знаю, как и ответить. Дело в том, что консоль в онионфоне реализована совсем нестандартно. С целью использовать один поток на все я на старте перевожу консоль в raw и поллингом асинхронно получаю коды нажатия клавиш, затем обрабатываю их последовательности, формирую все остальное. Это как ncurses, только написано мною вручную и более компактно. Этот код больше embedded-ориентированный, и кажется диким системным программистам. Но зато он легко может быть портирован в железо без ОС: подтягивается библиотека звука (АЦП и т.п.), работы с SD-картой (файловая система) и ТСП-стек (для используемого чипа контролера сети), и имеем аппаратную реализацию. Попробуйте так портировать Jitsi :)
Отсюда косяки с консолью: это не совсем консоль по определени, и не стоит от нее ожидать полного функционала. Этот интерфейс задумывался как дополнение к другим UI (Telnet, потом WebSocket). В принципе в идеале сделать нормальную консоль в отдельном потоке, но есть ли в этом смысл, когда можно работать через тот же Telnet?

в ней "забиты" предопределенные команды, и только?

Не совсем так. Вводимые символа накапливаются в массиве до первого Enter (или других управляющих, например Del), затем массив анализируется. Если первый символ -, то интерпретируется как команда, иначе – как текст для отправки в чат.


И теперь по связке OP & TorChat

Собственно, связки нет. Просто я хотел использовать популярность TorChat для продвижения ОР как плагина к нему. Протокол ОР никак не связан с протоколом TorChat, использует отдельный порт на том же HS. TorChat имеет возможность отслеживать online-присутствие абонента, что более привычно для обычного пользователя и напоминает тот же скайп.
Что касается самого TorChat, то я тщательно изучил его протокол по исходникам (и есть публикация на хабре). Сам протокол видится безопасным, что бы там не говорили: он использует обоюдную аутентификацию по Abadi, достаточные по размеру nonce. Но доверие к нему полностью исходит из доверия к Tor: TorChat не имеет своего слоя шифрования и отправляет в Tor открытый текст, а для аутентификации использует онион-адрес в качестве ID и соответствующий приватный ключ HS (файл private_key в папке hidden_service). Файл ключа не шифруется, поэтому надо тщательно хранить эту папку (например, в контейнере TC), т.к. утечка фатальна для аутентификации и анонимности (PFS все же защищает предыдущие сеансы от дешифровки).
Что мне не нравится в протоколе TorChat, так это постоянная поддержка двух встречных соединений с каждым контактом. Это огромный оверхед по памяти (два активных сокета на каждый контакт в книге). Сделано ради того же online-присутствия.
Но на сегодня, несмотря на все попытки депопуляризировать TorChat, он де факто является стандартом общения специфической публики (начиная с закрытых хакерских форумов и заканчивая нарко и педо). Сейчас ссылку не вспомню, но пару лет назад была опубликована работа (авторы – русские) по исследованию портов в HS Tor, так TorChat был на втором месте после известного бота, положившего потом сеть. Так что менять протокол и предлагать свое – слишком амбициозно.
Абсолютно нет проблемы включить поддержку TorChat в ОР из коробки, но для мессенжера важен интерфейс (цитирую ZAS: кому интересно жить в сером и унылом чате), поэтому прежде надо сделать дружелюбный Qt GUI с большими цветными кнопками и смайликами. Я к этому авангардизму морально не готов сейчас, возможно, позже дозрею.


форк под названием JTorChat

Мне Java не особо симпатична, лучше уж оригинал на Piton. Но это мое личное мнение.

зацените, пожалуйста, его пригодность для OP

Для ОР нужен лишь Tor. Из чего Вы его возьмете, разницы нет. Наверное, для безопасности лучше использовать последний TBB. А представление ОР в качестве плагина для TorChat – больше реклама.


В свете этих успехов меня заинтересовал симбиоз OnionPhone и Raspberry.

Уже ответил выше по тексту. И не только на Raspberry, а и на другом открытом HW. Если планируется внешний Tor (например, в роутере), то можно OP сделать вообще без ОС. Проблема может быть только с кодеками (например, для MELPE нужно как минимум 40MIPS, 256K RAM и столько же быстрой ROM для кодовой книги).

— Гость (06/01/2015 23:02)   <#>

У торчата есть один принципиальный минус: если вы даёте ссылку на свой id противнику, это то же самое, как сообщить ему onion-адрес, работающий на вашем ПК. Это открывает возможность атакующему инициировать соединения с вами, трафик к вам и т.д. — огромное поле для всезвозможных атак по деанону и не только. Если же мы отказываемся от P2P-архитектуры, то придётся доверять третьей стороне, которая может отслеживать список контактов, моменты активности и т.д. Я бы просуммировал это так: централизованные onion-сервисы при прочих равных безопаснее, а децентрализованные не полагаются на присутствие в онлайне какой-то третьей стороны; для анонимности есть свои минусы в обоих случаях.
— Гость (06/01/2015 23:55)   <#>
Итак, для функционирования OP достаточно запущенного TBB, который предоставляет первому свой SOCKS, вроде так.

А TorChat умеет делать то же самое по прокси, как TBB?
Если да, то это очень хорошо, т.к. решаются сразу две полезные задачи:
– получаем индикатор он-лайн присутствия собеседника;
– обзаводимся криптующим текстовым мессенжером
(правда, остается вопрос влияния "свежести" TorChat, но если правильно понял, на безопасность он никак не влияет, т.к. сам не шифрует, а пользуется сервисом Tor).

Если отказаться от TorChat (либо он не заменяет TBB по поддержке SOCKS), то теряем не только текстовый мессенжер (не так печально), но и он-лайн индикатор (важнее).
И тогда встает вопрос: чем заменить этот он-лайн индикатор?
Потому что если воспользоваться вспомогательным софтом типа Jitsi, Tox, то напрочь теряем с таким трудом добытую анонимность.

Просто пытаюсь смоделировать наиболее употребимую и практичную схему использования OP с учетом вышеописанных реалий.
— Гость (07/01/2015 01:38)   <#>
Насчёт TorChat: он не помер. Сейчас он развивается в направлении переписывания в виде плагина для Pidgin на FreePascal.

gegel, насколько сложно, зная список функций в OP, использовать его в своей программе? pfactum разделил код на несколько библиотек, за что ему очень большое спасибо. Правильно ли я понимаю, что для включения OP в свою программу достаточно запустить отдельный поток, в котором реализовать свой loop, аналогичный main() из libdesktop/oph.c? (а также прилинковать все остальные библиотеки из OP и подсунуть процессу конфигурационные файлы от OP)
На страницу: 1, ... , 35, 36, 37, 38, 39, ... , 50 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3