Внимание! Не авторский материал, но выложен нами ввиду его ПРАКТИЧЕСКОЙ информационной ценности. Авторское будет в нашем комментарии. Источник: https://xss.is/threads/129896/
• Теги: #it #тайна_связи #переписка #безопасность #конфиденциальность #matrix_org #simplex #messengers #криптография #шифрование #приватность #анонимность
Статья для тех, кто беспокоится о конфиденциальности переписки, знает правду о Telegram и WhatsApp, но сомневается в безопасности и других популярных мессенджеров (типа Signal, TeleGuard и других). В том числе для тех, кто пользуется протоколом http://matrix.org и уверен в его безопасности.
Множество компаний собирают избыточную информацию о пользователях, которая, в случае утечек, взломов или иных инцидентов, может попасть в руки злоумышленников, что снижает уровень вашей личной безопасности. Например, из-за этого вы часто сталкиваетесь с назойливыми звонками или спамом в почтовом ящике. Это во многом связано с тем, что сервисы собирают огромное количество данных о своих пользователях и недостаточно тщательно защищают их.
В этой статье я расскажу об анонимном мессенджере SimpleX, который разработан на языке программирования Haskell и поддерживает работу через сеть Tor для безопасного общения.
Что такое SimpleX?
SimpleX — это один из немногих мессенджеров, который не собирает персональные данные пользователей, а также единственный, который не использует идентификаторы для профилей, даже случайные числа. Он полностью открыт для разработчиков и является open source, что позволяет любому желающему участвовать в его создании.
Как работает SimpleX?
Вместо использования идентификаторов пользователей для доставки сообщений, SimpleX применяет уникальные идентификаторы для очередей сообщений, которые создаются отдельно для каждого контакта. На текущий момент каждая очередь сообщений сохраняется до тех пор, пока контакт не будет удален или пока пользователь вручную не изменит адрес получения сообщений. В будущем команда проекта планирует автоматизировать этот процесс и добавить механизм ротации очередей в клиентский протокол, чтобы даже сами сообщения не имели постоянных идентификаторов, видимых в сети. Такая схема предотвращает утечку метаданных пользователей на уровне приложения.
Кроме того, пользователи могут самостоятельно выбирать, какие серверы использовать для получения сообщений. При этом, для отправки сообщений своим контактам, они будут использовать другие серверы. Это значит, что для каждого общения будет задействовано два разных сервера — один для получения сообщений и один для их отправки.
Профили пользователей, контакты, группы и сообщения с двухуровневым сквозным шифрованием хранятся исключительно на устройствах клиентов.
Протокол SimpleX
Разработчики SimpleX создали собственный протокол для передачи сообщений — SimpleX Messaging Protocol (SMP). Этот протокол предназначен для однонаправленной отправки сообщений получателю через промежуточный сервер. Сообщения передаются через однонаправленные очереди, которые создаются на стороне получателя.
SMP работает через транспортный протокол, который гарантирует целостность передаваемой информации, аутентификацию сервера, защиту конфиденциальности и привязку канала связи к транспортному слою.
Сервер SimpleX — это сервер, который участвует в процессе передачи сообщений.
Сеть SimpleX — это группа серверов, которые работают с протоколом SMP и способствуют его функционированию.
Библиотеки SimpleX Client используют язык SMP для общения с серверами SimpleX и предоставляют низкоуровневый API, который не предназначен для использования конечными приложениями.
Как видно на картинке, matrix оказывается лидирующим. Но давайте разбираться.
Чуть углубимся в матрикс.
Что может сделать злонамеренный администратор домашнего сервера Matrix?
У меня есть собственный домашний сервер Matrix, которым я делюсь с друзьями и семьей. С тех пор, как я начал работать в Element в феврале 2020 года, я узнал намного больше о протоколе Matrix и о том, что с ним можно делать. Во время разговора с несколькими друзьями, заботящимися о конфиденциальности, которые используют мой HS (HomeServer), я отметил, что администратор домашнего сервера имеет большую власть над их учетными записями и что они, как пользователи, явно доверяют администратору. В этом посте я хочу изучить и задокументировать способы, которыми злонамеренный администратор может нарушить конфиденциальность учетной записи Matrix. Примечание: злонамеренный админ в данном случае также может означать взломанного админа.Я буду говорить конкретно о Synapse, потому что это реализация домашнего сервера, с которой я наиболее знаком, но одни и те же аргументы должны применяться как к Dendrite, так и к Conduit, поскольку они касаются не конкретной реализации, а самого протокола. Более того, я подхожу к этому с точки зрения группы людей, где каждый использует домашний сервер, которому он доверяет, и доверяет всем в комнатах, в которых участвует, но один из пользователей находится на вредоносном домашнем сервере.Пассивный сбор информацииЗлоумышленник-администратор может собрать много пассивной информации, просто запросив базу данных Synapse, и это может произойти задним числом. Некоторые из (мета)данных включают в себя:История чата любой незашифрованной комнаты (ага!)1.Информация о пользователях их домашнего сервера (ага!), например, об устройствах, IP-адресах и т.д.2.Реакции на сообщения со сквозным шифрованием (e2ee), поскольку реакции не шифруются.3.Метаданные, связанные с комнатой (даже для комнат e2ee), участники комнаты и их аватары/ники, тема комнаты, уровни мощности, количество и когда отправленных людьми сообщений и т. д.4.Предварительный просмотр URL-адресов общих ссылок (если включено в настройках для каждой комнаты)Активные атакиЗлонамеренный администратор может осуществлять активные атаки на своих пользователей и комнаты, в которых они участвуют, если захочет. Некоторые из них можно легко обнаружить с точки зрения клиента, другие — нет.Возиться с комнатамиВ Matrix есть понятие событий состояния, которые определяют, как выглядит комната. Они определяют, какие пользователи входят в комнату, какие пользователи забанены, уровни полномочий пользователей, имя и тема комнаты и т. д. Эти события не являются e2ee, поэтому злонамеренный администратор может как прочитать их, так и отправить. свои собственные события, выдавая себя за пользователя своего домашнего сервера. В основном это может привести к атакам социальной инженерии. Я перечислю несколько способов социальной инженерии и эксплуатации людей, поскольку существует множество способов сделать это. Я буду использовать @victim:http://example.com в качестве учетной записи, которую выдает себя злонамеренный администратор.1.Реагируйте на сообщения как выдающий себя за пользователя. Злонамеренный администратор не будет знать содержания сообщения, на которое он реагирует, но сможет увидеть реакцию на него других.2.Установите тему комнаты на URL-адрес, контролируемый злоумышленником. Каждый участник комнаты, независимо от домашнего сервера, увидит, что это установлено пользователем @victim:http://example.com, пользователем, которому они лично доверяют. Таким образом возможна атака Drive-by или утечка IP-адресов сторонних пользователей.3.Пригласите аккаунты в комнату. Недавно присоединившаяся учетная запись не сможет читать предыдущие сообщения e2ee, но любые сообщения, отправленные после ее присоединения, будут видны с учетом настроек по умолчанию большинства клиентов.4.Выгонять и запрещать людям выходить из комнаты, что само по себе не так уж и плохо, но может мешать. Точно так же они могут повысить уровень мощности других пользователей в комнате.5.Отправляйте события надгробия, отмечая комнату как заменяемую для большинства клиентов и предотвращая дальнейшую отправку ей сообщений.В общем, у администратора комнаты есть несколько способов полностью разрушить или испортить комнату, вплоть до того, что единственным решением является воссоздание комнаты с нуля.
Вмешательство в устройства пользователя
Ранее описанные атаки можно осуществить, просто выдав себя за пользователей, не добавляя новые устройства в их аккаунт. Однако злоумышленный администратор может просто добавить новое устройство в аккаунт пользователя, что позволит отправлять и получать сообщения с сквозным шифрованием (e2ee).В большинстве клиентов это будет отображаться как незарегистрированное устройство, что приведет к появлению красного значка щита в комнате, сигнализируя о наличии незарегистрированного устройства. Исходя из моего личного опыта, большинство людей, даже тех, кто озабочен конфиденциальностью и обладает техническими знаниями, просто игнорируют это по разным причинам. Я сам тоже был виновен в игнорировании этого. Однако в настройках сессии и каждой комнаты можно отключить отправку сообщений на незарегистрированные устройства, если хочется быть полностью в безопасности.В большинстве случаев атакованный пользователь получит уведомление в своем клиенте о том, что было добавлено новое незарегистрированное устройство. Существуют способы обойти это уведомление, не сообщая пользователю о добавлении нового устройства, однако я не знаю, будет ли продолжать работать шифрование в таком случае.
Резюме
Вы не можете предотвратить того, чтобы злонамеренный администратор читал различные (мета)данные или необратимо вмешивался в комнату, если пользователь на их домашнем сервере обладает достаточными правами. Однако вы можете предотвратить чтение сообщений с e2ee, если все следуют правильной гигиене устройства и не отправляют сообщения на незарегистрированные сессии.Одним из возможных решений этих проблем может стать реализация peer-to-peer (p2p) сети в Matrix. В такой настройке устройство (например, мобильный телефон) работает как клиент и сервер одновременно. Это полностью исключает администратора третьей стороны из процесса, фактически делая пользователей администраторами своих собственных домашних серверов!
Из вышеописанного следует:
Пассивный сбор информации
Злоумышленный администратор может проводить значительный пассивный сбор информации, просто запрашивая базу данных Synapse, и это может происходить ретроспективно. Некоторые из (мета)данных могут включать:
Историю чатов в незашифрованных комнатах (ну конечно!)
Информацию о пользователях их домашнего сервера (ну конечно!), включая устройства, IP-адреса и т. д.
Реакции на сообщения с сквозным шифрованием (e2ee), поскольку реакции не шифруются.
Метаданные комнат (даже для комнат с e2ee), участники комнаты и их аватары/никнеймы, тема комнаты, уровни прав, количество отправленных сообщений и время их отправки и т. д.
Превью ссылок, которые были поделены (если эта опция включена для каждой комнаты).
Активные атаки
Злоумышленный администратор может проводить активные атаки против своих пользователей и комнат, в которых они участвуют. Некоторые из этих атак можно легко заметить с клиентской стороны, а другие — нет.
Вмешательство в комнаты
В Matrix есть понятие «событий состояния», которые определяют, как выглядит комната. Они указывают, какие пользователи входят в комнату, кто забанен, уровни прав пользователей, название и тему комнаты и т. д. Эти события не защищены сквозным шифрованием, и потому злоумышленный администратор может как читать их, так и отправлять свои собственные события, выдавая себя за пользователя своего домашнего сервера. Это в первую очередь может привести к атакам с элементами социальной инженерии. Я приведу несколько примеров того, как можно использовать социальную инженерию и эксплуатировать пользователей, так как существует множество вариантов подобных атак. В качестве примера буду использовать аккаунт @victim:http://example.com, за который злоумышленник выдает себя.
Реакции на сообщения от имени подставляемого пользователя. Злоумышленник не будет знать содержание сообщения, на которое он реагирует, но сможет видеть реакции других пользователей.
Установить тему комнаты на URL, контролируемый атакующим. Каждый участник комнаты, независимо от того, на каком домашнем сервере он находится, увидит, что это сделал @victim:http://example.com — пользователь, которому они доверяют. Это может быть использовано для атак типа «drive-by» или утечек IP-адресов третьих пользователей.
Пригласить аккаунты в комнату. Новый участник не сможет прочитать старые сообщения с e2ee, но все сообщения, отправленные после его присоединения, будут видны, если не были изменены настройки клиента.
Кикать и банить людей из комнаты — это не так уж плохо само по себе, но может быть нарушением работы. Также администратор может повысить уровень прав других пользователей в комнате.
Отправлять события «tombstone», помечая комнату как замененную для большинства клиентов, и предотвращая дальнейшую отправку сообщений в эту комнату.
Вмешательство в устройства пользователя
Вышеописанные атаки могут быть выполнены просто путем выдачи себя за пользователя, без добавления новых устройств в его аккаунт. Однако злоумышленный администратор может просто добавить новое устройство в аккаунт пользователя, что позволит отправлять и получать сообщения с e2ee.
В большинстве клиентов это будет отображаться как незарегистрированное устройство, что приведет к появлению красного значка щита в комнате, указывающего на наличие незарегистрированного устройства. Исходя из моего личного опыта, большинство людей, даже те, кто обеспокоены конфиденциальностью и разбираются в технологиях, просто игнорируют это по разным причинам. Я сам тоже склонен игнорировать это. Однако существуют настройки сессии и комнаты, которые позволяют отключить отправку сообщений на незарегистрированные устройства, если хотите быть на 100% уверены в безопасности.
В большинстве случаев атакованный пользователь получит уведомление в клиенте о том, что было добавлено новое незарегистрированное устройство. Существуют способы обойти это уведомление, не сообщая пользователю о добавлении нового устройства, но я не знаю, продолжит ли шифрование работать корректно для пользователя в этом случае.
Теперь перейдем к слабым сторонам протокола Matrix
Выжимка из моих статей.
Matrix — это сложный протокол обмена сообщениями, который служит основой для чатов и работает как распределенная частично реплицированная графовая база данных. "Комната" в Matrix представляет собой направленный ациклический граф (DAG), состоящий из событий, которые могут включать сообщения, состояния пользователей и баны. Серверы в комнате стремятся к конечной консистентности, что означает, что они должны реплицировать достаточно состояния, чтобы все участники видели схожий обзор.
Чтобы отправить событие в комнату, участвующий сервер добавляет его в граф. Каждый сервер должен проверять входящие события в соответствии с определенными правилами аутентификации, при этом события криптографически подписываются для подтверждения их происхождения. Однако существует несколько значительных проблем и рисков, связанных с использованием Matrix:
1. Дизайн «только для добавления»:
События не могут быть удалены, что может привести к бесконечному накоплению истории, что, в свою очередь, может подорвать возможность пользователей отрицать свою активность.
2. Ограничения на редактирование:
События редактирования (redaction) носят рекомендательный характер; серверы с плохим поведением могут их игнорировать, сохраняя оригинальное содержимое.
3. Утечка данных:
Серверы, игнорирующие редактирование, могут случайно делиться удаленными данными с новыми серверами, присоединившимися к комнате.
4. Необратимые события:
Некоторые события, такие как изменения участников, не могут быть удалены, поскольку они становятся частью цепочки аутентификации комнаты.
5. Уязвимость к спаму:
Боты могут быть использованы для спама в комнатах, что усложняет структуру графа и потребляет ресурсы серверов, что может потребовать пересоздания комнаты для устранения спама.
6. Проблемы с линейным представлением истории:
Линейное представление истории сложно реализовать, что может привести к тому, что разные серверы будут видеть сообщения в разном порядке.
7. Подделка сообщений:
Можно вставить сообщения в историю, создавая правдоподобные события, которые могут быть незамечены пользователями.
8. Опциональное шифрование:
End-to-end шифрование не является обязательным, что создает риск раскрытия незащищенных сообщений в федеративных комнатах.
9. Хрупкость шифрования:
Шифрование зависит от надежных обновлений списка устройств; сбои могут привести к поломке шифрования.
10. Утечка информации о устройствах:
Обновления списка устройств могут случайно раскрывать информацию о устройствах пользователей.
11. Проблемы с совместимостью API:
Отсутствие строгого определения каноничного JSON может привести к несовпадению подписей между различными реализациями серверов.
12. Ошибки проверки подписей:
Использование различных языков программирования для домашних серверов может вызвать проблемы с совместимостью JSON, что приведет к сбоям при проверке подписей.
13. Произвольный срок действия ключей подписей:
Ключи подписей могут истечь произвольным образом, что приведет к тому, что новые серверы будут отклонять события от исходного сервера, вызывая разделение комнат (split-brained rooms).
14. Общие проблемы с разделением комнат (split-brained rooms):
Алгоритм консенсуса для разрешения конфликтующих состояний не является безошибочным, что часто приводит к сбросам состояний.
15. Хаос при сбросе состояния:
Сбросы состояний могут происходить чаще на серверах, написанных на разных языках, что вызывает значительные перебои в работе.
16. Потеря административных прав:
Сбросы состояний могут лишить администраторов комнаты их полномочий, что затрудняет эффективное управление комнатами.
17. Ограничения на завершение работы комнаты:
Комнату невозможно универсально закрыть на всей федерации, что может привести к злоупотреблениям.
18. Проблемы с модерацией:
Эффективная модерация затруднена системой аутентификации событий, которая зависит от точного разрешения состояний.
19. Неаутентифицированная загрузка медиа:
Пользователи могут загружать медиа без аутентификации, что может привести к злоупотреблению медиа-репозиториями.
20. Риски репликации медиа:
Домашние серверы могут реплицировать медиа с других серверов, что может вызвать проблемы с отказом в обслуживании (DoS).
21. Не проверенная загрузка медиа:
Загрузка медиа по умолчанию не проверяется, что представляет риск, если загружены вредоносные материалы.
22. Ответственность за незаконное медиа:
Домашние серверы могут неосознанно размещать незаконные медиа из-за активной репликации из нежелательных комнат.
Таким образом, строить свое общение в таком мессенджере может быть опасно, так же как и размещать там свои сервера)
Что предлагаю?
Переходить в SimpleX!
Как работает сеть SimpleX
Структура сети SimpleX напоминает P2P-сети, однако, в отличие от большинства таких сетей, она не имеет централизованного компонента и состоит из клиентов и серверов, работающих независимо. Основные отличия от традиционных мессенджеров, таких как WhatsApp, Signal и Telegram, заключаются в следующем:
1.Участникам не нужно иметь уникальные глобальные адреса для общения. Вместо этого используется система однонаправленных (симплексных) очередей сообщений, причем для каждого контакта создается отдельный набор очередей.
2.Соединения и запросы передаются вне сети, что не требует обязательной защиты обмена ключами от атак типа MITM (человек посередине).
3.Простые однонаправленные очереди, предоставляемые серверами сети, используются клиентами для создания более сложных коммуникационных сценариев, таких как двустороннее общение, передача файлов, групповое общение без центральных серверов, а также каналы для обмена контентом и коммуникаций.
4.Серверы не хранят информацию о пользователях, их профилях, контактах или сообщениях после доставки — они работают в основном с данными в оперативной памяти.Пользователи могут легко сменить серверы с минимальными перебоями — даже если текущий сервер перестанет работать, достаточно изменить конфигурацию для создания новых очередей на других серверах.
Слово о безопасности!
Каждое сообщение в SimpleX шифруется с использованием алгоритма NaCl cryptobox, что гарантирует безопасность на уровне каждой очереди сообщений. Это обеспечивает дополнительную защиту, особенно в случае, если сообщения проходят через несколько серверов, что исключает появление одного и того же шифрованного текста в различных очередях (и делает его видимым для злоумышленников только при компрометации TLS). Ключи, используемые для шифрования, не изменяются, вместо этого планируется использовать ротацию очередей. Для согласования ключей применяется Curve25519.
Начиная с версии 2 протокола SMP (текущая версия — v4), все метаданные сообщений, включая время их получения сервером (с округлением до секунды), передаются получателям в зашифрованном виде.
Обмен между клиентом и сервером
Для клиент-серверных соединений разрешены только версии TLS 1.2 и 1.3, с ограниченными криптографическими алгоритмами: CHACHA20POLY1305_SHA256, Ed25519/Ed448, Curve25519/Curve448.
Для защиты от атак повторного воспроизведения серверы SimpleX требуют использования tlsunique как уникального идентификатора сессии для каждой команды клиента, подписанной эфемерным ключом, привязанным к очереди.
Анонимность и защита IP-адреса
Все клиенты SimpleX Chat поддерживают анонимный доступ к серверам через сеть Tor, что помогает скрыть ваш IP-адрес.
Шифрование локальных данных
Для обеспечения безопасности данных на вашем устройстве используется шифрование локальной базы данных с помощью парольной фразы. Ваши контакты, группы и все сообщения, как отправленные, так и полученные, хранятся в зашифрованном виде. Если вы использовали SimpleX Chat до версии 4.0, вам необходимо включить шифрование в настройках приложения.
О безопасности проекта
С каждым днем растет количество пользователей SimpleX Chat, и особенно те, кто придает большое значение безопасности, ждали проведения независимого аудита кода.
Для этого команда разработчиков обратилась к компании Trail of Bits с просьбой провести тщательную проверку безопасности. В ходе аудита были рассмотрены несколько ключевых вопросов:
Уязвима ли реализация проекта для известных криптографических атак?
Хранится ли ключевой материал таким образом, чтобы минимизировать его возможное раскрытие?
Соблюдаются ли лучшие практики программирования на языке Haskell?
Аудит выявил две проблемы средней серьезности и две проблемы низкой степени риска. Все они требуют наличия высоких технических знаний и привилегированного доступа для эксплуатации, что делает их крайне сложными для использования злоумышленниками.
Обзор - https://github.com/trailofbits/publications/blob/m…
Что пишут в англоязычном сообществе?
Почему Федерация должна умереть
Привлекательность федерации заключается в ее потенциале расширения прав и возможностей отдельных лиц, групп и сообществ за счет использования программного обеспечения с открытым исходным кодом и облегчения децентрализованного взаимодействия между серверами. Эта модель обеспечивает определенную степень устойчивости к цензуре, поскольку сообщения или изображения реплицируются на нескольких серверах, что затрудняет цензуру или контроль контента каким-либо отдельным лицом.Однако после более чем двух лет администрирования общедоступных федеративных сервисов (Matrix, Lemmy) я из первых рук узнал фундаментальные проблемы, связанные с разработкой всех федеративных протоколов.
Друзья, выбирайте SimpleX, счастливого Нового Года!
НАШИ КОММЕНТАРИИ
Мы считаем, что элита программистов, по крайней мере те из них, знает права человека, уважает себя и реализует естественную потребность в приватности - они защищены. Как минимум, ещё пока. Пока на квантовых компьютерах не начали залихватски тестировать новые версии нейросетей. Но даже тогда, реальные спецы будут защищены, ведь есть и алгоритмы ПОСТквантового шифрования.
Лучшие технари ещё долго будут защищены, а благодаря лучшим их них в силу духовности - и многие другие люди тоже, так как информационные технологии, хотя и всеми силами верхушка пытается монополизировать, но они, пока ещё развиваются для всех и это прекрасно! Слава Богу! По-прежнему, ОООЧЕНЬ МНОГИЕ крутые технологии, прямо лежат под ногами простых людей!
Лучшие айтишники используют протокол Matrix и другие мессенджеры, написанные для самих себя. Также спецслужбы и верхушка тех, кто занимается не хорошими делами. Те же, кому есть что скрывать, но уровнем ниже, по-прежнему используют Jabber и, тоже, Matrix, но непосредственно в настройке управления своей перепиской не участвуют.
А вы, друзья, что думаете об этом? Пишите в комментариях!
Bellingcat
Kolibri
PeerTube Creator
Habr 25+
Habr
INFERNUM1488
DonOperInfo