id: Гость   вход   регистрация
текущее время 10:51 18/06/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 След.
Комментарии
— ZAS (21/10/2014 02:26)   <#>
Важным есть снижение общего трафика: Tor переформатирует пакеты и использует паддинг, в итоге (а может, и по другим причинам) прослеживается четкая зависимость между средним трафиком в kbps и средней латентностью в mS.


Логично. Для уменьшения оверхеда TCP пакует данные во фреймы большего размера.


Онионфон по умолчанию для Onion использует как компромисс кодек AMR на 4750 cbr, но в режиме DTX (встроенный голосовой детектор заменяет неголосовые фреймы на короткие дескрипторы комфортного шума аналогично сотовой связи). Таки образом, удалось достичь среднего трафика около 2000-2500 kbps при хорошем качестве речи. Соотношение качество/трафик также улучшается за счет предобработки звука (подавления шума и авторегулировки усиления микрофона).


Оверхед TCP или UDP что-то порядка 40 байт на пакет. Если кодек выдает пакеты данных раз в 20ms, то чисто оверхед протокола составляет по крайней мере 16 kbps. Стоит ли бороться за скорость кодека на фоне протокольного оверхеда?
Конечно, при ожидаемых задержках в канале более пол-секунды, можно cклеивать на передающей стороне по десятку пакетов кодека в один фрейм и уменьшить оверхед ибо ничего не ухудшит. Но зачем DTX – это же общеизвестная проблема с безопасностью?

Далее: если фрагмент все-таки теряется, я заменяю его комфортным шумом, т.о. пользователь в курсе. Ну, и введены автоматические сигналы окончания передачи PTT, что дает возможность не произносить постоянно "Прием". При использовании VAD это очень удобно и вполне сопоставимо с дуплексом.


Настоящий дуплекс незаменим. Возможность перебить собеседника важна.

Кроме того, для борьбы со спонтанными замираниями используется дублирование Онион-соединения: оригинатор сообщает акцептору свой адрес, и акцепор устанавливает встречное соединение к оригинатору.


То есть удваиваем оверхед и дополнительно демаскируем друг друга. За что боролись?

Т.к. ведется строгий учет полученных пакетов (ТСП – безпотерьный транспорт), и шифрование использует однонаправленный счетчик, то опоздавший дубль уже не будет аутентифицирован и будет просто отвергнут. Таким образом, если одно из соединений временно замерзает, второе продолжает работать.


По двум цепям хорошо бы установить два разных соединения, на разных ключах. Отсеивать дупы на следующем уровне протокола.

http://www.zas-comm.ru
— gegel (21/10/2014 11:42, исправлен 21/10/2014 11:44)   профиль/связь   <#>
комментариев: 389   документов: 4   редакций: 0
можно cклеивать на передающей стороне по десятку пакетов кодека в один фрейм

Именно так и склеиваю, причем разное фиксированное количество элементарных фреймов для каждого кодека: чем ниже битрейт, тем больше голосовая длина одиночного TCP-пакета в mS. Например, для AMR склеиваю именно 10 фреймов по 20 mS каждая. В итоге имеем дополнительную задержку в 200 mS, но на фоне Tor-задержек в общем выигрываем с латентностью по сравнению с передачей 10 пакетов по 20 mS каждый.


Но зачем DTX – это же общеизвестная проблема с безопасностью?

Имея озвученную кем-то абстрактную проблему, стоит сначала оценить условия ее проявления. Фонемная реконструкция эффективна только при коротких фреймах в случае настоящего VBR. Уже на 60mS фреймах OPUS реконструкция непрактична. А при склеивании, скажем, 10 VBR-фреймов в одном пакете на 200 mS никакой реконструкции просто быть не может. А что касается DTX, то там все еще лучше: есть всего два варианта: голос (длинный фиксированный фрейм) и тишина (короткий фиксированный), т.е. утечка 1 бита на фрейм. А еще используется хвост: шумовые дескрипторы начинают передаваться только после определенного количества подряд безголосых фреймов. А если еще и склеивать по 10 фреймов в пакете...


Настоящий дуплекс незаменим. Возможность перебить собеседника важна.

В Онионфоне не совсем симплекс: входящий канал работает постоянно, так что возможность перебить есть всегда. Смысл PTT – максимально снизить трафик, тем самым минимизируя латентность, сбрасывать накопленные задержки. Имея DTX, на который наложен еще и VOX, получаем минимальный трафик с определенной иллюзией дуплекса.


То есть удваиваем оверхед и дополнительно демаскируем друг друга. За что боролись?

Оверхем удваивается, но по двум разным цепочкам. Боролись за минимизацию трафика по каждой из Tor-цепочек. Общий трафик никого не интересует, в принципе можно организовать хоть 100 цепочек и пускать по ним массу дублей и кусков, в зависимости от их состояния: я эту модель предлагал для видео.
Что касается демаскировки, то это вопрос спорный, и ответа на него я так и не получил. Поэтому опция дублирования отключаема.


По двум цепям хорошо бы установить два разных соединения, на разных ключах.

По уму да. И паддинг отдельный применять. Но, опять же, до прояснения картины с демаскировкой встречными цепочками я не стал это делать. "Дикую" анонимность никто и не обещал, это нереально в низколатентной среде с регулярными пакетами. Многих вообще бы устроили VOIP-Tor-цепочки из двух нод вместо трех – все же лучше, чем p2p или TURN.


Gegel, а про файрфоксовский клиент что можете сказать?

Я не специалист по веб-технологиям. Но на вскидку видны нестывковки.


применяются API PeerConnection и DataChannels с использованием шифрованного транспортного протокола DTLS-SRTP

SRTP требует согласования ключа. Как в данном случае производится согласование между браузерами? Через DTLS? Тогда чем аутентифицируется (защищается от MitM) (обычно в клиент-серверной модели это делается именными сертификатами с их проверкой до доверенных, но между браузерами то как?). Уж не через сервер ли Мозиллы, под честное-пречестное слово? :)


Интересно, как они проходят NAT? (ZAS подтвердит, что это не так просто). Уж не тот же сервер Мозиллы им помогает, незаметно логируя все, включая то, что браузеры смогли натянуть с системы? Стоит попробовать запустить два браузера на компах в локалке, изолированной от интернет, и посмотреть, как они будут соединяться по сгенерированным ими ключам. А также запустить WireShark и посмотреть, куда и что уходит.


Вообще-то браузерные технологии и безопасность мало совместимы: в этой реализации гораздо больше возможностей для прослушки и слежки, чем даже у Скайпа: последний все же в начале задумывался как действительно защищенное VOIP.


Но думаю в TorBrowser этот клиент со временем попадет, и будет всё в одном флаконе.

Никогда (по крайней мере до тех пор, пока не введут поддержку UDP на Tor HS). Это только я и подобные могут наплевать на стандарты и пустить медиапоток по TCP, нацарапав собственный протокол (так же сделали разрабы Скайп в свое время, отказавшись от RTP/SRTP в пользу проприеретарного решения). В браузер никогда не введут TCP-медиапротокола до его стандартизации, а это очень длинный путь.

— unknown (21/10/2014 14:11)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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

Ты дурак или притворяешься? Мои паспортные данные и прочие сведения уже давно в разных базах находятся. Речь о том, чтобы все эти базы законно опубликовать в Интернете. Чтобы любой желающий имел доступ через веб-интерфейс или мог скачать дамп для работы на домашнем компьютере. После этого каждый задумается о важности персональных данных, заодно и число пользователей тора повысится.
— gegel (21/10/2014 19:58)   профиль/связь   <#>
комментариев: 389   документов: 4   редакций: 0
Типа такого?

Спасибо за ссылку: оказывается, все есть. По ссылке rfc на TCP ICE (проход NAT-ов TCP-транспортом). Это сложная проблема и далеко не всегда выполнима, но, собственно в контексте VOIP over Tor это не нужно, т.к. уже имеется прямое соединение с HS. Достаточно прикрутить RTP over TCP.

Но тогда cовсем непонятно, если стандарт на TCP-media есть с 2006 года, то почему нет реализации в конкретных VOIP-решениях? В принципе, я не увидел ничего сложного, что мешало бы прикрутить это как альтернативный протокол к Онионфону. Только все равно другие популярные клиенты это не поддерживают.
— Гость (29/10/2014 16:25)   <#>
Если отбросить криптозащищенность трафика (в Jitsi она вроде получше), то в каком телефоне анонимность выше – в Jitsi или uTox?
В смысле отслеживания кто с кем разговаривает, т.е. IP.
— Гость (01/11/2014 03:46)   <#>
Тоже интересует этот вопрос, и сдается что Tox дает лучшую анонимность потому что работает по DHT, типа пиринга, поэтому не поймешь толком кто с кем разговаривает.
А в XMPP сразу ясно, два потока – один на jabber сервер, другой между собеседниками – все как на ладони.
— Гость (12/11/2014 13:31)   <#>
А в DHT Tox'а хранятся сразу IP-адреса клиентов.
— Гость (12/11/2014 22:32)   <#>
Поставил uTox на Debian 6 и вылезла ошибка:
utox: /lib/i686/cmov/libpthread.so.0: version `GLIBC_2.12' not found (required by utox)
— unknown (13/11/2014 09:49)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
А не обновлялись до 2.13-38+deb7u6?
— Гость (13/11/2014 11:16)   <#>
При обновлении вылетает:
"Error: Breaks existing package 'libc-dev-bin' dependency libc6 (< 2.12)"

Пакет libc-dev-bin существует.
— Гость (13/11/2014 11:19)   <#>
ЗЫ Установлен то он установлен, но версия 2.11.3-4.
Для squeeze я так понял новее нет
— unknown (13/11/2014 12:20)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Squeeze — давно oldstable, на него сложно ставить что-то со стороны, не входящее в дистрибутив. А обновить libc — это равносильно поломатьобновить всю систему.
— Гость (13/11/2014 12:49)   <#>
Что-то подсказывало, что именно так дело и обстоит. Видимо пришло время переходить на 7.
— Гость (20/11/2014 00:32)   <#>
Испробовал работу uTox в сети Tor.

В 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. Другое
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3