id: Гость   вход   регистрация
текущее время 16:24 20/08/2018
Автор темы: Гость, тема открыта 09/10/2014 23:38 Печать
Категории: криптография, софт, анонимность, приватность, инфобезопасность
http://www.pgpru.com/Форум/АнонимностьВИнтернет/ToxJitsiИДругие-КудыКрестянинуПодаться
создать
просмотр
ссылки

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-телефоном и может принести ее еще больше, если продолжит это полезнейшее занятие, за что ему огромное спасибо!


 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Комментарии
— gegel (18/10/2014 19:24, исправлен 18/10/2014 19:27)   профиль/связь   <#>
комментариев: 389   документов: 4   редакций: 0
у обоих на дисплее появляется ключ соединения

Это SAS (Anti-MitM проверочное значение, его надо зачитывать голосом друг другу), т.е. используется ZRTP.


Еще одно малоизвестное решение на питоне: TorPhone.
Источник тут.

— unknown (18/10/2014 21:46)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
А каково мнение по поводу библиотек проекта psjsip? Это бэкпортнули в текущий Debian — libpj2, libpjsip2 и пр.

Если код там качественный (не проверял), может есть смысл поддержать проект дополнительными наработками, а не изобретать всем велосипед, каждый раз переписывая код с нуля?
— gegel (18/10/2014 23:34)   профиль/связь   <#>
комментариев: 389   документов: 4   редакций: 0
pjsip – кроссплатформенная библиотека для SIP-клиентов, включающая аудиокодеки и видео. Ее используют множество SIP-клиентов, включая ​csipsimple – клиент, рекомендованный ранее упомянутым Ostel.

Это хорошая С-библиотека, я к ней присматривался давно, планируя надергать с нее кода для H264-видео.
Но, на сколько я понимаю, топикастер поднял другую тему – VOIP-решение с другой (не SIP) философией. Это требует ряда нестандартных решений, для которых нет готовых либ, связанных с VOIP: p2p соединения (по типу DHT, TorHS, i2p), медиа-протоколы на основе TCP (не UDP-RTP), навешенное на них крипто со специальными свойствами (дополнительная аутентификация, PFS).
Пока тут готовых вариантов нет. Можно использовать что-то специально написанное и жутко нестандартное типа Онионфона (предварительно для себя просмотрев код, в надежде, что пронесет с уязвимостями), или ждать, пока сообщество определится (свободно или под давлением?) и добавит что-то, например, в Tails, стандартизировав и выверив код. Опять же, никакой гарантии, что через пару лет не окажется, что SPRNG хитро выводит ерунду, прецедентов ведь масса.
— Гость (18/10/2014 23:54)   <#>
Свежая новость – "Ну тупые" иностранные люди, в отличие от "дружного славянского народа", не только поддерживают ветку по ринтонам, но уже даже представили рабочее решение по ним – https://github.com/notsecure/u.....ssuecomment-59596918
Теперь остается ждать, когда команда uTox внедрит его в очередную версию.
— gegel (19/10/2014 00:37, исправлен 19/10/2014 00:39)   профиль/связь   <#>
комментариев: 389   документов: 4   редакций: 0
Свежая новость

Оперативно срегировали :)

PlaySound(TEXT("ring.wav"), NULL, SND_FILENAME | SND_ASYNC);

Я так понял, для Линукс аналога не нашлось, что привело к

samples[ii] = 32760 * sin( (2.0*3.1415*freq)/sample_rate * ii );

Я в точности прошел этот путь, и следующим шагом было извлечение в wav-редакторе фрагмента с ring.wav и предcтавление в виде массива:
https://github.com/gegel/onion.....ob/master/ringwave.h


Все же звучит приятнее, чем просто beep.
Только там unsigned short, возможно потребуется привести к signed.

— Гость (19/10/2014 00:57)   <#>
Насколько понял, виновник торжества bob3434 вообще не использовал звуковые файлы.
И правильно сделал, имхо – лучше жесткая генерация звука, при которой шаловливым ручкам будет меньше мест где что подкрутить, подправить и ... испортить!
— Гость (19/10/2014 01:30)   <#>

Имеется ввиду Zfone?
глядя сюда "Источник wwwтут."

Так он рекомендуется для Андроид, а для других ОС свое (!)
— unknown (19/10/2014 02:01, исправлен 19/10/2014 02:10)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Торификация Mumble описана в вики со всеми сопутствующими замечаниями, в основном касающимися потенциальной небезопасности Mumble — всё таки это изначально игровой голосовой сервер и чат. Есть ещё один принципиальный момент. В большинстве примеров ставят некие серверы, в т.ч. голосовые в качестве обычных скрытых сервисов. Но как было ранее отмечено и подтверждено экспериментально, даже если никому не говорить адрес скрытого сервиса, то из-за несовершенства текущего протокола он становится известным в открытом виде узлам Tor. Разумеется, только onion-адрес, а не скрывающийся за ним IP. Для защиты от этого необходимо использовать специальную скрытую авторизацию клиентов. Иначе, если голосовй трафик не шифруется самой программой, а только криптографией самого тора, то можно предположить, что при некоторых настройках посторонний может подключиться к скрытому сервису и прослушать разговор в нешифрованом виде.



Да, начинали они понимая технические трудности, но с некоторым оптимизмом. А дальше разъяснили свою позицию в плане, почему это малоперспективная идея именно из-за технических трудностей. В общем случае, задержки составляют секунды, а при долгом разговоре в полнодуплексном режиме они будут только накапливаться. И между собеседниками могут создаться задержки уже на минуты, причём несимметричные (могут отличаться в разные стороны). Это же совершенно невыносимо: вы будете думать, что собеседник уже закончил реплику, захотите ему ответить, а он уже наговорил вперёд ещё на несколько минут. И никакого заговора и давления на разработчиков скорее всего здесь нет. Любой может сделать простейшее решение и объективно убедиться, что задержки речи совершенно неприемлемы и это скорее всего непреодолимая задача. Остаётся только полудуплексный режим рации (push-to-talk), который мало кому интересен. Это не просто неполноценный режим разговора («приём, over»), но и требует ещё больше терпения, чем в радио: наговоренный фрагмент может опять же накопить задержки в несколько минут, может быть потерян или надолго зависнуть. Придёться сообщить собеседнику, что его речь была принята не полностью, кусок потерян. Он должен или вспомнить, о чём говорил и переотправить, или нужно вести запись и переотправлять повторно речевые посылки файлами вместо потоков.



Have a device in your pocket or on your desk? Then you can make a call with Ostel. We work on Android, iPhone, Blackberry, Nokia, Mac, PC, and Linux through supported apps.
— Гость (19/10/2014 02:42)   <#>

Речь не о том, на каких платформах реализуется использование OSTEL, но посредством каких софтфонов.
а там ситация такая: Client Applications
— gegel (19/10/2014 14:23, исправлен 19/10/2014 14:35)   профиль/связь   <#>
комментариев: 389   документов: 4   редакций: 0
Насколько понял, виновник торжества bob3434 вообще не использовал звуковые файлы

Вчера я просмотрел историю его pull-request-ов (сегодня он уже объединил все в один окончательный) и проследил эволюцию его идеи. В самом первом реквесте была использована озвученная здесь рекомендация PlaySound(), но только для Windows-сборки; потом он изменил концепцию и решил кроссплатформенно синтезировать звук в виде синусоиды. Следующий логичный шаг на перспективу – отказаться от унылого синусоидального beep и синтезировать что-то политональное математически, или (проще) использовать статическую wav-таблицу, полученную с файла какого-нибудь гламурного рингтона.


Имеется ввиду Zfone?

Нет, именно 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.
Так что все возможно, если есть желание.

— Гость (19/10/2014 21:58)   <#>
Gegel, а про файрфоксовский клиент что можете сказать? Кроме того, что он не использует TOR. Но думаю в TorBrowser этот клиент со временем попадет, и будет всё в одном флаконе.

В браузер добавлена функция Firefox Hello с реализацией аудио- и видеочата, построенного с использованием технологии WebRTC и доступного для вызова через меню. Реализация примечательна тем, что позволяет напрямую организовать канал связи между двумя браузерами с поддержкой WebRTC без передачи трафика через промежуточные серверы, без установки внешних плагинов, на любых устройствах и операционных системах. Поддерживается соединение с любым браузером, поддерживающим WebRTC, в том числе с Chrome и Opera.

Для упрощения установки соединений рекомендуется завести учётную запись в Firefox Account, после чего можно совершать и принимать звонки от других зарегистрированных пользователей. При этом для работы с Firefox Hello можно обойтись и без заведение учётной записи, установка соединения может производиться через отправку ссылки. Имеется встроенная реализация адресной книги, позволяющая сохранять наиболее востребованные контакты, в том числе поддерживается импорт контактов из адресной книги Google. Для занесённых в адресную книгу пользователей, у которых имеется учетная запись в службе Firefox Account, автоматически высвечивается статус доступности абонента. Добавить значок чата на панель можно через блок кастомизации в меню.

Код чата построен с использованием платформы OpenTok, предоставляющей средства для организации прямой передачи видео между пользовательскими системами. Для организации безопасного шифрованного P2P-соединения между браузерами применяются API PeerConnection и DataChannels с использованием шифрованного транспортного протокола DTLS-SRTP и системы организации установки сетевых соединений ICE. Для передачи контента применяются аудиокодек Opus и видеокодек VP8.

— Гость (20/10/2014 19:44)   <#>
Разрабы uTox совершили, наконец, невероятный по сложности рывок в будущее – прикрутили рингтон :))
Но почему-то всего один, для входящих. А где же исходящий?
Интересно, в каком мире они живут, неужто никогда не пользовались обычным телефоном? ;)
— Гость (20/10/2014 22:13)   <#>
Нет, так не пойдёт, либо все в одежде, либо все голые.

Начни с себя – выложи свои паспортные данные, данные о доходах и собственности, медицинскую карту и рентгеновские снимки, информацию когда тебя нет дома и где хранишь деньги. Подай личный пример борьбы с несправедливостью режима.
— Гость (20/10/2014 22:55)   <#>

Это как это?

Да, кстати. присоединяюсь к вопросу.
— Гость (21/10/2014 01:27)   <#>

Ну как в обычном телефоне:
– ты звонишь – слышишь свои (исходящие) звонки (рингтоны),
– тебе звонят – слышишь чужие (входящие) звонки (рингтоны).

А пока токсовцы реализовали только второе, да и то только под Linux.
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3