Комментарии 54
Здесь неправильное сравнение (конечно в угоду этому проекту), если и сравнивать его, то не с telegram надо, а с briar.
threema уже давно есть вроде?
Есть. В реестре.
https://roscenzura.com/threads/2527/
Что-то очень много непонятных решений для "безопасного" общения.
Заменили идентификаторы на избыточные очереди, а в чем смысл? Это также идентифицирует пользователя такой сети, просто усложняя метод идентификации (впрочем в своей статье авторы сами в этом признаются). Только вот искать контактов в таком случае станет сложнее обычным пользователям. Про проблемы мультикаста (сообщение многим адресатам) тоже умолчу.
Про защиту от MITM - ничего не понял. "Запросы на соединение передаются вне сети" - так если так поступать в других системах это тоже защитит их от этой атаки. Но как это сделано тут? Борьба с MITM это довольно хитрая штука и здесь я не увидел описания защиты.
"разрешены только TLS 1.2/1.3, ограниченные криптографические алгоритмы" - сомнительное техническое решение, не способствует доверию участников общения. Как обновлять схему при нахождении проблем в текущей (а они обязательно будут)?
"Серверы не хранят никакой пользовательской информации" - а что мешает им хранить? Получается я должен доверять серверу, но я его не выбираю (его выбирает абонент с которым я общаюсь). Вот это "Для защиты от атак повторного воспроизведения ..." хорошо помогает собирать метаданные по клиентам на стороне сервера.
"Пользователи могут менять серверы с минимальными перебоями – даже после исчезновения используемого сервера" - э... а как я узнаю о появлении нового сервера? Или как новый сервер узнает о появлении меня с моими очередями? А если сообщать явно - это утечки метаданных и возможности для хитрых атак.
Добавлю еще одно - как предполагается защищать эти сервера (которые, судя по всему, должны хостить добровольцы) от злонамеренного использования? Например, чтобы заботливые авторы ботнетов не использовали их как прекрасный децентрализованный командный центр?
А зачем? Можно же координировать ботнет хоть даже через хабр. (Коммент "А зачем*" в сегодняшнем посте дает команду делать X, а коммент "добавлю еще одно*" - команда делать Y. Лишь бы это не убивало, не перегружало саму сеть.
Иначе и в календаре надо делать защиту, вдруг жена там внесет запись "14:00 подсыпать мужу цианистый калий в обед".
«разрешены только TLS 1.2/1.3, ограниченные криптографические алгоритмы» — сомнительное техническое решение, не способствует доверию участников общения. Как обновлять схему при нахождении проблем в текущей (а они обязательно будут)?
Т.е. разрешить устаревшие протоколы лучше? Будет как с https
Это также идентифицирует пользователя такой сети
Идентификаторы очереди никак не связаны с каким то пользователем на уровне приложения, только на уровне сессии / транспорта, что отдельно решается.
"Запросы на соединение передаются вне сети" - так если так поступать в других системах это тоже защитит их от этой атаки. Но как это сделано тут?
Ссылка с адресом соединения и публичными ключами передается вне сети, дополнительно в следующей версии будет верификация. В других системах согласование ключа происходит через саму систему (за редким исключением типа PGP).
Как обновлять схему при нахождении проблем в текущей (а они обязательно будут)?
В протоколе есть согласование версии, просто добавится поддержка новой версии.
"Серверы не хранят никакой пользовательской информации" - а что мешает им хранить?
То что у них ни в какой момент времени нет никакой пользовательской информации вообще кроме адресов очередей, анонимных ключей для верификации запросов (ED448, которые разные для каждой очереди) и зашифрованных сообщений.
как я узнаю о появлении нового сервера?
так же, как вы узнаете о существовании нового email провайдера например - какие использовать серверы определяется только конфигурацией клиента, сами серверы не формируют сеть – они не знают о существовании других серверов.
Или как новый сервер узнает о появлении меня с моими очередями?
никак, на новом сервере будет просто создана новая очередь, и сообщения тому же контакту будут через нее передаваться, переключение прозрачно для пользователя.
Идентификаторы очереди никак не связаны с каким то пользователем
Идентификаторы не связаны напрямую, но вычисляются, об этом написано даже в официальной статье на сайте. Никакой особой дополнительно анонимности от замены прямых идентификаторов косвенными нет, кроме дополнительных сложностей. Хотя может где-то есть сводная таблица достоинств и недостатков?
Ссылка с адресом соединения и публичными ключами передается вне сети
Вопрос и был в том как это сделать прозрачно для пользователя? В сравнительной табличке было написано что система противостоит MITM, но передача ключей по стороннему каналу сделает любую систему защищенной от MITM. Тут я не увидел никаких объяснений на этот счет, почему это именно эта система лучше всех остальных.
у них ни в какой момент времени нет никакой пользовательской информации вообще кроме адресов очередей, анонимных ключей
Так этой "анонимной" информации достаточно чтобы собирать статистику с какого адреса запрашивают какие данные из какой очереди и тем самым потихоньку набрать информацию. В любой (полу)централизованной системе - сервер может играть против пользователя. Только полностью децентрализованная система может пытаться защитить пользователя от злонамеренного сервера.
так же, как вы узнаете о существовании нового email провайдера например
Это же жутко неудобно и непрозрачно для пользователя. Я что должен следить за серверами при общении? Или где-то есть централизованный список всех доступных серверов (здравствуй полная централизация этой сети)?
на новом сервере будет просто создана новая очередь, и сообщения тому же контакту будут через нее передаваться
Можете описать что будет если во время сеанса между А и Б рухнет их общий сервер? "А" полезет выбирать свой другой, "Б" свой другой, как они согласовывать это будут если прямой связи между А и Б больше нет по определению?
Идентификаторы не связаны напрямую, но вычисляются, об этом написано даже в официальной статье на сайте.
Не очень пока понимаю о чем это?
передача ключей по стороннему каналу сделает любую систему защищенной от MITM.
Это верно, но другие системы этого просто не позволяют (за редкими исключениями вроде email/PGP)
Вопрос и был в том как это сделать прозрачно для пользователя?
Это будет решать optional identity layer (который тоже не будет раскрывать social graph).
с какого адреса запрашивают какие данные из какой очереди
IP адреса можно/нужно защищать на уровне транспорта - Tor итд
Это же жутко неудобно и непрозрачно для пользователя.
Вы же знаете какого провайдера вы используете для email – почему это неудобно иметь возможно поменять провайдера не теряя никакие контакты при этом (как произойдет в случае с большинством email провайдеров, за исключением случая когда вы используете свой домен)?
Или где-то есть централизованный список всех доступных серверов
Нет, и его не должно быть, иначе это будет централизованная сеть. Есть ли где то список всех email providers?
Можете описать что будет если во время сеанса между А и Б рухнет их общий сервер? "А" полезет выбирать свой другой, "Б" свой другой, как они согласовывать это будут если прямой связи между А и Б больше нет по определению?
1) это событие очень низкой вероятности, и если нет redundancy то придется установить новый контакт 2) будет redundancy.
Насколько я понимаю, для этого вам и Васе нужно встретиться, и добавить друг друга.
>Какая уникальная информация, которая позволит сообщениям приходить от вас ко мне.
id очереди сообщений я так понимаю. В принципе для чатов на несколько человек могло бы и сработать, если действительно нельзя определить по сообщению кто его написал.
Гипотетическая схема с потолка:
Первоначальный обмен ID
Генерация ключей, согласование сессии закрытой e2e шифрованием
Обмен сообщениями
Устройства генерируют новый ID и проводят регистрацию на сервере, сервер понятия не имеет что это теже самые устройства
Внутри согласованного канала в п.2 происходит ротация ID, серверу этот обмен недоступен ибо зашифровано
Продолжение общения по новым ID, для сервера неотличимо от новой сессии пункта 1, с абсолютно новых устройств. Для клиента - разрыва нити беседы нет
И где вот тут вот противоречие написанному мной? И вот этот ID можно поменять
Но чтобы сообщения доходили то получается, что нужно либо заново встретится и по блютуз обменяться новыми идентификаторами
Суть в том, что не надо встречаться лично для ротации ID/ключей, и это логично. Но это не отменяет необходимости в изначальном установлении доверия, самом первом
либо сервер должен сам знать какой был, а какой стал
Это тоже лишнее, устройства сгенерировали новые ID, провели их регистрацию на сервере, обменялись ими в текущей сессии, чтобы начать новую. Сервер будет знать что по изначальным ID кто-то переписывался, по новым ID кто-то переписывался, но сервер понятия не имеет что это одни и теже люди
MITM сразу на пункте 1.
Вернемся к обсуждаемой статье о мессенджере
Запросы на соединение передаются вне сети, не обязательно защищая обмен ключами от атаки MITM (человек посередине).
Т.е. для надежности ты сам должен обеспокоится изначальным обменом, например при личной встрече.
P.S. опять же, если вернутся к данной статье, автоматическая ротация ID на уровне сети ещё только в планах
P.P.S в целом, на уровне данной статьи выглядит достаточно интересно, с учетом e2e (если оно там нормальное), и когда прикрутят ротацию идентификаторов. Но все же проблему доверия к собеседнику оно не решает и скорее всего не взлетит. Telegram/WhatsApp/Signal решают её по средствам "арбитра" в виде сервера, проверяющего номер телефона и имеют низкий порог вхождения. Но претензии к ним, а они есть, я сейчас обсуждать не намерен
да, такая атака возможна, но это очень сложная атака если например вы показываете qr code в видео звонке. Следующая версия (сегодня/завтра будет бета) добавит возможность проверить security code через другой канал.
Ну это не id профиля, это как ссылка на веб страницу где любой может что то написать без всякой авторизации. Если ссылка достаточно уникальна и обьяснить ее наличие на телефоне можно как: "я просто смотрел но не писал" то вполне себе интересное решение
Т.е. фактически ID профиля есть. Просто он иногда меняется.
Нет, у профилей нет никаких идентификаторов, идентификатор есть у Вашего соединения с одним контактом только (pairwise identifier), и он иногда меняется. Наличие ID профиля позволило бы двум контактам установить что они общаются с одним и тем же пользователем, в данном случае это невозможно, потому что два разных контакта не видят никаках общих данных кроме display name (которое во-первых low entropy и не уникальное, то есть его совпадение не доказывает что это тот же самый пользователь, во-вторых можно каждому контакту слать случайное display name - для этого есть incognito mode).
Но чтобы сообщения доходили то получается, что нужно либо заново встретится и по блютуз обменяться новыми идентификаторами, либо сервер должен сам знать какой был, а какой стал.
нет, это не так работает. Для переноса коммуникаций с тем же контактом на другой сервер клиент передает адрес новой очереди через зашифрованный канал, прозрачно для пользователей, не надо заново встречаться, это просто часть протокола. При этом старый сервер не знает куда перешли коммуникации, он только видит что очередь удалена, а новый сервер не видит откуда они пришли - для него это просто новое соединение.
он работает не так как другие
это корректное утверждение, SimpleX протокол отличается от всех остальных тем что вместо profile identifiers & user credentials используются temporary pairwise connection identifiers / anonymous credentials. Если вы представите себе ваши коммуникации как граф, где узлы это пользователи, то во всех сетях часть или весь граф пользователя доступен для наблюдения оператором или другим пользователям, в данном случае узлы сети недоступны серверам, серверы только предосталяют односторонние соединения. На сайте (https://simplex.chat) в разделе SimpleX Explained есть картинка которая это объясняет.
я в приложении на своём телефоне нажимаю кнопку «сгенерить QR-код», вы на своём нажимаете «считать QR-код». (как в Briar, собственно.)
разница в том что в Briar этот QR code является идентификатором профиля пользователя - он один и тот же для разных пользователей, в SimpleX этот qr code одноразовый (многоразовый тоже можно сделать) и два разных кода не содержать никакой общей информации (кроме адреса relay где создана очередь для сообщений).
это верно, однако, насколько я понял, не это интересовало shasoftX, который спросил, как пользователи находят друг друга для общения .
— Не очень понятно, как пользователи находят друг друга для общения если нет никакого ID профиля. Т.е. вот я хочу общаться с Васей Петровым. Оба мы подключились. Но как будет выглядеть процесс поиска куда отправлять сообщения вида "отправить Васе Петрову"?
— Насколько я понимаю, для этого вам и Васе нужно встретиться, и добавить друг друга.
— Вот и непонятно, что именно и как нужно добавить. Т.е. вот у нас установлена эта программа. Мы с вами встретились. …и "что именно будет добавлено вам и мне"?
я этот вопрос истолковал в практической плоскости: что нужно делать. (судя по его более поздним репликам, я ошибся. ну ок.)
первоначальное приглашение может быть передано через открытый канал, при условии что он не подменяет информацию - там только публичные ключи и одноразовый адрес – это работает похожим образом на PANDA когда только один пользователь может получить доступ к ресурсу.
На гитхабе есть гифка с консолями:
Клиент 1 запускает клиент. Предтсавляется Алисой. Жмет коннект и получает ключ от какой-то очереди на каком-то сервере. Каким-то чудесным образом этот ключ доставляется Клиенту 2.
Клиент 2 запускает клиент. Представляется Бобом. Жмёт коннект, куда вставляет магическим образом полученный ключ и попадает в ту же самую какую-то очередь на каком-то сервере.
Каким-то чудесным образом этот ключ доставляется Клиенту 2.
Не "чудесным образом", а "передаётся каким-то образом в реальном мире". Например, записанным на бумажке. Но показать это средствами гитхаба было сложно.
То бишь полезность такой анонимности снижается до некоторого района проживания. В противном случае ключ-приглашение оказывается доступен и свинье. Интесный вопрос ещё насколько такие ключи устойчивы к перебору: запускаешь бота, который генерит какие-нибудь случайные ключи по типу AFL и пытается приконнектиться к ним.
это не совсем так - этот ключ не должен быть защищен от пассивной атаке - его можно передать через любой канал связи, при двух условиях - 1) вы доверяете что канал не подменяет информацию (что достаточно сложно сделать например при видео звонке) 2) вы можете установить личность получателя/отправителя
то есть можно установить соединение с кем угодно где угодно.
даже в случае если пункт 1 не выполняется, то с версии 4.4 можно проверить security code через какой то независимый от первого канал - если он совпадает, это доказывает что канал не был перехвачен, то есть это добавляет второй фактор.
В противном случае ключ-приглашение оказывается доступен и свинье.
Всё гораздо проще. Достаточно ввести фактор времени.
Отправляю емейл Васе: "Запомни часть A: 23132123234234823"
Отправляю SMS Васе: "Запомни часть B: 321231687217236"
В телеграме пишу Васе: "Запомни часть C: 67897646113183354"
По телефону звоню Васе: — Твой ключ: часть C до цифр 83 включительно + часть A от цифр 231 включительно + часть B до цифр 72 включительно.
Вася собирает части вместе (а они у него уже на экране), и за 15 секунд соединяется со мной в симплекс-часте. Я ему туда говорю: "новый ключ - 98134423453425322451234554324654234523, а все те три части выкинь".
Вот и всё. Для того, чтобы кто-то смог вклиниться в эту цепочку и сделать MITM, нужно, чтобы группа людей перехватывала ВСЕ приходящие Васе сообщения по ВСЕМ каналам связи (включая голосовые) без выходных и перерывов на обед (а если кто моргнёт, то всё, рыбка уплыла), при этом успевала делать все те действия, которые я говорю делать Васе, а потом все "обратные" действия (в данном случае — порезать подменный ключ, отправленный мною Васе, точно так же, как порезал его я, при этом ключ ещё надо подобрать такой, чтобы в нём были заданные цифры).
Помножить Васю на 10 и рутина становится довольно громоздкой. То бишь до уровня хотя бы того же матрикса на таких алгоритмах подняться едва ли выйдет. Профит если и будет, то только для чёрных делишек - хакеры, барыги и прочие тёмные личности из тёмной сети.
Помножить Васю на 10 и рутина становится довольно громоздкой
У Вас так много друзей, с которыми Вы обсуждаете такие вещи, которые хорошо бы не показывать тащу майору? И они так часто меняются?
(Любые наставления, кстати, во первых строках учат, что в ячейке должно быть не более трёх человек.)
То есть мессенджер изначально позиционируется как инструмент для нелегальных вещей, получается, а не как baseline messenger?
Ложная дихотомия. Мессенджер изначально позиционируется как "настолько защищённый, что по нему можно даже на нелегальные темы общаться".
Иными словами, если у Вас в спальне шторы задёрнуты — то это ни в коей мере не значит, что Вы там внутри варите наркотики, а не жарите жену.
Telegram, WhatsApp, Signal, TeleGuard и др
Вы сравниваете его с большими мессенджерами, но при этом из плюсов только относительно полная анонимность, при примерно никакой эргономике. Отсюда вытекает относительно узкая серая зона применения - что-то, что требует повышенной анонимности и перевешивает минусы такой многоступенчатой авторизации в чате - среднечеловек таким заниматься не станет. Потому и такие выводы.
что-то, что требует повышенной анонимности и перевешивает минусы такой многоступенчатой авторизации в чате - среднечеловек таким заниматься не станет.
Шторы. В спальне.
"Среднечеловеку" повесить шторы в спальне тоже не особо просто — это ж дрель покупать надо, дюбели, карнизы...
Я не согласен что полная анонимность необходима только для людей которые совершают противоправные действия, анонимность необходима всем, кто не хочет тратить лишние деньги, не хочет жить в информационном пузыре, который поисковые сервисы для них курируют, и не хочет лишиться свободы только из за того, что был знаком с кем то не тем, или оказался не в том месте не в то время. На сайте проекта описано как это сегодня все работают - мы уже давно перестали видеть один и тот же интернет и платить одну и ту же цену за одинаковые товары и услуги. Чтобы посмотреть куда двигаются централизованные платформы, посмотрите на системы Social scoring в Китае. Только на днях подписан указ о мониторинге ~9000 СМИ и не только в России. Поэтому позиция что privacy / anonymity нужна только в узких случаях немного устарела, мне кажется.
Проблема предлагаемой анонимности - достижение её либо проблематично, либо ни разу не анонимно/безопасно, как утверждается. Как впрочем и прежде до сих пор было. По этому всякие сигналы-телеграмы-ватсапы это такой компромисс между относительной анонимностью и безопасностью, вкупе с простотой использования. Для того чтобы иметь большую анонимность закономерно надо прилагать больше усилий, однако это не решает проблемы с общением, как это делают мажорные мессенджеры. А это по крайней мере 3 млрд уникальных пользователей. Поэтому, применимость настолько сложных способов анонимизации становится довольно узконаправленной.
совершают противоправные
собственно поэтому я и назвал это серой зоной - в стране может постулироваться свобода слова, но могут посадить за иногента в ленте или за мемасик, а может то была просто порнография и паства против - по закону имеют право нагнуть, хотя действительно дурного могло и не случиться. Или взять того же Сноудена, который однозначно преступник в США, но в России даже вроде свободный человек. Барыги опять же с одной известно, что поставляют запрещенку разного рода, но исходя из презумпции невиновности сделать однозначное соответствие нельзя, поэтому он вроде тоже относительно честный человек, а Вася просто сало солить любит на берегу Невы.
Именно поэтому мои вопросы были направлены в эту сторону и исходя из ответов выходит, что именно эта масса в серой зоне и есть целевая аудитория, а не некоторый генерик житель какой-нибудь страны. Поэтому все эти "шторы на окошке" в качестве примера анонимности оказываются не шторами, а бронированным тонированным односторонним зеркальным стеклом с идентификацией по сетчатке глаза.
И уж ни в коем случае я не против анонимности в интернете, несмотря на мои сомнения относительно предлагаемой анонимности.
Существует задача "Миллионеров-социалистов" и протокол, решающий её, может использоваться для безопасного обмена ключами, без риска проведения MITM атаки. Примером такого протокола может служить Off the Record.
В идеале я вижу проект аппаратно-програмный, уровня Meshtastic. Где помимо месседжера на когда все хорошо и есть интернет, есть режим работы с ble устройством на когда все плохо. Лучше чтобы LoRa модемы были встроенны в смартфоны, как экстренный канал связи.
Большое спасибо за статью - пользователь только что прислал ссылку! Сейчас отвечу на вопросы/комментарии!
Я правильно понимаю, вы автор данного проекта?
SimpleX – первый мессенджер без идентификаторов пользователей