Internet a Technologie 16.2
V sobotu 3. prosince se na Fakultě informačních technologií ČVUT v Praze konala tradiční konference Internet a Technologie. Tu pravidelně (dvakrát ročně) pořádá sdružení CZ.NIC společně se svými partnery, v tomto případě právě s FIT ČVUT.
K organizaci konference není příliš co říct – její vysoká úroveň je stabilní a na účastníky kromě odborného programu pokaždé čeká i průběžně dostupné občerstvení, v poledne pak oběd. Na této konferenci bylo specifické, že se rychle vyčerpala plánovaná kapacita, proto organizátoři kapacitu navýšili – to se projevilo hlavně přidáním třetí „občerstvovací stanice“.
Jedním z mediálních partnerů konference byl i náš magazín IT Systems
Základem konference byly samozřejmě přednášky a workshopy. Dále byl k dispozici stánek s routerem Turris Omnia (jeden z workshopů byl také zaměřen na tento router) a knihy z Edice CZ.NIC za zvýhodněné ceny.
Soukromí v DNS
Dvě přednášky byly věnovány již notoricky známému řešení DNSSEC, kde kromě jiného zaznělo, že v české národní doméně (.cz) je již takto zabezpečena skoro polovina domén druhé úrovně. Česká TLD je čtvrtá na světě v absolutním počtu domén využívajících DNSSEC (první je nizozemská TLD .nl), v relativním počtu je dokonce druhá (za norskou doménou .no).
Již dlouho se však hovoří nejen o zabezpečení DNS proti neoprávněným zásahům (což DNSSEC řeší), nýbrž i proti odposlechu (a to DNSSEC naopak neřeší). Ondřej Surý na své přednášce ukázal, jaký je aktuální stav řešení této oblasti v rámci IETF.
Ondřej Surý při své přednášce o soukromí v DNS
Tuto oblast v IETF řeší pracovní skupina dprive (DNS Privacy Exchange). Ta už vydala čtyři finální dokumenty. Jsou jimi minimalizace posílání kvalifikovaných názvů (QNAME) na autoritativní servery (RFC 7816), DNS over TLS (RFC 7858) a EDNS(0) Padding (RFC 7830). „Jeden tam není [na snímku prezentace], protože to jsou jen definice toho, jaký je 'problem space' té pracovní skupiny, to znamená definice toho, co ta skupina řeší,“ doplňuje Ondřej Surý.
Dále jsou rozpracovány ještě tři drafty – DNS over DTLS, autentizace a (D)TLS profil pro DNS přes (D)TLS a konečně profily pro EDNS(0). První už má poměrně blízko k finální podobě.
Minimalizace posílání kvalifikovaných názvů
Dosud to funguje tak, že se resolver nejdřív zeptá kořenového serveru. Pošle mu celý (kvalifikovaný) název domény, kořenový server mu pak logicky odpoví, že odpověď nezná, ale že ji může znát server jiný (a pošle mu, který). Podobně to pokračuje i na dalších úrovních, než se resolver dostane až k serveru, který doménový název zná (případně může autoritativně odpovědět, že název neexistuje).
Problém je, že se tímto postupem každý z dotazovaných serverů dozví, na co přesně se resolver ptá. To je samozřejmě zásah do soukromí, protože provozovatelé jednotlivých serverů mají přehled, kdo se dotazuje na jaké názvy. V zájmu ochrany soukromí je tedy žádoucí omezit posílání těchto plně kvalifikovaných názvů.
Účastníci konference sledují přednášku
Místo nich se pak posílá jen minimální potřebná část z celého názvu. Takže kořenové servery dostávají jen dotazy na domény nejvyšší úrovně (např. .cz), autoritativní servery jednotlivých TLD dotazy na domény druhé úrovně atd.
Řešit problém minimalizace však není triviální. „DNS je rozbité. To je prostě fakt,“ vysvětluje Ondřej Surý. „To je tak starý protokol, že proto, aby fungoval, je potřeba spousta různých 'odrbávek' na různých místech.“ Minimalizace by se měla zastavit poté, co se iterovalo přes všechny „labely“ (komponenty doménového názvu). Ale tak jednoduché to opravdu není.
Někdo totiž může poslat název složený z jednoznakových komponent a tím vytvořit DoS vektor na resolver, protože iterace zdržuje. Problém tohoto druhu je i s IPv6 (u reverzních záznamů). S iteracemi by se mělo také skončit, pokud přijde jiná odpověď než NOERROR. Ovšem například CDN Akamai se chová chybně a posílá odpověď NXDOMAIN i tam, kde nemá.
Dokument RFC 8020 upřesňuje, že NXDOMAIN se posílá jen v případě, že pod danou doménou už opravdu nic není. Pokud je uzel ve stromě sice prázdný, ale pod ním něco je (existují subdomény), mělo by se vracet NODATA.
Aktuální stav implementace je takový, že Knot DNS a Unbound minimalizaci v současných verzích podporují (a mají ji standardně zapnutou), BIND by ji měl zřejmě mít v chystané verzi 9.12 a PowerDNS Recursor ve verzi 4.1.0.
DNS over TLS
Tato technologie slouží k šifrování DNS komunikace probíhající protokolem TCP. Využívá klasické TLS 1.x a standardně naslouchá na portu 853. Šifruje se komunikace mezi koncovým resolverem (stubem) a rekurzivním serverem, mezi stubem a forwardujícím serverem a mezi forwardujícím a rekurzivním serverem.
Technologie není určena pro komunikaci mezi rekurzivním a autoritativním serverem.
Volitelné ověření druhé strany (autentizace) je teprve ve fázi draftu. „Je několik modelů. Buď je to oportunistické ověření, to znamená, že když tam to šifrování je, tak ho použiju, když není, tak není. Certifikát druhé strany vůbec neřeším. (…) Druhý profil je striktnější. Dá se použít PKIX (máte nadefinované, že důvěřujete certifikátům těchto certifikačních autorit), pak se dá použít DANE, dá se použít pinning SPKI, poslední varianta je hostname.“
Přečtěte si o použití DANE pro e-mailovou komunikaci.
Knot DNS a Unbound už tuto technologii podporují, u ostatních serverů lze využít TLS proxy (stunnel, HAProxy, nginx…). Na klientské straně je podpora v nástrojích kdig (z balíku Knot DNS), drill (ldns), digit a getdns.
Stánek routeru Turris Omnia
Kromě DNS over TLS existuje ještě DNS over DTLS – zatím ne jako standard, ale specifikace už prošla pracovní skupinou a brzy by mohla mít podobu finálního dokumentu. Zatímco DNS over TLS souvisí s TCP komunikací, DNS over DTLS přenáší data přes UDP. Navázání spojení je tu mnohem rychlejší (přestože u TCP lze navázání urychlit pomocí TCP Fast Open).
Plná podpora pro TCP Fast Open (RFC 7413) je v linuxovém jádře k dispozici od verze 3.7 (IPv4), resp. 3.16 (IPv6).
EDNS(0) Padding
I když se komunikace šifruje, mohou postranní kanály leccos prozradit. Zejména se to týká délky dotazu a odpovědi. Lze tak odlišit zprávy pro krátkou a dlouhou doménu atd. Technologie EDNS(0) Padding do zpráv přidává data a tím omezuje možnost něco zjistit.
Samozřejmým předpokladem je šifrování (u nešifrované komunikace nemá význam něco řešit, protože data jsou přímo dostupná). Lze využívat různé strategie – zatím jsou opět jen ve fázi draftu, takže se finální podoba může lišit o toho, s čím se teď pracuje.
O workshop zaměřený na Turris Omnia byl velký zájem
Těmito strategiemi může být fixní délka (všechny dotazy/odpovědi jsou stejně dlouhé), zarovnání do bloku (např. na 64 B), náhodná délka (trpí výkonovou penalizací – je potřeba získávat náhodná čísla) nebo náhodná délka se zarovnáním do bloku.
Se stavem implementací je to slabší. Na serverové straně technologii podporuje jen Knot Resolver, na klientské Knot DNS kdig a getdns. „V létě tady bude IETF. A před IETF bývá IETF Hackathon, tam bývá skupinka lidí, co programují DNS. A přesně tohle – to DNS over TLS a EDNS(0) Padding jsou technologie, které vznikly na tom hackathonu a potom jsme je začlenili do resolveru.“
Shrnutí
Pro zajištění soukromí je již specifikováno několik významných technologií a na dalších se intenzivně pracuje. Dostupnost v implementacích je různá, zatím spíše nízká (kromě Knot DNS a souvisejících). Je ale zřejmě jen otázkou času, kdy nebude nic bránit nasazení do praxe a tedy i ochraně soukromí na úrovni DNS.
V předsálí konference IT 16.2
