Кратко

  • RFC 10015 запрещает клиентам TLS/DTLS 1.2 предлагать, а серверам выбирать наборы FFDH, FFDHE и с обменом RSA; для статического ECDH действует SHOULD NOT.
  • Граница зависит от версии и функции: FFDHE разрешён в TLS/DTLS 1.3, а RSA-сертификат может аутентифицировать допустимый эфемерный обмен.
  • Метка IANA D фиксирует классификацию, но не меняет процесс. Нужны реестр точек, положительные и отрицательные пробы, причины отказов, истекающие исключения, rollback и контроль дрейфа.

Проверка стандарта прошла, проверка соединения — нет

В отчёте об аудите всё выглядело завершённым: RFC опубликован, в колонке Recommended у старых наборов появилась D, в центральном репозитории лежала новая политика. Затем тестовый клиент успешно установил TLS 1.2 через TLS_RSA_*.

Успех показал, что ни один из трёх документов не управлял реально работающей точкой завершения.

RFC 10015, опубликованный в июле 2026 года как Standards Track, требует, чтобы в TLS и DTLS 1.2 клиент не предлагал, а сервер не выбирал наборы с обменом ключами RSA. Поддержка самой версии 1.2 может сохраниться. Исчезнуть должен конкретный способ создания секрета.

Это делает общий показатель «TLS 1.2 разрешён» почти бесполезным для данной миграции. Он не сообщает, какой обмен состоялся, был ли секрет эфемерным, какая группа использовалась и кто выбрал набор — edge, proxy или origin.

Три MUST NOT и одно SHOULD NOT

FFDH означает неэфемерный Diffie-Hellman над конечным полем: статический открытый DH-ключ находится в сертификате. FFDHE передаёт временное значение в рукопожатии и аутентифицирует его сертификатом. ECDH и ECDHE проводят аналогичную границу на эллиптических кривых.

Для TLS/DTLS 1.2 RFC 10015 задаёт точную матрицу:

  • неэфемерный FFDH нельзя предлагать и выбирать (MUST NOT);
  • FFDHE нельзя предлагать и выбирать (MUST NOT);
  • обмен RSA нельзя предлагать и выбирать (MUST NOT);
  • неэфемерный ECDH не следует предлагать и выбирать (SHOULD NOT).

Клиентам также не следует применять, а серверам принимать фиксированные типы сертификата rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh и ecdsa_fixed_ecdh. Они относятся только к 1.2 и более ранним версиям.

Разница в силе требования влияет на управление. Статический ECDH может остаться лишь при исключительном, документированном обстоятельстве с границей и сроком, однако это не абсолютный запрет RSA или FFDHE. Для запрещённого набора недостаточно снизить приоритет: если он выбирается при отсутствии иной общей возможности, путь всё ещё открыт.

Фильтр по названию нарушает обе стороны решения

RSA в сертификате не равен RSA в обмене ключами. RSA-ключ может подписать аутентификацию ECDHE, где секрет создаётся эфемерно. Глобальное правило «удалить RSA» способно отключить допустимый путь.

Столь же неточно «удалить DHE». RFC 10015 отдельно говорит, что FFDHE в TLS и DTLS 1.3 не наследует перечисленные проблемы конструкции 1.2 и может предлагаться. Правило должно учитывать версию вместе с набором.

Минимальная доказуемая запись поэтому состоит из точки завершения, загруженной конфигурации, предложения клиента, выбора сервера, версии и результата. Список сертификатов или сканирование версий не дают эту связь.

Почему эфемерность не спасла FFDHE 1.2

Эфемерный секрет важен для forward secrecy, но не исправляет выбор конечной группы. В TLS 1.2 распространились пользовательские группы. Клиент не может практически проверить все свойства произвольной группы во время рукопожатия и не получает удобного механизма попросить другой приемлемый параметр.

RFC 7919 стандартизировал именованные FFDHE-группы и описал давление совместимости, сохранявшее широко поддерживаемые размеры. RFC 10015 перечисляет малые подгруппы, остающееся использование 1024 бит и возможность распределить крупное предварительное вычисление на множество соединений с популярной группой.

Буква «E» также не доказывает свежесть секрета в реализации. Повторное использование открывает тайминговые риски класса Raccoon. Вывод относится к сочетанию согласования, проверки параметров, совместимости и жизненного цикла секретов в 1.2, а не ко всему Diffie-Hellman.

RSA переносит компрометацию назад во времени

При RSA-обмене TLS 1.2 клиент создаёт premaster secret и шифрует его для RSA-ключа сервера. Forward secrecy отсутствует. Сохранённый трафик может раскрыться, если приватный ключ будет получен позже.

Оракулы типа Bleichenbacher используют наблюдаемые различия при обработке некорректных RSA-шифротекстов. ROBOT и DROWN показывают, почему варианты этой атаки возвращаются: сделать все ошибки абсолютно неразличимыми трудно.

Риск расширяется между системами. В TLS/DTLS 1.2 нет удобного разделения доменов ключа, а несколько точек часто используют один приватный RSA-ключ. Уязвимость самого слабого endpoint может изменить оценку трафика остальных. Реестр должен связывать отпечаток приватного ключа со всеми местами использования.

D описывает решение, но не исполняет его

RFC 10015 обновляет семнадцать документов, включая TLS 1.2, DTLS 1.2 и BCP 195. Реестр IANA пометил затронутые записи D и добавил новую ссылку. RFC 9847 определяет её как нежелательную для новых реализаций или развёртываний.

Метка синхронизирует язык разработчика, закупки и эксплуатации. Она не меняет библиотеку, crypto provider, framework, переменную среды, proxy, балансировщик, CDN или firmware. Даже правильный diff в репозитории может быть перекрыт локальным шаблоном.

Diff доказывает намерение. Загруженная конфигурация показывает состояние процесса. Только наблюдаемое предложение и выбор доказывают, что старый путь перестал возникать между участниками.

Сначала журнал согласований, потом выключение

Нужно перечислить публичные listeners, внутренние API, исходящие клиенты, DTLS, service mesh, proxies, edge, appliances и встроенные устройства. Для каждого фиксируются владелец, библиотека и провайдер, фактические suites, границы версий, SNI/ALPN, роль сертификата, повторное использование ключа, регион и клиенты.

Базовая линия связывает успешную сессию с версией, набором, обменом, решающей точкой и canary приложения. Отказ получает первую полезную причину: нет общей suite, группа, сертификат, версия или прикладная ошибка после транспорта.

Пробы идут парами. Клиент только с RSA или FFDHE в 1.2 должен получить отказ. Разрешённый эфемерный путь 1.2 должен пройти. TLS 1.3 и допустимый FFDHE должны сохраниться. Смешанное предложение не должно приводить к скрытому fallback.

Раскатка следует границам владения: класс listener, регион, proxy-уровень или группа клиентов. Сохраняются fingerprints до/после, примеры handshakes, распределение ошибок и ограниченный rollback. Доставка файла — событие; исчезновение запрещённого пути при доступности разрешённых — результат.

Факт устанавливает работающий код

Принцип Heng Lu о приоритете работающего кода отделяет декларацию от исполнения. RFC задаёт условие, IANA ведёт общий учёт, но ни один из них не создаёт production handshake.

Модель минимальной начальной спецификации и локализованного будущего решения сохраняет узкую общую несовместимость и местную ответственность. Участник решает инвентаризацию, порядок, замену, изоляцию, исключение и rollback. Это не право назвать запрещённую suite совместимой, а обязанность назвать владельца перехода и условие его окончания.

RFC 10015 проводит границу. Загруженная конфигурация и рукопожатие показывают, существует ли она в сети.