Исследователи из компании NCC Group раскрыли (https://www.nccgroup.trust/us/about-us/newsroom-and-events/b.../) сведения (https://eprint.iacr.org/2018/1173) (PDF (https://eprint.iacr.org/2018/1173.pdf)) о новой атаке по сторонним каналам, позволяющая через анализ остаточных данных в процессорном кэше восстановить содержимое каналов связи, зашифрованных при помощи протоколов TLS и QUIC. Проблема в том числе затрагивает протокол TLS 1.3. Атака может применяться на многопользовательских системах для перехвата зашифрованных сеансов других пользователей, при наличии контроля за транзитным трафиком жертвы (для атаки необходимо выполнение кода на том же CPU и контроль за сетевым шлюзом, например, через организацию подключения клиента к фиктивной точке доступа).
Атака позволяет восстановить шифротекст, зашифрованный при помощи RSA-ключа, через анализ добавочного заполнения (padding oracle), используемого для выравнивания зашифрованных данных по границе блока.
Принцип атаки основан на усовершенствованном методе, предложенном Даниэлем Блейхенбахером (Daniel Bleichenbacher) в 1998 году, суть которого в том, что атакующий на основании разных ответов от сервера может отделить корректные и некорректные блоки добавочного заполнения (padding oracle) в режиме PKCS #1 v1.5. Манипулируя информацией о корректности блоков добавочного заполнения атакующий может путём перебора определить (https://eklitzke.org/the-cbc-padding-oracle-problem) подходящий шифротекст.Так как утечки состояний на основе активности сервера уже давно блокированы в реализациях криптографических библиотек, в новой атаке для определения корректности блоков предлагается анализировать следы работы библиотек в процессорном кэше. Для атаки применимы различные техники извлечения остаточных данных из процессорного кэша, такие как Flush+Reload (https://www.opennet.ru/opennews/art.shtml?num=46812), Prime+Probe (https://www.opennet.ru/opennews/art.shtml?num=48091) и на основе манипуляций (https://www.opennet.ru/opennews/art.shtml?num=49608) с блоком предсказания переходов.
Проблема была выявлена в ноябре 2018 года и сообщена разработчикам библиотек, но детали раскрыты только сейчас, после публикации исправлений. Проблема затрагивает реализации TLS в библиотеках OpenSSL, Amazon s2n, MbedTLS, Apple CoreTLS, Mozilla NSS, WolfSSL и GnuTLS. Не подвержена атаки оказались библиотеки BearSSL и BoringSSL.
Атака является достаточно эффективной и позволяет восстановить все 2048 бит шифротекста RSA за время, не превышающее 30 секунд. В TLS 1.3 не используется обмен ключами на основе RSA, поэтому для атаки на TLS 1.3 применяется обходной манёвр, позволяющий откатить шифрованное соединение на прошлую версию протокола через спуфинг TCP-пакетов.
Для атаки на клиентские браузеры может применяться метод, напоминающий атаки BEAST (https://www.opennet.ru/opennews/art.shtml?num=31797) и POODLE (https://www.opennet.ru/opennews/art.shtml?num=40833), и требующий запуска подконтрольного атакующему JavaScript-кода в браузере жертвы (например, через подстановку кода в любой незашифрованный HTTP-ответ при наличии контроля за транзитным шлюзом). JavaScript-код используется для отправки на защищённый сайт, с которым работает жертва, фиктивных запросов с изначально известными контрольными метками, которые используются атакующим для воссоздания отдельных блоков для шифра TLS/SSL. Так как для успешной атаки необходимо проанализировать тысячи проверочных запросов, которые не удаётся отправить в рамках установленного в браузерах таймаута (обычно 30 секунд), предложен (https://github.com/mimoo/RSA_PKCS1v1_5_attacks) метод распараллеливания подобных запросов через их отправку к различным TLS-серверам, на которых используется сертификат с одним и тем же открытым ключом.URL: https://www.nccgroup.trust/us/about-us/newsroom-and-events/b.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=50121
Тема LibreSSL не раскрыта
А что там раскрывать, кривой форк от левых чуваков
>>для атаки необходимо выполнение кода на том же CPU и контроль за сетевым шлюзом
>>Для атаки на клиентские браузеры может применяться метод, требующий запуска подконтрольного атакующему JavaScript-кода в браузере жертвы через подстановку кода в любой >>незашифрованный HTTP-ответ при наличии контроля за транзитным шлюзом----------------------------------------
O'rly? Может в конечном итоге вообще требуется возможность запуска вредоносного кода из загрузочного с сектора жёсткого диска до загрузки оси, а потом ось грузить внутри виртуальной машины нападающего кода и там уже перехватывать весь сетевой трафик? Контроль же за сетевым шлюзом как никак нужен, ну. Такие забавные условия нужны: и тебе исполнение кода на CPU жертвы, и тебе контроль сетевого шлюха и нешированный простой HTTP (не HTTPS) трафик, ага.
С контролем транзитного трафика проблем как раз меньше всего - для выуживания паролей и номеров кредитных карт устраивается ловля на подставную WiFi точку доступа. А для более серьёзных применений у спецслужб есть административный рычаг. Труднее с выполнением кода на стороне клиента, но до недавних пор через JavaScript вполне можно было проводить атаки по анализу кэша. Теперь разве что для атаки спецслужб на облака описанный метод применим.
а смысл возиться с расшифровкой трафика если имея доступ к тачке можно снимать уже расшифрованные сообщения из самих программ?
это сделали ради развлечения))) и эго потешить.
А кто сказал, что у твоего кода будут локальные привилегии на прослушивание сетевого трафика? В уязвимости главное то, чтобы твой код исполнялся на одном CPU, даже если он из-под отдельного пользователя или в песочнице браузера.
> шифротекст, зашифрованныйДва раза зашифрованный?
там же запятая)
Если я правильно понял, для защиты на вэб-сервере и на почтовом сервере нужно использовать только серт на эпилептических кривых и разрешить только TLS 1.3?
>на вэб-сервере и на почтовом сервере нужно использовать только серт на эпилептических кривыхДа, эпилептики неуязвимы!
FU****
Извиняюсь, промахнулся, хотел +1 поставить.
А по теме - устойчивость эллиптических кривых еще не совсем доказана.
В АНБ почему-то не то что не спешат их использовать, а спешат их НЕ использовать... для себя.
Вот и думай - почему.
причем обязательно на идиопатических, потому что фотосенсибили... (язык сломаешь) короче, фото-эти-самые уязвимы, так как недостаточно кривые.
Вот это
да
Помнится, кто-то недавно в комментах к другой новости очень громко кричал, что TLS 1.3 не нужен и совсем-совсем не улучшает безопасность. И отказывался предоставить доказательства, типа как же я предоставлю доказательства отсутствия чего-то.
К чему такие глупые коментарии на техническом ресурсе? Не можете что-то дельное сказать - не говорите ниче. Хочется высказаться - валите в соцсети или заведите блог.
> требующий запуска подконтрольного атакующему JavaScript-кода в браузере жертвы (например, через подстановку кода в любой незашифрованный HTTP-ответ при наличии контроля за транзитным шлюзом)И потом ыксперты тут говорят, что никакой проблемы в открытом http нет. Пускай котики бегают, религия не позволяет шифровать и тратить 0.01% cpu.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256> И потом ыксперты тут говорят, что никакой проблемы в открытом http нет.
> Пускай котики бегают, религия не позволяет шифровать и тратить 0.01% cpu.Это потому что еще ранее Ыксперты заучили мантру "аутентификация совсем-совсем не нужна, если шифровать канал, поэтому можно и нужно сэкономить 0.001% CPU!".
В итоге, до сих пор нет нормальной авторизации/аутентификации в стандарте веба, пароли и прочее могут спокойно хранить в плейн -- зато/ведь канал передачи зашифрован!!1разъясняю:
проблема не в отсутсвии шифрования (содержимое скрипта может узнать любой, обратившийся к тому же серверу), а в отсутсвии аутентификации, когда содержимое подменяется. HTTPS тут не более, чем костыль.
Не верящим предлагаю попробовать подменить мое сообщение:
-----BEGIN PGP SIGNATURE-----iHUEAREIAB0WIQTQaLRjLMt2TTkWkoZ+PeLyUDdO7wUCXGGJWwAKCRB+PeLyUDdO
799RAP9Od5K6EBPLx1h2qxCvDoAZtuPTnN1yUc7+r8Tmz+m1bAEAgP4y9YFhRjrZ
VHqKm8N8SsjAnN8XK4aaGZ1LeDinu3Y=
=vjuZ
-----END PGP SIGNATURE-----
следующим этапом развития процессоров- вероятно станет выделение процессора на каждую задачу в монопольном режиме. Ядер сейчас в процессорах- как грязи...и дальше будет больше... так чего мелочится? к том уже разные задачи требуют мягко говоря разной процессорнной мощности. зачем занимать сложное ядро простой задачей? соответственно ядра в процессорах будут тоже разными - 1000 простых ядер, 100 чуть более сложных, 10 сложных... вангую новый виток .искомерятельных тредов...