Q1. Можете ли вы кратко рассказать о происхождении Session и что побудило вас создать децентрализованную сеть обмена сообщениями?
Сессия является совместным творением сотен участников со всего мира — это красота программного обеспечения с открытым исходным кодом; любой может писать и вносить код в кодовую базу Сессии. Однако у каждого продукта есть более центральная история основания. Для Сессии первоначальные основатели хотели создать приложение для демонстрации концепции на основе недавно созданной децентрализованной сети. Мы считали, что лучшее приложение для демонстрации концепции — это создать приложение для обмена сообщениями, которое хранило и перенаправляло сообщения через эту децентрализованную сеть, потому что, как только у вас есть базовый мессенджер, вы можете обобщить эту концепцию для многих других приложений, которые часто сводятся к передаче сообщений от одного устройства к другому. Сессия была запущена под другим именем и сразу же начала расти. Стало очевидно, что внимание должно быть сосредоточено на Сессии, и то, что изначально было задумано как демонстрация концепции, превратилось в одно из крупнейших приложений для частного обмена сообщениями, доступных сегодня.
Вопрос 2. Недавнее экстренное указание CISA выявило два критических недостатка в TM SGNL. С вашей точки зрения, что пошло не так в дизайне или реализации, что позволило злоумышленникам собирать журналы чата и метаданные?
Это классический случай каскадирования проблем проектирования и реализации, которые сами по себе могут быть неэксплуатируемыми, но в сочетании могут привести к катастрофическому сбою в безопасности сети.
Первая ошибка заключалась в дизайне. TeleMessage взял Signal, хорошо известное приложение для безопасного обмена сообщениями, и добавил то, что в конечном итоге стало намеренной уязвимостью в приложении с целью создания аудиторского журнала. Этот аудиторский журнал функционировал путем отправки копии каждого сообщения, которое пользователь отправлял, до его сквозного шифрования, на один центральный сервер. Этот сервер затем хранил копию всех этих сообщений в незашифрованном виде. Это создало мишень для злоумышленников, имеющую дело с крайне чувствительными данными, настоящую сокровищницу информации о национальной безопасности, неудержимую для хакеров.
Вторая ошибка заключалась в неправильной настройке службы (Spring Boot Actuator), которая работала на архивном сервере TM SGNL. Это очень простая проблема с неправильной настройкой, когда URL, обычно используемый разработчиками для диагностики ошибок, был оставлен открытым для всех без аутентификации. Это позволило злоумышленникам выгрузить память сервера, в этой выгрузке незашифрованные сообщения и информацию для аутентификации пользователей были видны в открытом виде, что позволило хакерам восстановить сообщения и информацию об аккаунтах.
Важно отметить, что обе ошибки должны были сосуществовать, чтобы хакерская атака такого масштаба могла произойти. Это часто бывает в случаях кибербезопасности, когда злоумышленники находят единственный дефект в дизайне или реализации, а затем используют этот дефект, чтобы обнаружить другие уязвимости для эксплуатации.
Вопрос 3. Насколько часто клиенты с E2EE — даже совместимые с Signal — вводят такие уязвимости, и почему их не обнаруживают раньше?
Обычные потребительские мессенджеры, такие как WhatsApp, Signal и Telegram, как правило, имеют гораздо лучшую безопасность вокруг своих серверов, чем серверы TeleMessage. Однако, когда речь идет о мессенджерах, разработанных и модифицированных специально для создания аудита логов преобразований, гораздо чаще встречаются такие типы неправильной конфигурации. Особенно когда эти приложения имеют закрытый код, исследователи безопасности из сообщества не имеют такой возможности анализировать код на наличие уязвимостей, поэтому распространенные неправильные конфигурации могут оставаться нераспознанными в течение долгого времени или скрываться государственными хакерами для поддержания бэкдоров в системах, которые не исправляются.
Вопрос 4. Вы утверждали, что пока единственный поставщик контролирует ключевые части стека, существует врожденный риск. Как централизация поставщика приводит к реальным провалам в области конфиденциальности?
Централизация поставщиков обычно сочетается с закрытым исходным кодом и централизованными серверами. Когда сервис обмена сообщениями хранит все пользовательские сообщения в одном центральном месте, он создает мишень для атакующих, которые знают, что, взломав один сервер, они получат доступ ко всем сообщениям, отправленным через сервис. В сочетании с закрытым исходным кодом, который не может быть проверен исследователями безопасности и аудиторами с открытым исходным кодом, стимул для атакующих увеличивается, и ошибки, которые могли бы быть обнаружены, остаются незамеченными только для самых сложных атакующих, которые хранят эти ошибки в секрете, чтобы сохранить доступ через свои задние двери, оставляя всех пользователей сервиса скомпрометированными.
Q5. Можете привести пример ( вне TM SGNL), где ошибка на стороне поставщика подорвала гарантии сквозного шифрования?
Использование Twilio для SMS-подтверждения в Signal привело к компрометации некоторых аккаунтов пользователей Signal, когда Twilio был взломан. Поскольку SMS-подтверждение является одним из способов восстановления аккаунтов пользователей Signal, когда Twilio был взломан, злоумышленники могли обмануть серверы Signal, заставив их думать, что они владеют номером телефона пользователя Signal, и восстановить их аккаунт, используя этот доступ для отправки несанкционированных сообщений с аккаунтов этих пользователей Signal.
Q6. Почему вы считаете, что децентрализация — это единственный способ полностью смягчить риски, связанные с использованием одного поставщика?
Децентрализация является единственным способом полностью смягчить риск единого поставщика, поскольку она устраняет единую точку отказа, присущую любой централизованной системе. Когда одна сущность контролирует ключевые части стека – от пользовательских идентификаторов до маршрутизации сообщений и хранения – она становится неотразимой целью для злоумышленников, и ее недостатки в проектировании или реализации могут иметь катастрофические последствия, как это было видно с TM SGNL.
В децентрализованной сети нет центрального сервера, который можно было бы нарушить, нет единой компании, которую можно было бы заставить вставить закладки, и нет единой базы данных, которая могла бы быть нацелена на сбор метаданных. Идентичности пользователей часто представляют собой криптографические ключи, а не реальные идентификаторы, связанные с центральным органом. Сообщения передаются и хранятся в распределенной сети независимых узлов, что означает, что ни один узел не видит как IP-адреса отправителя, так и получателя, и ни одно отдельное лицо не может собрать исчерпывающий журнал коммуникаций.
Это распределение власти и данных по своей природе делает систему более устойчивой к атакам, цензуре и эксплуатации данных, потому что нет единой уязвимой точки. Безопасность не зависит от надежности одной компании, а скорее от коллективной целостности и надежного криптографического дизайна распределенной сети.
Q7. Сессия использует сеть сервисных узлов. Как эта архитектура гарантирует, что ни одна сторона не может скомпрометировать данные пользователей?
В отличие от традиционных мессенджеров, Session не полагается на один центральный сервер, который хранит все данные пользователей. Вместо этого сообщения передаются через распределенную сеть из тысяч независимых узлов Session, управляемых сообществом. Это устраняет эффект «медовой ловушки» единой централизованной базы данных, что делает крайне сложным для какой-либо единой сущности собирать полные зашифрованные сообщения и метаданные. Узлы Session временно хранят сообщения для оффлайн-получателей. Однако эти сообщения зашифрованы от конца до конца, что означает, что узлы сами не могут читать содержимое. Более того, сообщения хранятся только ограниченное время (Time-To-Live) и могут быть удалены после прочтения, что предотвращает долгосрочное хранение в сети узлов.
Дополнительно Session использует модифицированную технику луковой маршрутизации, аналогичную Tor. Когда вы отправляете сообщение, оно шифруется слоями, и каждый слой снимается последующими узлами Session. Крайне важно, что ни один узел не знает как IP-адрес отправителя, так и IP-адрес получателя. Это означает, что даже если узел будет скомпрометирован, он не сможет связать сообщение с его источником или местом назначения.
Сессионные аккаунты генерируются криптографически без необходимости в какой-либо личной информации, такой как номера телефонов или адреса электронной почты. Это означает, что реальная идентичность не связана с вашим идентификатором сессионного аккаунта, что дополнительно повышает уровень конфиденциальности и затрудняет компрометацию идентичности пользователя через внешние утечки данных.
Этот многоуровневый подход, не имеющий центральной точки управления, временного хранения, сквозного шифрования и анонимной маршрутизации, обеспечивает сохранение целостности и конфиденциальности сети, даже если небольшое количество узлов сессии будет скомпрометировано.
Вопрос 8. Учитывая развертывание TM SGNL в федеральных агентствах, видите ли вы, что правительства движутся к действительно децентрализованному обмену сообщениями? Какие барьеры существуют для этого перехода?
Это сложный вопрос. Государственные органы обычно требуют создания и хранения журналов аудита таким образом, чтобы их мог просматривать аудитор, что создает внутреннюю уязвимость безопасности. Сквозное шифрование предназначено для того, чтобы только участники разговора могли видеть содержимое коммуникаций. Требование аудита вводит намеренную «заднюю дверь» в сквозное шифрование, что трудно реализовать безопасным образом.
Однако существуют способы, как это можно лучше управлять, например, журналы аудита всегда должны храниться в зашифрованном виде на хранении, и должны быть надежные меры защиты для пользователей, которые могут получить доступ к этому журналу аудита. Государства должны использовать инструменты с открытым исходным кодом, которые могут быть легко проверены, и очень тщательно обдумывать, как хранятся журналы аудита и на каких серверах они хранятся.
Если бы регулирование было обновлено, это могло бы предложить способ лучшего использования децентрализованных решений в государственных коммуникациях.
Q9. Как бы вы убедили организацию, обеспокоенную вопросами безопасности, перейти с совместимого с Signal проприетарного клиента на Session?
Я думаю, что взлом TM SGNL предоставляет наилучший стимул для пользователей отказаться от проприетарных технических решений в пользу открытых инструментов, таких как Session, которые предлагают значительно улучшенные функции безопасности и конфиденциальности. Возможно, в будущем организациям удастся взять открытые инструменты, такие как Session, и разработать свои собственные инструменты аудита, которые будут интегрированы с этими инструментами. Однако такие решения для аудита сами по себе должны быть открытыми и подлежать аудиту, чтобы избежать повторения тех же проблем, которые возникли с TM SGNL.
Q10. Глядя вперед, какие основные функции или улучшения запланированы в дорожной карте Session на следующие 12‒18 месяцев? В конечном итоге, какова ваша долгосрочная концепция для Session и для безопасного, приватного обмена сообщениями в целом?
Текущий фокус Session направлен на привлечение большего числа пользователей. У Session уже более миллиона активных пользователей в месяц, но мы хотим видеть еще больше пользователей, выбирающих решения, которые встраивают сильную конфиденциальность и безопасность в основу проектирования приложений. Вкладчики Session в настоящее время работают над премиум-набором функций для активных пользователей Session, которые обеспечивают устойчивое финансирование экосистемы Session. Это включает в себя такие функции, как большие группы, больше возможностей настройки профиля и увеличенные размеры файлов, все функции, которые повышают полезность Session.
В более широком смысле я вижу Session как единственное приложение, которое предлагает как конфиденциальность контента, так и метаданных в высококачественном и простом в использовании формате, и я думаю, что по мере того, как утечки данных продолжают влиять на пользователей, Session будет продолжать расти в течение следующих 12-18 месяцев.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Реинвенция безопасных сообщений: глубокое погружение с соучредителем Session Ки Джефферисом
Q1. Можете ли вы кратко рассказать о происхождении Session и что побудило вас создать децентрализованную сеть обмена сообщениями?
Сессия является совместным творением сотен участников со всего мира — это красота программного обеспечения с открытым исходным кодом; любой может писать и вносить код в кодовую базу Сессии. Однако у каждого продукта есть более центральная история основания. Для Сессии первоначальные основатели хотели создать приложение для демонстрации концепции на основе недавно созданной децентрализованной сети. Мы считали, что лучшее приложение для демонстрации концепции — это создать приложение для обмена сообщениями, которое хранило и перенаправляло сообщения через эту децентрализованную сеть, потому что, как только у вас есть базовый мессенджер, вы можете обобщить эту концепцию для многих других приложений, которые часто сводятся к передаче сообщений от одного устройства к другому. Сессия была запущена под другим именем и сразу же начала расти. Стало очевидно, что внимание должно быть сосредоточено на Сессии, и то, что изначально было задумано как демонстрация концепции, превратилось в одно из крупнейших приложений для частного обмена сообщениями, доступных сегодня.
Вопрос 2. Недавнее экстренное указание CISA выявило два критических недостатка в TM SGNL. С вашей точки зрения, что пошло не так в дизайне или реализации, что позволило злоумышленникам собирать журналы чата и метаданные?
Это классический случай каскадирования проблем проектирования и реализации, которые сами по себе могут быть неэксплуатируемыми, но в сочетании могут привести к катастрофическому сбою в безопасности сети.
Первая ошибка заключалась в дизайне. TeleMessage взял Signal, хорошо известное приложение для безопасного обмена сообщениями, и добавил то, что в конечном итоге стало намеренной уязвимостью в приложении с целью создания аудиторского журнала. Этот аудиторский журнал функционировал путем отправки копии каждого сообщения, которое пользователь отправлял, до его сквозного шифрования, на один центральный сервер. Этот сервер затем хранил копию всех этих сообщений в незашифрованном виде. Это создало мишень для злоумышленников, имеющую дело с крайне чувствительными данными, настоящую сокровищницу информации о национальной безопасности, неудержимую для хакеров.
Вторая ошибка заключалась в неправильной настройке службы (Spring Boot Actuator), которая работала на архивном сервере TM SGNL. Это очень простая проблема с неправильной настройкой, когда URL, обычно используемый разработчиками для диагностики ошибок, был оставлен открытым для всех без аутентификации. Это позволило злоумышленникам выгрузить память сервера, в этой выгрузке незашифрованные сообщения и информацию для аутентификации пользователей были видны в открытом виде, что позволило хакерам восстановить сообщения и информацию об аккаунтах.
Важно отметить, что обе ошибки должны были сосуществовать, чтобы хакерская атака такого масштаба могла произойти. Это часто бывает в случаях кибербезопасности, когда злоумышленники находят единственный дефект в дизайне или реализации, а затем используют этот дефект, чтобы обнаружить другие уязвимости для эксплуатации.
Вопрос 3. Насколько часто клиенты с E2EE — даже совместимые с Signal — вводят такие уязвимости, и почему их не обнаруживают раньше?
Обычные потребительские мессенджеры, такие как WhatsApp, Signal и Telegram, как правило, имеют гораздо лучшую безопасность вокруг своих серверов, чем серверы TeleMessage. Однако, когда речь идет о мессенджерах, разработанных и модифицированных специально для создания аудита логов преобразований, гораздо чаще встречаются такие типы неправильной конфигурации. Особенно когда эти приложения имеют закрытый код, исследователи безопасности из сообщества не имеют такой возможности анализировать код на наличие уязвимостей, поэтому распространенные неправильные конфигурации могут оставаться нераспознанными в течение долгого времени или скрываться государственными хакерами для поддержания бэкдоров в системах, которые не исправляются.
Вопрос 4. Вы утверждали, что пока единственный поставщик контролирует ключевые части стека, существует врожденный риск. Как централизация поставщика приводит к реальным провалам в области конфиденциальности?
Централизация поставщиков обычно сочетается с закрытым исходным кодом и централизованными серверами. Когда сервис обмена сообщениями хранит все пользовательские сообщения в одном центральном месте, он создает мишень для атакующих, которые знают, что, взломав один сервер, они получат доступ ко всем сообщениям, отправленным через сервис. В сочетании с закрытым исходным кодом, который не может быть проверен исследователями безопасности и аудиторами с открытым исходным кодом, стимул для атакующих увеличивается, и ошибки, которые могли бы быть обнаружены, остаются незамеченными только для самых сложных атакующих, которые хранят эти ошибки в секрете, чтобы сохранить доступ через свои задние двери, оставляя всех пользователей сервиса скомпрометированными.
Q5. Можете привести пример ( вне TM SGNL), где ошибка на стороне поставщика подорвала гарантии сквозного шифрования?
Использование Twilio для SMS-подтверждения в Signal привело к компрометации некоторых аккаунтов пользователей Signal, когда Twilio был взломан. Поскольку SMS-подтверждение является одним из способов восстановления аккаунтов пользователей Signal, когда Twilio был взломан, злоумышленники могли обмануть серверы Signal, заставив их думать, что они владеют номером телефона пользователя Signal, и восстановить их аккаунт, используя этот доступ для отправки несанкционированных сообщений с аккаунтов этих пользователей Signal.
Q6. Почему вы считаете, что децентрализация — это единственный способ полностью смягчить риски, связанные с использованием одного поставщика?
Децентрализация является единственным способом полностью смягчить риск единого поставщика, поскольку она устраняет единую точку отказа, присущую любой централизованной системе. Когда одна сущность контролирует ключевые части стека – от пользовательских идентификаторов до маршрутизации сообщений и хранения – она становится неотразимой целью для злоумышленников, и ее недостатки в проектировании или реализации могут иметь катастрофические последствия, как это было видно с TM SGNL.
В децентрализованной сети нет центрального сервера, который можно было бы нарушить, нет единой компании, которую можно было бы заставить вставить закладки, и нет единой базы данных, которая могла бы быть нацелена на сбор метаданных. Идентичности пользователей часто представляют собой криптографические ключи, а не реальные идентификаторы, связанные с центральным органом. Сообщения передаются и хранятся в распределенной сети независимых узлов, что означает, что ни один узел не видит как IP-адреса отправителя, так и получателя, и ни одно отдельное лицо не может собрать исчерпывающий журнал коммуникаций.
Это распределение власти и данных по своей природе делает систему более устойчивой к атакам, цензуре и эксплуатации данных, потому что нет единой уязвимой точки. Безопасность не зависит от надежности одной компании, а скорее от коллективной целостности и надежного криптографического дизайна распределенной сети.
Q7. Сессия использует сеть сервисных узлов. Как эта архитектура гарантирует, что ни одна сторона не может скомпрометировать данные пользователей?
В отличие от традиционных мессенджеров, Session не полагается на один центральный сервер, который хранит все данные пользователей. Вместо этого сообщения передаются через распределенную сеть из тысяч независимых узлов Session, управляемых сообществом. Это устраняет эффект «медовой ловушки» единой централизованной базы данных, что делает крайне сложным для какой-либо единой сущности собирать полные зашифрованные сообщения и метаданные. Узлы Session временно хранят сообщения для оффлайн-получателей. Однако эти сообщения зашифрованы от конца до конца, что означает, что узлы сами не могут читать содержимое. Более того, сообщения хранятся только ограниченное время (Time-To-Live) и могут быть удалены после прочтения, что предотвращает долгосрочное хранение в сети узлов.
Дополнительно Session использует модифицированную технику луковой маршрутизации, аналогичную Tor. Когда вы отправляете сообщение, оно шифруется слоями, и каждый слой снимается последующими узлами Session. Крайне важно, что ни один узел не знает как IP-адрес отправителя, так и IP-адрес получателя. Это означает, что даже если узел будет скомпрометирован, он не сможет связать сообщение с его источником или местом назначения.
Сессионные аккаунты генерируются криптографически без необходимости в какой-либо личной информации, такой как номера телефонов или адреса электронной почты. Это означает, что реальная идентичность не связана с вашим идентификатором сессионного аккаунта, что дополнительно повышает уровень конфиденциальности и затрудняет компрометацию идентичности пользователя через внешние утечки данных.
Этот многоуровневый подход, не имеющий центральной точки управления, временного хранения, сквозного шифрования и анонимной маршрутизации, обеспечивает сохранение целостности и конфиденциальности сети, даже если небольшое количество узлов сессии будет скомпрометировано.
Вопрос 8. Учитывая развертывание TM SGNL в федеральных агентствах, видите ли вы, что правительства движутся к действительно децентрализованному обмену сообщениями? Какие барьеры существуют для этого перехода?
Это сложный вопрос. Государственные органы обычно требуют создания и хранения журналов аудита таким образом, чтобы их мог просматривать аудитор, что создает внутреннюю уязвимость безопасности. Сквозное шифрование предназначено для того, чтобы только участники разговора могли видеть содержимое коммуникаций. Требование аудита вводит намеренную «заднюю дверь» в сквозное шифрование, что трудно реализовать безопасным образом.
Однако существуют способы, как это можно лучше управлять, например, журналы аудита всегда должны храниться в зашифрованном виде на хранении, и должны быть надежные меры защиты для пользователей, которые могут получить доступ к этому журналу аудита. Государства должны использовать инструменты с открытым исходным кодом, которые могут быть легко проверены, и очень тщательно обдумывать, как хранятся журналы аудита и на каких серверах они хранятся.
Если бы регулирование было обновлено, это могло бы предложить способ лучшего использования децентрализованных решений в государственных коммуникациях.
Q9. Как бы вы убедили организацию, обеспокоенную вопросами безопасности, перейти с совместимого с Signal проприетарного клиента на Session?
Я думаю, что взлом TM SGNL предоставляет наилучший стимул для пользователей отказаться от проприетарных технических решений в пользу открытых инструментов, таких как Session, которые предлагают значительно улучшенные функции безопасности и конфиденциальности. Возможно, в будущем организациям удастся взять открытые инструменты, такие как Session, и разработать свои собственные инструменты аудита, которые будут интегрированы с этими инструментами. Однако такие решения для аудита сами по себе должны быть открытыми и подлежать аудиту, чтобы избежать повторения тех же проблем, которые возникли с TM SGNL.
Q10. Глядя вперед, какие основные функции или улучшения запланированы в дорожной карте Session на следующие 12‒18 месяцев? В конечном итоге, какова ваша долгосрочная концепция для Session и для безопасного, приватного обмена сообщениями в целом?
Текущий фокус Session направлен на привлечение большего числа пользователей. У Session уже более миллиона активных пользователей в месяц, но мы хотим видеть еще больше пользователей, выбирающих решения, которые встраивают сильную конфиденциальность и безопасность в основу проектирования приложений. Вкладчики Session в настоящее время работают над премиум-набором функций для активных пользователей Session, которые обеспечивают устойчивое финансирование экосистемы Session. Это включает в себя такие функции, как большие группы, больше возможностей настройки профиля и увеличенные размеры файлов, все функции, которые повышают полезность Session.
В более широком смысле я вижу Session как единственное приложение, которое предлагает как конфиденциальность контента, так и метаданных в высококачественном и простом в использовании формате, и я думаю, что по мере того, как утечки данных продолжают влиять на пользователей, Session будет продолжать расти в течение следующих 12-18 месяцев.