Что такое DANE и какую проблему решает TLSA
Обычный TLS полагается на удостоверяющие центры: браузер доверяет сертификату, если его подписал признанный CA. Если скомпрометирован хоть один CA из сотен встроенных в систему, злоумышленник может выпустить сертификат на чужой домен. DANE (DNS-Based Authentication of Named Entities, RFC 6698) решает эту проблему иначе: владелец домена сам публикует в DNS-зоне, какой сертификат или ключ считается легитимным для его сервиса, а зона защищена DNSSEC-подписью.
Запись, которая хранит эту привязку, называется TLSA. Она отвечает на вопрос «каким сертификатам можно доверять на этом порту этого хоста», независимо от того, что скажет цепочка CA.
Синтаксис TLSA-записи: usage, selector, matching type
Имя записи строится как _порт._протокол.хост, а значение — из трёх чисел и хэша:
_443._tcp.example.com. IN TLSA 3 1 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971Первое число (usage) задаёт модель доверия: 0 — ограничение на CA (PKIX-TA), 1 — ограничение на конечный сертификат при сохранении проверки через публичный CA (PKIX-EE), 2 — собственный корневой CA вместо публичного (DANE-TA), 3 — прямая привязка к конкретному сертификату без участия CA вообще (DANE-EE), самый частый вариант для Let's Encrypt. Selector определяет, что именно хэшируется: 0 — весь сертификат, 1 — только открытый ключ (SubjectPublicKeyInfo), что удобно при обновлении сертификата с тем же ключом. Matching type: 0 — сертификат целиком, 1 — SHA-256, 2 — SHA-512.
Как сгенерировать TLSA-запись для своего сертификата
Хэш открытого ключа по SHA-256 получают через openssl:
openssl x509 -in cert.pem -noout -pubkey \n | openssl pkey -pubin -outform DER \n | openssl dgst -sha256 -binary | xxd -p -c 256Полученную строку подставляют четвёртым полем в запись TLSA с usage 3 и selector 1. При выпуске сертификата через ACME-DNS-challenge, описанный в статье про DNS-challenge для SSL, хэш стоит пересчитывать при каждой смене ключа, а не только сертификата.
DANE для почты: применение в SMTP
Веб-браузеры DANE для HTTPS практически не поддерживают: Chrome убрал такую проверку ещё в 2015 году, Firefox её так и не включил по умолчанию. Зато DANE активно используется для защиты почтового трафика: Postfix с параметром smtp_tls_security_level = dane проверяет TLSA-запись на MX-хосте получателя перед отправкой письма и отказывается слать её открытым текстом, если запись есть, а сертификат ей не соответствует. Настройка обычной защиты почты на уровне SPF, DKIM и DMARC описана в статье про защиту email, а DANE дополняет её на транспортном уровне, а не на уровне содержимого письма.
Как проверить TLSA-запись
Запись проверяется через dig, а соответствие сертификату — через сверку хэша вручную:
dig TLSA _443._tcp.example.com +shortЕсли утилита dnsviz или онлайн-чекер сообщает, что DNSSEC для зоны не проходит проверку, TLSA-запись бесполезна: резолвер обязан доверять именно подписи DNSSEC, иначе злоумышленник может подменить саму TLSA-запись так же легко, как и сертификат. Способы диагностики зоны собраны в статье про dig, dnsviz и типовые ошибки.
Ограничения DANE: обязательный DNSSEC и поддержка софта
- DANE работает только поверх подписанной DNSSEC-зоны — без неё запись TLSA не даёт защиты, см. статью про настройку DNSSEC.
- Браузеры не проверяют TLSA для HTTPS-соединений, поэтому для веб-сайтов DANE носит вспомогательный характер.
- Почтовые серверы, не поддерживающие DANE, просто игнорируют запись и продолжают полагаться на CA.
- При ротации сертификата важно заранее опубликовать TLSA для нового ключа, иначе строгие DANE-клиенты откажутся соединяться в момент смены.
Итог: чек-лист внедрения TLSA
Перед включением DANE убедитесь: зона подписана DNSSEC и проходит валидацию, TLSA-запись создана с usage 3 и selector 1 для собственных сертификатов, хэш пересчитан под текущий ключ, а почтовый сервер настроен на строгую проверку DANE только после того, как запись опубликована и проверена внешним резолвером.