Кратко

  • Для TLS 1.2 и DTLS 1.2 RFC 10015 требует, чтобы клиенты не предлагали, а серверы не выбирали несколько вариантов конечнополевого Diffie–Hellman и статический обмен ключами RSA. Статический ECDH и фиксированные DH-типы клиентских сертификатов остаются на уровне SHOULD NOT.
  • Метка D в IANA подтверждает позицию стандарта, но не исполнение. Слово «отключено» требует связать норму с загруженной конфигурацией, всеми точками терминации, отрицательными пробами, телеметрией согласования, сроками исключений и миграцией зависимых клиентов.

Центральная политика уже была исправлена, а контрольная панель показывала зелёный статус. Тем не менее отдельный DTLS-терминатор продолжал работать на старом образе. Реестр верно описывал стандарт; панель ошибочно выдавала это за факт о запущенном процессе.

RFC 10015 — документ IETF категории Standards Track. Он обновляет требования к обмену ключами в TLS 1.2 и DTLS 1.2. В нём нет измерений внедрения, перечня продуктов или результатов сканирования сетей. Стандарт определяет допустимое поведение совместимой реализации, но не утверждает, что конкретная инфраструктура уже изменилась.

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

Нормативная сила не одинакова

RFC 10015 не объединяет все старые механизмы в одну категорию. В TLS 1.2 и DTLS 1.2 клиент MUST NOT предлагать, а сервер MUST NOT выбирать наборы с неэфемерным конечнополевым DH. То же MUST NOT действует для эфемерных DHE-наборов в этих версиях. Статический обмен ключами RSA также запрещён к предложению и выбору.

Для статического ECDH сохраняется SHOULD NOT. Рассматриваемые типы клиентских сертификатов с фиксированным DH тоже относятся к SHOULD NOT. Отступление требует веской и проверяемой причины, но семантически это не то же самое, что нарушение MUST NOT. Если учётная система оставляет только слово «устарело», она уничтожает данные, необходимые для управления исключением.

Версия протокола — часть утверждения. RFC 8996 ранее вывел из применения TLS 1.0 и 1.1. RFC 5246 описывает TLS 1.2, а RFC 8446 перестраивает согласование ключей в TLS 1.3. RFC 10015 прямо допускает FFDHE в TLS 1.3: проблемы варианта TLS 1.2 не делают любой конечнополевой DHE запрещённым. RFC 7919 остаётся важным контекстом для согласования стандартных групп.

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

За требованиями стоят конкретные риски. Без прямой секретности последующая компрометация долговременного ключа способна раскрыть старые сессии. Повторное использование конечнополевых DH-ключей связано с временными утечками и выбором групп; повторное использование ECDH добавляет атаки через неверные кривые, побочные каналы и сбои. Статический RSA сохраняет класс атак Bleichenbacher и опасность повторного использования ключей между протоколами. RFC 9325 и RFC 9847 входят в более широкую работу по обновлению практики TLS вслед за доказательствами, а не вслед за привычкой.

Что именно подтверждает D

В реестре TLS-параметров IANA затронутые наборы и четыре значения ClientCertificateType отмечены D со ссылкой на RFC 10015. Буква означает discouraged. Конкретную силу — MUST NOT либо SHOULD NOT — задаёт цитируемая спецификация.

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

Она не обходит все listener, SNI, прокси, балансировщики и региональные узлы. Она не показывает, прекратили ли клиенты предложение и перестали ли серверы выбирать набор. Путь исключения или rollback-образ тоже может вернуть механизм. У каждого из этих утверждений отдельный владелец и отдельный срок достоверности.

Возможность, предложение, выбор и наблюдение

Операционная модель должна хранить как минимум четыре состояния. Возможность означает, что код способен выполнить обмен. Предложение — то, что клиент отправил в конкретном рукопожатии. Выбор — решение сервера. Наблюдение — фрагмент реальности, который увидели сканер или телеметрия.

Код может сохранить возможность, а политика — запретить все предложения. Название набора может оставаться в файле, но никогда не выигрывать приоритет. Сканер может ничего не увидеть, если не знает нужный SNI, не проверяет UDP, пропускает внутреннюю границу или всегда предлагает лучшую альтернативу. Отсутствие в выборке не означает невозможность.

Контролируемая отрицательная проба предлагает только запрещённое семейство и ожидает отказа. Она сильнее обычного подключения современного клиента, но действует лишь для достигнутых адреса, порта, транспорта, SNI, момента и версии политики. DTLS 1.3 в RFC 9147 напоминает: проверка TLS по TCP не закрывает DTLS по UDP.

Квитанция закрытия устаревания

Для каждой экспозиции нужна квитанция закрытия устаревания. В первом разделе фиксируются RFC, идентификатор IANA, версия протокола, семейство обмена и нормативная сила. Так разрешённый в TLS 1.3 FFDHE не удаляется по сходству названия, а SHOULD NOT не превращается молча в MUST NOT.

Второй раздел называет реальную точку управления: авторитетный источник конфигурации, утверждённую ревизию, сгенерированную политику, версию программы или устройства, listener, SNI, адрес, порт, транспорт и вышестоящие прокси. Фраза «глобальная политика обновлена» выражает намерение, если завершение соединений распределено.

Третий раздел подтверждает активацию: перезапуск, горячую загрузку или управляемое развёртывание; время; номер изменения; целевую совокупность; успешные, сбойные и отсутствующие экземпляры; rollback-версию. Diff показывает план. Идентификатор процесса и загруженная политика приближают доказательство к исполнению.

Четвёртый раздел описывает поведение: отказ при единственном запрещённом предложении, выбор среди допустимых альтернатив, предложения и выборы в телеметрии, окно наблюдения и пробелы выборки. «Не увидели» не переводится в «невозможно».

Последний раздел связывает исключения и зависимости: старый клиент, функцию, область, компенсирующую меру, владельца, согласование, срок и критерий выхода. Миграция клиента и удаление совместимого пути подтверждаются отдельно. Исключение без срока — уже не мост, а параллельная политика.

Эта квитанция — редакционное предложение Daniel Kade, а не новое требование RFC 10015. Она нужна, чтобы скорость машинного чтения нормы не превращалась в машинную уверенность относительно непроверенной инфраструктуры.

Формулировки по силе доказательств

Автоматизация должна сообщать: «устарело в реестре», «удалено из конфигурации», «перезагрузка подтверждена», «отрицательное предложение отклонено», «в данной области выбор не наблюдался», «исключение закрыто». Слово «отключено» уместно только после закрытия всех относящихся точек терминации.

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

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

Источники