Pull to refresh

Comments 67

спасибо, интересно
вы сами лично от проекта что-либо получаете?
Нет. Каким образом? Нет сервера — нет возможности управлять пользователями.
UFO just landed and posted this here

Если кто-то пришел сюда найти ссылку на репо, то вот она:


https://github.com/gegel/torfone


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

Ихние публикации???
Извините, но Хабр пал в моих глазах

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

Исключительно справедливости ради замечу, что если прогуляться по ссылкам помимо вашей, то выяснится, что обсуждаемое местоименное прилагательное относится к просторечным, употребляемым в речи малообразованных людей и в литературе используется, как правило, как художественный приём для отражения речи вышеупомянутой категории людей. «Живой язык» != «престижная норма».
Пусть не престижная норма, но уж точно не ошибка и не повод для проявления гнева. У Достоевского, кстати, используется широко, в том числе в тексте от автора.
Как сказал один лингвист — «Если 90% страны говорит неправильно, это становится нормой»
Спасибо
А с телефона это можно?
Мобильная функциональность сильно ограничена
Вроде бы с телефона можно только если зайти на полную версию сайта и клавиатура позволяет зажать Ctrl (то есть USB/Bluetooth клавиатура или типа HackerKeyboard на Андроид).
В любом случае такое действие выглядит точно также, как если просто написать автору в личные сообщения «Ошибка в публикации <ссылка><цитата>[комментарий]».
+10 благ этому человеку.

А вот риторический вопрос в воздух: сколько усилий нужно приложить, чтобы просто поговорить с другим человеком приватно, без посторонних ушей?

Во время моей молодости просто собирались на кухнях! Я думаю, этот опыт стоит иметь в виду

Русская рулетка по-советски: рассказывать в компании политические анекдоты. Причем все знают что среди них есть стукач, знают кто именно. Но продолжают рассказывать ;)
Две одноразовые симки на чужие данные, желательно в роуминге.

Учитывая потенциальную возможность определения человека по голосу, этот способ уже не анонимен

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

Анонимно купленная VDS с VPN и астериском, 2 незасвеченных телефона, 2 анонимных симки.


Торфон существенно упростит задачу. Спасибо автору!

Странный выбор для UI, можно было бы одним Qt обойтись для linux, windows, macos по примеру телеги.

Да, согласен. Это, наверное, оптимальный вариант, хотя и громоздкий. Возможно, в итоге так и будет, но пока что все на этапе альфа-тестирования самой библиотеки, поэтому UI временно лепил на скорую руку.

Вроде для tor находили атаки, позволяющие деанонимизировать источник при наличии определенного доступа к инфраструктуре. После этого интерес к технологии заметно ослаб. В статье описаны элементы кастомной криптографии с характерным профилем данных. Есть-ли понимание, для каких типов атак решение будет уязвимо или создает новые уязвимости для tor?

Слышал только про атаку а ля «51%», когда большое количество нод компрометируется и на основе их данных пытаются строиться пути доставки трафика и выяснить кто есть кто. Но это нетривиальная и дорогая атака, насколько мне известно. У торфона немало мер, чтобы избежать/затруднить идентификацию. Начиная от рандомизации пакетов до нескольких этапов шифрования id для связи.
> Если так, то по запросу на почту рад предоставить тестовые сборки (статически линкованные исполняемые файлы, не требуемые установки)

Как идея звучит конечно забавно, но если это open source то мне не понятно что мешает сразу разместить проект скажем на github? Зачем эта почта и вот это вот все :-? Если же нет… Кхм. Ну пилите, Шура, пилите :)

А вы коментария владельца репозитория читали под статье?

Вот оно как… Действительно, не все так однозначно. Спасибо, что ткнули носом читателя rss
Отчасти он прав. О причинах блокировки ошибочно предположил автор той статьи, но блокировка таки случилась, хотя и по другому поводу.
Учитывая, что коллизии хэша не исключены, под угрозу попадает абсолютно любой файл, у которого случайно чек-сумма совпадет с блокируемым контентом.
И ладно, если б только случайный файл блокировался, но накрывает медным тазом весь аккаунт, а потом доказывай, что ты не верблюд.

UPD. Дело не в хэше, а в содержимом файла. Но сильно ли это меняет суть?

Там «не все так однозначно»)
Забавный код. В лучших традициях «embedded C». Почему-то вспоминается WiringPI.
Собственно, проект изначально делался как embedded. И, действительно, там есть кусок из WiringPI (последовательный порт в Linux). Такой код легко портировать под ОС, хотя он, конечно, будет выглядеть несколько странно. Но код в традициях ОС очень трудно портировать для работы в bare metal. Поэтому в итоге получилось универсальное решение, не привязанное к ОС.
Я бы порекомендовал причесать код. Сделать его более дружелюбным к интеграции со сторонними системами. Избавиться от глобальных переменных в пользу контекста. Добавить проверку статуса исполнения системных и библиотечных вызовов где это не проверяется. Поработать над четким разделением на модули, в том числе на уровне аргументов публичных интерфейсов модуля. В текущей реализации масса вызовов вида foo(char *data) что накладывает необоснованные требования на вызывающий код по выделению этого самого data. Шаг влево шаг вправо и креш. И поменьше смотреть в wiringpi — IMHO это один из анти-примеров как не нужно писать библиотечный код :) Удачи!
Полностью с Вами согласен, код писался в течение месяца, поэтому однозначно сыроват. Четкое разделение на модули — основная цель реализации, процентов на 99 выдержана (кроме пары вызовов инициализации пути из main). Что касается вызовов foo(char *data), то сделано это с целью получить интерфейс, адаптированный к использованию UART микроконтроллера в режиме DMA. Конечно, по всем канонам это небезопасно, но в данном случае используются глобальные массивы фиксированного размера и фиксированные поля данных строго в пределах этих массивов. Понятно, смотрится это не очень красиво, тем более для библиотеки. Буду рад, если предложите более изящное решение, но в первую очередь удовлетворяющее требованием к интерфейсу, модульности и переносимости.
Блин, это очень круто! К сожалению не могу поставить "+".
И да, опубликуйте весь проект на github, а ссылку добавьте в статью.
Если так, то по запросу на почту рад предоставить тестовые сборки

Если нет доверия к публичным github-like сервисам, то почему бы не поднять свое gogs.io?
С учетом end-to-end шифрования звонков в WhatsApp, Viber, Signal в чем преимущество сервисов на основе tor, кроме сокрытия самого факта звонка?

Децентрализованные сервисы это отлично, но лично для меня побеждает удобство использования.
Пожалуйста почитайте новости из Шри-Ланки, где были заблокированы подавляющее большинство ресурсов.
VPN всё решает, нет? Я себе настроил бесплатный Outline на AWS (через год перерегистрироваться и заново запустить)
Разница в том, что провайдерам можно зафиксировать сам факт совершения вызова, насколько я понимаю. Можно определить звонящего, можно определить вызываемого, можно определить сам факт того, что это звонок (по ClientHello, например).
Наверное. Ну, по пакет-сайзам можно распознать, например? В любом случае тором надёжнее.
Спасибо за очень важное приложение!

Подскажите, пожалуйста, какие реальные значения latency могут быть в случае с EDGE, а какие — для широкополосного доступа?

Возможно ошибаюсь, но с точки зрения latency Wave API проигрывает Direct Sound, хотя на общем фоне, вероятно, незначительно.
Для GPRS (2G) задержка составляет около 0.8 сек, для WCDMA (3G) менее 100 мсек. Tor вносит от 0.5 до 1.5 сек. Но важен также jitter: для его компенсации необходим буфер, вносящий дополнительную задержку. В Торфоне этот буфер в широких пределах адаптируется к каналу, и алгоритм различен для звонка через Tor, TCP-звонка на IP-адрес и UDP-соединения после прохода NAT. Что касается различия между Wave API и Direct Sound, то оно ничтожно в сравнении с задержками в GPRS и, тем более, в Tor. Wave API было выбрано из-за лучшей совместимости (текущая Windows-версия работает от Win98 до Win 10).
Черт с ней с задержкой и кросплатформенностью. Мне больше интересует будут ли мешать операторы прохождению тор-траффика. Например сейчас операторы грешат тем что обрубают сессии к контенту если не могут предоставить надлежащее соединение.
Несколько дней назад тестировал в Free WiFi на Киевском вокзале в Москве. WhatsApp и Viber не работают голосом, прямое TCP соединение блокируется на порт по умолчанию 4444, но успешно на 8080, соединение через Tor работает везде. Tor заблокировать не так просто, судя по опыту Китая и Ирана.
Дело даже не в блокировке как в таковой сколько в шейперах и прочей нечисти.
Вот поэтому личный разговор не сможет заменить никакой костыль.
Теперь все эти перипетии с Телеграмом кажутся чем-то ничтожным. Потому что вот он — проект, бескомпромиссно использующий современные технологии для приватной связи. Вот так в одночасье претензии на доступ к переписке стали бессмысленны, потому что появился способ действительно анонимной связи.

… который из-за "удобства" пользования и сырости проекта никому не нужен. Все продолжают пользоваться телеграмом.

Это всё-таки разные продукты (если можно назвать Торфон продуктом на текущей стадии) и сравнивать их бессмысленно. Конечно, Телеграм как мессенджер с самым удобным интерфейсом в мире (IMHO) ультимативно привлекателен. Но у него закрыта серверная часть и фактически есть точки отказа. А здесь появился проект с вроде как открытым исходным кодом и другим способом связи. Да, ему без году неделя и пока не было никакого аудита кода. Но как концепт это просто «вау» — выжать из Tor-сетей такую низкую задержку при голосовой связи и одновременно обеспечить работу вне Tor сетей, пускай с потерей анонимности — это сильная идея.
В чем проблема просто пользоваться телеграмом? Ведь там тоже имеется шифрование трафика по звонка. Или я чего то не знаю?:)
Спасибо за статью.
Поясните, а что с MOS в реальной жизни? Проводились измерения?

P.S.
выражение " а также постепенное отвыкание пользователей от PSTN в пользу GSM связи с присущей ей значительной латентностью. " не верно.
Качество голосовой связи оценивают несколько по другому, вот тут хорошая статья:
habr.com/ru/post/177099

Качество голосовой связи — понятие весьма многогранное. В данном проекте основным вызовом была задержка, вносимая Tor. И дискомфорт пользования Торфоном определялся именно эти фактором. Но человек может адаптироваться к задержке существенно выше рекомендованных 400 мсек. Именно это имелось в виду в плане постепенного «привыкания» пользователя к высоколатентным каналам голосовой связи.
При необходимости человек прекрасно адаптируется к симплексной рации и нисколько по этому поводу не переживает — лишь бы работало надежно.
Симплексная рация имеет кнопку «Передача», и это «дисциплинирует» участников. В дуплексных высоколатентных системах участник, задавая вопрос, ожидает ответ, и, не дождавшись, начинает опять говорить в то время, когда ответ как раз доходит. Просто к этому нужно привыкнуть (другой пример — прямое спутниковое включение журналистов ТВ и их диалог со студией).
Спасибо всем за указание на мои глупые ошибки по тексту — поправил. Еще раз извините за мою невнимательность.

Можете, как автор, сравнить ваш продукт с https://jami.net/?
Обычно, все p2p звонилки и чаты имеют одну проблему — невозможность позвонить или отправить сообщение, если абонент оффлайн. Как у вас с этим?

Хм, я впервые слышу об этом проекте. При беглом знакомстве напоминает Tox (p2p через DHT) плюс SIP-клиент. Последний функционал потребует SIP-сервер (например, поднять свой Asterisk на белом IP).
DHT — это здорово, но я вижу тут другую проблему: количество участников должно быть достаточно большим, чтобы обеспечить безопасность системы. Но на старте проекта при недостаточной популярности, естественно, участников мало, и это весьма ограничивает развитие. Т.е. получается замкнутый круг.
И, кстати, я не увидел внятного описания криптографии. Ее нет вообще, или я не нашел в их Вики? Подскажите ссылку, если она есть.
Что касается оффлайн-состояния, то это проблема мессенжеров, но никак не звонилок: разговаривать с отключенным абонентом невозможно априори. Многие месенжеры решают проблему по разному, но это отдельная тема, и тут другие модели угроз. Я просто отказался от чата в Торфоне — нет чата, нет и проблем.
Хм, я впервые слышу об этом проекте.

Ранее назывался SFLphone, а потом GNU Ring.


DHT — это здорово, но я вижу тут другую проблему: количество участников должно быть достаточно большим, чтобы обеспечить безопасность системы. Но на старте проекта при недостаточной популярности, естественно, участников мало, и это весьма ограничивает развитие. Т.е. получается замкнутый круг.

Я предполагаю, что DHT используется только для поиска участников. Можете раскрыть мысль про проблемы с безопасностью и замкнутый круг?


И, кстати, я не увидел внятного описания криптографии. Ее нет вообще, или я не нашел в их Вики? Подскажите ссылку, если она есть.

Не подскажу — я ее сам не видел.


Как я понимаю работу jami:


  • При создании аккаунта генерируется пара ключей (допустим rsa).
  • Для поиска участников используется что-то типа трекеров для торрентов.
  • При добавлении контакта происходит обмен ключами.
  • Далее используется end2end шифрование.

Торфон делает похожие вещи, только вместо dht используются onion сервисы и трафик "блуждает" через промежуточные узлы.


Но это только мои фантазии на тему.

Я имел ввиду вариации Sybil attack. При незначительном количестве пользователей злоумышленник легко может контролировать сеть, извлекая метаданные так же эффективно, как и в случае контроля центрального сервера. С ростом количества участников делать это сложнее.
В современных коммуникаторах оконечное шифрование само собой разумеется, и на первый план выходят другие требования, определяемые свойствами протокола: PFS, отрицаемость, защита ID, KCI и UKS — устойчивость и т.п. В этом плане хорошими примерами являются протоколы Axolotl («трещетка» с окном компромисса в Signal, WhatsApp) и новые разработки OTR (с использованием ring signatures на билинейном спаривании). MTPproto (Telegram) и Tox собраны «на коленке» и, хоть и практически безопасны, имеют теоретические изъяны.
Так что пока jami не предоставит формализованное описание протокола, говорить вообщем то не о чем. Особенно глядя на их гламурный сайт: там только лишь не хватает фраз «military grade encryption» и «AES-256» для полного счастья…
ПС: нашел таки протокол git.jami.net/savoirfairelinux/ring-project/wikis/technical/Protocol
Использует DTLS, аутентификация осуществляется RSA-4096 ключом (собственно, аккаунт). Для шифрования медиа используется SRTP, ключ согласуется посредством SDES под DTLS.
В принципе, все доказуемо стойко. Нет отрицаемости, но это на сегодня не самое актуальное свойство. Хуже, что нет защиты ID: злоумышленник может собирать информацию о звонках, привязанную к приватному ключу, особенно, с учетом Sybil attack.
Но это проблема не только jami, почти все ею страдают в той или иной степени.
В Торфоне я, по крайней мере, старался ее решать использованием протокола с нулевым разглашением. И надо еще учитывать и практическую сторону: в реальных условиях злоумышленник, собирая статистику, будет скорее привязываться к IP пользователей, чем к их приватным ключам.
Sign up to leave a comment.

Articles