id: Гость   вход   регистрация
текущее время 18:48 28/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, ... , 30, 31, 32, 33, 34, ... , 50 След.
Комментарии
— Гость (04/10/2014 12:18)   <#>
UPD. Кроме трёх перечисленных способов подключения к демону есть ещё один, возможно наиболее интересный – через консольный интерфейс, по типу почтового агента mutt.
— Гость (06/10/2014 00:26)   <#>

У меня -C14 тоже отказывается падать. -C16 легко роняется, если поперебирать разные значения -Q. backtrace, coredump.
— gegel (06/10/2014 01:20, исправлен 06/10/2014 01:34)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

C -C14 разобрался: падает сборка с оптимизацией -o3. Это не столь важно сейчас, т.к. ILBC не особо настолько ресурсоемкий, -o2 вполне работает даже на Celeron 700MHz. По поводу -C16: именно, падает при переборе. В случае постоянного использования кодек устойчив, т.е. скорее всего проблема в моем wrapper (codecs.c), я там немного поизвращался с оригинальной компактной упаковкой OPUS-VBR-фреймов в общий пакет. Отладку затрудняет спонтанность бага. Стараюсь разобраться.


С addkey --help тоже разобрался, конечно: тупо strlen(NULL). Все исправлю одним заходом.


через консольный интерфейс, по типу почтового агента mutt

Если можно, вкратце опишите механизм или ткните носом в доку: бегло просмотрел вики mutt, ничего не прояснил.

— Гость (06/10/2014 03:51)   <#>
Наверное не совсем в тему mutt упомянул. Просто имел в виду UI на ncurses, т.е. текстовый UI работающий без X-сервера. Для unix-систем это было бы удобно, но не уверен что подходит в плане кроссплатформенности, чтобы ещё и под Windows работало.

Решение может состоять из следующих частей:
1. C-библиотека, реализующая протокол и ваши алгоритмы
2. Демон, использующий библиотеку и прослушивающий порты
3. UI, из которого осуществляется взаимодействие пользователя с демоном через его порты/каналы/файлы. Варианты UI приводил выше – command-line, ncurses, web-based, GTK-based и т.п.
— Гость (06/10/2014 17:19)   <#>
А зачем демон между библиотекой и клиентами? Это должно защитить от атак на клиентов, как библиотека gpgme, которая запускает gpg в отдельном процессе?
— gegel (06/10/2014 18:57, исправлен 06/10/2014 19:14)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
UI на ncurses

ncurces я использовал в одной из первых сборок, потом отказался: слишком громоздкая штука. Решил, что проще самому перевести консоль в raw, асинхронно читать с клавиатуры и написать простую процедуру обработки ESC-последовательностей для управляющих клавиш. Получилась навигация по меню стрелками, управление PTT удержанием Tab и т.д.


Но интересуют варианты взаимодействия на нижнем уровне:

взаимодействие пользователя с демоном через его порты/каналы/файлы.

Через что же лучше? Порт – это понятно, и будет сделано. Неважно, будет это control port со своим протоколом, Telnet, Web (HTTP) И т.д.
Но есть много других техник взаимодействия: системные сообщения Windows, файлы в памяти Linux, перенаправить ввод-вывод и т.д. и т.п. Интересно, что используют другие, и что лучше.


А зачем демон между библиотекой и клиентами?

Изначально вопрос стоял об использовании OnionPhone как добавки к другим клиентам. Это можно сделать двумя способами: издать его в виде so (dll) и использовать API (всего-то пару функций: отправка команды и чтение рапортов), или запускать отдельно OnionPhone в качестве демона и подключаться к нему, используя UI. Речь идет об низкоуровневых вариантах UI. Навреное, TCP-порт здесь – лучшее решение.


ПС: также пробую собирать под Androind, используя NDK и SWIG. Низкоуровневое аудио взял с этого примера (аудио – единственный платформ-специфический код). Пока все на стадии прикидок, но надежды есть.


ППС: кодер OPUS падает при слишком большом уровне PCM на входе. Особенно заметно при манипуляциях с AGC (-Q0, -Q1). Возможно, уже пофиксили в OPUS (попробую обновить), или придется что-то придумывать самому.
Пофиксил вроде, сам протупил. После более тщательного тестирования все вместе обновлю на git.

— Гость (07/10/2014 05:12)   <#>
А зачем демон между библиотекой и клиентами?

Свобода выбора UI. Например есть программа mldonkey, это просто движок работающий как демон закачки файлов. Такая реализация позволяет существовать целому множеству разных пользовательских интерфейсов. Такой подход также закладывает потенциал расширения – допускает подключение нескольких клиентов к одному демону, который в этом случае может выполнять функцию VoIP-шлюза. Возможно что для OnionPhone это излишество, решать разработчику. Просто привёл пример как это сделано в p2p-приложениях.

Через что же лучше? Порт – это понятно, и будет сделано. Неважно, будет это control port со своим протоколом, Telnet, Web (HTTP) И т.д.
Но есть много других техник взаимодействия: системные сообщения Windows, файлы в памяти Linux, перенаправить ввод-вывод и т.д. и т.п.

Не занимался разработкой, поэтому вряд-ли обладаю квалификацией для таких советов. Лучше наверное сокет, он двунаправленый и обладает параметрами для настройки. По сравнению с каналом имеет небольшой оверхед, т.к. работает в пакетном режиме, но зато более стандартный способ коммуникации. Приложение работает в основном на локалхосте, поэтому есть смысл опционально использовать unix-сокет. Это безопасней по сравнению с портом, т.к. применяются системные права доступа.
— Гость (07/10/2014 22:44)   <#>

Я всё равно не понимаю, чем хуже разделяемая библиотека. gegel, пяосните, пожалуйста. Для P2P-клиента демонизация в какой-то степени оправдана (пусть компьютер сам раздаёт файлы, пока пользователь спит и не кликает в него мышкой), но OnionPhone она зачем? С моей точки зрения, демон будет лишним процессом, а необходимость сериализации и десериализации команд для него – лишней сложностью. Для поддержания соединения у нас и так есть демон Tor, достаточно к нему подключиться, и связь, можно сказать, уже есть.

Написать свою программу, слинковав её с кодом протокола напрямую, проще, и точек сбоя в этой схеме мне представляется меньше. Свободу выбора UI разделяемая библиотека тоже не ограничивает.
— gegel (07/10/2014 23:38, исправлен 07/10/2014 23:42)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Написать свою программу, слинковав её с кодом протокола напрямую, проще, и точек сбоя в этой схеме мне представляется меньше.

Я совершенно согласен в Вами, и этот вариант рассматривается как предпочтительный, и, конечно, будет реализован. Но хочется максимально учесть возможные ситуации с использованием OnionPhone с другими приложениями.


но OnionPhone она зачем?

Надо же как-то ожидать входящие звонки.
Демон – наверное, самый простой способ использования. Продумываю возможность UI в виде вебинтерфейса, использующего WebSocket. Это не совсем знакомая мне отрасль, пока консультируюсь с web-программистом. Со стороны OnionPhone придется держать отдельный порт для подключения браузера и реализовать на С протокол WebSocket. Открывая подготовленный html-файл, имеем GUI и подключаемся к указанному порту, получаем возможность двухстороннего общения с запущенным OnionPhone, кроссплатформенно.

— SATtva (08/10/2014 13:23)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Имхо, это крайнее переусложнение. Согласен с Гостем: ничего сверх библиотеки для такого приложения не нужно. Ну, будет у Вас демон висеть "для ожидания звонков", а как и кому он будет сигнализировать о поступлении звонка? Так или иначе, должен быть поднят UI. В итоге, демон и UI должны всегда исполняться вместе, что эквивалентно отсутствию демона, как такового. Получается обычное пользовательское приложение, слушающее сетевой порт для приёма звонков. API в виде библиотеки нужен только для свободы в создании графических надстроек, которые для таких задач на порядок проще реализовать на Qt/GTK/ncurses, чем многослойным веб-пирогом.
— unknown (08/10/2014 17:05)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

[off and humor]
Слать сообщение в /var/log/syslog, а умный systemd подключится к современному аналогу устройства /dev/audio и сделает всё остальное.
[/off and humor]
— Гость (08/10/2014 19:19)   <#>
Я всё равно не понимаю, чем хуже разделяемая библиотека

Нигде не утверждалось что это хуже, а наоборот. Демон и библитека могут существовать независимо.

точек сбоя в этой схеме мне представляется меньше

Какие там точки сбоя? Нужен только дополнительный слушающий сокет для управления через UI и поддержка соответствующего ему протокола.

Свободу выбора UI разделяемая библиотека тоже не ограничивает

Библиотека к пользовательскому интерфейсу вообще не имеет отношения, это только API для написания движка.

демон и UI должны всегда исполняться вместе, что эквивалентно отсутствию демона, как такового

Привильней сказать, демон интегрирован с UI.

будет у Вас демон висеть "для ожидания звонков", а как и кому он будет сигнализировать о поступлении звонка?

Вариантов много – записывать в лог и сообщать список пропущенных вызовов при запуске UI или выдавать их историю по команде. Записывать в канал на STDIN какой-нибудь утилиты для проигрывания мелодии вызова, отправки email или sms.

API в виде библиотеки нужен только для свободы в создании графических надстроек, которые для таких задач на порядок проще реализовать на Qt/GTK/ncurses, чем многослойным веб-пирогом

Как уже отмечалось выше, для создания части UI используется стандартное API, к OnionPhone отношения не имеющее. Но в случае интеграции демона и UI в одно приложение, для создания нового UI нужно будет и демон переписывать, т.к по сути создавать приложение с нуля, имея только библиотеку OnionPhone. Если же он реализован отдельно, то такой проблемы нет. При этом ничто не мешает создать из двух частей монолитное приложение на этапе компиляции, если будет предусмотрена такая опция.

Кстати, в таком случае проще защититься – поместить в chroot демон гораздо легче, чем комбайн демон+GUI, который потянет за собой кучу графических библиотек плюс пробема с общим X-сервером.
— gegel (08/10/2014 21:39, исправлен 08/10/2014 21:57)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

Гость, огромное спасибо за pull-реквесты – фиксы моего английского.


Демон и библитека могут существовать независимо.

Именно так я себе это и представлял, также абсолютно согласен с остальными вашими замечаниями.


создании графических надстроек, которые для таких задач на порядок проще реализовать на Qt/GTK/ncurses, чем многослойным веб-пирогом.

Вначале я тоже смотрел в сторону Qt, и на самом деле такой подход мне ближе и понятней. Но это верно для тех, кто пишет на С. Большинство кодит максимум в веб, поэтому им проще как раз то, что нам сложнее.


это крайнее переусложнение.

Оказалось, что с WebSocket ситуация похожа на ту, с которой я столкнулся год назад, прикручивая SOCKS5 клиент к Торфону. Вначале, как и положено, я искал подходящие либы и пытался с ними разобраться, но потом прочитал rfc на протокол и с удивлением обнаружил, что SOCKS5-клиент на нижнем уровне реализуется десятью строчками С-кода. Точно так же, почитав спецификацию на WebSocket, обнаружил что реализация сервера на удивление проста. Клиент (браузер) открывает TCP-соединение и отсылает handshake-пакет с текстом (это делает простой Java-скрипт в html-файле). Сервер (OnionPhone) парсит полученный текст, ищет заданный подтекст, выделяет строку после него, дописывает к ней еще фиксированную строку, считает SHA1, результат кодит в base64 и вставляет в стандартный текст ответа, отсылает его обратно клиенту.
Это и вся процедура установки соединения, займет от силы 10 строк кода сервера.
Сам обмен текстовыми строками с браузером (строка команды на OnionPhone и текстовых сообщений от него, дублирующих stdout) еще проще: к UTF-8 строке в начале сервер добавляет два байта (фиксированный тип пакета и длина в байтах) и отсылает клиенту байт-пакет через установленное TCP-соединение в любой момент времени. Клиент (браузер) делает аналогично, но дополнительно добавляет еще 4 рандомные байта маски после длины, с которыми побайтно ксорит отправляемый текст.
Это все. Причем таким образом реализуется универсальный UI, который может быть использован и небраузерным клиентом.
Преимущества: кроссплатформенный GUI-клиент может быть легко реализован на HTML+Java-script, т.е. даже начинающим разработчиком под себя, используя только текстовые команды OnionPhone из описания.
Недостатки:
– не все браузеры (особенно на андроид – штатный только с 4.4) поддерживают стандарт;
– запущенный браузер – раздражитель для параноика.

— Гость (09/10/2014 13:49)   <#>
Браузер в любом случае нужно запускать чтобы по сайтам ходить. Раздражителем является скорей включение скриптов в браузере. Но если telnet-порт будет, то интерфейс можно и на bash-скрипте сделать.
— Гость (13/10/2014 18:51)   <#>
gegel, почта на вашем сайте работает? Проверьте получение, плиз
На страницу: 1, ... , 30, 31, 32, 33, 34, ... , 50 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3