DNS-based Authentication of Named Entities (DANE)

Šifrování SMTP komunikace

Šifrování komunikace mezi poštovními (SMTP) servery (MTA - Message Transfer Agent) je důležité pro ochranu před útoky typu Man-in-the-middle. Pro textový protokol SMTP můžeme využít rozšíření STARTTLS. Více v SMTP over TLS šifrování na MS Exchange a Cisco Email Security.

Neochrání to komunikaci, pokud ji útočník může po cestě měnit. Může například odstranit informaci o podpoře STARTTLS, a tedy se nezačne šifrovat (STARTTLS Downgrade Attack). Nebo může podvrhnout svůj certifikát a přesměrovat provoz na svůj server. SMTP server standardně nekontroluje platnost certifikátu ani použitou doménu.

Ne všechny SMTP servery podporují šifrování spojení, takže při zapnutí vyžadování STARTTLS bychom mohli přijít o nějaké zprávy. Situace se zlepšuje. Naše statistika za poslední měsíc ukazuje, že je šifrováno 91,5 % příchozích spojení a 98,2 % odchozích.

Princip DANE

Řešením je využití DNS-based Authentication of Named Entities (DANE), které informuje protistranu pomocí záznamu v DNS. Že náš poštovní server podporuje STARTTLS a jaký používá certifikát nebo od jaké CA. Podmínkou je, že záznamy v doméně jsou podepsány pomocí DNSSEC - Domain Name System Security Extensions, aby nemohl být záznam v DNS podvržen.

Při navazování SMTP spojení se ověří, zda pro doménu existuje TLSA záznam. Pokud ano, tak musí druhá strana uvést podporu STARTTLS a pro šifrování využít certifikát určený v TLSA záznamu. Při nesplnění podmínek se spojení nenaváže.

DANE je popsán v několika RFC, hlavně RFC 6698 (RFC 7218 doplňuje zkratky) a pro SMTP RFC 7672. Obecný popis nalezneme například v DANE for SMTP how-to.

Pro implementaci DANE musíme nejprve vytvořit odpovídající TLSA záznam nebo záznamy (pro MX doménová jména). Poté povolit DANE ověřování na odesílajících poštovních serverech (bráně). Musíme mít také zapnuté TLS. Při povoleném DANE není problém, pokud cílový poštovní server (doména) DANE nepodporuje. Funguje se standardně pomocí STARTTLS nebo čistého textu.

Pozn.: DANE můžeme použít i s jiným protokolem, například HTTPS. Dalo by se tak řešit důvěryhodné použití certifikátu od nedůvěryhodné autority.

TLSA záznam

DANE přidává do DNS nový typ záznamu (Resource Record) TLSA (Transport Layer Security Association, typ 52). Doménové jméno záznamu se sestaví z portu, protokolu a FQDN _<port>._<ipprotokol>.<domena>. Tedy pro SMTP server, který běží na adrese mail.firma.cz, je záznam _25._tcp.mail.firma.cz.

Pro každý server (existující MX záznam na doméně) vytváříme TLSA záznam. Záznamy se vytváří na MX doméně. Pokud tedy poštovní server má adresu na jiné doméně, než je doména, pro kterou přijímáme poštu, tak musíme vytvořit záznam zde. Doména musí být podepsaná pomocí DNSSEC.

TLSA záznam obsahuje v části RDATA čtyři položky:

• Certificate Usage - určuje, jak (jaký) ověřovat certifikát
  • 0 - certifikát CA, od které má služba svůj certifikát, certifikační cesta musí být validní, musíme důvěřovat kořenovému certifikátu (PKIX-TA: CA constraint)
  • 1 - certifikát služby (EE - End Entity), certifikační cesta musí být validní, musíme důvěřovat kořenovému certifikátu (PKIX-EE: Service certificate constraint)
  • 2 - certifikát CA, který ověří certifikát služby, nemusí být důvěryhodný, můžeme použít pro vlastní CA (DANE-TA: Trust Anchor Assertion)
  • 3 - certifikát služby (EE - End Entity), které je self-signed, neověřuje se důvěryhodnost autority (DANE-EE: Domain issued certificate)
• Selector - určuje, která část certifikátu se ověřuje s uvedenými daty (Certificate Association Data)
  • 0 - celý certifikát (Cert)
  • 1 - pouze veřejný klíč certifikátu, což je většinou dostatečné (SPKI)
• Matching Type - určuje, jaká data se použijí pro porovnání (Certificate Association Data)
  • 0 - celý obsah (přesná shoda) (Full)
  • 1 - SHA-256 hash (SHA-256)
  • 2 - SHA-512 hash (SHA-512)
• Certificate Association Data - vlastní binární data, která se porovnávají podle uvedených nastavení s poskytnutým certifikátem

RFC 7672 - DANE Authentication doporučuje pro SMTP používat pouze určité varianty prvních tří položek a vysvětluje proč.

Primárně jde o variantu DANE-EE(3) SPKI(1) SHA2-256(1). To znamená, že vezmeme veřejný klíč certifikátu, použitého na poštovním serveru, a z něj vypočítáme SHA-256 hash, který uložíme do Certificate Association Data. Při kontrole se vezme veřejný klíč, poslaný pro navázání TLS, vypočítá se z něj SHA-256 hash a porovná s hodnotou v TLSA záznamu. Nekontroluje se, zda je certifikát vystaven od důvěryhodné autority.

Případně můžeme přidat jako záložní DANE-TA(2) Cert(0) SHA2-256(1) (v praxi se častěji uvádí DANE-TA(2) SPKI(1) SHA2-256(1)).

Příklad záznamu

_25._tcp.mail.nic.cz. 1800 IN TLSA 3 1 1 4F9736249AB586F37FC110856F6A3358ADADBF99DB03628866466194F5BB2E09

Do TLSA záznamu můžeme použít certifikát autority, takže pokud budeme měnit certifikát od stejné CA, tak nemusíme měnit záznam. I když použijeme koncový certifikát, tak se při vystavení následného nemusí změnit veřejný klíč. Pokud záznam potřebujeme vyměnit, tak se vytvoří druhý záznam, po dobu TTL existují oba a pak se starší smaže. TTL pro TLSA záznam by nemělo být větší než 1 hodina (3600 vteřin).

Pro vytvoření TLSA záznamu můžeme použít TLSA Record Generator. Volba Usage určuje pouze položku v TLSA záznamu, ale hash (nebo binární hodnota) se vypočítá z vloženého certifikátu ve formátu Base-64 encoded X.509. Pokud chceme použít certifikát CA (Usage 0 nebo 2), tak musíme vložit ten.

Microsoft DNS Server a TLSA

DNS Server role Windows Server podporuje TLSA záznam od Windows Server 2016 (také přidává podporu pro neznámé záznamy, takže můžeme vytvořit typ záznamu, který DNS server nezná, pomocí binárního formátu). Zmínka je v What's New in DNS Server in Windows Server.

Záznam ovšem nevytvoříme pomocí GUI DNS Manager, ale pouze PowerShell cmdletem Add-DnsServerResourceRecord.

Příklad vytvoření TLSA záznamu

Add-DnsServerResourceRecord -TLSA -CertificateUsage DomainIssuedCertificate -MatchingType Sha256Hash -Selector SubjectPublicKeyInfo -CertificateAssociationData "99b38700b469e1379e18788ea9f91307823142265d7294ab4fd1e9a7383d3316" -ZoneName firma.cz -Name _25._tcp.mail

Add-DnsServerResourceRecord -TLSA -CertificateUsage TrustAnchorAssertion -MatchingType Sha256Hash -Selector SubjectPublicKeyInfo -CertificateAssociationData "e3c8573709f795a240cacac8069ace72ec146f4f7b04634bedef8c54ced1722b" -ZoneName firma.cz -Name _25._tcp.mail

Zobrazení záznamu

Get-DnsServerResourceRecord -ZoneName firma.cz -Name _25._tcp.mail -RRType TLSA

$r = Get-DnsServerResourceRecord -ZoneName firma.cz -Name _25._tcp.mail -RRType TLSA
$r.RecordData | select *

Testování DANE a reporty na doméně

Můžeme použít různé online nástroje pro otestování, zda naše poštovní doména správně podporuje DANE.

• My Email Communications Security Assessment - zadáme emailovou adresu, na kterou dorazí zpráva (pokud ji nezablokuje AntiSpam filtr). Na zprávu odpovíme, není potřeba něco psát, ale musí se zachovat předmět. Vytvoří se report, jehož ID přijde do emailu.
• Internet.nl - stačí zadat emailovou doménu a můžeme rozsáhleji otestovat zabezpečení emailové komunikace
• Huque.COM - obsahuje různé nástroje a generátor TLSA, například Check a DANE SMTP Service

RFC 8460 popisuje SMTP TLS Reporting (TLS-RPT). Podobně jako pro DMARC se vytvoří speciální DNS TXT záznam s adresou, kam se mají posílat reporty. Různé online služby nám mohou reporty zobrazovat, například DMARCian - What is SMTP TLS Reporting?.

Cisco Email Security (ESA)

Poštovní bezpečnostní brána Cisco Email Security podporuje DANE ověřování. Popis Cisco ESA - DNS-based Authentication of Named Entities, DANE for Email Security Appliance.

Povolení DANE podpory při odesílání pošty

• Mail Policies - Destination Controls

Nastavení se provádí na stejném místě, kde jsme povolili TLS při odesílání pošty. Upravíme nebo vytvoříme profil pro cílovou doménu nebo můžeme využít Default pro všechny. TLS musí být zapnuté, abychom mohli nastavit DANE. Musíme také využívat DNSSEC capable DNS Resolver (pokud máme nastavené Root servery, tak je v pořádku). V položce DANE Support vybíráme

• None - DANE vypnuté
• Opportunistic - pokud vzdálená strana nepodporuje DANE, tak se použije oportunistické TLS (STARTTLS případně nešifrované spojení), pokud DANE podporuje, tak se využije
• Mandatory - DANE je povinné, pokud jej vzdálená strana nepodporuje, tak se spojení nenaváže

Monitorování a kontroly

• Monitor - TLS Connections

U odchozích spojení vidíme statistiky o použití šifrování a také DANE Success a DANE Failure. V detailech máme údaje pro jednotlivé domény. Ale DANE Failure se patrně bere i pro zprávy, kde doména DANE nepodporuje (což mi nepřijde správné) a celkové hodnoty v tabulce mi přijdou podivné. Nenašel jsem žádné vysvětlení jednotlivých položek.

• Monitor - Message Tracking

Vyhledávání zpráv v logu umožňuje pod Advanced vybrat událost DANE Failure. V detailech vidíme zprávu, pokud DANE selhalo (při úspěchu zde nic není). Příklad dvou chyb:

MID 5290305 (DCID 0) DANE failed for cisco.com. Reason: A record INSECURE.
MID 5262944 (DCID 664172) DANE failed for seznam.cz. Reason: No TLSA Record. 

• System Administration - Log Subscriptions

Pro ještě detailnější informace můžeme stáhnout a prohlédnout mail_logs.

DANE Failure

Jak jsem zmínil, tak mi přijde, že v TLS Connections jsou divné hodnoty pro DANE Failure. Mám pod 5 % DANE Success a podobně DANE Failure (okolo 48 %) a Successful - Preferred (okolo 47 %). Připadá mi, že většinou se započítá i DANE Failure i Successful - Preferred.

V Message Tracking mi připadá, že pouze případy DANE Success nemají v logu žádnou DANE informaci. Všechny ostatní zalogují jedenkrát DANE failed, ale zpráva je hned doručena.

Message 5618574 queued for delivery.
MID 5618574 (DCID 876522) DANE failed for seznam.cz. Reason: No TLSA Record.
Delivery connection (DCID 876522) successfully accepted TLS protocol TLSv1.2 cipher ECDHE-RSA-AES256-GCM-SHA384 None.

V praxi nastávají případy, kdy cílový server dočasně nepřijímá zprávy. V té chvíli se opakovaně loguje DANE failed a odesílá se email alert správci (pokud je nastaveno) DANE verification failed.

Pokud si v Message Tracking vyfiltrujeme událost DANE Failure, tak to vypadá, že se nabízí skoro všechny odchozí zprávy. Když se podíváme do mail_logs, tak vidíme, že po chybě dojde k přepadu na normální TLS.

MID 5520505 DCID 818685 DANE failed for the domain seznam.cz: No TLSA Record
DANE fall back for seznam.cz in the Opportunistic mode

Vytvořil jsem na tuto situaci ticket na podporu Cisco TAC. Technik rychle uznal, že jde o chybu a založil bug CSCwa01524. Tak snad bude opraveno.

Ověření DANE pro doménu v ESA CLI

Pomocí CLI můžeme provést komplexní ověření, že určitá doména podporuje DANE a připojení je v pořádku. Také ověříme (dotazem na známou doménu), že máme v pořádku nastavené DNS (podporuje DNSSEC).

ESA.firma.cz> daneverify ietf.org

SECURE MX record(mail.ietf.org) found for ietf.org
SECURE A record (4.31.198.44) found for MX(mail.ietf.org) in ietf.org
Connecting to 4.31.198.44 on port 25.
Connected to 4.31.198.44 from interface 192.168.1.1.
SECURE TLSA record found for MX(mail.ietf.org) in ietf.org
Checking TLS connection.
TLS connection established: protocol TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384.
Certificate verification successful
TLS connection succeeded ietf.org.
DANE SUCCESS for ietf.org
DANE verification completed.

Pokud používáme DNS server, který nepodporuje DNSSEC, tak se má zobrazit.

ESA.firma.cz> daneverify ietf.org

BOGUS MX record found for ietf.org
DANE FAILED for ietf.org
DANE verification completed.

Příklad, pokud doména není podepsaná nebo nepublikovala TLSA záznam.

ESA.firma.cz> daneverify cisco.com

INSECURE MX record(alln-mx-01.cisco.com) found for cisco.com
INSECURE MX record(alln-mx-01.cisco.com) found. The command will still proceed.
INSECURE A record (173.37.147.230) found for MX(alln-mx-01.cisco.com) in cisco.com
Trying next MX record in cisco.com
INSECURE MX record(rcdn-mx-01.cisco.com) found for cisco.com
INSECURE MX record(rcdn-mx-01.cisco.com) found. The command will still proceed.
INSECURE A record (72.163.7.166) found for MX(rcdn-mx-01.cisco.com) in cisco.com
Trying next MX record in cisco.com
INSECURE MX record(aer-mx-01.cisco.com) found for cisco.com
INSECURE MX record(aer-mx-01.cisco.com) found. The command will still proceed.
INSECURE A record (173.38.212.150) found for MX(aer-mx-01.cisco.com) in cisco.com
DANE FAILED for cisco.com
DANE verification completed.

ESA.firma.cz> daneverify seznam.cz

SECURE MX record(mx1.seznam.cz) found for seznam.cz
SECURE A record (77.75.78.42) found for MX(mx1.seznam.cz) in seznam.cz
Connecting to 77.75.78.42 on port 25.
Connected to 77.75.78.42 from interface 192.168.50.50.
No TLSA record found for MX(mx1.seznam.cz) in seznam.cz
Trying next A record (77.75.76.42) for MX(mx1.seznam.cz) in seznam.cz
SECURE A record (77.75.76.42) found for MX(mx1.seznam.cz) in seznam.cz
Connecting to 77.75.76.42 on port 25.
Connected to 77.75.76.42 from interface 192.168.50.50.
No TLSA record found for MX(mx1.seznam.cz) in seznam.cz
Trying next MX record in seznam.cz
SECURE MX record(mx2.seznam.cz) found for seznam.cz
SECURE A record (77.75.76.32) found for MX(mx2.seznam.cz) in seznam.cz
Connecting to 77.75.76.32 on port 25.
Connected to 77.75.76.32 from interface 192.168.50.50.
No TLSA record found for MX(mx2.seznam.cz) in seznam.cz
Trying next A record (77.75.78.32) for MX(mx2.seznam.cz) in seznam.cz
SECURE A record (77.75.78.32) found for MX(mx2.seznam.cz) in seznam.cz
Connecting to 77.75.78.32 on port 25.
Connected to 77.75.78.32 from interface 192.168.50.50.
No TLSA record found for MX(mx2.seznam.cz) in seznam.cz
DANE FAILED for seznam.cz
DANE verification completed.