Co je DANE a jak zabezpečuje přenos e-mailů
Co je DANE
DANE (DNS-based Authentication of Named Entities) je bezpečnostní mechanismus, který umožňuje publikovat informace o TLS certifikátech přímo v DNS záznamech. Definuje ho RFC 6698, rozšířený o provozní pokyny v RFC 7671.
DANE řeší základní problém tradičního modelu certifikačních autorit (CA): jakákoli CA může vydat certifikát pro jakoukoli doménu. Vlastník domény nemá kontrolu nad tím, která CA vydá certifikát jeho jménem. DANE tuto kontrolu vrací vlastníkovi domény — ten přímo v DNS deklaruje, jaký certifikát je pro jeho služby platný.
Aby DANE fungoval, doména musí mít aktivní DNSSEC. Bez kryptograficky podepsaných DNS odpovědí by útočník mohl podvrhnout TLSA záznam stejně snadno jako samotný certifikát.
Jak DANE funguje
DANE zavádí nový typ DNS záznamu — TLSA (Transport Layer Security Authentication). Tento záznam obsahuje otisk (hash) TLS certifikátu nebo veřejného klíče serveru. Klient, který se připojuje k serveru, si z DNS stáhne TLSA záznam a porovná ho s certifikátem, který server předloží při TLS handshake.
Struktura TLSA záznamu
TLSA záznam se publikuje na specifickém DNS jméně, které kombinuje port, protokol a doménu:
_25._tcp.mx.firma.cz IN TLSA 3 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a8d0bdf6d27c4b3b7e6b32
Záznam má čtyři parametry:
| Parametr | Název | Hodnoty | Význam |
|---|---|---|---|
| Použití (Usage) | Certificate Usage | 0–3 | Jak se certifikát ověřuje |
| Selektor (Selector) | Selector | 0–1 | Která část certifikátu se porovnává |
| Typ shody (Matching Type) | Matching Type | 0–2 | Jak se porovnání provádí |
| Data (Certificate Association Data) | — | hex řetězec | Otisk certifikátu nebo klíče |
Režimy použití (Certificate Usage)
| Hodnota | Název | Popis |
|---|---|---|
| 0 | PKIX-TA | Certifikát musí být podepsaný uvedenou CA a projít standardní PKIX validací |
| 1 | PKIX-EE | Certifikát serveru musí odpovídat otisku a projít PKIX validací |
| 2 | DANE-TA | Uvedený trust anchor musí být v řetězci certifikátů serveru, PKIX validace se neprovádí |
| 3 | DANE-EE | Certifikát serveru musí přímo odpovídat otisku, bez PKIX validace |
Pro e-mailové servery se v praxi používají hodnoty 2 (DANE-TA) a 3 (DANE-EE). Hodnota 3 je nejčastější — umožňuje použít i self-signed certifikáty, pokud jejich otisk odpovídá TLSA záznamu.
Selektor a typ shody
| Selektor | Význam |
|---|---|
| 0 | Celý certifikát (Full certificate) |
| 1 | Pouze veřejný klíč (SubjectPublicKeyInfo) |
| Typ shody | Význam |
|---|---|
| 0 | Přesná shoda (celý certifikát/klíč) |
| 1 | SHA-256 hash |
| 2 | SHA-512 hash |
Nejběžnější kombinace pro SMTP je 3 1 1 — DANE-EE, veřejný klíč, SHA-256 hash. Tato varianta je odolná vůči výměně certifikátu, pokud zůstane zachován stejný klíč (např. při obnově certifikátu u Let's Encrypt).
DANE pro SMTP
Specifické použití DANE pro e-mailovou komunikaci definuje RFC 7672 (SMTP Security via Opportunistic DANE TLS). Na rozdíl od obecného DANE přidává pravidla pro to, jak odesílající mailový server ověřuje přijímající server.
Postup ověření
- Odesílající server chce doručit e-mail na doménu
firma.cz. - Dotáže se DNS na MX záznamy domény — dostane např.
mx.firma.cz. - Ověří, zda je odpověď na MX dotaz podepsaná DNSSEC. Pokud ne, TLSA záznamy se nevyhledávají a DANE se nepoužije — e-mail se doručí standardním oportunistickým STARTTLS.
- Dotáže se DNS na TLSA záznam
_25._tcp.mx.firma.cz. - Pokud TLSA záznam existuje a je podepsaný DNSSEC, server naváže STARTTLS spojení.
- Porovná certifikát přijímajícího serveru s otiskem v TLSA záznamu.
- Pokud certifikát odpovídá, e-mail se doručí šifrovaně. Pokud ne, server zkusí další MX záznamy. Pokud žádný neprojde ověřením, doručení se odloží (dočasné selhání s opakovanými pokusy).
Klíčový rozdíl oproti oportunistickému STARTTLS: pokud přijímající doména publikuje TLSA záznam, odesílající server musí použít TLS a musí ověřit certifikát. Žádný downgrade na nešifrované spojení není přípustný.
Ochrana proti útokům
DANE pro SMTP chrání proti dvěma hlavním hrozbám:
- Downgrade útok: útočník potlačí STARTTLS odpověď a e-mail se přenese nešifrovaně. DANE toto zabraňuje — pokud TLSA záznam existuje, TLS je povinné.
- Man-in-the-Middle (MITM) útok: útočník předloží vlastní certifikát a odposlouchává komunikaci. DANE toto znemožní — certifikát musí odpovídat otisku v DNS, který je chráněný DNSSEC.
DANE vs. MTA-STS
MTA-STS (RFC 8461) řeší stejný problém jako DANE — vynucení šifrovaného přenosu e-mailů. Oba protokoly se liší v přístupu.
| Vlastnost | DANE | MTA-STS |
|---|---|---|
| Distribuce politiky | DNS (TLSA záznamy) | HTTPS (webový server) |
| Závislost na DNSSEC | Ano (povinné) | Ne |
| Ověření certifikátu | Přes TLSA záznam v DNS | Přes CA (certifikační autoritu) |
| Odolnost proti CA kompromitaci | Ano | Ne |
| Složitost nasazení | Vyšší (vyžaduje DNSSEC) | Střední (DNS + HTTPS) |
| Podpora na straně odesílatele | Postfix, Exim | Google, Microsoft, Yahoo |
DANE je technicky robustnější — ověřuje certifikát přímo přes DNS a nezávisí na důvěryhodnosti certifikačních autorit. MTA-STS je pragmatičtější — nevyžaduje DNSSEC, a proto ho může nasadit prakticky kdokoli.
Oba protokoly se vzájemně nevylučují. Odesílající server, který podporuje obojí, preferuje DANE (pokud je k dispozici DNSSEC a TLSA záznam) a MTA-STS použije jako fallback. Podrobný návod k nasazení MTA-STS najdete v článku MTA-STS a TLS-RPT — šifrování přenosu e-mailů.
Jak nasadit DANE pro e-mailový server
Předpoklady
- Doména má aktivní DNSSEC s funkčním řetězem důvěry
- Mailový server podporuje TLS (STARTTLS)
- DNS hosting umožňuje publikovat TLSA záznamy
1. Ověřte DNSSEC
Zkontrolujte svou doménu — analyzér ověří stav DNSSEC. Alternativně v terminálu:
dig firma.cz DNSKEY +short
Pokud příkaz nevrátí žádné klíče, nejprve aktivujte DNSSEC.
2. Získejte otisk certifikátu
Pro DANE-EE (usage=3) s SHA-256 hashem veřejného klíče (selector=1, matching-type=1):
openssl s_client -starttls smtp -connect mx.firma.cz:25 < /dev/null 2>/dev/null \
| openssl x509 -noout -pubkey \
| openssl pkey -pubin -outform DER \
| openssl dgst -sha256 -hex
Výstup obsahuje prefix (stdin)= následovaný hexadecimálním hashem. Zkopírujte pouze hex hodnotu — tu použijete v TLSA záznamu.
3. Publikujte TLSA záznam
Přidejte DNS záznam pro každý MX server:
_25._tcp.mx.firma.cz IN TLSA 3 1 1 b2a7d4f1e8c3960573bfa21de8045c9ab0e1f7d3c8264a95e0d4127bf3c68e51
4. Ověřte konfiguraci
Otestujte TLSA záznam přes DNS lookup nebo v terminálu:
dig _25._tcp.mx.firma.cz TLSA +short
5. Aktivujte TLS-RPT
Pro přehled o stavu TLS spojení přidejte TLS-RPT záznam. Odesílající servery vám budou posílat reporty o úspěšných i neúspěšných TLS spojeních:
_smtp._tls.firma.cz IN TXT "v=TLSRPTv1; rua=mailto:firma.cz@rua.spfmonitor.com"
Správa TLSA záznamů při obnově certifikátu
Nejčastější provozní problém DANE je nesoulad TLSA záznamu s certifikátem po jeho obnově. Pokud server předloží nový certifikát, ale TLSA záznam stále odkazuje na starý, odesílající servery s DANE odmítnou doručit e-mail.
Strategie pro bezproblémovou obnovu
Varianta A — Zachovat klíč: Při obnově certifikátu použijte stejný soukromý klíč (CSR se stejným klíčem). Pokud TLSA záznam odkazuje na veřejný klíč (selector=1), zůstane platný i po výměně certifikátu. Toto je doporučený postup pro DANE s parametry 3 1 1.
Varianta B — Předpublikovat nový TLSA: Před výměnou certifikátu přidejte druhý TLSA záznam s otiskem nového certifikátu/klíče. Po výměně certifikátu odstraňte starý TLSA záznam. V DNS pak dočasně existují dva TLSA záznamy současně:
_25._tcp.mx.firma.cz IN TLSA 3 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a8d0bdf6d27c4b3b7e6b32
_25._tcp.mx.firma.cz IN TLSA 3 1 1 4f7c91e85a14d3a9bc831f2c05e47190dae1bc83a7b6f4e028350712b4c9f3a1
U varianty B počítejte s dobou propagace DNS (TTL) — nový záznam musí být rozšířený dříve, než proběhne výměna certifikátu.
Kdo DANE podporuje
Na straně příjemce (vaše doména)
DANE můžete nasadit na jakékoli doméně, pokud splňuje předpoklady: DNSSEC, TLS na mailserveru a TLSA záznamy v DNS. Nasazení závisí na vašem DNS poskytovateli — ne všichni umožňují publikovat TLSA záznamy.
Na straně odesílatele (kdo ověřuje váš TLSA záznam)
- Postfix — nativní podpora DANE od verze 2.11 (2014)
- Exim — podpora DANE od verze 4.91
- Google (Gmail) — DANE nepodporuje, používá MTA-STS
Na straně příjemce (kdo publikuje TLSA záznamy)
- Microsoft Exchange Online — podpora příchozího DANE od roku 2024 (domény hostované na Exchange Online mohou publikovat TLSA záznamy)
- Jakýkoli mailový server s TLS a DNSSEC na doméně
DANE je rozšířenější v Evropě, zejména v Německu, Nizozemsku a České republice, kde je DNSSEC adopce vysoká. Google jako největší odesílatel e-mailů zatím spoléhá výhradně na MTA-STS.
DANE jako součást zabezpečení domény
DANE doplňuje trojici SPF, DKIM a DMARC o vrstvu zabezpečení přenosu. Zatímco autentizační protokoly ověřují, kdo e-mail poslal, DANE zajišťuje, že obsah zprávy nikdo nepřečte ani nezmění cestou k příjemci — a že příjemce komunikuje se skutečným serverem, ne s podvrhnutým.
| Vrstva | Protokol | Co chrání |
|---|---|---|
| Autentizace odesílatele | SPF, DKIM, DMARC | Kdo e-mail poslal |
| Šifrování přenosu | DANE, MTA-STS | Jak se e-mail přenáší mezi servery |
| Integrita DNS | DNSSEC | Pravost DNS záznamů, na kterých vše ostatní stojí |
Zkontrolujte zabezpečení vaší domény — analyzér ověří SPF, DKIM, DMARC i DNSSEC najednou a ukáže, kde jsou mezery.