DANE
DANE (DNS-Based Authentication of Named Entities, RFC 6698) — способ прикрепить TLS-сертификат или публичный ключ прямо к DNS-записи через DNSSEC. Клиент проверяет: «этот cert от этого сайта? — DNS говорит да, вот подтверждение».
Идея: не полагаться на список из 100+ доверенных CA, где любой скомпрометированный CA может выпустить серт на твой домен. DANE говорит: «CA должен быть указан в моей DNS-записи».
TLSA-запись
Формат: _port._proto.host TLSA usage selector matching data
_443._tcp.example.com. IN TLSA 3 1 1 abcdef012345...Четыре числа:
| Поле | Значения | Смысл |
|---|---|---|
| usage | 0/1/2/3 | 0 CA-constraint · 1 Service-cert · 2 Trust-anchor · 3 Domain-issued (самоподписан) |
| selector | 0/1 | 0 полный cert · 1 SPKI (только публичный ключ) |
| matching | 0/1/2 | 0 exact · 1 SHA-256 · 2 SHA-512 |
| data | hex | сам отпечаток/ключ |
Стандартная комбинация: 3 1 1 — самоподписанный, SPKI, SHA-256.
Зачем нужен DNSSEC
Без DNSSEC DANE бесполезен: атакующий подделает DNS-ответ и подставит свой TLSA. Поэтому DANE = DNSSEC-signed зона + TLSA record. Если DNSSEC у тебя не настроен — DANE тоже не будет работать.
Где реально используется
- SMTP + STARTTLS — самый успешный кейс. DANE в почте прижилась (Google, Comcast, немецкие провайдеры). Решает MITM-даунгрейд STARTTLS. См. SMTP.
- HTTPS для браузеров — не прижился. Chrome/Firefox не поддерживают TLSA. Причина: производительность (DNSSEC-lookup медленный), низкое распространение DNSSEC.
- XMPP, IRC, Tor onion v3 — используют DANE-подобные конструкции.
Плюсы
- Владелец домена сам решает какой cert легитимный, а не «любой из 100 CA».
- Не зависит от Certificate Transparency-мониторинга.
- Работает и для самоподписанных сертов.
Минусы
- Требует DNSSEC (которого нет у большинства зон).
- Клиенты не поддерживают (браузеры игнорируют TLSA).
- Кэширование DNSSEC-ответов даёт лаги при ротации серта.