id: Гость   вход   регистрация
текущее время 01:32 08/12/2022
создать
просмотр
ссылки

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, ... , 22, 23, 24, 25, 26, ... , 50 След.
Комментарии
— Гость (13/04/2014 21:57)   <#>
SpeakFreely под Linux проверил, все функционирует ОК

Гм, это неожиданный поворот. Здесь пока обсуждался Torfonе, по нему за столь огромный топик накопленомного вопросов и ответов, сложилась определенная оценка его возможностией и некоторое доверие.
А тут бац – и SpeakFreely. "© Кто такой, зачем, почему?"
Как к нему относится, он что, защищеннее TorFone, раз вы на него переключились?
В-общем, переход непонятен, поясните, плиз.
— Гость (13/04/2014 22:10)   <#>
PS: SpeakFreely под Linux проверил, все функционирует ОК, как Linux-Linux, так и Linux-Win32. Чистая консоль, минимум библиотек, относительно простой код на С (всего два потока для двух направлений передачи).

Это, как говорится, "внушает и впечатляет". Но в самом деле, как в этом довольно старом проекте с уровнем криптозащиты? AES, TwoFish и пр. в нем вроде не замечены, имхо.
— gegel (13/04/2014 23:25, исправлен 13/04/2014 23:28)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
А тут бац – и SpeakFreely. "© Кто такой, зачем, почему?"

На сайте Торфона с самого начала существует страница, где сделан порт SpeakFreely-Win32 для работы через Tor.

Но в самом деле, как в этом довольно старом проекте с уровнем криптозащиты?

В версии 7.2-Win32, которую я патчил год назад, AES нет, только DES-56 в ECB-режиме без никаких MAC (тоесть никак). В версии 7.6, на которую я давал ссылку, есть AES-128. Но не это сейчас главное: шифрование – не проблема, я прикручу все, что пожелаете. Планируется AES-256-OCB и Keccak-SpongeWrap в качестве красивой игрушки. Ну, и ECDH25519 для периодического наложения на имеющийся предрасшаренный ключ для PFS.
Гораздо важнее другое: TCP-транспорт, кодеки и т.д. Портировать Торфон под Linux as-is – весьма геморройное занятие. Нативный PGPFone написан на С++ под VisualC с использованием специфической для Win32 MFC и развитым GUI. Существенное снижение трудозатрат – взять готовый проект под Linux (пользовательский интерфейс, работа со звуком, буферизация, интернет-сокеты) и добавить к нему код из Торфона (благо, все, добавленное мною – на С). Это и шифрование, и кодеки, и проход NAT. Можно даже один в один повторить протокол Торфона, и сделать поную обратную совместимость, хотя эта идея не особо меня впечатляет, т.к. лучше сразу создать версии под разные платформы (или даже попробовать cygwin + прицепить GUI под Win32).
Можно назвать это Linux-Тофрон (или onionphone, чтобы не драконить Роджера).
Но в любом случае C-код SpeakFreely анализировать куда проще, чем С++ код Торфона, т.о. желающим будет проще найти потенциальные баги.
Еще раз повторюсь: из SpeakFreely я хочу взять командный интерфейс и логику консоли, работу со звуком и частично с сетью. Остальное – из Торфона.
Иначе, если пытаться делать новое Linux-приложение с нуля или один в один портировать Торфон вместе с GUI, этот проект так и умрет, не родившись.

— Гость (13/04/2014 23:35)   <#>
Эхехех... :( и когда же это все будет? Обещанного завершенного юзабельного Торфона мы уже сколько ждем – полгода или год?
К тому же Torfone сегодня уже хоть как-то, но работает! С прикручеными необходимыми аесами и т.п.
Зачем тогда было вообще браться за него, если SpeakFreely, как теперь оказывается, предпочтительнее?

Хотя, конечно, если получится обновленный SpeakFreely сделать быстро, то да. Идею с более простым консольным приложением на предыдущих страницах я подавал. Вопрос – насколько быстро?
— unknown (13/04/2014 23:38)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Вот поэтому качественный кроссплатформенный сишный код сначала делают на Linux, с прицелом на кроссплатформенность в самой начальной стадии проектирования. Случаи с джавой не рассматриваем.
— gegel (14/04/2014 00:21)   профиль/связь   <#>
комментариев: 393   документов: 4   редакций: 0
Обещанного завершенного юзабельного Торфона мы уже сколько ждем – полгода или год?

Это и будет Торфон. Лучше бы я не упоминл о SpeakFreely, молча взяв оттуда парсер командной строки и кроссплатформенную звуковую библиотеку. Все остальное все равно от Торфона прилепится. А GUI под Linux никому тут не интересно.

Вот поэтому качественный кроссплатформенный сишный код сначала делают на Linux

Согласен на все 100%, со всеми новыми проектами так и делаю. Но Торфон вообще изначально не планировался как проект: я хотел просто показать возможность передачи голоса через Tor. Взял первое попавшееся под руку приложение, наскоро перевел на TCP и увеличил голосовой буфер. К сожалению, попался PGPFone, жестко заточенный под Win32.
— Гость (14/04/2014 00:28)   <#>
Вот поэтому качественный кроссплатформенный сишный код сначала делают на Linux,.....

Да кто ж с этим спорит. Но для того, чтобы что-то реальное сделать, нужно либо достойную оплату получать, либо жить в сытой стране, где нет никаких забот и можно спокойно заняться хобби, Voice over TOR, например :)

Gegel, давайте попробуем пообщаться в приватке https://fastzone.net, я там зарегился под ником Liteminer

unknown, вы все-таки не хотите помочь общему делу, ответив на заданные вам выше вопросы?
— Гость (14/04/2014 00:42)   <#>
А GUI под Linux никому тут не интересно.

Вот именно! Одни ненужные проблемы.
— Гость (14/04/2014 07:07)   <#>

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

Ещё в начале этого треда высказывались аргументы, что голосовая связь несовместима с анонимностью органически, и даже после всех страховок безопасности она всё равно будет хуже шифрованного IM. Как минимум, одна из неустранимых проблем — то, что голос могут прослушать локально, и это намного проще, чем ловить акустические или электромагнитные сигналы с ПК/клавиатуры/монитора.


А что с ней сейчас не так? На ограниченных группах работает прекрасно.


Есть рекомендация общего характера: если используется виртуальная машина, то прикладной софт нужно запускать в гостевой ОС, а рулить трафиком (и запускать сетевые средства анонимизации) в хостовой ОС, чтобы критичные для безопасности и анонимности вещи выполнялись не в той же гостевой ОС, где и потенциально уязвимые программы. Это самый простой вариант. Есть сложнее: сделать несколько гостевых ОС, в одной — только программы для конечного использования, в другой — только сетевая инфраструктера (Tor, VPN, файерволл).


Риск получить ошибку в проекте из-за невнимательности или недостаточной компетентности разработчика (без всякого АНБ), которая потом ещё и не будет исправлена из-за того, что никто не читает её код, намного выше риска получить злонамеренный бэкдор. Это если речь идёт о программах с открытым исходным кодом.


Да, в основном распространено именно такое мнение, хотя ЦРТ храбрится и пиарится изо всех сил. В любом случае, голосовой трафик пишется и складируется. Может быть, лет через 30, когда технологии позволят распознавать голос не хуже человека, весь архив голосовой связи будет «оцифрован» (превращён в текст), каталогизирован, а голоса говорящих распознаны. Сначала к архиву получат доступ избранные, типа полицейских, потом маркетологи, потом историки, а потом все остальные. Можно будет прийти в Ленинку зайти на сайт и скачать полное собрание текстов разговоров (по телефону и другим средствам недостаточно защищённой связи) любого человека за всю его жизнь. Радуйтесь наступающему цифровому будущему, развиваются ведь не только средства шифрования и анонимности, но и средства слежки и анализа.


Не повторяйте ошибок предыдущих поколений, ставьте Debian. Он ничем не сложнее, зато безопаснее.


Да не связывайтесь вы с curses-интерфейсами! Есть традиционный промышленный подход — командная строка + конфиги с пояснениями к опциям. onionphone --port NUMBER --call USER_ADDRESS --config-file /path/to/config — что-нибудь в духе этого. В домашней директории ~/.onionphone можно хранить не только конфиги, но и ключи. Любую опцию конфига по возможности должно быть возможным переопределить в командной строке при запуске программы. По такому принципу работают тысячи программ, включая GnuPG и climm. Интерфейс у последнего вполне удобен для общения с абонентами, его можно было бы и для звонков приспособить.


А кредентиалсы не подписаны. На pgpru есть возможность подписывать комментарии через gpg -sa. Почему бы этим не воспользоваться?


Но даже он не достаточно безопасен (на примере пранковских записей и всяких TV-шоу все могли в этом убедиться).


Эллиптика — минное поле, не стоит туда лезть мелким проектам. Даже в GnuPG-ключах рекомендуют придерживаться RSA, хотя эллиптика там есть. Т.е. даже касаемо проекта такой тотальной распространённости нет уверенности, что в его реализации эллиптики всё ОК, и это нигде потом не аукнется.


Самоподписанный сертификат. После добавления в исключения получаем

Forbidden

You don't have permission to access / on this server.
— Гость (14/04/2014 07:31)   <#>

Примерно так:

  1. Отключить IPv6 [Важно! Файерволлом он не блокируется].

  1. Удалить утилиту ping [опционально]. Ни в коем случае не разрешать ICMP в файерволле. ICMP всегда посылается с правами рута, какой бы юзер ни был указан в качестве отправителя. Не забывайте об этом.

  1. С учётом требований конкретного софта отредактировать под себя следующий скрипт и выполнить его:
    #!/bin/sh
    # iptables script
     
    # Сброс ранее загруженных правил:
    iptables -F ;
     
    # Установка политик:
    iptables -P INPUT DROP ;
    iptables -P OUTPUT DROP ;
    iptables -P FORWARD DROP ;
     
    # На машине используются только 2 сетевых интерфейса: loopback (lo) и eth0.
    # Трафик уже созданных соединений идёт без фильтрации:
    iptables -A INPUT -i lo -m state --state ESTABLISHED -j ACCEPT
    iptables -A INPUT -i eth0 -m state --state ESTABLISHED -j ACCEPT
     
    # ФИЛЬТРАЦИЯ НА LOOPBACK-ИНТЕРФЕЙСЕ (ЛОКАЛЬНЫЕ ПАКЕТЫ)
    # (Если не нужно, всё закомментировать; если нужно, отредактировать под себя):
     
        # Разрешить софту, запущенному от имени юзера USER1,
        # инициировать соединение с адресом 127.0.0.1:1111 по TCP:
        iptables -A OUTPUT -o lo -s 127.0.0.1 -d 127.0.0.1 -p tcp \
                    -m owner --uid-owner USER1 -m tcp --dport 1111 -j ACCEPT
        # Разрешить принимать TCP-пакеты на адрес 127.0.0.1:1111:
        iptables -A INPUT  -i lo -s 127.0.0.1 -d 127.0.0.1 -p tcp \
                    -m tcp --dport 1111 -j ACCEPT
     
        # Разрешить софту, запущенному от имени юзера USER2,
        # инициировать соединение с адресом 127.0.0.1:2222 по UDP:
        iptables -A OUTPUT -o lo -s 127.0.0.1 -d 127.0.0.1 -p udp \
                    -m owner --uid-owner USER2 -m udp --dport 2222 -j ACCEPT
        # Разрешить принимать UDP-пакеты на адрес 127.0.0.1:2222:
        iptables -A INPUT  -i lo -s 127.0.0.1 -d 127.0.0.1 -p udp \
                    -m udp --dport 2222 -j ACCEPT
     
    # ФИЛЬТРАЦИЯ НА eth0-ИНТЕРФЕЙСЕ (ВНЕШНИЕ ПАКЕТЫ)
    # (Если не нужно, всё закомментировать; если нужно, отредактировать под себя):
     
      # ИНИЦИИРУЕМЫЕ НАМИ СОЕДИНЕНИЯ НАРУЖУ:
     
        # Разрешить софту, запущенному от имени юзера USER3,
        # инициировать соединение с адресом X.X.X.X:3333 по TCP:
        iptables -A OUTPUT -o eth0 -s ВАШ_IP_НА_eth0 -d X.X.X.X -p tcp \
                    -m owner --uid-owner USER3 -m tcp --dport 3333 -j ACCEPT
     
        # Разрешить софту, запущенному от имени юзера USER4,
        # инициировать соединение с адресом X.X.X.X:4444 по UDP:
        iptables -A OUTPUT -o eth0 -s ВАШ_IP_НА_eth0 -d X.X.X.X -p udp \
                    -m owner --uid-owner USER4 -m udp --dport 4444 -j ACCEPT
     
      # ПОДКЛЮЧЕНИЕ К НАМ ИЗВНЕ (ОПАСНО ДЛЯ АНОНИМНОСТИ И БЕЗОПАСНОСТИ):
     
        # Разрешить хосту X.X.X.X инициировать соединение с нашим адресом
        # ВАШ_IP_НА_eth0:5555 по TCP:
        iptables -A INPUT -i eth0 -s X.X.X.X -d ВАШ_IP_на_eth0 -p tcp \
                    -m tcp --dport 5555 -j ACCEPT
     
        # Разрешить хосту X.X.X.X инициировать соединение с нашим адресом
        # ВАШ_IP_НА_eth0:6666 по UDP:
        iptables -A INPUT -i eth0 -s X.X.X.X -d ВАШ_IP_на_eth0 -p udp \
                    -m udp --dport 6666 -j ACCEPT
    Если где-то что-то нужно разрешить для всех, конкретизирующий параметр (например, адрес хоста или порт) просто не указывается. Вначале ESTABLISHED, возможно, нужно заменить на RELATED,ESTABLISHED, но я не уверен. Эти правила — на ваш страх и риск, т.к. я не специалист по iptables. Правильно внимательно прочитал, но это не исключает ошибок и отпечаток, и нажимую я их не тестировал.

    Последние обсуждения того, как правильно писать безопасные правила для iptables, были тут. Низкоуровневость iptables, вытекающая из этого требовательность внимательности к мелочам, большой объём текста даже для самой минимальной политики фильтрации — основные факты, из-за которых считается, что в Linux нормального файерволла нет. Интеграции iptables с окружением тоже нет (поэтому всё делается в виде самописных скриптов). На старте системы правила могут не работать. Стандартных способов загрузки правил тоже нет: каждый их суёт туда, куда вздумается, в стартовых скриптах. Поддержки owner для входящих пакетов в iptables также нет. iptables — говно, ненавижу^Wне используйте iptables. Там, где можно, не используйте iptables, используйте pf. У последнего нет перечисленых недостатков, правила удобочитаемые человеком, а писать их легко, приятно и безопасно.*

    Проверка загруженных правил — команда iptables-save.

*По ссылке пример намного более сложных правил, чем в этой рыбе-заготовке. Там несколько внешних интерфейсов + форвардинг, но при всём этом они легче читаются, чем вышеприведённая «ассемблерная» мешанина iptables.
— unknown (14/04/2014 10:27, исправлен 14/04/2014 10:33)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Я обсуждал на примере разработки торфона, что нехорошо лепить протоколы на коленке. Мне было интересно выяснить (думаю, что и Gegel'ю тоже), что протоколы с отрицаемой аутентификацией — гораздо более сложная вещь, чем кажется. И ведущими теоретиками проблема до сих пор не решена.


Сам торфон, как реальный программный продукт для пользователя мне пока никак не был интересен.



Сама такая возможность многим тоже интересна, как концепт. Я слежу за её развитием, но никакой конкретный проект пока практического интереса не вызывает. Ни в каком «общем деле» я не участвую. Отвечаю на те вопросы, которые лично считаю интересными со своей субъективной точки зрения и не более того.

— Гость (15/04/2014 06:58)   <#>

Описка. Следует читать не "по голосу" а "по стилю". Речь идёт о распознавании автоматически озвученного текста, полученного из туда-сюда перевода распознанной в текст речи.


Чем вам этот случай не люб?
— Гость (15/04/2014 07:00)   <#>
s/распознавании/идентификации/
— Гость (15/04/2014 13:29)   <#>

Мне кажется, живая речь содержит намного больше уникальных паттернов, чем письменная, как минимум, потому, что «поправить» уже произнесённое нельзя. А раз даже авторство письменной речи успешно определяется стилометрией, то что говорить про устную...
— Гость (15/04/2014 20:15)   <#>
под себя следующий скрипт и выполнить его:
а что скажите по поводу сайтов, которые генерируют правила для iptables? еще есть надстройка arno для iptables, которая немного помогает, а новичкам так много, произвести настройку.
На страницу: 1, ... , 22, 23, 24, 25, 26, ... , 50 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3