Уязвим ли TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 к атакам Zombie POODLE/GOLDENDOODLE?

Я получаю смешанные сообщения об этом. У меня есть веб-хост и несколько инструментов сканирования SSL (в том числе тот, который запускается Лаборатория Qualsys SSL), говоря, что набор шифров TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 НЕ уязвим для Zombie POODLE/GOLDENDOODLE, и в то же время у меня есть фирма по соблюдению требований PCI, указывающая, что это является уязвимый. К сожалению, ни один из них не желает сдвинуться с места по этому вопросу или предоставить гораздо больше деталей, чем то, что я уже упоминал здесь.

Я не очень много знаю о криптографии, но я достаточно знаю, что наличие «CBC» в названии набора шифров само по себе предполагает, что он реализует цепочку блоков шифра, и, в более широком смысле, он может непреднамеренно раскрыть оракула заполнения. , и, таким образом, уязвим для атак Zombie POODLE. Если это так, то почему все инструменты сканирования SSL, которые я использовал, говорят об обратном?

Кроме того, я понимаю, что есть веские аргументы против использования TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 в целом, но это выходит за рамки этого вопроса, так как меня действительно интересует только то, уязвим ли он конкретно для атак Zombie POODLE/GOLDENDOODLE.

Набор шифров указывает, что CBC с дополнением PKCS#7 используется с проверкой MAC, выполняемой только после расшифровки. Это означает, что он уязвим для оракулов с открытым текстом до проверки MAC.

Распаковка в основном подвергается риску не потому, что оракулы заполнения более склонны к утечке информации по сравнению с другими оракулами открытого текста, а просто потому, что распаковка обычно происходит до восстановления MAC.

Хитрость реализации заключается в том, чтобы не распаковывать явно, поскольку длина открытого текста известна заранее, и выполнять сравнение (предпочтительно с постоянной времени) тега аутентификации, созданного HMAC, до того, как будет использован любой из байтов открытого текста.

Если реализация неизвестна, то фирма, отвечающая за соответствие PCI, права, она представляет риск. Этого можно относительно легко избежать, используя TLS 1.3 или TLS 1.2, используя режим работы GCM или CCM для AES.

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 — это протокол (подмножество семейства протоколов TLS). Zombie POODLE и GOLDENDOODLE являются уязвимостями в некоторых реализациях этого протокола. Так что, если фирма по обеспечению соответствия утверждает, зная только, что ваш сервер принимает этот набор шифров, что ваш сервер может быть уязвим для этих атак, они правы. Если фирма по обеспечению соответствия утверждает, что как только ваш сервер примет этот набор шифров, он станет уязвимым для этих атак, то они ошибаются.

Эти атаки основаны на анализе ответов об ошибках, отправляемых сервером TLS, когда он получает неверные данные (которые могут исходить от вредоносного клиента или посредника). (Этот анализ также включает потенциальное отсутствие ответа, а также как время ответа.) Оба заполнение атак оракула. Все наборы шифров TLS, использующие CBC, уязвимы для атак оракула заполнения, если реализованы наивно. Почти каждая реализация TLS была уязвима для Счастливая Тринадцать когда он был раскрыт в 2013 году, и некоторые из них все еще могут быть уязвимы для его вариантов, но OpenSSL и несколько других основных стеков TLS теперь реализуют контрмеры, которые полностью защищают от атак оракула заполнения, если они реализованы правильно.Эти контрмеры по своей природе медленные и незаметные, поэтому вы можете не захотеть полагаться на них, но для уровня безопасности, ожидаемого для соответствия PCI, их достаточно.

Если ваш сервер использует OpenSSL или стек Windows TLS или большинство основных реализаций TLS, это безопасно. (Однако OpenSSL был уязвим для другой похожей атаки, обнаруженной в то же время, получившей название «OpenSSL нулевой длины», поскольку она была очень специфичной для поведения OpenSSL.) В основном вам нужно беспокоиться о некоторых промежуточных блоках, которые расшифровывают трафик TLS ( брандмауэры, балансировщики нагрузки, …). Тем не менее, пока вы применяете все исправления безопасности, у вас все должно быть в порядке (и если последняя прошивка все еще уязвима, немедленно откажитесь от поставщика).

В любом случае вы можете использовать сканер, предоставленный исследователями, обнаружившими атаки для проверки ваших систем. Это тот же самый сканер, который использует Qualys (и, несомненно, другие), поэтому, если Qualys говорит, что ваша система неуязвима, у вас нет проблемы с безопасностью: ваша единственная проблема — убедить своего аудитора.

Если ваш аудитор хоть немного компетентен, он должен либо запустить этот сканер, либо использовать службу, которая запускает этот сканер, и сделать вывод, что ваша система не уязвима. Но, судя по их ответу, они могут быть менее чем компетентны. Хороший одитор знал бы и смог бы объяснить все, что я здесь написал. Также странно, что аудитор упоминает только эти две атаки на наборы шифров на основе CBC, а не более старые, такие как BEAST, Lucky Thirteen и т. д.

Насколько вы заботитесь о поддержке наборов шифров CBC? Хотя они могут быть реализованы безопасно, для этого требуется, чтобы все ваши серверы и промежуточные устройства, перехватывающие TLS, были высокого качества, и это приводит к снижению производительности. если вы не необходимость их, я рекомендую отключить их. Как правило, для TLS хорошим балансом между безопасностью и совместимостью является использование только наборов шифров на основе подписи (т.с ECDHE или, возможно, DHE в их названии, в дополнение к RSA или ECDSA), с AEAD (CCM, GCM или CHACHA20_POLY1305). Некоторые другие наборы шифров могут быть безопасными, но имеют повышенный риск уязвимостей реализации.

Итак, моя стратегия с этим одитором была бы следующей:

1. Проверьте, действительно ли вам нужны наборы шифров CBC. Если нет, отключите их и скажите своему одитору, что это спорный вопрос.
2. Если вам нужны наборы шифров CBC, напомните аудитору, что это уязвимости реализации, и аргументируйте тем, что Qualys говорит, что реализация уязвима. Если они все еще не убеждены, запустите сканер оракулов заполнения самостоятельно и предложите вашему одитору сделать то же самое.
3. Если одитор действительно ничего не услышит, у вас может не остаться иного выбора, кроме как сменить одитора. На данный момент мы далеко ушли от криптографии в сферу бизнеса.