Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 76
Идея шикарная, но ахиллесова пята - передача файлов оффера и ответа. Как бы не передавались эти файлы - факт обмена этими файлами не через вашу программу покажет связь между двумя людьми.
Куча бесплатных уже давным давно есть.
В том-то и дело, что почти все они используют серверы, даже если этого не видно. Моя идея это соединение вручную, вообще без них. Это другая концепция.
: “Если приложение про приватность, почему код не открыт?”. Хочу ответить на это максимально честно.
Silent Channel - это мой коммерческий проект, в который вложено много сил на решение задач P2P-стабильности. На данном этапе я выбрал модель закрытого кода для защиты
Вынесете это, пожалуйста, в заголовок. Потому что дальше можно не читать.
Справедливое замечание. Я, как и многие, верю, что честный труд заслуживает честной оценки. Надеюсь, вы тоже не работаете исключительно за идею. Статья, впрочем, остаётся бесплатной для всех любопытных
Ну вы же рекламируете товар. Так рекламируйте его заинтересованным в покупке клиентам, а не случайным прохожим, зашедшим поинтересоваться решением... Ведь сами признали "для многих отсутствие Open Source - это «красный флаг»." Так зачем вы заставляете их время терять?..
Спасибо за вашу точку зрения. Цель статьи - в первую очередь обсудить архитектуру чистого P2P-соединения и её жизнеспособность, а не продвижение продукта. Модель монетизации упомянута лишь для полноты картины, так как это часто важный практический вопрос. Основная задача - получить мнения и отзывы от читателей, чтобы понять, насколько такая концепция вообще имеет перспективы и что в ней можно улучшить. Ваше мнение, как человека с интересом к теме, тоже ценно для этого обсуждения.
так вроде это нормально в рекламе. Вдруг кто-то из изначально не желающих передумает под влияним аргументов?
а как у вас связываются клиенты за NAT? Какой TURN сервер они используют?
TURN сервер не используется. Только STUN сервера.
Присоединюсь к вопросу, это было первое, о чём я подумал.
Плюс более глобальный: как двум клиентам найтись? Допустим, я хочу связаться с кем-то, как я идентифицирую собеседника? По его IP? По какому-то уникальному ключу? А как наши приложения узнают друг друга? Как проверить, что посреди нас не появился мужик посередине?
Вы правы, но именно этап обмена файлами и есть критическая точка. WebRTC защищает уже установленный канал, но не процесс «рукопожатия».
Если злоумышленник перехватит и подменит файлы offer и answer в момент их передачи (например, по email или в другом мессенджере), он может встать между вами, представившись каждому из вас вашим собеседником. После этого он сможет расшифровывать и перенаправлять весь трафик.
Думаю для этого можно использовать рэндомный/одноразовый канал доставки предложения/ответа. Не уверен что все каналы мужик посредине сможет отследить.
Это не делает систему абсолютно неуязвимой (теоретически, целевая атака на конкретных лиц всё ещё возможна), но повышает порог входа для атаки на несколько порядков, что для большинства сценариев более чем достаточно.
Вообще, было бы интересно почитать о безопасности stun и turn серверов. Без них никакого p2p нет.
STUN сервера только выдают однократно тебе твой публичный адрес в момент запроса, но он не знает, с кем вы планируете общаться дальше.
Использование же TURN-серверов сопряжено с серьезными рисками для приватности, так как владелец сервера технически может видеть IP-адреса участников и объемы передаваемого трафика. TURN же видит IP обеих сторон одновременно, так как он соединяет их внутри себя.
Вопрос туда же: если несколько устройств сидят за NAT, и двое из них решили связаться с кем-нибудь извне по вашему протоколу, как система поймёт, кто куда подключается? По портам?
Система различает устройства за одним NAT в основном с помощью портов и механизмов NAT-трансляции, которые координируются через STUN-серверы.
Ключевую роль играют порты. Даже если публичный IP-адрес у всех устройств за NAT один, маршрутизатор назначает уникальный внешний порт для каждого исходящего соединения. Это позволяет системе однозначно идентифицировать, какому именно устройству в локальной сети предназначен входящий трафик.
Давно ждал чего-то подобного (я не программист).
По оплате: нет подписки. Пишу здесь, т.к. в GPlay невозможен отзыв без установки программы.
Зачастую разовая оплата программы это - высокая вероятность, что проект рано или поздно будет заброшен... неоднократно сталкивался.
Задумка прямого P2P-соединения хороша, но в реальном мире почти неосуществима. Вы убрали из модели угроз сервера, которые могли бы хранить метаданные о вас, вашем онлайн/оффлайн статусе, переписках и прочей активности - это хорошо. Тем не менее P2P-соединение - оно не является прямым, оно проходит сквозь множество маршрутизаторов провайдеров связи, фактически тех же серверов, всё также собирающих множество метаданных. Чтобы скрыть от них активность уже недостаточно обычной установки P2P-соединения в сети Интернет. В результате, мы получаем слегка пониженный риск сбора метаданных, но основной риск в лице майора - он остаётся.
Вы совершенно правы: P2P-соединение не является абсолютной защитой от слежки, а скорее меняет источник угроз. Оно устраняет центральный сервер, который хранит метаданные и историю переписки, что защищает от корпоративной слежки и взломов серверов. Однако, как вы верно заметили, соединение проходит через маршрутизаторы провайдеров, которые по-прежнему могут анализировать сам факт коммуникации между IP-адресами.
Ключевая уязвимость чистого P2P — раскрытие реальных IP-адресов собеседникам, что позволяет легко их идентифицировать.
Именно эту проблему эффективно решает VPN. Он скрывает ваш настоящий IP-адрес от собеседника и шифрует трафик от локального провайдера, перенося "точку доверия" на VPN-сервис. Таким образом, комбинация P2P и VPN значительно повышает уровень приватности, защищая как от корпоративного, так и от другого анализа трафика, при условии выбора надёжного VPN-провайдера.
У вас VPN ещё в придачу? Или вы так съехали с темы?
>>при условии выбора надёжного VPN-провайдера
Если резюмировать, то здесь самый обычный P2P без какой-то большой маскировки -сетевая активность по-прежнему видна.
А если ваш проприетарный код написан ИИ (в чём я не сомневаюсь, учитывая структуры текста в ваших сообщениях и текстах) без аудита профессионального разработчика, то грош цена вашему решению, извините.
Пусть это будет вашим pet-проектом, который вы сможете демонстрировать на собеседованиях.
А выложить apk на github или у себя на сайте можно?
Интересно, если это Москва, с Билайна на МТС пройдет звонок через эту штуку? Вы можете попробовать?
Идея Pure P2P, по моему мнению пушка. Выкинуть сервер из уравнения - единственно верный путь. Нооооо... давайте без иллюзий. "Приватность базируется на архитектуре" разбивается о "я выбрал модель закрытого кода". В мире Security это так не работает насколько мне известно. "Trust me, bro" это тоже не аргумент. ИМХО. Если я не могу скомпилить клиент сам и убедиться, что он не пишет копию SDP-оффера в скрытый лог (который улетит при краше или обновлении), то вся эта "архитектурная защита" держится на честном слове. Или я что-то не понимаю?
Хотите доверия параноиков (а это по сути ваша ЦА) - открывайте код. Хотите денег - продавайте сборки в сторе, донаты или Enterprise-лицензии. А "Приватный проприетарный мессенджер" - это оксюморон.
Согласен с вами на 100%: в безопасности одних слов недостаточно. Поэтому главный принцип Silent Channel - полная проверяемость сетевой активности на уровне ОС. Любой желающий (с помощью Wireshark, PCAPdroid или встроенного мониторинга) может убедиться, что после обмена SDP-файлами приложение не устанавливает ни одного соединения с какими-либо внешними серверами - только прямой P2P-канал с собеседником. Архитектура без серверов - это не просто заявление, а технический факт, который можно подтвердить независимо от открытости кода. Для параноиков (нашей ЦА) это, пожалуй, даже важнее, чем исходники - ведь даже в открытом коде можно спрятать сюрприз, а здесь доказательство лежит в плоскости сетевого трафика, который вы можете проконтролировать сами.
Бэкдор может ждать сигнала к действию молча :)
Это верное наблюдение. Однако в системе без серверов «сигнал к действию» должен откуда-то прийти. Приложение не имеет фоновых подключений — весь его трафик это прямое P2P-соединение, которое можно проверить. Чтобы активировать бэкдор на конкретном пользователе, нужен механизм целевой доставки команды, а в чистом P2P для этого просто нет инфраструктуры. Интересно услышать вашу гипотезу: как, технически, по-вашему, мог бы выглядеть такой сигнал и каналы его доставки в данной архитектуре?
С инициализацией соединения со стороны клиента спустя 180 дней от вчера, либо 18 сентября...
Как верно заметили, параноики не станут верить на слово. Проверять весь трафик? Ну такой себе совет на самом деле, в данном контексте
В андроиде есть такое понятие как бекграунд/фореграунд сервис. Он должен быть прописан в манифесте по типу <uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
Открываете приложение при помощи к примеру jadx, смотрите манифест (он там в открытом виде). Там указаны все разрешения. Вы увидите что там перечислены только вот эти:
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.CHANGE_NETWORK_STATE" />
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.RECORD_AUDIO" />
<uses-permission android:name="android.permission.MODIFY_AUDIO_SETTINGS" />
Эти разрешения не дают возможности находиться приложению в бекграунде и быть готовым принимать в любой момент команду или активизироваться.
Вы так же не найдете описания никаких других сервисов которые могут подобным заниматься. Чистое сингл активити.
Есть механизмы стеганографии по встраиванию бэкдора в криптографию. Например, можно к каждому шифрованному офферу прилагать метаинформацию, зашифрованную публичным ключом злоумышленика. Или в самом p2p соединении оставлять шифрованный блок.
Дальше продать эту информацию провайдерам/точкам обмена трафиком и профит. Ну или мониторить офферы и собирать информацию.
Или в другую сторону: а сколько по времени нужно производить эксперимент по мониторингу? Что если приложение выходит на связь только раз в сутки, в глубокую ночь?;)
И напомню, что всю процедуру проверки необходимо повторять после каждого обновления. С нуля, т.к. неизвестно что поменялось.
Короче говоря, нет. Закрытые исходники — это крест на доверии/приватности.
Offer/Answer - сигнальные текстовые файлы стандартного JSON с ICE кандидатами. Вы их можете легко проверять.
Мониторинг можно делать автоматическим, покажет пустоту за ночь. Приложение не имеет разрешений для работы сервисов в бекграунде - см. манифест. А если приложение не имеет возможности получить команду в любой момент, то это явно не айс.
Открыть исходники - подумаю. Может быть позже. А пока у меня маленький вопрос - а зачем это мне?
Вопрос не в том, чтобы убедиться что нет конкретной лазейки. Вопрос в том, что доказать отсутствие бэкдоров внешними методами — крайне проблематично.
А пока у меня маленький вопрос - а зачем это мне?
Не знаю. Если Вы хотите, чтобы Вашим приложением пользовались в качестве "приватного мессенджера" — то открыть прийдётся. Если же Ваша ЦА — обычные пользователи, которым просто нужен мессенжер (удобный, красивый, etc), то можете не открывать.
Если что, открытие исходников не означает отсутствие заработка. Можете рассмотреть разные модели монетизации.
Вопрос именно в том, что открытые исходники есть необходимый пререквизит к приватному мессенжеру. Если мы о реальной приватности, а не о маркетинге, конечно
Не разделяю общий восторг. Надёжность системы будет равна надёжности ее самого слабого компонента. Обмен ключами, поиск в глобальной сети абонента добавляют ту самую ложку дегтя, превращая всю бочку меда в бочку ну точно не меда.
Переходите на ipv6, и вам не нужны будут посредники. Yggdrasil / mycelium например. Используйте готовые решения типа i2p или tor - развивайте эти сети, и в них транслируйте ваши сообщения. В чем проблема? Есть куча вариантов.
А вот эти вот ваши чистый прямой p2p так же будет залогирован операторами.
Ура, мы достигли использования ИИ вместо человека на всех этапах разработки продукта, от кода и сайта, до написания статьи на Хабр.
... и ответов в комментариях. Вернее, надеюсь, что это просто мерещится мне.
Вы совершенно правы: P2P-соединение не является абсолютной защитой от слежки, а скорее меняет источник угроз.
Вы абсолютно правы, я использую AI для написания приложений Андроид приблизительно с 2009 года, для публикаций на Хабре с 2011 года. Да, еще библиотеки на GitHub c 2010 года.
Рекомендую, очень помогает. Я исправлю статью.
Или я что-то не понимаю, или...
Зачем на сигнальном сервере что либо сохранять? Я делал чат, сокет принял-отправил сообщение и забыл.
Keet вроде уже придумали... Вы придумали его еще раз? :)
Скрытый текст
Слушайте, ну хоть не позорьтесь написанием ответов с помощью ИИ. Видно же насквозь и по обычным признакам, и по повторяемости, и по занудству.
Если вы душу в софт вложили, так и ответить могли бы. А если там нейро-слоп "напиши мне приложение для отправки текста через WebRTC" (как у вас в промпте для ответов на комментарии), то платить вам не за что. Самое ответственное (передачу ключ-файлов) вы не придумали.
Статья про "народный" (пролетарский) мессенджер, а в конце интеллектуальная собственность, монетизация... Не изжил ещё мелкобуржуазное в себе.
Лучше бы донаты принимал.
Вы правы, возможно если бы не было войны, то у меня не было бы столько свободного времени в связи с отсутствием работы и невозможностью выйти из дома (загребут ТЦК). А так появилось много свободного времени чтобы придумать как прокормить семью.
Сейчас я полностью мелкобуржуазный и только истинные пролетарии не нуждаются в земной пище. А поскольку учился в советское время, то не умею нормально продавать свои продукты (не учили), поэтому до крупно буржуазного не дорос.
Донаты вещь хорошая. Только "кто девушку поит, тот ее и танцует". Не хочется заниматься танцами с кем то.
Мне кажется честней использовать либо бесплатную версию с небольшими ограничениями, либо одноразовый небольшой платеж. Ну и конечно же можно вообще не использовать ).
Чем все эти "приседания" и сложности лучше, чем скажем выдать ключ от непривилигированного доступа по ssh на любой арендованный сервак в Африке, где можно двоим пообщаться в текстовом файлике и оставить файлы прям в домашнем каталоге?
В этом сценарии я вижу проблем не меньше, чем в предлагаемом в статье варианте
есть неплохая технология - симплекс чат.
У тебя может быть идеальный P2P, но если оба за CGNAT — вы никогда не встретитесь.
Автономность
И вот тут как раз будут проблемы на мобильных устройствах. Потому что если у вас нет сервера, который через сервисы вендора пришлёт пуш "проснись, Нео, у тебя новое сообщение", то нужно держать приложение постоянно активным. А пользователю хочется, чтобы батарея разряжалась помедленнее и жила, хотя бы, в течение дня (во время которого он ещё и ютуб смотрит, и веб читает).
Вторая проблема - оффлайн сообщения. Например, собеседник свернул с трассы и временно потерял доступ к интернету. Или случился налёт беспилотников и интернет отключили. Если нет сервера, то сообщения будут бегать лишь тогда, когда оба собеседника в сети.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Удалил сервер из мессенджера. Как общаться по P2P в 2026 году без метаданных и Google Services. Личный опыт и KMP