ИИтог

IETF запретила RSA и Diffie-Hellman в TLS 1.2 из-за атак Raccoon и Bleichenbacher

безопасностьРедакция ИИтогHacker News🔥53Рейтинг ИИтог53Влияние55Новизна35Релевантность80Неожиданность20Участники30Достоверность95

IETF опубликовала RFC 10015, стандартизационный документ (Internet Standards Track), одобренный Internet Engineering Steering Group (IESG) и представляющий консенсус сообщества IETF. Он запрещает использование в (D)TLS 1.2 и DTLS 1.2 двух методов обмена ключами: RSA key exchange и Diffie-Hellman (DH) над конечным полем, причём как в статической (непересоздаваемой заново на каждое соединение), так и в эфемерной форме (DHE, она же FFDHE). Отдельно документ настоятельно не рекомендует статический (непересоздаваемый заново) вариант эллиптической криптографии Диффи-Хеллмана (ECDH); эфемерный ECDHE под запрет не попадает.

Причина в накопившихся практических атаках. RSA key exchange не даёт прямой секретности (forward secrecy) и годами страдает от атаки Блейхенбахера (Bleichenbacher) и её вариаций, исследователи находят новые формы этой уязвимости каждые несколько лет, потому что корректно реализовать защиту от неё на практике сложно. Конечно-полевой Diffie-Hellman (FFDHE) страдает от атаки Raccoon: при повторном использовании публичных ключей, как в статических наборах шифров, так и при переиспользовании ключей в эфемерных, возникает тайминг-канал утечки секрета соединения. Дополнительно у FFDHE нет механизма согласования параметров группы, нестандартные (кастомные) группы широко распространены, а клиент не может на лету проверить их безопасность; часть операторов до сих пор использует 1024-битные группы ради совместимости, при этом текущий рекорд взлома дискретного логарифма уже достиг 795 бит, оставляя малый запас прочности. У статического ECDH похожая проблема: переиспользование ключа не только позволяет ретроактивно расшифровать перехваченный трафик при компрометации ключа, но и открывает атаки на некорректные эллиптические кривые (invalid curve attacks), уже показанные практически работоспособными против реальных TLS-реализаций.

Ограничения касаются только (D)TLS 1.2: версии 1.0 и 1.1 уже выведены из обращения ранее (RFC 8996), а в TLS 1.3 перечисленные проблемы не воспроизводятся, поэтому там конечно-полевой DHE по-прежнему разрешён (не обязателен, но допустим). Документ обновляет более десятка прежних RFC, включая базовую рекомендацию по безопасной настройке TLS, RFC 9325 (BCP 195), и одновременно правит реестр IANA: все соответствующие наборы шифров и типы сертификатов с фиксированными DH/ECDH-параметрами получают в реестре пометку «не рекомендовано» (D).

Ключевые факты

  • RFC 10015, стандарт IETF (Internet Standards Track, одобрен IESG): запрещает RSA key exchange и весь конечно-полевой Diffie-Hellman (и статический DH, и эфемерный DHE/FFDHE) в (D)TLS 1.2 и DTLS 1.2; статический ECDH, не запрещён, но настоятельно не рекомендуется.
  • Запрет RSA обоснован атакой Bleichenbacher и её вариантами, которые периодически всплывают уже десятилетия; запрет DH, атакой Raccoon (тайминг-утечка секрета при переиспользовании ключей) и проблемами малых подгрупп и совместимости у нестандартных FFDHE-групп.
  • Мера предосторожности не абстрактна: текущий рекорд взлома дискретного логарифма, 795 бит, а часть операторов до сих пор использует 1024-битные группы Diffie-Hellman ради широкой совместимости, оставляя малый запас прочности.
  • TLS 1.3 изменения не затрагивают: там finite-field DHE остаётся разрешённым (не обязательным, но допустимым), потому что современная версия протокола не подвержена этим проблемам; TLS 1.0/1.1 выведены из обращения ранее отдельным RFC 8996.
  • Документ обновляет более десятка прежних RFC, включая рекомендацию по безопасной настройке TLS (RFC 9325, BCP 195), и переводит соответствующие наборы шифров и типы сертификатов в реестре IANA в статус «не рекомендовано».

Почему это важно

Это не косметическое обновление реестра, а официальное признание IETF того, что три давно живущих в TLS 1.2 метода обмена ключами имеют рабочие, а не теоретические атаки: Raccoon против Diffie-Hellman, атаки на некорректные эллиптические кривые против статического ECDH и семейство атак типа Bleichenbacher (включая ROBOT) против RSA. IETF формализует то, что практикующие специалисты по безопасности уже знали, и поднимает планку для аудитов соответствия и чек-листов настройки серверов по всей индустрии.

Кому это важно

Разработчикам TLS-библиотек и серверного и клиентского программного обеспечения, которым нужно обновить списки поддерживаемых наборов шифров. Системным администраторам, которые всё ещё держат TLS 1.2 в продакшене, это распространённая ситуация в устаревшей инфраструктуре, промышленных и встраиваемых системах, банковском ПО. Специалистам по безопасности и комплаенсу, которые сверяют конфигурации с рекомендациями IETF и реестром IANA.

Как это применить

На серверах и клиентах нужно отключить наборы шифров, использующие RSA key exchange, а также любые формы конечно-полевого Diffie-Hellman, и статические (TLS_DH_*), и эфемерные (DHE/FFDHE). Стоит также отказаться от сертификатов с фиксированными DH-параметрами (типы rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh) и по возможности не использовать статический ECDH. Предпочтительная замена, эфемерный ECDHE или переход на TLS 1.3, где перечисленные проблемы не встречаются.

Можно ли доверять

Источник, официальный текст RFC на сайте RFC Editor: документ имеет статус Internet Standards Track, представляет консенсус сообщества IETF и прошёл публичное рецензирование и одобрение Internet Engineering Steering Group (IESG). Документ опирается на конкретные именованные атаки и исследования (Raccoon, атаки на некорректные кривые, Bleichenbacher и его варианты вроде ROBOT) и явно ссылается на предыдущие RFC, которые он обновляет, это первичный нормативный источник, а не пересказ третьей стороны.

Риски и подводные камни

В тексте нет конкретной даты вступления требований в силу или срока, к которому реализациям нужно отключить поддержку устаревших наборов шифров, это оставляет миграцию на усмотрение разработчиков и операторов и может растянуть её на годы. Нестандартные (кастомные) группы Diffie-Hellman по-прежнему широко распространены, и клиент не может на лету проверить их безопасность. Наконец, ограничение действует только для (D)TLS 1.2, для TLS 1.3 finite-field DHE остаётся разрешённым, так что при настройке легко перепутать версии протокола и решить, что запрет распространяется шире, чем на самом деле.