Translated message

A translation of this page exists in English.

Logjam: уязвимости в TLS (CVE-2015-4000)

Обновлено -

Центр безопасности Red Hat предупреждает об уязвимости соединений TLS, использующих алгоритм обмена ключами Диффи-Хеллмана.

Описание

Соединения TLS, использующие алгоритм обмена ключей Диффи-Хеллмана (DHE, Diffie-Hellman Exchange), потенциально уязвимы для атаки, в которой «человек посередине» может ослабить шифрование до экспортного уровня 512 бит, тем самым скомпрометировав защиту соединения. В группу риска попадают серверы, поддерживающие шифры DHE_EXPORT. Атака реализуется путем предварительного вычисления начальных простых чисел длиной в 512 бит, которые обычно предопределены в двух наиболее распространенных наборах начальных значений протокола Диффи-Хеллмана, в том числе в используемых в Apache httpd 2.1.5 - 2.4.7 и во всех версиях OpenSSL.

Исследовательская работа по Logjam обсуждает риски, связанные с ослаблением ключей в протоколе Диффи-Хеллмана:

  1. Криптография DHE_EXPORT в протоколе TLS или использование экспортных ключей: при наличии достаточных вычислительных ресурсов и времени подбор ключа длиной 512 бит не представляет особой сложности. Более того, при использовании PFS (Perfect Forward Secrecy) злоумышленник может записать зашифрованный трафик и расшифровать его позднее.

  2. Использование предопределенных начальных простых чисел во многих программах, в том числе Apache httpd и sshd: это позволяет предварительно выполнить вычисления для исходных значений, что впоследствии помогает быстро подобрать ключ, с помощью которого будет расшифрован трафик.

  3. Уязвимость протокола TLS, позволяющая снизить уровень шифрования DHE до DHE_EXPORT. Этой уязвимости был присвоен код CVE-2015-4000.

Степень воздействия

Ниже приведены возможные сценарии проведения атаки:

  1. Асинхронная расшифровка соединений, использующих слабые ключи DHE.
    Это относится к серверам, которые по умолчанию используют 512-битные ключи, передаваемые по протоколу Диффи-Хеллмана. В этом случае трафик сразу может записываться в пассивном режиме прослушивания, что впоследствии позволяет расшифровать его в любое время.

  2. Ослабление шифрования до уровня DHE_EXPORT с использованием расширения TLS False Start и асинхронная расшифровка трафика.
    Этот сценарий подразумевает, что сервер поддерживает набор шифров DHE_EXPORT или не запрещает 512-битные ключи в неэкспортном варианте DHE. Тогда если клиент использует функции TLS False Start, злоумышленник может перехватить его запрос и запросить ослабленное шифрование.

  3. Ослабление шифрования до уровня DHE_EXPORT с реализацией атаки «человек посередине».
    В этом случае поддержка TLS False Start не нужна, так как злоумышленник приостанавливает сам процесс рукопожатия настолько, сколько потребуется для взлома и подмены ключа (может занять несколько минут).

Решение

Серверы SSL/TLS

Если сервер поддерживает экспортный набор шифров, злоумышленник может снизить уровень шифрования DHE до DHE_EXPORT, используя метод атаки «человек посередине». Причина кроется в уязвимости протокола TLS, что делает возможной подмену отправляемых на сервер данных и ослабление шифрования.

Эта уязвимость не затрагивает текущие версии openssl в Red Hat Enterprise Linux 6 и 7, так как они не включают экспортные наборы шифров в стандартный список шифров DEFAULT, который используется приложениями по умолчанию. Тем не менее, на уровне отдельных приложений можно будет включить DHE_EXPORT. Информацию о защите клиентов SSL/TLS, использующих openssl, читайте в следующей секции.

В Red Hat Enterprise Linux 7 экспортные шифры были исключены из списка DEFAULT в openssl с момента выпуска, в то время как в Red Hat Enterprise Linux 6 это изменение было представлено в рекомендации RHBA-2014:1525 к версии Red Hat Enterprise Linux 6.6.

Red Hat Enterprise Linux 5 поддерживает экспортные шифры в стандартном списке DEFAULT. Однако Red Hat Enterprise Linux 5 уже находится на третьем этапе этапе жизненного цикла, на котором выпускаются только критические обновления безопасности, поэтому публикация исправлений для этой уязвимости (имеющей СРЕДНИЙ приоритет) не планируется.

Клиенты SSL/TLS

Так как клиенты не могут контролировать шифрование на стороне сервера SSL/TLS, единственным способом защиты является отказ от приема коротких простых чисел в ходе рукопожатия DHE.

В основной ветви разработки OpenSSL остальные проблемы решаются увеличением минимального размера параметров DH, которые будет принимать клиент, до 768 бит, что затруднит подбор ключей.

В настоящее время все версии NSS в стандартных комплектах Red Hat Enterprise Linux допускают обмен 512-битными ключами по алгоритму Диффи-Хеллмана. Ниже приведены ссылки на внешние исправления, сообщающие об увеличении их минимальной длины до 1023 бит:

Эти предложения уже находятся на рассмотрении в центре безопасности продуктов Red Hat. По результатам проверки будет принято окончательное решение с возможной интеграцией изменений в Red Hat Enterprise Linux.

Openswan/Libreswan

Logjam не затрагивает IKE в Openswan и Libreswan. Дело в том, что для создания VPN-туннелей IPSec демон pluto из openswan и libreswan использует не TLS, а IKEv1 и IKEv2. Обе реализации — Openswan и Libreswan — по умолчанию используют DH-группы от MODP1024 и выше и не поддерживают группы ниже MODP768.

JBoss

За информацией о мерах защиты, направленных на уменьшение вероятности эксплуатации Logjam в продуктах JBoss, обратитесь к статье Logjam: уязвимости в TLS (CVE-2015-4000) в продуктах JBoss

Comments