Кратко

  • Ненулевой ExtSupportLifetime возникает только после проверки TLSA-цепочки, её соответствия сертификатной цепочке и успешной DANE-аутентификации для конкретного SNI-имени и порта. TTL ограничивает текущую запись, pin — обязанность предоставить следующее доказательство.
  • Заверенное отсутствие TLSA, доказательство небезопасного делегирования или проверенный нулевой срок могут снять pin. Простое отсутствие расширения при действующем pin ничего не доказывает и способно потребовать разрыва соединения.

Как проверить DNS-службу до первого DNS-запроса

Клиент DNS over TLS хочет аутентифицировать резолвер через DANE. Для этого ему нужны TLSA RRset и DNSSEC-путь до доверенного якоря. Но естественный способ получить их проходит через тот же резолвер, чья подлинность ещё не установлена. Экспериментальное расширение dnssec_chain из RFC 9102 переносит необходимые DNS-записи и подписи внутрь TLS-handshake.

Ответ сервера содержит саму цепочку и 16-битное число часов — ExtSupportLifetime. Цепочка описывает состояние TLSA для SNI-имени и порта сейчас. Число показывает, как долго сервер или обслуживающий это имя кластер обязуется поддерживать расширение. Совместная доставка не означает общего срока действия.

RFC 9102 подписали Viktor Dukhovni, Shumon Huque, Willem Toorop, Paul Wouters и Melinda Shore; исходную идею документ приписывает Adam Langley. Профиль IETF и публичная биография Huque связывают его работу с DNS-инфраструктурой, сетями и протоколами безопасности: сегодня в Salesforce, ранее в Verisign и Университете Пенсильвании. Это точная привязка вклада, а не заявление о единоличном владении DANE, DNSSEC, TLS или экспериментальным RFC.

Pin нельзя создать одним полем

Клиент может принять ненулевой срок только тогда, когда расширение несёт действительную TLSA authentication chain, она соответствует сертификатной цепочке сервера, а handshake полностью проходит DANE-проверку. Синтаксически корректное значение, успех только по PKIX или неподписанный набор RR такого состояния не создают. Иначе внедрённое число само стало бы инструментом длительного отказа в обслуживании.

Область действия тоже узкая. В запросе указан TCP-порт, имя берётся из SNI клиента. Для встроенного метода сервер не разворачивает CNAME этого SNI при выборе TLSA base domain. Поэтому pin хранится для пары имя-порт, а не для всех виртуальных хостов на IP-адресе или всех сервисов домена.

Клиент вправе сократить срок до локального максимума. RFC упоминает теоретическую атаку, где скомпрометированный сервер объявляет семь лет. Ограничение уменьшает зависимость, но слишком короткий максимум ослабляет защиту от downgrade. Эффективный срок формируется предложением сервера и политикой клиента.

Две независимые шкалы времени

Проверенный TLSA RRset можно использовать из кэша до истечения полученного TTL. Пока он свеж, клиенту не обязательно просить расширение в каждом соединении. После TTL прежние байты больше не являются актуальным доказательством, даже если pin ещё действует. Тогда нужна новая цепочка — через расширение или другой DNSSEC-проверенный канал.

TTL и окно RRSIG образуют короткие часы свежести. ExtSupportLifetime задаёт длинные часы доступности доказательства. RFC 9102 прямо отделяет их: pin не продлевает старую подпись, а обязывает сервер перестраивать цепочку в течение срока поддержки. Одна дата в мониторинге скрыла бы эту разницу.

Возобновление TLS-сессии даёт отдельный случай. При resumption сервер не отправляет dnssec_chain; в TLS 1.3 отсутствует и новое сообщение Certificate, к которому расширение прикрепляется. Если считать любое отсутствие downgrade-атакой, появятся ложные тревоги. Квитанция должна включать тип handshake, срок кэшированного TLSA, срок pin и фактически использованное доказательство.

Заверенное «нет» сильнее отсутствия ответа

Если владелец домена удалил TLSA, сервер может вернуть NSEC- или NSEC3-цепочку, заверяющую отсутствие записи для нужного имени и порта. Успешная проверка снимает pin. Его может снять и доказательство небезопасного делегирования. После этого локальная политика решает, допустим ли PKIX или соединение нужно закрыть.

Молчание такой силы не имеет. Когда pin активен, а свежего TLSA в кэше нет, клиент требует расширение с действительным TLSA или корректным доказательством отсутствия. Если сервер его не прислал, связь задерживается или прерывается до получения данных вне TLS; при неудаче соединение завершается. Иначе злоумышленник с приемлемым для PKIX сертификатом мог бы просто скрыть DANE-материал и вызвать незаметное ослабление проверки.

Поэтому требование расширения не означает вечного TLSA, DANE или DNSSEC. Оператор зоны может удалить TLSA и даже DS. Пока старый pin жив, серверу нужно лишь показывать новое состояние проверяемым способом. Положительный ответ может стать отрицательным; он не может бездоказательно исчезнуть.

Выключение начинается с нуля

Оператор сначала возвращает ExtSupportLifetime равный нулю в DANE-аутентифицированном handshake. Затем поддержка сохраняется, пока не истекут все ранее объявленные ненулевые сроки. Только после этого расширение отключается. TLSA или DNSSEC можно убрать раньше, но клиентам со старыми pins всё ещё требуется заверенное отсутствие.

В хостинге эта процедура пересекает границы компаний. Владелец домена управляет DNS и хочет сохранять возможность переезда; провайдер может управлять сертификатами, TLS-узлами и сборкой цепочки. RFC рекомендует ненулевые сроки только по взаимному согласию. Каждый узел кластера обязан знать максимальное ещё возможное обещание.

Доставленная сервером цепочка не назначает себе корень доверия. Клиент проверяет её от заранее настроенного DNSSEC trust anchor, отслеживает rollover и поддерживает достаточно точное время для RRSIG. Расширение меняет транспорт доказательства, но не источник его полномочий.

Экспериментальный статус RFC 9102 существенен. В TLS Working Group опасались, что pinning усложнит внедрение, и документ предлагает исследовать это в реальных реализациях. Изученные публичные источники не измеряют сегодняшнее распространение. Они зато фиксируют полезное правило: положительное утверждение, аутентифицированное отрицание и отсутствие ответа ведут к разным решениям.

Источники