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-телефоном и может принести ее еще больше, если продолжит это полезнейшее занятие, за что ему огромное спасибо!
Оверхед TCP или UDP что-то порядка 40 байт на пакет. Если кодек выдает пакеты данных раз в 20ms, то чисто оверхед протокола составляет по крайней мере 16 kbps. Стоит ли бороться за скорость кодека на фоне протокольного оверхеда?
Конечно, при ожидаемых задержках в канале более пол-секунды, можно cклеивать на передающей стороне по десятку пакетов кодека в один фрейм и уменьшить оверхед ибо ничего не ухудшит. Но зачем DTX – это же общеизвестная проблема с безопасностью?
Настоящий дуплекс незаменим. Возможность перебить собеседника важна.
То есть удваиваем оверхед и дополнительно демаскируем друг друга. За что боролись?
По двум цепям хорошо бы установить два разных соединения, на разных ключах. Отсеивать дупы на следующем уровне протокола.
http://www.zas-comm.ru
комментариев: 393 документов: 4 редакций: 0
Именно так и склеиваю, причем разное фиксированное количество элементарных фреймов для каждого кодека: чем ниже битрейт, тем больше голосовая длина одиночного TCP-пакета в mS. Например, для AMR склеиваю именно 10 фреймов по 20 mS каждая. В итоге имеем дополнительную задержку в 200 mS, но на фоне Tor-задержек в общем выигрываем с латентностью по сравнению с передачей 10 пакетов по 20 mS каждый.
Имея озвученную кем-то абстрактную проблему, стоит сначала оценить условия ее проявления. Фонемная реконструкция эффективна только при коротких фреймах в случае настоящего VBR. Уже на 60mS фреймах OPUS реконструкция непрактична. А при склеивании, скажем, 10 VBR-фреймов в одном пакете на 200 mS никакой реконструкции просто быть не может. А что касается DTX, то там все еще лучше: есть всего два варианта: голос (длинный фиксированный фрейм) и тишина (короткий фиксированный), т.е. утечка 1 бита на фрейм. А еще используется хвост: шумовые дескрипторы начинают передаваться только после определенного количества подряд безголосых фреймов. А если еще и склеивать по 10 фреймов в пакете...
В Онионфоне не совсем симплекс: входящий канал работает постоянно, так что возможность перебить есть всегда. Смысл PTT – максимально снизить трафик, тем самым минимизируя латентность, сбрасывать накопленные задержки. Имея DTX, на который наложен еще и VOX, получаем минимальный трафик с определенной иллюзией дуплекса.
Оверхем удваивается, но по двум разным цепочкам. Боролись за минимизацию трафика по каждой из Tor-цепочек. Общий трафик никого не интересует, в принципе можно организовать хоть 100 цепочек и пускать по ним массу дублей и кусков, в зависимости от их состояния: я эту модель предлагал для видео.
Что касается демаскировки, то это вопрос спорный, и ответа на него я так и не получил. Поэтому опция дублирования отключаема.
По уму да. И паддинг отдельный применять. Но, опять же, до прояснения картины с демаскировкой встречными цепочками я не стал это делать. "Дикую" анонимность никто и не обещал, это нереально в низколатентной среде с регулярными пакетами. Многих вообще бы устроили VOIP-Tor-цепочки из двух нод вместо трех – все же лучше, чем p2p или TURN.
Я не специалист по веб-технологиям. Но на вскидку видны нестывковки.
SRTP требует согласования ключа. Как в данном случае производится согласование между браузерами? Через DTLS? Тогда чем аутентифицируется (защищается от MitM) (обычно в клиент-серверной модели это делается именными сертификатами с их проверкой до доверенных, но между браузерами то как?). Уж не через сервер ли Мозиллы, под честное-пречестное слово? :)
Интересно, как они проходят NAT? (ZAS подтвердит, что это не так просто). Уж не тот же сервер Мозиллы им помогает, незаметно логируя все, включая то, что браузеры смогли натянуть с системы? Стоит попробовать запустить два браузера на компах в локалке, изолированной от интернет, и посмотреть, как они будут соединяться по сгенерированным ими ключам. А также запустить WireShark и посмотреть, куда и что уходит.
Вообще-то браузерные технологии и безопасность мало совместимы: в этой реализации гораздо больше возможностей для прослушки и слежки, чем даже у Скайпа: последний все же в начале задумывался как действительно защищенное VOIP.
Никогда (по крайней мере до тех пор, пока не введут поддержку UDP на Tor HS). Это только я и подобные могут наплевать на стандарты и пустить медиапоток по TCP, нацарапав собственный протокол (так же сделали разрабы Скайп в свое время, отказавшись от RTP/SRTP в пользу проприеретарного решения). В браузер никогда не введут TCP-медиапротокола до его стандартизации, а это очень длинный путь.
комментариев: 9796 документов: 488 редакций: 5664
Типа такого?
Ты дурак или притворяешься? Мои паспортные данные и прочие сведения уже давно в разных базах находятся. Речь о том, чтобы все эти базы законно опубликовать в Интернете. Чтобы любой желающий имел доступ через веб-интерфейс или мог скачать дамп для работы на домашнем компьютере. После этого каждый задумается о важности персональных данных, заодно и число пользователей тора повысится.
комментариев: 393 документов: 4 редакций: 0
Спасибо за ссылку: оказывается, все есть. По ссылке rfc на TCP ICE (проход NAT-ов TCP-транспортом). Это сложная проблема и далеко не всегда выполнима, но, собственно в контексте VOIP over Tor это не нужно, т.к. уже имеется прямое соединение с HS. Достаточно прикрутить RTP over TCP.
Но тогда cовсем непонятно, если стандарт на TCP-media есть с 2006 года, то почему нет реализации в конкретных VOIP-решениях? В принципе, я не увидел ничего сложного, что мешало бы прикрутить это как альтернативный протокол к Онионфону. Только все равно другие популярные клиенты это не поддерживают.
В смысле отслеживания кто с кем разговаривает, т.е. IP.
А в XMPP сразу ясно, два потока – один на jabber сервер, другой между собеседниками – все как на ладони.
utox: /lib/i686/cmov/libpthread.so.0: version `GLIBC_2.12' not found (required by utox)
комментариев: 9796 документов: 488 редакций: 5664
"Error: Breaks existing package 'libc-dev-bin' dependency libc6 (< 2.12)"
Пакет libc-dev-bin существует.
Для squeeze я так понял новее нет
комментариев: 9796 документов: 488 редакций: 5664
поломатьобновить всю систему.В uTox есть возможность работы под SOCKS 5.
В качестве SOCKS 5 использовал запущеный Tor Browser v4.0.1.
uTox настроил на 127.0.0.1 и порт 9150.
UDP пока не использовал.
Получилась не только анонимизирующая модель общения (непонятно, кто с кем и откуда разговаривает, поскольку выход на exit-node не используется), но и с двойным слоем шифрования трафика – uTox + Tor.
Качество речи вполне преемлемое, точнее сказать – оно вообще не поменялось по сравнению вариантом без Tor.
Однако есть и недостатки – речь периодически прерывается, и приходится повторять сказанное.
Каковы ваши рекомендации по уменьшению прерывистости? (в порядке приоритетности)
1. Включить в uTox опцию UDP
2. Настроить TBB на работу с предпочтительными узлами (какими?)
3. Поднять свой релейный узел и настроить TBB на работу с ним
4. Другое