id: Гость   вход   регистрация
текущее время 05:08 29/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, ... , 5, 6, 7, 8, 9, ... , 50 След.
Комментарии
— Гость (15/02/2013 12:19)   <#>
А можно ли настроить скрытый сервис так, чтобы даже при известном .onion доступ к нему мог идти только по паролю (чтобы, например, не заDDOSили канал)?
— unknown (15/02/2013 13:05, исправлен 15/02/2013 13:07)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Наглядно показано как взламывают fileголосовое шифрование в стандартных программах, которые используют сжатие голоса.


Всё-таки для VoIPoTor пока лучше всего подходит mumble, ссылка на который в форуме уже была.


А можно ли настроить скрытый сервис так, чтобы даже при известном .onion доступ к нему мог идти только по паролю

Именно для этого эти опции и предназначены. Более того, там есть два варианта: "не знает пароль, но сможет узнать, что сервер запущен, но не сможет туда попасть" и "не знает пароль и без этого даже не сможет определить, запущен ли этот скрытый сервис в Tor или нет".


Обсуждалось здесь.

— gegel (15/02/2013 23:02)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Сорри, давно не заходил. Постараюсь ответить по очереди.

Повторно перепроверил под Wine – у меня все ОК. Причину не могу понять, т.к. досконально с Wine не знаком, но ошибка однозначно возникает из-за невозможности создать/биндить tcp-сокет на указанный IP:port. Замечание о задержке при создании сокета принято – учту. Используйте 0.0.0.0, если IP динамический: это стандартный вариант. Если есть возможность, проверьте, возникает ли при этом ошибка. Указание конкретного IP может понадобиться только лишь в экзотических тестовых случаях.

Чат/форум на сайте – хорошая идея, прикручу как нибудь. Пока спасибо комьюнити на pgpru за возможность обсуждения.
Порт под Андроид сам пока не осилю (нет опыта, хотя хочу попробовать), под линукс уже думаю, как лучше.

По поводу описанных вариантов анонимной связи: есть множество возможностей, но в любом случае надо сделать все доступно обычному юзеру. Чем проще в установке и пользовании, тем лучше. А два профессионала всегда найдут способ для себя.

По поводу AES – прикрутить его вобще нет проблем. Я полностью разобрался с процедурой шифрования: используется CTR, счетчик инкрементируется с каждым пакетом. В составе пакета передается TimeStamp, который определяет валидность пакета. Т.е. можно легко заменить 3DES на AES, и от этого только выиграет быстродействие. Но зачем? 3DES проверен временем и не уступает AES по надежности. Тем более что на момент разработки 3DES точно не думали о потайных ходах. Для себя я бы предпочел 3DES...

По взлому голосового шифрования (по ссылке): я уже отвечал вначале ветки. Данная уязвимость базируется на переменной длине голосовых пакетов. PGPFone использует GSM-кодек: захватывает сэмплы с частотой, скажем, 7350 слов/сек, разбивает на блоки по 160 слов и кодирует в блоки по 33 байта, и отсылает их по 4 шт в пакете. Хоть говоришь, хоть молчишь, трафик равномерный. Так что описанная уязвимость в данном случае неактуальна.

Mumble? Это оригинальный вывод, учитывая, что она вобще не шифрует трафик. Конечно, ТОР все сам шифрует до HS, но зачем тогда говорить об уязвимостях PGPFone? Кроме того, она использует внешний сервер murmur (т.е. не p2p): если его запускать в открытой сети, то без шифрования никак, если на HS, то между абонентами уже не 6, а 12 нод. Да и контролирующий сервер слушает все. На guardianproject.info ее просто используют для тестов, но, судя по постам n8fr8, задумывают они совсем другой вариант.
— Гость (16/02/2013 04:17)   <#>

Золотые слова! :)


Гм. А зачем тогда в инструкции рекомендовано сменить 0.0.0.0 на реальный айпишник, если проще ничего не менять, оставив эти нули?
— gegel (16/02/2013 15:42, исправлен 16/02/2013 15:51)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

Виноват, невнятно написал. По умолчанию создается ini с параметром ListenAddr:Prt=127.0.0.1:17447, что дает возможность слушать только HS и защищает от деанонимизации путем обнаружения TORFone напрямую извне. А значение 0.0.0.0 (INADDR_ANY) на скриншоте в инструкции – уже отредактированное, а не требующее редактирования.
Т.е. там просто рекомендуется сменить 127.0.0.1 на 0.0.0.0


Использовать конкретный IP может понадобиться, например, если у Вас поднята Hamachi, и Вы хотите общаться только через нее, но не хотите быть доступными из интернета (а на компьютере внешний IP), и т.п.


Еще раз сорри, просто когда сам "варишься" в этом, порой трудно предположить, как оно может быть истолковано другими.

— Гость (17/02/2013 02:17)   <#>
Уважаемый gegel, можете внести эти свои последние разъяснения по поводу вариантов Фиспользования айпишника прямо в файл справки testingru.pdf на вашем сайте?
Ведь при работе приходится ориентироваться на него, и получаются разночтения и путаница.
Спасибо!
— gegel (17/02/2013 12:30)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Заменил в testing1.pdf и testingru1.pdf
— alex_10 (17/02/2013 15:11)   <#>
@ GEGEL
There is a lot of people asking for a modified version of the speakfreely
http://sourceforge.net/p/advto.....231/thread/9d735faa/
can you do something ?
— michel_25 (17/02/2013 16:24)   <#>
Уважаемый gegel
Существует много людей просят модифицированную версию speakfreely
http://sourceforge.net/p/advto.....231/thread/9d735faa/
Вы можете что-нибудь сделать?
Спасибо!
— unknown (17/02/2013 17:49, исправлен 17/02/2013 17:54)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Mumble? Это оригинальный вывод, учитывая, что она вобще не шифрует трафик. Конечно, ТОР все сам шифрует до HS, но зачем тогда говорить об уязвимостях PGPFone? Кроме того, она использует внешний сервер murmur (т.е. не p2p): если его запускать в открытой сети, то без шифрования никак, если на HS, то между абонентами уже не 6, а 12 нод. Да и контролирующий сервер слушает все. На guardianproject.info ее просто используют для тестов, но, судя по постам n8fr8, задумывают они совсем другой вариант.

Да идея, изначально положенная в архитектуру Tor, даёт возможности делать многие более сложные вещи несколько проще и красивее. VoIP просто частный пример. Который концептуально хорошо бы намертво привязать к тору и не давать возможности прямых звонков через интернет из-за опасности смешивания контекстов анонимности и раскрытия круга контактов от внешнего наблюдателя.


Предположим, Алиса хочет принять звонок от Боба. Между собой они в большой степени доверяемы и не анонимны, им важно скрыть содержимое и факт связи от внешнего наблюдателя.


Рассмотрим приём звонков Алисы от Боба.


  1. Алиса запускает локально на своей машине скрытый сервис (HS) с возможностью авторизации Боба (HS authorization protocol).
  2. Алиса запускает локально на своей машине VoIP-сервер. С помощью файрволла она его "заторивает", так чтобы он работал только через свой скрытый сервис Tor и был невидим из обычного интернета. Для доп. защиты виртуалки, псевдовиртуалки, SELinux и пр. — добавлять по вкусу, но вообще-то Алиса и Боб другу другу более-менее доверяют и рассчитывают, что друг друга они ломать не будут. А посторонний в их канал вклиниться не может. Так что уязвимости в запускаемых сервисах, конечно нежелательны, но не столь критичны и определяются доверием между абонентами.
  3. Боб использует заторенный VoIP-клиент, чтобы сделать звонок на HS и VoIP-сервер Алисы. Для инициализации звонка ему не нужен свой сервер. Сервер нужен только стороне, принимающий звонок (в данный момент Алисе).
  4. Алиса принимает звонок из тора на свой HS и локально запущенный VoIP-сервер.
  5. У Алисы запущен VoIP-клиент, который принимает сообщения с локального хоста (127.0.0.1) только от своего VoIP-сервера и общается только с ним. VoiP-клиент Алисы может быть на всякий случай ещё и заторен, когда ей понадобиться не только принимать звонки от собственного локального VoIP-сервера, но и звонить кому-то ещё. Но в данном примере используется только связь с локальным хостом для приёма звонка.
  6. Алиса принимает звонок по цепочке [Bob] — [VoIP-client]Bob — [Tor] — [HS]Alice — [VoIP server]Alice — [localhost 127.0.0.1]Alice — [VoIP client]Alice — [Alice]. Если Боб хочет принимать звонки от Алисы, то он проделывает весь описанный процесс, начиная с п.1, запуская свой локальный скрытый торифицированный VoIP-сервер и подставляя себя во все пункты вместо Алисы и наоборот.

Как видим, не через какие лишние узлы цепочек трафик не идёт.


Mumble скорее всего выбрали потому, что там легко настраиваемый VoIP-сервер и клиент. Плюс push-to-talk (режим рации), экономный кодек для TCP, встроенный чат и пр. Безопасность этого сервера на первом этапе малоинтересна, это вообще игровая поделка, которая удачно подходит для экспериментов.


Доп. шифрования данных не нужно, т.к. всё и так завязано на безопасность шифрования внутри самого Tor, но при желании такие решения могут быть навешены в более общих случаях.


Можно подумать и о перспективах развития предложенного общего алгоритма.


  1. По этой схеме двум сторонам можно запустить локальным скрытым сервисом любой сервер: чат, почту, веб, wiki, блоги и пр.
  2. Можно вынести сервер и скрытый сервис на домашний, корпоративный сервер в пределах помещения (связь в пределах своей подконтрольной локалки), чтобы обращаться к нему с разных компьютеров и гаджетов.
  3. Можно прописать в авторизации скрытого сервиса более одного доверяемого пользователя (Боб, Кэрол, Дейв и далее по стандартному списку имён по алфавиту). Получается, что запуская различные сервисы для ограниченного круга лиц и невидимые посторонним, пользователи создают F2F-сеть — Friend to Friend.

Доп. свойства и соображения по поводу F2F-сетей на базе Tor:


  1. В отличие от готовых решений для F2F-сетей, такая сеть гибка, универсальна, псевдонимна (не путать анонимность с псевдонимностью), скрыта от постороннего наблюдателя (неотслеживаемость).
  2. Децентрализованность в пределах Tor.
  3. Отсутствие возможности не только внешнему, но внутреннему наблюдателю для выявления всего круга контактов и построения графа социальных связей (скрытость сегментированности и связности): Алиса знает Боба и включает его в свой круг авторизованных контактов на скрытом сервисе. Боб знает ещё Кэрол и включает в свой авторизационный список Алису и Кэрол. Алиса и Кэрол ничего не знают друг о друге и о том, что Боб общается с ними обеими, пока Боб это сам не захочет раскрыть. Любой член сети может сам управлять доверием, раскрывать часть своих контактов, искать нужных людей, распространять информацию, запрашивать помощи через своих знакомых. Но никакой внешний наблюдатель или внутренний "предатель" не сможет раскрыть всю сеть без получения согласия её участников. Даже сам участник не может легко обойти круг своих социальных контактов дальше первого звена.
  4. Эфемерность данных. Данные, передаваемые по сети, хранятся только у её участников (если они хотят их хранить или уничтожать — каждый сам волен распоряжаться хранением полученных/отправленных данных).
  5. Возможность управления эфемерностью контактов и связей. Достаточно удалить или сменить авторизационный ключ и/или адрес персонального скрытого сервиса, как сведения о ранее переданных/полученных контактах с этого адреса теряются. Скрывается факт раннего участия в контактах, сетях и пр.
  6. Наперёд заданная секретность. В случае взлома или конфискации сервиса агента сети (в случае его провала) можно просмотреть только неудалённые персональные контакты и контролировать только будущие передаваемые данные. Сведения о ранее переданных данных и удалённых контактах принципиально невосстановимы, если пользователь грамотно осуществлял их уничтожение.
  7. Лёгкость бесследной самоликвидации сети при отсутствии в ней дальнейшей необходимости. Тут уж правда как участники договорятся: если они все друг друга знают по общему делу — всем разойтись или прерывать контакты по одиночке. Опять же — саморегуляция на основе собственных желаний пользователей без возможности контроля и надзора третьей стороны.
  8. Относительная лёгкость повторного разворачивания сети после компрометации: достаточно исключить недоверяемых лиц и сменить список адресов скрытых сервисов и авторизационных ключей.
  9. Лёгкость завязывания временных полуанонимных контактов. Можно временно подключить любого человека к своему скрытому сервису для приватного общения и затем сразу же удалить следы контакта с ним.
  10. Возможность образования скрытых сообществ, социальных сетей и получения мостов между ними за счёт шлюзов, посредников и пр.

В принципе, зачатки этого всего есть в сетях, подобных Freedom/I2P за счёт наличия встроенных сервисов из коробки. На базе Tor можно организовать более мощные, правда труднонастраиваемые и пока малоисследованные решения.


Хотя какую-нибудь простую штуку такого типа могли бы включить в отдельную Tor-сборку для использования "из коробки".

— Гость (17/02/2013 19:44)   <#>

Точно? :) Пытаюсь сравнить старый и новый файл, и не нахожу между ними никакой разницы.
Во всяком случае первые страницы руководства "один в один".
Может, не там ищу?
— Гость (17/02/2013 23:48)   <#>

По ссылке:
The developer of TOR Fone recommends against using TOR Fone. Quote: "I did not think this project as a finished product for practical use." The project got overall a pretty bad review in the mailing list thread.
:)
— gegel (18/02/2013 03:17, исправлен 18/02/2013 03:34)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

Шо ж с этой mumbl-ой так носятся... Наверное, naif не совсем равнодушен :) Главное, что расшевелились немного. Я ж не вчера родился, и все это прошел на других своих проектах. Жизнь покажет. Крутые парни сами решат, что им пользовать, не особо слушая такие рекомендации, а хомячки все равно на Скайпе останутся... В общем, собака лает, а караван идет :)


"Mumble скорее всего выбрали потому, что там легко настраиваемый VoIP-сервер и клиент. Плюс push-to-talk (режим рации), экономный кодек для TCP, встроенный чат и пр. Безопасность этого сервера на первом этапе малоинтересна, это вообще игровая поделка, которая удачно подходит для экспериментов."

: вот я тоже думаю, что все это в точности есть в TORFone и еще в десятке приложений, но они все плохие. А хороший жавовский Jitsi после дефолтной инталляции сразу лезет на сервер обновляться... Так может, просто гранты оправдать надо?


To alex_10 & michel_25: сейчас именно SpeakFreely и занимаюсь. Архитектура там немного другая, так что не сразу сделаю, тем более, что занимаюсь в свободное время. Можно также попробовать опционно прикрутить к SpeakFreely DH4096 от PGPFone (т.к. изначально там только Preshared key или PGP). И еще можно попробовать добавить "ручной" обход NAT для неанонимного режима (получая данные от любого STUN и предварительно обмениваясь ими например через любой мессенжер на Tor c OTR).


В руководстве поправил рисунок на первой странице и подпись к нему, смотрите внимательно. Если что-то еще желательно изменить, уточните – сделаю.


To unknown: полностью согласен и поддерживаю. Но в реале это не только не развивается, а, наоборот, сдерживается. Например, тот же TorChat – прекрасное приложение, предельно простое и востребованное. Добавить голос, видео – вполне решаемо даже для одного разработчика. И не надо ни мумбл, ни локального сервера. Но похоже, играют роль совсем другие маркетинговые интересы, о которых можно только догадываться.

— unknown (18/02/2013 10:25)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Команда торпроджекта не против торчата в принципе. Они вскользь озвучивали свою позицию. И про "маркетинговые" интересы они открыто заявляли. Им спонсоры в последнее время выделяют больше денег на использование тора как средства обхода цензуры, для получения населением стран с цензурированным интернетом информации из других сегментов интернета. P2P-chat over Tor и другие подобные сервисы у них даже в обозримых планах не стоят. В отдалённых планах — чат с удалённым централизованным сервисом за пределами цензурированной страны, не больше.

Просто они пока берутся за более простые задачи, остальное отдано на откуп энтузиастам. Скрытые сервисы тоже не в самом приоритете, т.к. всё ещё требуют дополнительных исследований. Они их сами называли "our orphaned child". Но тем не менее, собрались и многое в них допилили на уровне и протокола, и реализации, хотя это в основной roadmap не входило.

Наконец, торчат не совсем адекватно как-то развивается. То он забрасывается, то форкается, то на пакеты авторы подписи не проставляли, то пишется на каких-то совсем левых языках вместо первоначального питона.

Могли бы договориться с названием, согласованием формата документации, и прочими формальностями типа proposals, reports и получили бы возможно хотя бы полуофициальную поддержку торпроджекта.
— meticulous (18/02/2013 22:35)   профиль/связь   <#>
комментариев: 48   документов: 4   редакций: 0
gegel, приветствую тебя! :)

Как автор многочисленых комментариев к твоему топику, решил наконец сегодня зарегистрироваться ;)
Прими от меня наилучшие пожелания в развитии твоего интереснейшего проекта!
На страницу: 1, ... , 5, 6, 7, 8, 9, ... , 50 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3