id: Гость   вход   регистрация
текущее время 17:52 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, ... , 27, 28, 29, 30, 31, ... , 50 След.
Комментарии
— gegel (03/05/2014 18:44)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Я, например, отнюдь не рад вездесущей «китайчатине»

Никто не рад, но их умение решить вопрос оптимально с практической точки зрения, отделяя на данный момент основное для пользователя от второстепенного, заслуживает уважение. Например, мне гораздо приятнее пользоваться телефоном Donod C+ за $12, чем фирменным Samsung того же класса. Софт лучше, хотя по железу, конечно, гораздо хуже.

И что, этот SpeakFrealy обеспечивает такую же криптозащиту, как и TorFone?

Я выше писал, что не разбирал подробно криптографию версии 7.6. Но, думаю, что в общем можно ответить "нет". Но это актуально при прямом соединении, т.к. при работе через Tor обеспечивается оконечное шифрование средствами Tor. Думаю, повода не доверть Tor нет?
В любом случае, я прикручу современную криптографию к Linux-версии вместе с возможность перехода на прямое UDP с автоматическим проходом NAT (Tor в качестве SIP).

У SpeakFrealy длинная история: сначала она развивалась автором на офсайте. В 2004 автор (John Walker) объявил об окончании поддержки проекта, и проект перешел на sourceforge.net в статусе коллективной разработки. Там же доступны исходные коды версии 7.6, более поздние патчи и т.д. Собственно, моя поддержка TCP и Tor – просто патч этой версии (ведь проекты подобного уровня не делаются за неделю с нуля).
В отличие от Циммермановского PGPFone, забытого почти сразу (он опередил время – ни пользователи, ни сети тогда были не готовы ни к VIOP, ни к шифрованию), SpeakFreely нашла практическое применение, и до сих порт используется в специфических коммьюнити как средство VOIP, хотя по уровню защиты уступает PGPFone (последний проектировался как часть пакета PGP, изначально заточен на безопасность).
Сразу после релиза Торфона ко мне начали обращаться с просьбой сделать поддержку TCP+SOCKS5 в SpeakFreely, причем практическая публика, думаю, связанная с какими-то политическими движениями.
Ну, и на других форумах были просьбы торификации именно SpeakFreely.

ПС: есть еще один незаслуженно забытый и раскритикованный Qt-проект I Hear U под Linux, работающий в т.ч. и через TCP. Я не пробовал его, но по идее статически линкованная версия должна работать и на Tails.
— Гость (03/05/2014 19:09)   <#>

И когда это можно ожидать?
— Гость (04/05/2014 03:22)   <#>
@gegel,

Забавный топик. Файловая система, тогда тоже должна быть аппаратной. Как марчить файлы, что бы они аппаратно были не стрираемы. В противном случае, защита на стороне файловой системы, программно делается. В любом получается случае, надо вокруг файловой системы плясать, и что бы её Windows/Linux читать умели. Зачем такой велосипед?

@gegel, а зачем этот Raw UDP/TCP, если название уже позиционирует разработку как прикладную к Tor – TorFone? Или здесь Tor – это что то другое?

А учитывая уже имеющуюся криптографию в Tor-e, Вы лишний слой добавляете? Связь между двумя onion доменами, для передачи видео, может лишь потребовать грандиозной работы в области сжатия этого видео.
— gegel (04/05/2014 10:48)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Файловая система, тогда тоже должна быть аппаратной

Понятие "аппаратный" относительное. Например, шифрование на ПЛИС – аппаратное? Но ведь ПЛИС все равно программируется. Тем более в данном случае – ведь используется микроконтроллер. Реализуется FAT. Защита программная, но не силами ОС, а в прошивке микроконтроллера, и написанной собственноручно, а не производителем флешки.

зачем этот Raw UDP/TCP

Tor дает ощутимые (пару секунд) задержки, и это весьма напрягает при общении. В серьезной модели угроз это оправдывается, но в большинстве практических случаев предпочтителен переход на p2p соединение после установки Tor-соединения, согласования ключей в нем и обмена инвайтами для прохода NAT. Естественно, p2p не дает анонимности, но в отсутствии сервера невозможно собирать метаданные и контролировать все в одной точке. Другой вариант – DHT, но Tor HS предоставляет коробочное решение.
Связь между двумя onion доменами, для передачи видео, может лишь потребовать грандиозной работы в области сжатия этого видео.

К сожалению, не все так просто. В своих экспериментах с HS-соединением я заметил четкую корреляцию между потоком трафика и латентностью. Алгоритм Нагла на узлах продолжал работать, и TCP-пакеты переформатировались произвольно, буферизируясь сокетами узлов. Т.к. сжатие видео не бесконечно, то в любом случае единичной HS-соединие будет перегружено и даст значительную латентность, что вызовет неудобства в общении, особенно у той публики, кто в этом больше всех заинтересован.
Единтственный выход – использовать множество цепочек (и Tor-клиентов), разбивая видеопоток на небольшие фрагменты, маршрутизируя их отдельно и собирая на приемной стороне. Но тут повышается вероятность отказа всей системы в случае отказа всего одной цепочки. Поэтому придется использовать соответствующее кодирование видео (потеря или задержка фрагмента данных должна приводить к потере только одного фрагмента кадра), а также предусмотреть алгоритм исключения медленных цепочек, т.к. самая медленная и будет определять общую латентность. Для уменьшения вероятности отказа надо предусмотреть дублирование проблемных (вновь созданных, нестабильных) цепочек.
Только таки способом можно получить то, что ожидает пользователь.
— Гость (04/05/2014 21:30)   <#>

:)))

А под Linux полностью через Tor оно уже работает? Т.е., чтобы не только согласование параметров, но и весь трафик шёл через Tor.
— gegel (05/05/2014 10:07, исправлен 05/05/2014 10:51)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

Да, под Linux именно так (и пока только так) оно и работает:
Скачиваем последний TBB, распаковываем в папку. Открываем файл \tor-browser_en-US\Data\Tor\torrc и добавляем строку:
HiddenServicePort 17447 127.0.0.1:17447
Запускаем ./start-tor-browser, дожидаемся подключения. Открываем появившийся файл \tor-browser_en-US\Data\Tor\hidden_service\hostname и копируем созданный ваш onion-адрес.


Скачиваем fileпатченую SpeakFrealy7.6, распаковываем в отдельную папку. Запускаем ./start
Для исходящего звонка вводим onion-адрес абонента с восклицательны знаком вначале и жмем ввод. Для приема входящего звонка жмем ввод.
Для тестирования жмем ввод и слышим себя.


Если что-то не так, опишите ошибку, посоветую.

— Гость (05/05/2014 11:10)   <#>
Да, под Linux именно так

2 gegel: а под Ubuntu Touch заработает?
— gegel (05/05/2014 11:39, исправлен 05/05/2014 11:39)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
а под Ubuntu Touch заработает?

Я же не ясновидец. Для того и выложил, чтобы попробовали на разных ОС.
Не заработать может только звук. Просто запустите ./start (без никакого Тора) и затем нажмите ввод, и еще раз ввод. Или услышите себя, или получите ошибку. И в том, и в другом случае отпишите. Если будет ошибка, укажите, я попробую подсказать, как поправить ситуацию.

— Гость (06/05/2014 09:49)   <#>

А можно кадры поочерёдно по цепочкам распределять, тогда будет просто пропуск каждого n-ого кадра, в плохом случае слайд-шоу.
— unknown (06/05/2014 10:31, исправлен 06/05/2014 10:34)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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

— gegel (06/05/2014 11:08, исправлен 06/05/2014 11:12)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
тогда будет просто пропуск каждого n-ого кадра

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


Если пропускать много трафика по множеству параллельных цепочек, то анонимность будет падать

Год назад я несколько раз поднимал этот вопрос и здесь, и на TorProject, но ответа не получил. Хотя у меня с самого начала были сомнения аналогично вашим.

фиксированный набор гвард-узлов скрытого сервиса

Об этом тоже где-то я упоминал. Практически это подтверждается при активировании экспериментальной функции Торфона: создаются две встречные цепочки, пакеты передаются по обоим, накапливается статистика за определенный интервал, и более медленная перезапускается. Я тщательно тестировал это в прошлом году: выше головы прыгнуть не удается из-за гвардов.
Отказаться от гвардов, уменьшить цепочки (наверное, это возможно в современной реализации Тор, не в курсе) можно в ущерб анонимности, все зависит от модели угроз.
Кроме того, я не зря упомянул об множестве экземпляров Tor на обеих концах, соответственно, наборе независимых HS. Конечно, надо думать о возможности корреллирования и т.п. потенциальных деанонимизаторах.

— Гость (01/06/2014 21:40)   <#>
В продолжение /comment78555:
#!/bin/sh
 
# Отредактировать
MYIP=X.X.X.X.
Guard1=X.X.X.X.
Guard2=X.X.X.X.
Guard3=X.X.X.X.
PortOfGuard1=PORT
PortOfGuard2=PORT
PortOfGuard3=PORT
 
iptables -F 
 
# По умолчанию запрещаем всё:
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
 
iptables -A OUTPUT -p icmp -j DROP
iptables -A OUTPUT -p udp -j DROP
 
# Разрешаем ответы от Guard'ов (только в рамках уже установленных с ними 
# нами соединений):
iptables -A INPUT  -i eth0 -s $Guard1 -d $MYIP -p tcp -m tcp \
    --sport $PortOfGuard1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT  -i eth0 -s $Guard2 -d $MYIP -p tcp -m tcp \
    --sport $PortOfGuard2 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT  -i eth0 -s $Guard3 -d $MYIP -p tcp -m tcp \
    --sport $PortOfGuard3 -m state --state RELATED,ESTABLISHED -j ACCEPT
 
# Разрешаем исходящий трафик от нужного юзера к Guard'ам на их IP:порт:
iptables -A OUTPUT -o eth0 -s $MYIP -d $Guard1 -p tcp -m owner \
    --uid-owner TBB-user -m tcp --dport $PortOfGuard1 -j ACCEPT
iptables -A OUTPUT -o eth0 -s $MYIP -d $Guard2 -p tcp -m owner \
    --uid-owner TBB-user -m tcp --dport $PortOfGuard2 -j ACCEPT
iptables -A OUTPUT -o eth0 -s $MYIP -d $Guard3 -p tcp -m owner \
    --uid-owner TBB-user -m tcp --dport $PortOfGuard3 -j ACCEPT
 
# Рзарешаем на lo ответы от Tor'а для уже установленных (в общем случае, 
# иными программами) соединений:
iptables -A INPUT  -i lo -s 127.0.0.1 -d 127.0.0.1 -p tcp -m tcp \
    --sport 9151 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT  -i lo -s 127.0.0.1 -d 127.0.0.1 -p tcp -m tcp \
    --sport 9150 -m state --state RELATED,ESTABLISHED -j ACCEPT
# Разрешаем Tor'у самому (первому) отправлять что-либо иным програмам 
# с его портов (Зачем это нужно?! Почему -m state --state
# RELATED,ESTABLISHED в этих правилах ниже недостаточно?):
iptables -A OUTPUT -o lo -s 127.0.0.1 -d 127.0.0.1 -p tcp -m tcp \
    --sport 9151 -m owner --uid-owner TBB-user -j ACCEPT
iptables -A OUTPUT -o lo -s 127.0.0.1 -d 127.0.0.1 -p tcp -m tcp \
    --sport 9150 -m owner --uid-owner TBB-user -j ACCEPT
 
# Разрешаем входящие на порты Tor'а от других программ (firefox'а и т.п.):
iptables -A INPUT  -i lo -s 127.0.0.1 -d 127.0.0.1 -p tcp -m tcp \
    --dport 9151 -j ACCEPT
iptables -A INPUT  -i lo -s 127.0.0.1 -d 127.0.0.1 -p tcp -m tcp \
    --dport 9150 -j ACCEPT
# Разрешаем исходящие на порты Tor'а от (в общем случае) других программ:
iptables -A OUTPUT -o lo -s 127.0.0.1 -d 127.0.0.1 -p tcp -m tcp \
    --dport 9151 -m owner --uid-owner TBB-user -j ACCEPT
iptables -A OUTPUT -o lo -s 127.0.0.1 -d 127.0.0.1 -p tcp -m tcp \
    --dport 9150 -m owner --uid-owner TBB-user -j ACCEPT
Это попытка затянуть гайки для стандартного рекомендуемого случая (есть только искаробочный TBB, всё работает из-под него). Трафик TBB разрешаем, всё остальное фильтруем (даже на loopback-интерфейсе).

Вышеприведённые вопросы говорят о том, что я сам до конца не понимаю, как работает фильтрация на lo. Обычно правила (для системного Tor'а) пишутся исходя из того, что Tor, как локальный сервер, должен отвечать на запросы клиентов, но сам соединенения никогда не инициирует. Тут не так. Может быть, дело во всяких PluggableTransport и т.п. наворотах бандла.

Правила, конечно, ни от чего по сути не страхуют (особенно, если у кого-то на машине белый IP), но слегка сужают манёвр атакующему в случае, если будет уязвимость (соединения в сеть напрямую зарезаны, придётся отсылать трафик во вне через Tor или ждать, когда попадётся подконтрольный Guard). Список Guard'ов и их портов для конфига выцепляется из netstat -apn |grep ВАШ_IP. Если у кого исходящий не eth0, пусть поправит для своего случая.
— RubyOnRails (11/06/2014 19:43)   <#>
torchat ужасно глючит – не регистрируется нормально в сети (человечки не зеленеют). у всех так?
— gegel (11/06/2014 20:17, исправлен 11/06/2014 20:18)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0

Проверил – подключается без проблем.
Убедитесь в правильность установки системного времени и соответствии его часовому поясу. Обновите tor.exe, заменив файлом из последнего TBB.
А вообще такое было в последний раз во время августовской атаки, тогда в первую очередь пострадали HS. Сейчас, судя по торовскому мейл-листу, все спокойно.

— RubyOnRails (11/06/2014 21:02)   <#>
только tor.exe надо заменять или кучу dll файлов впридачу?
На страницу: 1, ... , 27, 28, 29, 30, 31, ... , 50 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3