id: Гость   вход   регистрация
текущее время 18:58 28/03/2017
создать
просмотр
ссылки

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, 2, 3, 4, 5, ... , 46, 47, 48, 49, 50 След.
Комментарии
— Гость (14/01/2013 21:17)   <#>
Ок, соры гляну сегодня.
А что на счет NAT traversal, когда не через TOR?
— gegel (14/01/2013 21:47)   <#>
Приложение peer-to-peer, внешний STUN не использует. Напрямую без проблем, но ессно на белый IP (если динамический, то на dyndns аккаунт). Если локальный роутер стоит, то естественно, используемый TCP-порт проключить надо на комп с телефоном (слушающий порт настраивается в ini телефона).
— Гость (14/01/2013 23:54)   <#>
Спасибо, интересный проект.


Можете на главной странице подправить основной текст:

Internet telephony is now an important part of human people communications and should be protected from intruders collecting information about you. I had an idea to use the old PGPFone designed by Philip Zimmermann for these purposes by adding the ability possibility to use The Onion Router anonymizer for to ensure anonymity of callers. I did some tests to adapt adopt VoIP transport to TOR tunnels and eventually made acceptable alpha release.

As a result, the TORFone was designed to voice communicate voice via Internet (make phone calls to the addressee) similarly as to Skype but with the following differences:

1. TORFone is an open source project, therefore it which guarantees the absence of "backdoors" and the quick elimination fixing of potential vulnerabilities.

2. TORFone is fully portable (it can be run from a flash carrier or virtual TrueCrypt-disk and leaves no residue in the system) and works with all versions of Win32 from Windows 98, has very low system requirements (above PI 233 MHz 32M RAM), is economical in traffic (at least 20 kbit/s which corresponds to the GPRS Class 10).

3. TORFone decentralized ie does not use an external server and does not require pre-registration number.

4. TORFone provides complete full confidentiality (used by using DH-4096 to match the session key and 3-DES for to encryption of the voice traffic). The attacker is mirrored who mirrors the traffic is unable to listen to the conversation and is not be able to decode it later even if he gainsing access to the computers of participants.

5. As cCaller and callee are completely anonymous to each other and to outside observers (a call is made on hidden TOR-service user).

6. Calls using TORFone is hidden to the outside observer as since TOR traffic with not differsence from the usual https-connection.

I think now that TORFone is one of the most anonymous and confidential means for the Internet telephony. The payment for anonymity is voice latency up to 2-4 seconds (because traffic goes through a chain of 6 nodes located around the world). If anonymity is unnon-important Torfon can perform work as a direct connections "point to point" using IP-adress / domain name which fully keeps the privacy. Also Torfon also provides subscriber voice authentication to avoid attack "people man on in the middle" and, therefore, it can be used to safe exchange by of personal data (such as files or short text messaging) safely. (such as files or short text messaging)

В последнем абзаце: слово means (средства) вроде бы не имеет в английском языке единственого числа, потому фикс потребовал что-то поменять.
— Гость (14/01/2013 23:56)   <#>
Win98-XP-7-8.

Версия для Linux не планируется?
— Гость (14/01/2013 23:59)   <#>
Сырцы подписаны вашим PGP-ключом?
— Гость (15/01/2013 00:02)   <#>
По поводу первого пункта: открытость исходников не гарантирует отсутствие бэкдоров, а просто делает их поиск куда более лёгким делом. Многие бэкдоры могут быть замаскированы под невинные случайные ошибки в коде. Лучше так не палиться, а написать как-то мягче, более обтекаемо.
— gegel (15/01/2013 02:08)   <#>
Спасибо, на сайте все поправил.
Под Linux можно потом попробовать портировать, просто исходники оригинального PGPFone под Win32, с этого и начал.
Нет, да данном этапе я ничего не подписывал. Были подписаны оригинальные исходники Циммерманна, надо убрать.

ПС: также тестировал i2p в плане пригодности для voip. В принципе, streamr UDP туннель можно использовать, но я так понял, что он односторонний. Во всяком случае, мне не удалось передать данные только в одном направлении. Кто в курсе, подскажите, можно ли и как проще всего создать там двухсторонний UDP-тунель.
— gegel (15/01/2013 02:23)   <#>
ППС: Сорри, ссылка на исходники на главной странице сайта указывала на пакет. Поправил: torfone_v01a_src.zip
— Гость (17/01/2013 01:51)   <#>
Как там с качеством связи через Tor? Говорить без специального выбирания быстрых цепочек можно, или будут слышны только отдельные скомканные слова?
— Гость (17/01/2013 02:35)   <#>
Забыли исправить: not differs (т.е. 3е лицо ед.ч.).
— Гость (17/01/2013 02:43)   <#>
Как в вашем проекте обстоят дела, например, с этой уязвимостью? Другие комментарии по данной ссылке тоже примечательны. У вас ZRTP?
— Гость (17/01/2013 12:33)   <#>
На начальном этапе тестирования действительно были слышны отдельные слова, но очень помог адаптивный буфер пакетов. В нем накапливается до 32 пакетов по мере их поступления, а извлекаются они по таймеру с изменяемой частотой так, чтобы пытаться поддерживать заплненным 50% буфера. Беда ТОР в том, что бывают периодические замирания туннеля, а потом все данные приходят одномоментно. Штатный кодек естественно дает пазу при замирании, а избыточные данные теряются (выпадает часть слов). Я добился, что практически ничего не выпадает, но ценой дополнительной задержки в 1-2 сек. Так что единственной неприятностью есть задержка звука в 3-5 сек (а иногда и до 10 сек при неудачном туннеле), что не совсем приятно с непривычки, но терпимо в реальном общении типа "передача – прием".
Размер буфер (и дополнительная задержка, вносимая им) адаптируется к життеру туннеля, но скорее всего потребуются большие значения буфера: 10-15, лучше сразу же установить, т.к. адаптация с 1 до 15 займет 2-3 мин.
И еще: я заметил, что ТОР-туннель не сразу прояляет максимальную производительность: нужно какое-то время (1-2 мин), чтобы "раскачаться". Затем получается достаточно стабильное состояние и качество связи.
Я советовался с ребятами, создающими torrc с отбором узлов, они обещали сделать специально для данного приложения. В любом случае, рекомендовали использовать порты 80 и 443 (более быстрые).
Кроме того, появилась идея увеличить общий трафик (сейчас Торфон генерирует всего 2Kбайт/сек трафик) и тем самым избезать накопления данных в узлах ТОР-цепочек. С одной стороны, это должно увеличить анонимность за счет добавления рандом-данных, с другой чем плотнее трафик, тем система более подвержена статистическим атакам с модуляцией канала. Пока пробую, там посмотрим.
Очень интересны отзывы с результатами ваших тестов – попробовать дело 5 минут...

По поводу описанной уязвимости: ТОРФон фактически не использует RTP (тогда его просто не было). На выходе голосового кодека формируются пакеты строго одинаковой длины (149 байт при GSM7350) не зависимо от звукового содержимого, и передаются они через строго одинаковые интервалы (80 mS), поэтому данная уязвимость неактуальна.
В начале голосового пакета идет тип и мл. биты порядкового номера (синхронизируется на обоих сторонах), являющиеся частью nonce. Другая часть nonce – номер 8-байтного блока в пакете. Т.о., nonce для каждого блока шифруется tDES и результат ксорится с данными. Шифрованная часть пакета содержит относительный TimeStamp (номер пакета) и CRC.
На первый взгляд я не вижу тут явных уязвимостей (тем более Циммерманну доверяю полностью), но всяко бывает...
— unknown (17/01/2013 12:44, исправлен 17/01/2013 12:47)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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


Это одна из причин, почему трафик в торчате принципиально не шифруется никаким протоколом поверх (точнее внутри) торовского. Хотя равномерное шифрование с целью зашумливания и выравнивания статистики исходного звукового сигнала м.б. хорошей идеей.

— Гость (17/01/2013 13:58)   <#>
Наверное, я не до конца вник в алгоритм соединения с HS: мне казалось, что между концом цепочки (три узла) от исходящего клиента и началом созданной цепочки (еще три узла) к HS сегмент открытый.
Но тем не менее, лишний слой шифрования еще никому не вредил, хотя бы действительно с целью отбеливания. Кроме того, я предусматривал также режимы односторонней анонимности и вовсе без нее, где без прикладного уровня шифрования никак не обойтись.
— unknown (17/01/2013 14:47, исправлен 17/01/2013 14:47)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Ага и на точке встречи (RP) тогда сидел бы человек-посредине, слушал в открытую весь трафик и всё бы знал о скрытых сервисах. Нет уж, фиг ему. Внутри Tor весь трафик шифрован как узлами, так и самими клиентами.


В последних версиях можно даже скрыть сам факт работы (stealth mode) скрытого сервера от тех, кто даже знает его адрес, но не знает текущий аутентифицирующий ключ (auth cookie).


Для односторонней анонимности во внешнюю сеть, да, без прикручивания дополнительного криптопротокола не обойтись.

На страницу: 1, 2, 3, 4, 5, ... , 46, 47, 48, 49, 50 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3