Q1. Чи можете коротко розповісти про історію походження Session і що мотивувало вас створити децентралізовану мережу обміну повідомленнями?
Session є спільним творінням сотень учасників з усього світу — у цьому і полягає краса програмного забезпечення з відкритим кодом; будь-хто може писати та вносити код до кодової бази Session. Однак кожен продукт має свою більш центральну історію заснування. Для Session початкові засновники хотіли створити демонстраційний додаток на базі новоствореної децентралізованої мережі. Ми вважали, що найкращим демонстраційним додатком було б створити додаток для обміну повідомленнями, який зберігав і маршрутизував повідомлення через цю децентралізовану мережу, тому що, коли у вас є базовий месенджер, ви можете узагальнити цю концепцію для багатьох інших додатків, які часто зводяться до передачі повідомлень з одного пристрою на інший. Session був запущений під іншою назвою і відразу ж зріс. Стало зрозуміло, що увагу слід зосередити на Session, і те, що спочатку було розроблено як демонстраційний варіант, перетворилось на один з найбільших приватних додатків для обміну повідомленнями, доступних сьогодні.
Q2. Недавній екстрений директив CISA виявив дві критичні вразливості в TM SGNL. На вашу думку, що пішло не так у дизайні або реалізації, що дозволило зловмисникам збирати журнали чатів та метадані?
Це класичний випадок каскадних проблем проектування та впровадження, які самі по собі можуть не бути експлуатованими, але в поєднанні можуть викликати катастрофічну невдачу в безпеці мережі.
Перша помилка полягала в дизайні: TeleMessage взяла Signal, відому безпечну програму для обміну повідомленнями, і додала те, що виявилося навмисною «задньою дверима» в додатку для створення аудиторського журналу. Спосіб, яким функціонував цей аудиторський журнал, полягав у надсиланні копії кожного повідомлення, надісланого користувачем, до того, як воно було зашифровано наскрізним шифруванням, на один центральний сервер; цей сервер потім зберігав копію всіх цих повідомлень у незашифрованому стані. Це створило «медову пастку» для зловмисників з надзвичайно чутливими даними, справжнє скарбницю інформації про національну безпеку, яка була нездоланним спокусою для хакерів.
Друга невдача полягала в неправильній конфігурації служби (Spring Boot Actuator), яка працювала на архівному сервері TM SGNL. Це дуже базова проблема з конфігурацією, коли URL, зазвичай використовуваний розробниками для діагностики помилок, залишався відкритим для всіх без аутентифікації. Це дозволило зловмисникам скинути пам'ять сервера, в цьому скиданні некриптовані повідомлення та інформація для аутентифікації користувачів були видимі в відкритому вигляді, що дозволило хакерам відновити повідомлення та інформацію про облікові записи.
Важливо зазначити, що обидві невдачі повинні були співіснувати, щоб сталася атака такого масштабу. Це часто трапляється у випадках порушення кібербезпеки, коли зловмисники знаходять єдиний недолік у дизайні або впровадженні, а потім використовують цей недолік, щоб знайти інші вразливості для експлуатації.
Q3. Наскільки поширеною є проблема, коли клієнти з E2EE — навіть ті, що сумісні з Signal — виявляють такі слабкості, і чому їх не виявляють раніше?
Звичайні споживчі месенджери, такі як WhatsApp, Signal і Telegram, зазвичай мають набагато кращу безпеку своїх серверів, ніж сервери TeleMessage. Однак, коли мова йде про месенджери, які були розроблені та модифіковані спеціально для створення аудиторії логів конверсій, частіше можна побачити такі типи неправильних налаштувань. Особливо коли ці програми мають закритий код, дослідники безпеки з громади не мають такої ж можливості аналізувати код на вразливості, тому поширені неправильні налаштування можуть залишатися непоміченими тривалий час або бути прихованими державними хакерами для підтримки бекдорів у системах, які не виправляються.
Q4. Ви стверджували, що поки один постачальник контролює ключові частини стеку, існує вроджений ризик. Як централізація постачальників перетворюється на реальні невдачі в конфіденційності?
Централізація постачальника зазвичай поєднується з закритим кодом та централізованими серверами. Коли служба обміну повідомленнями зберігає всі повідомлення користувачів в одному центральному місці, це створює медову пастку для зловмисників, адже вони знають, що зламавши один сервер, отримують доступ до всіх повідомлень, надісланих через службу. У поєднанні із закритим кодом, який не може бути перевірений дослідниками з безпеки з відкритим кодом та аудиторами, стимул для зловмисників зростає, а помилки, які могли б бути виявлені, залишаються непоміченими для всіх, окрім найсофістикованіших зловмисників, які зберігають ці помилки в секреті, щоб підтримувати свій доступ через бекдор, залишаючи всіх користувачів служби скомпрометованими.
Q5. Чи можете поділитися прикладом ( поза TM SGNL), де недолік з боку постачальника підриває гарантії енд-ту-енд шифрування?
Використання Signal сервісу Twilio для SMS-верифікації призвело до компрометації деяких облікових записів користувачів Signal, коли Twilio був зламаний. Оскільки SMS-верифікація є одним із способів, якими користувачі Signal можуть відновити свої облікові записи, зламавши Twilio, зловмисники могли обманути сервери Signal, змусивши їх думати, що вони володіють номером телефону користувача Signal, і відновити свій обліковий запис, використовуючи цей доступ для надсилання несанкціонованих повідомлень з облікових записів цих користувачів Signal.
Q6. Чому ви вважаєте, що децентралізація є єдиним способом повністю зменшити ризик від одного постачальника?
Децентралізація є єдиним способом повністю зменшити ризик, пов'язаний з єдиним постачальником, оскільки вона усуває єдину точку відмови, властиву будь-якій централізованій системі. Коли єдине підприємство контролює ключові частини стеку – від ідентифікацій користувачів до маршрутизації повідомлень і зберігання – воно стає нездоланною мішенню для зловмисників, і його недоліки в дизайні або реалізації можуть мати катастрофічні наслідки, як це було видно з TM SGNL.
У децентралізованій мережі немає центрального сервера, який можна зламати, жодної компанії, на яку можна тиснути, щоб вставити бекдори, і жодної єдиної бази даних, на яку можна націлитися для збору метаданих. Ідентичності користувачів зазвичай є криптографічними ключами, а не реальними ідентифікаторами, пов'язаними з центральною владою. Повідомлення маршрутизуються та зберігаються у розподіленій мережі незалежних вузлів, що означає, що жоден вузол не бачить IP-адреси відправника та одержувача, і жодна окрема сутність не може збирати всебічний журнал комунікацій.
Ця розподілена структура влади та даних вкрай робить систему більш стійкою до атак, цензури та експлуатації даних, оскільки немає єдиної точки, яку можна експлуатувати. Безпека не залежить від надійності однієї компанії, а скоріше від колективної цілісності та надійного криптографічного дизайну розподіленої мережі.
Q7. Сесія використовує мережу сервісних вузлів. Як ця архітектура забезпечує те, що жодна сторона не може скомпрометувати дані користувача?
На відміну від традиційних додатків для обміну повідомленнями, Session не покладається на один центральний сервер, що зберігає всі дані користувачів. Натомість повідомлення пересилаються через розподілену мережу з тисяч незалежних, керованих спільнотою вузлів Session. Це усуває ефект «медового горщика» єдиної централізованої бази даних, ускладнюючи будь-якій окремій особі збирання всіх зашифрованих повідомлень і метаданих. Вузли Session тимчасово зберігають повідомлення для офлайн-одержувачів. Однак ці повідомлення зашифровані з кінця в кінець, що означає, що самі вузли не можуть прочитати вміст. Крім того, повідомлення зберігаються лише обмежений час (Час життя) і можуть бути видалені після прочитання, що запобігає тривалому зберіганню в мережі вузлів.
Крім того, Session використовує модифіковану техніку рутінгу з цибулевим шаром, схожу на Tor. Коли ви надсилаєте повідомлення, воно шифрується шарами, і кожен шар знімається послідовними вузлами Session. Важливо, що жоден окремий вузол не знає як IP-адреси відправника, так і одержувача. Це означає, що навіть якщо вузол буде скомпрометовано, він не зможе пов'язати повідомлення з його походженням або призначенням.
Облікові записи сесій генеруються криптографічно без необхідності надання особистої інформації, такої як номери телефонів або електронні адреси. Це означає, що немає реальної ідентичності, пов'язаної з вашим ID облікового запису сесії, що додатково підвищує конфіденційність і ускладнює компрометацію ідентичності користувача через зовнішні витоки даних.
Цей багаторівневий підхід, без центральної точки контролю, тимчасового зберігання, шифрування «від краю до краю» та анонімного маршрутизації, забезпечує те, що навіть якщо невелика кількість Сесійних Вузлів буде скомпрометована, загальна цілісність і конфіденційність мережі залишаться недоторканими.
Q8. Враховуючи впровадження 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 і що мотивувало вас створити децентралізовану мережу обміну повідомленнями?
Session є спільним творінням сотень учасників з усього світу — у цьому і полягає краса програмного забезпечення з відкритим кодом; будь-хто може писати та вносити код до кодової бази Session. Однак кожен продукт має свою більш центральну історію заснування. Для Session початкові засновники хотіли створити демонстраційний додаток на базі новоствореної децентралізованої мережі. Ми вважали, що найкращим демонстраційним додатком було б створити додаток для обміну повідомленнями, який зберігав і маршрутизував повідомлення через цю децентралізовану мережу, тому що, коли у вас є базовий месенджер, ви можете узагальнити цю концепцію для багатьох інших додатків, які часто зводяться до передачі повідомлень з одного пристрою на інший. Session був запущений під іншою назвою і відразу ж зріс. Стало зрозуміло, що увагу слід зосередити на Session, і те, що спочатку було розроблено як демонстраційний варіант, перетворилось на один з найбільших приватних додатків для обміну повідомленнями, доступних сьогодні.
Q2. Недавній екстрений директив CISA виявив дві критичні вразливості в TM SGNL. На вашу думку, що пішло не так у дизайні або реалізації, що дозволило зловмисникам збирати журнали чатів та метадані?
Це класичний випадок каскадних проблем проектування та впровадження, які самі по собі можуть не бути експлуатованими, але в поєднанні можуть викликати катастрофічну невдачу в безпеці мережі.
Перша помилка полягала в дизайні: TeleMessage взяла Signal, відому безпечну програму для обміну повідомленнями, і додала те, що виявилося навмисною «задньою дверима» в додатку для створення аудиторського журналу. Спосіб, яким функціонував цей аудиторський журнал, полягав у надсиланні копії кожного повідомлення, надісланого користувачем, до того, як воно було зашифровано наскрізним шифруванням, на один центральний сервер; цей сервер потім зберігав копію всіх цих повідомлень у незашифрованому стані. Це створило «медову пастку» для зловмисників з надзвичайно чутливими даними, справжнє скарбницю інформації про національну безпеку, яка була нездоланним спокусою для хакерів.
Друга невдача полягала в неправильній конфігурації служби (Spring Boot Actuator), яка працювала на архівному сервері TM SGNL. Це дуже базова проблема з конфігурацією, коли URL, зазвичай використовуваний розробниками для діагностики помилок, залишався відкритим для всіх без аутентифікації. Це дозволило зловмисникам скинути пам'ять сервера, в цьому скиданні некриптовані повідомлення та інформація для аутентифікації користувачів були видимі в відкритому вигляді, що дозволило хакерам відновити повідомлення та інформацію про облікові записи.
Важливо зазначити, що обидві невдачі повинні були співіснувати, щоб сталася атака такого масштабу. Це часто трапляється у випадках порушення кібербезпеки, коли зловмисники знаходять єдиний недолік у дизайні або впровадженні, а потім використовують цей недолік, щоб знайти інші вразливості для експлуатації.
Q3. Наскільки поширеною є проблема, коли клієнти з E2EE — навіть ті, що сумісні з Signal — виявляють такі слабкості, і чому їх не виявляють раніше?
Звичайні споживчі месенджери, такі як WhatsApp, Signal і Telegram, зазвичай мають набагато кращу безпеку своїх серверів, ніж сервери TeleMessage. Однак, коли мова йде про месенджери, які були розроблені та модифіковані спеціально для створення аудиторії логів конверсій, частіше можна побачити такі типи неправильних налаштувань. Особливо коли ці програми мають закритий код, дослідники безпеки з громади не мають такої ж можливості аналізувати код на вразливості, тому поширені неправильні налаштування можуть залишатися непоміченими тривалий час або бути прихованими державними хакерами для підтримки бекдорів у системах, які не виправляються.
Q4. Ви стверджували, що поки один постачальник контролює ключові частини стеку, існує вроджений ризик. Як централізація постачальників перетворюється на реальні невдачі в конфіденційності?
Централізація постачальника зазвичай поєднується з закритим кодом та централізованими серверами. Коли служба обміну повідомленнями зберігає всі повідомлення користувачів в одному центральному місці, це створює медову пастку для зловмисників, адже вони знають, що зламавши один сервер, отримують доступ до всіх повідомлень, надісланих через службу. У поєднанні із закритим кодом, який не може бути перевірений дослідниками з безпеки з відкритим кодом та аудиторами, стимул для зловмисників зростає, а помилки, які могли б бути виявлені, залишаються непоміченими для всіх, окрім найсофістикованіших зловмисників, які зберігають ці помилки в секреті, щоб підтримувати свій доступ через бекдор, залишаючи всіх користувачів служби скомпрометованими.
Q5. Чи можете поділитися прикладом ( поза TM SGNL), де недолік з боку постачальника підриває гарантії енд-ту-енд шифрування?
Використання Signal сервісу Twilio для SMS-верифікації призвело до компрометації деяких облікових записів користувачів Signal, коли Twilio був зламаний. Оскільки SMS-верифікація є одним із способів, якими користувачі Signal можуть відновити свої облікові записи, зламавши Twilio, зловмисники могли обманути сервери Signal, змусивши їх думати, що вони володіють номером телефону користувача Signal, і відновити свій обліковий запис, використовуючи цей доступ для надсилання несанкціонованих повідомлень з облікових записів цих користувачів Signal.
Q6. Чому ви вважаєте, що децентралізація є єдиним способом повністю зменшити ризик від одного постачальника?
Децентралізація є єдиним способом повністю зменшити ризик, пов'язаний з єдиним постачальником, оскільки вона усуває єдину точку відмови, властиву будь-якій централізованій системі. Коли єдине підприємство контролює ключові частини стеку – від ідентифікацій користувачів до маршрутизації повідомлень і зберігання – воно стає нездоланною мішенню для зловмисників, і його недоліки в дизайні або реалізації можуть мати катастрофічні наслідки, як це було видно з TM SGNL.
У децентралізованій мережі немає центрального сервера, який можна зламати, жодної компанії, на яку можна тиснути, щоб вставити бекдори, і жодної єдиної бази даних, на яку можна націлитися для збору метаданих. Ідентичності користувачів зазвичай є криптографічними ключами, а не реальними ідентифікаторами, пов'язаними з центральною владою. Повідомлення маршрутизуються та зберігаються у розподіленій мережі незалежних вузлів, що означає, що жоден вузол не бачить IP-адреси відправника та одержувача, і жодна окрема сутність не може збирати всебічний журнал комунікацій.
Ця розподілена структура влади та даних вкрай робить систему більш стійкою до атак, цензури та експлуатації даних, оскільки немає єдиної точки, яку можна експлуатувати. Безпека не залежить від надійності однієї компанії, а скоріше від колективної цілісності та надійного криптографічного дизайну розподіленої мережі.
Q7. Сесія використовує мережу сервісних вузлів. Як ця архітектура забезпечує те, що жодна сторона не може скомпрометувати дані користувача?
На відміну від традиційних додатків для обміну повідомленнями, Session не покладається на один центральний сервер, що зберігає всі дані користувачів. Натомість повідомлення пересилаються через розподілену мережу з тисяч незалежних, керованих спільнотою вузлів Session. Це усуває ефект «медового горщика» єдиної централізованої бази даних, ускладнюючи будь-якій окремій особі збирання всіх зашифрованих повідомлень і метаданих. Вузли Session тимчасово зберігають повідомлення для офлайн-одержувачів. Однак ці повідомлення зашифровані з кінця в кінець, що означає, що самі вузли не можуть прочитати вміст. Крім того, повідомлення зберігаються лише обмежений час (Час життя) і можуть бути видалені після прочитання, що запобігає тривалому зберіганню в мережі вузлів.
Крім того, Session використовує модифіковану техніку рутінгу з цибулевим шаром, схожу на Tor. Коли ви надсилаєте повідомлення, воно шифрується шарами, і кожен шар знімається послідовними вузлами Session. Важливо, що жоден окремий вузол не знає як IP-адреси відправника, так і одержувача. Це означає, що навіть якщо вузол буде скомпрометовано, він не зможе пов'язати повідомлення з його походженням або призначенням.
Облікові записи сесій генеруються криптографічно без необхідності надання особистої інформації, такої як номери телефонів або електронні адреси. Це означає, що немає реальної ідентичності, пов'язаної з вашим ID облікового запису сесії, що додатково підвищує конфіденційність і ускладнює компрометацію ідентичності користувача через зовнішні витоки даних.
Цей багаторівневий підхід, без центральної точки контролю, тимчасового зберігання, шифрування «від краю до краю» та анонімного маршрутизації, забезпечує те, що навіть якщо невелика кількість Сесійних Вузлів буде скомпрометована, загальна цілісність і конфіденційність мережі залишаться недоторканими.
Q8. Враховуючи впровадження 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 місяців.