- 28,114
- 46
- 8 Ноя 2022
Безопасный канал открыл дорогу совсем не тому получателю…
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:800/450;margin-bottom:2rem;overflow:hidden">
Доверие к защищённым облакам начинается с вопроса, кому на самом деле отправляются данные, и новая формальная проверка показала, что протокол Attested TLS не всегда способен дать верный ответ.
Attested TLS объединяет защищённое соединение TLS с удалённой аттестацией. Сервер должен криптографически доказать клиенту, что работает внутри подлинной и неизменённой доверенной среды. Специалисты из Дрезденского технического университета, IBM и Университета Намюра проверили семь способов связать такое доказательство с соединением и обнаружили, что ни один не предотвращает ретрансляцию трафика.
При такой атаке клиент получает корректное подтверждение от доверенного сервера или ИИ-агента, но затем шифрует данные для другой вредоносной системы. Протокол проверяет целостность программной среды, однако недостаточно надёжно связывает проверку с конкретным сервером и ключом, который защищает пользовательские данные после установки соединения.
Авторы проверили не только теоретические модели, но и четыре существующие реализации. Недостаток нашли в Private Processing для WhatsApp, Contrast, Cocos AI и демонстрационном проекте группы Confidential Computing Consortium. Для Cocos AI уязвимы версии с 0.4.0 по 0.8.2. Сведений об атаках на реальные системы источник не приводит.
Уязвимость получила номер CVE-2026-33697 и оценку 7,5 из 10 по шкале CVSS 3.1 (AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N). Предложенный авторами способ защиты подтверждает правильный сервер лишь на раннем этапе соединения, но не гарантирует, что последующие данные продолжат поступать в ту же систему. Иными словами, полной защиты сейчас попросту не существует.
Разработчикам рекомендуют отказаться от аттестации во время установки соединения и перейти к проверке после завершения рукопожатия, когда ключ для передачи данных уже создан.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:800/450;margin-bottom:2rem;overflow:hidden">
Доверие к защищённым облакам начинается с вопроса, кому на самом деле отправляются данные, и новая формальная проверка показала, что протокол Attested TLS не всегда способен дать верный ответ.
Attested TLS объединяет защищённое соединение TLS с удалённой аттестацией. Сервер должен криптографически доказать клиенту, что работает внутри подлинной и неизменённой доверенной среды. Специалисты из Дрезденского технического университета, IBM и Университета Намюра проверили семь способов связать такое доказательство с соединением и обнаружили, что ни один не предотвращает ретрансляцию трафика.
При такой атаке клиент получает корректное подтверждение от доверенного сервера или ИИ-агента, но затем шифрует данные для другой вредоносной системы. Протокол проверяет целостность программной среды, однако недостаточно надёжно связывает проверку с конкретным сервером и ключом, который защищает пользовательские данные после установки соединения.
Авторы проверили не только теоретические модели, но и четыре существующие реализации. Недостаток нашли в Private Processing для WhatsApp, Contrast, Cocos AI и демонстрационном проекте группы Confidential Computing Consortium. Для Cocos AI уязвимы версии с 0.4.0 по 0.8.2. Сведений об атаках на реальные системы источник не приводит.
Уязвимость получила номер CVE-2026-33697 и оценку 7,5 из 10 по шкале CVSS 3.1 (AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N). Предложенный авторами способ защиты подтверждает правильный сервер лишь на раннем этапе соединения, но не гарантирует, что последующие данные продолжат поступать в ту же систему. Иными словами, полной защиты сейчас попросту не существует.
Разработчикам рекомендуют отказаться от аттестации во время установки соединения и перейти к проверке после завершения рукопожатия, когда ключ для передачи данных уже создан.
- Источник новости
- www.securitylab.ru
