Що таке 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 лише після того, як запис опубліковано й перевірено зовнішнім резолвером.