Blog
Kryptografie v protokolech pro překlad jmenných názvů
K základním službám potřebným pro provoz internetu patří protokol DNS (Domain Name System). Slouží pro rozlišení doménových názvů a jejich překlad na IP adresy, případně pro překlad IP adres zpět na doménové názvy. Bez tohoto protokolu by dnešní internet nemohl pracovat tak, jak jsme zvyklí.
Problémy s bezpečností
Základním bezpečnostním problémem protokolu DNS je nulová ochrana. Jeho obsah nemá žádnou ochranu důvěrnosti (confidentiality), integrity, ani není možné zaručit autenticitu. V případě dotazu je textová komunikace nejnom viditelná přímo v paketech, ale neobsahuje žádnou kontrolu, zda nedošlo ke změně obsahu. Co je horší, pro tyto dotazy se používá protokol UDP a zde platí, kdo dřív přijde, ten dřív mele. Tedy když někdo odpoví, byt s podvrženou IP adresou, automaticky se tato odpověď akceptuje. To přináší spoustu zajímavých možností pro útočníky a z hlediska bezpečnosti těžké spaní pro správce.
Komunikace používaná mezi různými DNS servery
| Protokol | Technologie | Popis |
| udp/53 | DNS/DNSSEC | Standardní dotazy |
| tcp/53 | DNS/DNSSEC | Přenos zóny (AXFR/IXFR), dotazy přes TCP, fallback na TCP při velkých odpovědích |
| tcp/853 | DoT (DNS over TLS) | Standardní port pro komunikaci |
| tcp/443 | DoH (DNS over HTTPS) | Standardní port pro komunikaci |
| tcp/853 | DoQ (DNS over QUIC) | Standardní port pro komunikaci |
| udp/5353 | mDNS (Multicast DNS) | Standardní port pro komunikaci, pouze lokální síť |
DNS tu s námi je od roku 1984, ale nehodilo se pro všechny účely. Proto se začal připravovat DNSSEC, první standardy vznikly v roce 1997. Jiné požadavky měla společnost Apple, která okolo roku 2000 vytvořila Apple Bonjour, který byl o zhruba 13 let později standardizován jako Multicast DNS. Mezitím přibližně okolo roku 2005 začalo docházet k prvním implementacím DNSSEC. Okolo roku 2015 pak přišel DoT, tedy DNS over TLS. V roce 2018 uvedená skupina protokolů rozšířila o protokol DoH, opět jako zkratka DNS over HTTPS, a jako poslední přírůstek se tu v roce 2023 objevil protokol DoQ, který tentokrát znamená DNS over QUIC. Co nám tyto protokoly vlastně nabízí?
DNS
Základní protokol, používaný již více než 40 let. Nemá žádnou ochranu důvěrnosti přenášených dat, žádnou ochranu integrity, žádnou ochranu autenticity. Jeho nastavení a použití je snadné. Možná až příliš. Z dnešního pohledu se považuje za bezpečnostně problematický, protože není možné ověřit, zda náhodou poskytnuté informace nejsou podvrženy. Taková manipulace může dostat uživatele z dané organizace na servery, kde je útočník chce mít.
DNSSEC
Rozšíření původního protokolu DNS, které sice nezajišťuje důvěrnost dat, ale řeší jejich integritu a autenticitu. Pro tento postup se používají digitální podpisy záznamů a domén. Ke každému DNS záznamu, který je označen jako RRSET (tedy pro každý typ nebo název záznamu) je přiřazen digitální podpis RRSIG. Tento záznam obsahuje podpisy generované pomocí ZSK (Zone Signing Key). Veřejný klíč je uložen jako záznam DNSKEY přímo v doméně, privátní klíč je k dispozici autoritativnímu názvovému serveru. Parametr hodnoty u klíče pak určuje, zda se jedná o ZSK (Zone Signing Key = 256) nebo KSK (Key Signing Key = 257). Vlastní podepisování v rámci domény pak může používat dvou metod:
- Průběžné podepisování (je vhodné pro dDNS/Dynamic DNS, domény s častými změnami nebo některé NSEC3 odpovědi), klíč musí být k dispozici autoritativnímu názvovému serveru
- Dávkové podepisování, kdy se zóna podepíše najednou. Klíč může být offline, což zvyšuje bezpečnost domény
Důvěra záznamů závisí na prokazatelném vztahu od důvěryhodné kotvy (trusted anchor) ke konkrétnímu dotazovanému záznamu. Důvěryhodnou kotvu je možné si představit jako kořenovou certifikační autoritu. Pomocí důvěryhodné kotvy se prokazují kořenové servery. Kotva jako taková je dostupný záznam, jedná se o veřejný klíč dovolující ověřit digitální podpis v odpovědi. Vlastní DNSKEY na kořenové doméně poskytuje digitální podpis veřejného klíče pro jeho ověření. Protože kořenové servery moc často nemění informace, privátní klíč může být bezpečně uložen. Jeho únik by mohl ohrozit bezpečnost celého internetu. Zároveň kořenové servery drží DS záznamy pro podřízené domény, tyto záznamy jsou vždy podepsané privátním klíčem pro tuto doménu. V případě kořenové domény jsou podepsané privátním klíčem odpovídajícím důvěryhodné kotvě. DS záznamy obsahují hash KSK (Key Signing Key) domény další úrovně, odpovídající RRSIG pak digitální podpis KSK pomocí privátního klíče kořenové domény. Doména dalšího řádu pak obsahuje konkrétní reprezentace veřejných klíčů KSK a ZSK, které dovolují ověřit obsah. Pro představu je lepší využít konkrétní příklad.
Pokud je vytvořen dotaz na konkrétní doménu DOMAIN.TLD a záznamy v ní, DNSSEC bude řešit následující kryptogramy pro ustanovení důvěry. Prvním je dotaz na kořenové servery, který ověřuje obsah záznamů na kořenových serverech a zároveň obsah odpovídajícího klíčového materiálu. Kryptogramy použité pro tvorbu záznamů se tvoří následujícím způsobem:
TrustedAnchor = PublicKey.root KSK
DNSKEY.root ZSK = { PublicKey.root ZSK}
DNSKEY.root KSK = { PublicKey.root KSK}
RRSIG.root DNSKEY ZSK = Sign( PrivateKey.rootKSK, DNSKEY.root ZSK)
RRSIG.root DNSKEY KSK = Sign( PrivateKey.rootKSK, DNSKEY.root KSK)
Tedy je možné ověření souladu klíčů na doméně na základě ověření podpisů a informací o důvěryhodné kotvě. Aby bylo možné pokračovat na doménu TLD, je nutné získat ještě odpovídající záznamy pro kontrolu důvěryhodnosti domény dalšího řádu.
DS
TLD KSK = Hash(PublicKeyTLD KSK)
RRSIGTLD KSK = Sign(PrivateKey.root ZSK, DSTLD KSK)
Teď je tedy možné načíst záznamy z domény dalšího řádu, tedy domény TLD.
DS
DNSKEYTLD KSK = { PublicKeyTLD KSK }
DNSKEYTLD ZSK = { PublicKeyTLD ZSK }
RRSIGTLD KSK = Sign(PrivateKeyTLD KSK, DNSKEYTLD ZSK)
RRSIGTLD ZSK = Sign(PrivateKeyTLD KSK, DNSKEYTLD ZSK)
Na základě těchto údajů je možné ověřit libovolné záznamy dostupné v této doméně, které mají odpovídající RRSIG. Aby bylo možné pokračovat na doménu DOMAIN.TDL, je nutné opět získa odpovídající záznamu pro kontrolu důvěryhodnosti.
DS
DSDOMAIN.TLD KSK = Hash(PublicKeyDOMAIN.TLD KSK)
RRSIGDOMAIN.TLD KSK = Sign(PrivateKeyTLD ZSK, DSTLD KSK)
Poté je možné načíst záznamy z domény dalšího řádu, tedy domény DOMAIN.TLD.
DS
DNSKEYDOMAIN.TLD KSK = { PublicKeyDOMAIN.TLD KSK }
DNSKEYDOMAIN.TLD ZSK = { PublicKeyDOMAIN.TLD ZSK }
RRSIGDOMAIN.TLD KSK = Sign(PrivateKeyDOMAIN.TLD KSK, DNSKEYDOMAIN.TLD ZSK)
RRSIGDOMAIN.TLD ZSK = Sign(PrivateKeyDOMAIN.TLD KSK, DNSKEYDOMAIN.TLD ZSK)
Na základě těchto údajů je možné ověřit libovolné záznamy dostupné v této doméně, které mají odpovídající RRSIG, to včetně libovolných záznamů o názvech konkrétních serverů nebo služeb, identifikace autoritativních názvových serverů textových záznamů a dalších informací.
Díky ověřování stavu důvěry je možné pro doménu dané úrovně, za jistých okolností i pro konkrétní záznam, získat jedno z následujících hodnocení:
- SECURE, byl ověřen vztah důvěry až po důvěryhodnou kotvu. Tedy celý řetězec ověření kryptografických podpisů je v pořádku a nevíme o tom, že by byl narušen.
- BOGUS, tedy situace, kdy digitální podpis neodpovídá záznamu (RRSIG neodpovídá RRSET), hash DNSKEY neodpovídá DS v záznamu domény vyššího řádu, chybí podpis, podpis je expirovaný, případně je použit algoritmus nepodporovaný validátorem (neznámý algoritmus).
- INSECURE. K této situaci dochází, pokud doména vyššího řádu nemá odpovídající DS záznam pro doménu nižšího řádu (chybí hash DNSKEY obsahující KSK). V takovou chvíli se považuje toto přerušení za úmyslné, tedy zpravidla podřízená doména nepodporuje DNSSEC.
- INDETERMINATE je specifický stav, kdy validátor nemá potřebná data pro ověření. Například není dostupná nebo definovaná důvěryhodná kotva.
DNSSEC v současnosti využívá sadu asymetrických algoritmů, které nejsou odolné vůči útoku pomocí kvantových počítačů. Tyto algoritmy bude nutné nejdéle do roku 2035 změnit. Protože v současnosti dochází k výběru, je výsledek sledován s výraznou netrpělivostí. Ve výběru se zvažují tři přístupy, které je možné rozdělit na:
- Konzervativní přístup, podporující pouze standardizovaná schémata: ML-DSA (FIPS-204), SHL-DSA (FIPS-205), FN-DSA (FIPS-206), XMSS, LMS.
- Návrh s nízkým provozním dopadem, kde prozatím nedošlo ke standardizaci uvedených algoritmů, z těchto důvodů se čeká na výsledek standardizačních snah: MAYO, SNOVA
- Specifické režimy, jako je MTL (Merkle Tree Ladder) pro SHL-DSA.
V tuto chvíli ještě není zvolen nástupce pro současnou asymetrickou kryptografii a tomuto výběru je nutné ponechat odpovídající čas. Z uvedeného důvodu je také možné současné algoritmy dle registrů IANA klasifikovat zhruba následujícím způsobem.
| ID | Název algoritmu | DNSSEC | Poznámky |
| 1 | RSA/MD5 | must not implement | Tento podpis je slabý, MD5 je zlomená |
| 3 | DSA/SHA-1 | must not implement | Tento podpis je slabý, DSA je historické |
| 5 | RSA/SHA-1 | not recommended | Tento podpis je slabý, SHA1 je zlomená |
| 6 | DSA-NSEC3-SHA1 | must not implement | Tento podpis je slabý, DSA je historické |
| 7 | RSASHA1-NSEC3-SHA1 | legacy | Tento podpis je slabý, SHA1 je zlomená |
| 8 | RSA/SHA-256 | recommended | Aktuální do roku 2035, délka klíčů musí být delší než 3072b |
| 10 | RSA/SHA-512 | allowed | Aktuální do roku 2035, délka klíčů musí být delší než 3072b |
| 12 | GOST R 34.10-2001 | optional/rare | Ruský standard, v současnosti již považován za slabý |
| 13 | ECDSA P-256/SHA-256 | recommended | Aktuální do roku 2035 |
| 14 | ECDSA P-384/SHA-384 | optional | Aktuální do roku 2035 |
| 15 | Ed25519 | recommended | Aktuální do roku 2035 |
| 16 | Ed448 | optional | Aktuální do roku 2035 |
| 17 | SM2SM3 | registry entry | Čínské standardy SM2 a SM3, pouze do roku 2035. U nás nepodporované. |
| 23 | GOST R 34.10-2012 | registry entry | Aktualizovaný ruský standard, po roce 2035 nedostatečný. |
| 252 | Indirect Key | special | Nepřímé klíče |
| 253 | Private Algorithm | implementation defined | |
| 254 | Private OID | implementation defined | |
| 255 | Reserved | reserved |
Zajímavostí je také pohled na podporu algoritmů ze strany jednotlivých DNS serverů. Tento pohled bude v případě podpory kryptografie odolné kvantovým počítačům výrazně pozměněn, v současnosti ale vypadá přibližně následovně. Bohužel, protože s některými resolvery nemám zkušenosti, informace nemusí být zcela přesné.
| Algoritmus DNSSEC | BIND | Unbound | Knot Resolver | PowerDNS Recursor | Microsoft DNS | systemd-resolved | dnsmasq |
| RSA/SHA2-256 (8) | 9.5+ | S podporou DNSSEC | S podporou DNSSEC | 4.0+ | Windows Server 2008 R2+ | Experimentální | Forwarding |
| RSA/SHA2-512 (10) | 9.5+ | S podporou DNSSEC | S podporou DNSSEC | 4.0+ | obecně | Ano | Ano |
| ECDSA P-256 (13) | 9.9+ (ECSDA support) | 1.6+ | GnuTLS 3.0+ | neuvedeno | Windows Vista/Server 2008+ | Ano | Ano |
| ECDSA P-384 (14) | 9.9+ | 1.6+ | GnuTLS 3.4.8+ | neuvedeno | CNG | Ano | Ano |
| Ed25519 915) | Závislé na OpenSSL/GnuTLS | 1.6.4+ | Knot 2.6 a GnuTLS 3.6.0+ | 4.0.5+ a libsodium | CNG | Omezená | Forwarding |
| Ed448 (16) | Závislé na OpenSSL/GnuTLS | neuvedeno | GnuTLS 3.6.12+ | neuvedeno | CNG | Ne | Ne |
DNS over TLS (DoT)
Tento protokol zajišťuje transportní ochranu dotazů pomocí TLS vrstvy. Veškeré DNS dotazy jsou zapouzdřené v uvedeném kanále a směřují se na odpovídající port, komunikace není transportována pomocí jiných mechanismů. V případě použití mTLS a adekvátní verze protokolu je tak zajištěna silná ochrana důvěrnosti a integrity komunikace. Pokud se navíc použije pro dotazy protokol DNSSEC, je možné zajistit i odpovídající důkaz autenticity. V současnosti by se měl používat pro DNS over TLS minimálně protokol TLS 1.2 (nejdéle do roku 2030), lépe protokol TLS 1.3.
Pokud používá klient DoT k resolvování domén na internetu, obchází případný interní resolver. To může znamenat jednak bezpečnostní problémy včetně leaku interních názvů, dále problémy s dostupností týkající se adres, které se DoT snaží resolvovat na nesprávných místech. Z tohoto důvodu je vhodné nabídnout vlastní DoT server a DNS komunikaci centrálně řídit. Vlastní DoT server umožňuje řídit přístupy a přeposílat pouze akceptované dotazy.DNS over HTTPS (DoH)
Běžný DNS dotaz místo je cílení na DNS server zpracován do formy GET nebo POST HTTP dotazu a následně přenesen na portu 443. Ve valné většině případů platí pravidlo, kdy HTTP/2 probíhá přes HTTPS na portu tcp/443, ale HTTP/3 jde přes protokol QUIC na UDP. Data jsou dnes šifrována minimálně pomocí TLS 1.2, ale postupně se přechází na TLS 1.3. V případě QUIC se používá kryptografická ochrana založená na DTLS 1.2 potažmo DTLS 1.3. Použitý klíčový materiál odpovídá danému kanálu, tedy jeden klíčový materiál pro ochranu spojení, druhý klíčový materiál pro DNSSEC (pokud je použit).
Vlastní rozhodnutí, zda se použije GET nebo POST záleží na vlastním aplikačním serveru, který vyhodnocuje DNS odpovědi. Metoda GET kóduje dotaz ve formě Base64 URL v query stringu, metoda POST využívá dotaz v těle požadavku (binary wire format DNS). Na aplikačním serveru, odpovědném za resolving dochází k vyhodnocení DNS nebo DNSSEC požadavků a celá odpověď se posílá zpět žadateli. Pokud používá klient DoH k resolvování domén na internetu, obchází případný interní resolver. To může znamenat jednak bezpečnostní problémy včetně leaku interních názvů, dále problémy s dostupností týkající se adres, které se DoH snaží resolvovat na nesprávných místech. Z tohoto důvodu je nutné použít odpovídající nastavení systémů, případně lépe vlastní DoH server. Ten umožňuje řídit přístupy a přeposílat pouze akceptované dotazy.| Název | Typ | Verze |
| BIND | Autoritativní+rekurzivní resolver | 9.18+ |
| Knot Resolver | Rekurzivn resolver | 3.0.0.+ a modul doh |
| PowerDNS Recursor | Rekurzivn resolver | 4.3+ a modul doh |
| Unbound | Rekurzivn resolver | 1.9+ |
| dnsdist | Forwarder (DoH frontend) | dnsdist + web server |
DNS over QUIC (DoQ)
Tento protokol zajišťuje transportní ochranu dotazů pomocí DTLS. Veškeré DNS dotazy jsou zapouzdřené v uvedeném kanále a směřují se na odpovídající port, komunikace není transportována pomocí jiných mechanismů. Pokud se navíc použije pro dotazy protokol DNSSEC, je možné zajistit i odpovídající důkaz autenticity. V současnosti je pro navázání spojení podporován pouze protokol DTLS 1.3 na udp/853. Stejně jako u DoT probíhá uvedená komunikace přímo a na rozdí od DoH nedochází k zapouzdření do protokolu HTTPS.
Pokud používá klient DoQ k resolvování domén na internetu, obchází případný interní resolver. To může znamenat jednak bezpečnostní problémy včetně leaku interních názvů, dále problémy s dostupností týkající se adres, které se DoQ snaží resolvovat na nesprávných místech. Z tohoto důvodu je vhodné nabídnout vlastní DoQ server a DNS komunikaci centrálně řídit. Vlastní DoQ server umožňuje řídit přístupy a přeposílat pouze akceptované dotazy.
| Název | Typ | Verze |
| Knot Resolver | Rekurzivní resolver | 3.0.0.+ a modul doh |
| PowerDNS Recursor | Rekurzivní resolver | Experimentální, vyžaduje dnsdist |
| Unbound | Rekurzivní resolver | Prozatím experimentální |
Multicast DNS (mDNS)
Jedná se o systém pro překlad místních jmen bez centrálního serveru, formát dotazů je stejný jako v případě DNS. Pro komunikaci využívá tzv. Multicast, zprávu posílanou na určitou adresu, kterou ostatní stroje přijímají jako formu speciální komunikace. Pro IPv4 se jedná o adresu 224.0.0.251 na udp/5353 a pro IPv6 o adresu ff02::fb na udp/5353. Všechny stroje na síti podporující tuto službu naslouchají a odpovídají pouze, pokud se jedná o jejich názvy a služby.
Tento protokol vznikl pro malé sítě s cílem zajistit schopnost vyhodnocování jmenných názvů. Ochrana u tohoto protokolu neexistuje, tedy první odpověď platí. Z tohoto důvodu je velice snadné takovou komunikaci podvrhnout. Pro implementaci je sice možné použít Avahi/Bonjour, ale z bezpečnostního hlediska se jedná o značně problematické řešení.
DNS je extrémně důležitý protokol. Protože jeho zneužití není možné detekovat, je nutné nabídnout klientům možnost ověřit námi spravované záznamy pomocí vhodně konfigurovaných metod pro digitální podpis. Pokud je to důležité, je možné vytvořit resolvery, schopné dle organizačních pravidel nabídnout další služby a hlavně, šifrovat přenášená data pomocí dalších vrstev. Přesto je potřeba si uvědomit, že tyto vrstvy chrání transport, ale autenticitu stále zajišťuje pouze DNSSEC.
Reference:
- RFC Index
Zdroj: https://www.rfc-editor.org/
Autor článku:
