Tox, Jitsi и другие – куды крестянину податься?
В связи с переходом Skype под юрисдикцию M$ и контроль NSA и прочих НКВД, и начавшееся, особенно в 2014 году, выкручивание рук у пользователей принудительными сменами протоколами и версий, самая сознательная часть пользователей ринулись кто куда в поиска счастия.
Одни радостно вляпались в Viber, не осознавая, что всего лишь сменили шило на мыло, другие присели на освободившийся от оков проприетарности Jitsi, третьи возлагают надежды на бурно развивающийся uTox, Venome и другие Tox'ы, некоторых удовлетворил даже такой непритязательный телефон, как Linphone, и т.д. и т.п.
При этом не слишком сознательные пользователи используют SIP-протокол, совершенно забывая, что он не просто открытый, а вообще оголенный с точки зрения безопасности передаваемой информации, а значит, ничем не лучше Скайпа с его штатными соглядатаями.
В-общем, разброд и шатание, которое пока не позволяет выявить лидера защищенной IP-телефонии и объединить широкие массы пользователей вокруг него, тем самым дав новый импульс для его развития.
На этом хаотическом фоне видится лишь одна обнадеживающая тенденция – M$, которой достался Skype, сознательно, или в полуобморочном состоянии, делает все возможное и невозможное, чтобы вызвать к нему отвращение пользователей и вынудить искать ему достойную альтернативу. Видимо, благодаря этому в последнее время расплодилось столько альтернатив Скайпу – многие разработчики почуяли, что тут можно развернуться и при умелом продвижении и пиаре ухватить за хвост птицу удачи, перехватив у него инициативу.
В этой теме предлагаю обсуждать и анализировать не только текущие возможности наиболее перспективных альтернатив Скайпу, но и прогнозировать возможную перспективу и тенденции их развития на будущее с учетом этих самых возможностей.
Цель – объединение пользователей вокруг наиболее перспективных проектов и предотвращение распыления по малозначимым.
Чтобы не получилось так, как например, с Linux – число его проектов уже перевалило сотню, а в употреблении по прежнему 1% – налицо последствия гурта "Лебедь, рак и щука".
Также не помешает вести периодические голосования по рейтингу обсуждаемых IP-телефонов, чтобы ориентировать пользователей для использования наиболее полезных и перспективных.
PS. Намеренно не упомянул здесь о TorFone/OnionPhone ув. тов. Gegel'я – при всем уважении к нему и его чрезвычайно интересным разработкам полагаю его проекты на данный момент безперспективными. Причина проста и банальна – у него пока нет команды, и может получится, как, например, или с Privoxy – театром одного актера, который ушел вместе с ним. или даже с TrueCrypt с его малочисленной командой, которую выловили "прижали к ногтю". Конечно, эта ситуация поправима, но надо этим заниматься.
В то же время тов. Gegel уже приносит огромную пользу в анализе криптовозможностей защищенных IP-телефоном и может принести ее еще больше, если продолжит это полезнейшее занятие, за что ему огромное спасибо!
комментариев: 393 документов: 4 редакций: 0
Это SAS (Anti-MitM проверочное значение, его надо зачитывать голосом друг другу), т.е. используется ZRTP.
Еще одно малоизвестное решение на питоне: TorPhone.
Источник тут.
комментариев: 9796 документов: 488 редакций: 5664
Если код там качественный (не проверял), может есть смысл поддержать проект дополнительными наработками, а не изобретать всем велосипед, каждый раз переписывая код с нуля?
комментариев: 393 документов: 4 редакций: 0
Это хорошая С-библиотека, я к ней присматривался давно, планируя надергать с нее кода для H264-видео.
Но, на сколько я понимаю, топикастер поднял другую тему – VOIP-решение с другой (не SIP) философией. Это требует ряда нестандартных решений, для которых нет готовых либ, связанных с VOIP: p2p соединения (по типу DHT, TorHS, i2p), медиа-протоколы на основе TCP (не UDP-RTP), навешенное на них крипто со специальными свойствами (дополнительная аутентификация, PFS).
Пока тут готовых вариантов нет. Можно использовать что-то специально написанное и жутко нестандартное типа Онионфона (предварительно для себя просмотрев код, в надежде, что пронесет с уязвимостями), или ждать, пока сообщество определится (свободно или под давлением?) и добавит что-то, например, в Tails, стандартизировав и выверив код. Опять же, никакой гарантии, что через пару лет не окажется, что SPRNG хитро выводит ерунду, прецедентов ведь масса.
Теперь остается ждать, когда команда uTox внедрит его в очередную версию.
комментариев: 393 документов: 4 редакций: 0
Оперативно срегировали :)
Я так понял, для Линукс аналога не нашлось, что привело к
Я в точности прошел этот путь, и следующим шагом было извлечение в wav-редакторе фрагмента с ring.wav и предcтавление в виде массива:
https://github.com/gegel/onion.....ob/master/ringwave.h
Все же звучит приятнее, чем просто beep.
Только там unsigned short, возможно потребуется привести к signed.
И правильно сделал, имхо – лучше жесткая генерация звука, при которой шаловливым ручкам будет меньше мест где что подкрутить, подправить и ... испортить!
Имеется ввиду Zfone?
глядя сюда "Источник wwwтут."
Так он рекомендуется для Андроид, а для других ОС свое (!)
комментариев: 9796 документов: 488 редакций: 5664
Торификация Mumble описана в вики со всеми сопутствующими замечаниями, в основном касающимися потенциальной небезопасности Mumble — всё таки это изначально игровой голосовой сервер и чат. Есть ещё один принципиальный момент. В большинстве примеров ставят некие серверы, в т.ч. голосовые в качестве обычных скрытых сервисов. Но как было ранее отмечено и подтверждено экспериментально, даже если никому не говорить адрес скрытого сервиса, то из-за несовершенства текущего протокола он становится известным в открытом виде узлам Tor. Разумеется, только onion-адрес, а не скрывающийся за ним IP. Для защиты от этого необходимо использовать специальную скрытую авторизацию клиентов. Иначе, если голосовй трафик не шифруется самой программой, а только криптографией самого тора, то можно предположить, что при некоторых настройках посторонний может подключиться к скрытому сервису и прослушать разговор в нешифрованом виде.
Да, начинали они понимая технические трудности, но с некоторым оптимизмом. А дальше разъяснили свою позицию в плане, почему это малоперспективная идея именно из-за технических трудностей. В общем случае, задержки составляют секунды, а при долгом разговоре в полнодуплексном режиме они будут только накапливаться. И между собеседниками могут создаться задержки уже на минуты, причём несимметричные (могут отличаться в разные стороны). Это же совершенно невыносимо: вы будете думать, что собеседник уже закончил реплику, захотите ему ответить, а он уже наговорил вперёд ещё на несколько минут. И никакого заговора и давления на разработчиков скорее всего здесь нет. Любой может сделать простейшее решение и объективно убедиться, что задержки речи совершенно неприемлемы и это скорее всего непреодолимая задача. Остаётся только полудуплексный режим рации (push-to-talk), который мало кому интересен. Это не просто неполноценный режим разговора («приём, over»), но и требует ещё больше терпения, чем в радио: наговоренный фрагмент может опять же накопить задержки в несколько минут, может быть потерян или надолго зависнуть. Придёться сообщить собеседнику, что его речь была принята не полностью, кусок потерян. Он должен или вспомнить, о чём говорил и переотправить, или нужно вести запись и переотправлять повторно речевые посылки файлами вместо потоков.
Речь не о том, на каких платформах реализуется использование OSTEL, но посредством каких софтфонов.
а там ситация такая: Client Applications
комментариев: 393 документов: 4 редакций: 0
Вчера я просмотрел историю его pull-request-ов (сегодня он уже объединил все в один окончательный) и проследил эволюцию его идеи. В самом первом реквесте была использована озвученная здесь рекомендация PlaySound(), но только для Windows-сборки; потом он изменил концепцию и решил кроссплатформенно синтезировать звук в виде синусоиды. Следующий логичный шаг на перспективу – отказаться от унылого синусоидального beep и синтезировать что-то политональное математически, или (проще) использовать статическую wav-таблицу, полученную с файла какого-нибудь гламурного рингтона.
Нет, именно TorPhone (не TorFone!): по ссылке под номером 10 (homebrew) в виде скрипта. По крайней мере оригинально.
Как то давно я задавал здесь вопрос о наличии не шифрованных сегментов в соединении между Tor-клиентом и HS, и по моему даже Вы мне ответили, что используется p2p шифрование на ефемеральном ключе, на которое наслаивается все остальное. Но при кривой настройке самого Mumble-сервера это, наверное, возможно, да.
Мне кажется, ребята просто не стали напрягаться. Я с самого начала поставил перед собой задачу изучить особенности Onion-окружения, выделить основные проблемы для пользователя, выяснить причины и по возможности принять меры для их устранения. Кроме того, в последнее время появились теоретические работы (в т.ч. диссертация, ссылку я приводил раньше), где авторы делали практически то же, за исключением самой реализации. Онионфон проектировался с учетом особенностей Onion, и большинство описанных Вами проблем успешно решает.
Во первых, Tor за последний год стал гораздо быстрее и стабильнее: средняя латентность соединения составила менее 500mS в сравнении с 1-2 сек пару лет назад. Jitter составил в среднем менее 100mS, за исключением спонтанных "замираний" каналов (непредсказуемо и очень ориентировочно раз в 5-10 минут).
Во вторых, соединение Tor-HS существенно стабильнее и менее латентно, чем Tor-Internet (я объясняю это меньшим количеством и большей загрузкой Exit-ов в сравнии с релеями). Модель Mumble также предполагает сервер (возможен и на HS) с подключенной парой клиентов, что удваивает латентность. Онионфон же сам является сервером для клиента-оригинатора.
Важным есть снижение общего трафика: Tor переформатирует пакеты и использует паддинг, в итоге (а может, и по другим причинам) прослеживается четкая зависимость между средним трафиком в kbps и средней латентностью в mS. Онионфон по умолчанию для Onion использует как компромисс кодек AMR на 4750 cbr, но в режиме DTX (встроенный голосовой детектор заменяет неголосовые фреймы на короткие дескрипторы комфортного шума аналогично сотовой связи). Таки образом, удалось достичь среднего трафика около 2000-2500 kbps при хорошем качестве речи. Соотношение качество/трафик также улучшается за счет предобработки звука (подавления шума и авторегулировки усиления микрофона).
Выбирая между отбрасыванием сильно задержанных фрагментов (в итоге будут потери речи) и их проигрыванием (будет накопления задержек, но без потерь), я использовал альтернативу: проигрываю все (без потерь), но динамически меняю темп проигрывания в зависимости от накопленного объема, таким образом корректирую реальную задержку, постоянно приближая ее к оптимальному значению. Оптимальное значение также динамическое, оно плавно меняется в зависимости от актуального Jitter установленного соединения.
Описанные алгоритмы (коефициенты, таймауты и т.д.) тщательно выверены путем многократных проб, анализа логов и поведения на разных Онион-каналах.
Кроме того, для борьбы со спонтанными замираниями используется дублирование Онион-соединения: оригинатор сообщает акцептору свой адрес, и акцепор устанавливает встречное соединение к оригинатору. Аналогично поступает и ТорЧат с целью аутентификации оригинатора по протоколу Abadi. Но ТорЧат в качестве активного использует только исходящее соединение, и это оправдано в его модели безопасности. Так как в Онионфоне реализована отдельная аутентификация и свой слой шифрования, то используются оба направления независимо: все отсылаемые пакеты дублируются в оба соединения. Т.к. ведется строгий учет полученных пакетов (ТСП – безпотерьный транспорт), и шифрование использует однонаправленный счетчик, то опоздавший дубль уже не будет аутентифицирован и будет просто отвергнут. Таким образом, если одно из соединений временно замерзает, второе продолжает работать.
Мало того, ведется статистика по каждому из соединений, и более медленное периодически (раз в несколько минут) согласованно перезапускается. Не могу сказать, на сколько это эффективно в плане снижения латентности (Entry guard тот же), но хуже не будет. В любом случае опция отключаемая.
Далее: если фрагмент все-таки теряется, я заменяю его комфортным шумом, т.о. пользователь в курсе. Ну, и введены автоматические сигналы окончания передачи PTT, что дает возможность не произносить постоянно "Прием". При использовании VAD это очень удобно и вполне сопоставимо с дуплексом. Вообще, алгоритм PTT – отдельная история, реализован оригинальный компромисс между минимализацией задержки с проигрыванием доставленного фрагмента и необходимостью некоторого первичного накопления для компенсации возможного последующего Jitter (предупреждение кратковременного перерыва тот-час после начала фразы). Опять же, все динамически подстраивается под характеристики канала.
Во время последних тестов я вообще иногда забывал, что использую Onion, а не прямое UDP.
Так что все возможно, если есть желание.
Но почему-то всего один, для входящих. А где же исходящий?
Интересно, в каком мире они живут, неужто никогда не пользовались обычным телефоном? ;)
Начни с себя – выложи свои паспортные данные, данные о доходах и собственности, медицинскую карту и рентгеновские снимки, информацию когда тебя нет дома и где хранишь деньги. Подай личный пример борьбы с несправедливостью режима.
Это как это?
Да, кстати. присоединяюсь к вопросу.
Ну как в обычном телефоне:
– ты звонишь – слышишь свои (исходящие) звонки (рингтоны),
– тебе звонят – слышишь чужие (входящие) звонки (рингтоны).
А пока токсовцы реализовали только второе, да и то только под Linux.