Кратко

  • RRset TLSA становится доказательством DANE только вместе с результатом DNSSEC: небезопасные или неопределённые данные непригодны, а статус bogus требует отказа.
  • Использование сертификата, селектор и тип сопоставления определяют предмет сравнения и правила проверки.
  • Безопасно опубликованная ассоциация всё равно может быть непригодной или не совпасть с сертификатом либо ключом, фактически переданным сервером.
  • В журнале нужно раздельно хранить состояния опубликовано, безопасно, пригодно, совпало и принято.

Представим, что сертификат сервиса успешно заменён в полночь. Новая цепочка работает на всех серверах, но часть клиентов сохранила в кеше ассоциацию TLSA со старым открытым ключом. В DNS есть TLSA, HTTPS-мониторинг зелёный, заявка закрыта. Эти клиенты всё равно прерывают соединение: аутентифицированная ассоциация больше не совпадает с переданным ключом.

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

Публикация — лишь первое состояние

RFC 6698 задаёт TLSA через использование сертификата, селектор, тип сопоставления и данные ассоциации. Параметры определяют, ограничивает ли запись путь публичного центра сертификации, предоставляет ли якорь доверия или указывает конечный сертификат домена; сравнивается ли весь сертификат или SubjectPublicKeyInfo; применяются ли точные данные, SHA-256 или SHA-512.

Имя запроса зависит также от порта, транспорта и базового домена TLSA. Запрос другого сервиса или остановка на небезопасном псевдониме может дать правильные DNS-байты для неправильного решения. RFC 7671 включает безопасно проверенное раскрытие CNAME в определение базового домена. Реестр одного RDATA теряет идентичность сервиса.

DNSSEC определяет пригодность ассоциации

RFC 6698 делает состояние DNSSEC решающим. Безопасный RRset TLSA должен использоваться, если локальная политика не запрещает конкретную ассоциацию. Ответ bogus должен предотвратить или прервать TLS. Небезопасный или неопределённый RRset не применяется для TLSA-аутентификации.

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

Если пригодных ассоциаций нет, приложение обрабатывает TLS обычным способом без TLSA. Если они есть, клиент выполняет требуемые сравнения и должен найти совпадение. Поэтому клиенты с разными возможностями или политиками могут по-разному обработать один опубликованный RRset.

Переданный сертификат должен удовлетворять записи

Использование меняет смысл совпадения. Некоторые варианты сохраняют проверку пути PKIX; варианты DANE могут задавать якорь на основе DNSSEC или напрямую связывать конечный объект. Селектор определяет, сохранится ли совпадение при обновлении сертификата с тем же ключом или важен каждый байт сертификата.

RFC 7671 добавляет операционные требования. DANE-TA требует достаточного материала цепочки, а в определённых случаях — сертификата якоря доверия от сервера. DANE-EE с селектором SPKI переживает обновление при неизменном ключе, но не другой ключ. Гибкость дайджестов применяется после отбрасывания повреждённых и неподдерживаемых ассоциаций.

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

Время тоже разделяет публикацию и принятие

TTL TLSA, срок RRSIG, возраст кеша и порядок развёртывания ограничивают наблюдение. RFC 7671 предупреждает: устаревшая ассоциация в кеше может вызвать сбой после неожиданной смены сертификата или цепочки. Долгая подпись продлевает и период воспроизведения старых подписанных DNS-данных.

Ротация должна согласовать старые и новые ассоциации, авторитетную публикацию, вторичные серверы, кеши валидаторов, развёртывание сервиса и откат. Новый RRset на одном авторитетном сервере не доказывает, какую связь видят реальные клиенты.