Běžíme v testovacím provozu, prosíme o shovívavost a zpětnou vazbu.
Co je DANE a jak zabezpečuje přenos e-mailů

Co je DANE a jak zabezpečuje přenos e-mailů

· 9 min čtení · Tomas Hojgr · Zabezpečení e-mailu

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í

  1. Odesílající server chce doručit e-mail na doménu firma.cz.
  2. Dotáže se DNS na MX záznamy domény — dostane např. mx.firma.cz.
  3. 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.
  4. Dotáže se DNS na TLSA záznam _25._tcp.mx.firma.cz.
  5. Pokud TLSA záznam existuje a je podepsaný DNSSEC, server naváže STARTTLS spojení.
  6. Porovná certifikát přijímajícího serveru s otiskem v TLSA záznamu.
  7. 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.

Související články

MTA-STS a TLS-RPT — šifrování přenosu e-mailů

MTA-STS a TLS-RPT — šifrování přenosu e-mailů

MTA-STS vyžaduje šifrované TLS spojení pro příchozí e-maily a brání downgrade útokům. Zjistěte, jak MTA-STS a TLS-RPT nasadit krok za krokem.

· 9 min čtení
Co je DNSSEC a jak funguje

Co je DNSSEC a jak funguje

DNSSEC chrání DNS odpovědi kryptografickým podpisem a zabraňuje podvržení SPF, DKIM, DMARC i MX záznamů. Zjistěte, jak funguje a jak ho aktivovat.

· 7 min čtení
Jak ověřit, zda je doména chráněna DNSSEC

Jak ověřit, zda je doména chráněna DNSSEC

Jak ověřit DNSSEC vaší domény online nástrojem i příkazem dig. Interpretace výsledků, řešení nejčastějších problémů a dopad nefunkčního DNSSEC na e…

· 6 min čtení