DNS je velmi starý protokol, první standardy (RFC 1034 a RFC 1035) vyšly už v roce 1987, tedy před více než třiceti lety. Tehdy součástí návrhu nebyla ani bezpečnost ani snaha chránit uživatelovo soukromí. O to se snaží tvůrci standardu posledních dvacet let.
V roce 2014 bylo jasně deklarováno, že i odposlech je druhem útoku (RFC 7258) a nové standardy by měly být navrhovány tak, aby před sledováním uživatele ochránily. Začaly proto vznikat konkrétní snahy upravit DNS a ochránit data, která skrz něj proudí.
DNS over TLS
První vlaštovkou je protokol DNS over TLS (DoT), který chrání komunikaci pomocí standardního šifrování protokolem TLS. Standard je od roku 2016 definován ve dvou dokumentech (RFC 7858 a RFC 8310) a používá TCP port 853.
Implementace už existují, na straně serveru je možné použít Unbound, Knot Resolver či BIND. Klient je vestavěn do operačního systému Android Pie, který zkouší dostupnost TCP portu 853 a v případě možnosti jej použije. Kromě toho je podpora také součástí systemd nebo démona Stubby. Existuje také celá řada služeb, které DoT nabízí, včetně resolverů od Cloudflare (1.1.1.1) a Quad9 (9.9.9.9).
Spustit vlastní službu a používat ji je poměrně snadné, serverové i klientské aplikace existují. V tuto chvíli však chybí především podpora v operačních systémech Windows, macOS a iOS.
Takto zašifrované DNS brání pasivnímu odposlechu, zajišťuje integritu přenášených dat a umožňuje autentizaci serveru pomocí TLS. To například zvyšuje důvěryhodnost dat, která dostaneme od DNSSEC validujícího DNS resolveru. Zatímco v běžném DNS provozu se dozvíme, že „někdo“ po cestě tvrdí, že validoval DNSSEC, s DoT víme přesně, kdo to tvrdí.
Proč to nestačí?
Takto šifrované DNS není dokonalé, stále je ještě co zlepšovat. Data například unikají přes TLS hlavičku SNI, i když už vznikl návrh nového standardu ESNI, který by měl tyto hlavičky zašifrovat. Do praxe by se měl dostat poměrně brzy, Firefox už oznámil jeho podporu.
Druhý problém spočívá ve využití zmíněného TCP portu 853, který může být na mnoha sítích blokovaný, ať už úmyslně či nikoliv. DoT může samozřejmě běžet i na obvykle otevřeném portu 443, ale není to standardní řešení. Uživatelé si musí uvědomit, že koncový resolver vidí všechna data o DNS provozu. Vzniká tím otázka, zda je v danou chvíli lepší věřit resolveru svého poskytovatele nebo bude lepší využít některou z veřejných internetových služeb.
Pokud se uživatel v danou chvíli rozhodne, že větší problém pro soukromí představuje místní poskytovatel připojení, dokáže pomocí DoT dostat své dotazy kompletně z dosahu místní sítě. To může samozřejmě jít třeba proti bezpečnostní politice aplikované na dané síti, často to ale může být právě náš cíl.
DNS over HTTPS
Příběh nového standardu (RFC 8484) DNS over HTTPS (DoH) je úplně jiný. Jeho cílem je implementovat bezpečný DNS přímo v prohlížeči, aby komunikace probíhala z prohlížeče přímo na vybranou sadu serverů někde v internetu. Jedná se o velmi mladý standard, jehož první návrh se objevil teprve v květnu 2017.
Celý standard chce umožnit webovým aplikacím přístup k DNS pomocí existujících API v prohlížeči. Existují dva různé způsoby připojení k serveru: buď je možné sestavit nové HTTPS spojení přímo s ním nebo je možné využít už existujícího spojení, které je v danou chvíli navázáno s web serverem. Druhá varianta vyžaduje další mechanismus, pomocí kterého se klient (prohlížeč) dozví, že daný server disponuje také funkcionalitou DoH. Na druhé straně to přináší velkou výhodu v tom, že pak není možné blokovat pouze DNS provoz, který je namíchán s HTTP uvnitř jednoho šifrovaného kanálu.
Naopak tu vzniká riziko sledování jednotlivých uživatelů napříč sítí. S klasickým DNS totiž existuje promíchaný proud jednotlivých dotazů a odpovědí, který je navíc oddělený od běžných uživatelských dat. S DoH ovšem každé zařízení otevírá mnoho různých spojení vycházejících z různých zdrojů uvnitř počítače. Každá aplikace vyžadující DNS odpovědi pak odesílá vlastní HTTP hlavičky, podle kterých je teoreticky v některých případech možné konkrétní instanci identifikovat a stopovat tak konkrétního uživatele.
Jak to funguje?
Pomocí HTTPS je možné poslat dotaz v klasickém DNS wire formátu (RFC 1035), případně pomocí dostupnějšího formátu JSON. Druhou zmiňovanou možnost podporuje Cloudflare i Google, takže můžete směle komunikaci vyzkoušet například standardním nástrojem curl, který umí posílat GET požadavky pomocí HTTPS s hlavičkou application/dns-json.
Celý dotaz je zakódován do URL, kde jsou k dispozici čtyři položky. Povinné name a type pro doménové jméno a typ záznamu; volitelné do a cd pro zobrazení DNSSEC nebo vypnutí validace. Výsledný dotaz a odpověď může vypadat například takto:
$ curl -sH 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=root.cz&type=AAAA&do=true'|python -m json.tool
{
"AD": true,
"Answer": [
{
"TTL": 91,
"data": "2001:67c:68::76",
"name": "root.cz.",
"type": 28
},
{
"TTL": 91,
"data": "AAAA 5 2 600 20190528123431 20180528123431 8130 root.cz. DUKH/DmP1XFWtKXHpCLJ49786krOOqO0cIeEn+5sFsKx+ZS96WRyNpYyy0VQyvqm/D+y2HwZFpxRQMM3oAa+IQ==",
"name": "root.cz.",
"type": 46
}
],
"CD": false,
"Question": [
{
"name": "root.cz.",
"type": 28
}
],
"RA": true,
"RD": true,
"Status": 0,
"TC": false
}
Utilita curl byla zavolána v tichém režimu nevypisujícím servisní hlášení, byla zvolena hlavička a poté již proběhl GET na zadanou URL. Python za rourou byl použit kvůli rozlámání výstupu na odsazené řádky.
Na implementace zatím čekáme
Na rozdíl od pět let starého DoT je DoH velmi mladičkým standardem, takže není zdaleka tak rozšířený a dostupný. Už teď ale existuje zhruba tucet serverů, které funkci DoH nabízejí. Jsou mezi nimi Google, Cloudlfare, Quad9, PowerDNS a další. Pokud si budete chtít spustit vlastní server, bude to výrazně horší. Na podpoře pracuje DNSdist, patche jsou k dispozici pro Knot resolver a existuje několik dalších projektů ve fázi experimentů. Rozhodně zatím nic, co byste nasadili za minutu.
S klienty je situace trochu lepší, podporu je možné zapnout ve Firefoxu od verze 61, funkce DoH je ukrytá i v Chrome. Zatím se ještě experimentuje, časem snad přibude příslušné tlačítko také do uživatelského rozhraní. Výhodou implementace v prohlížečích je, že je možné ji aktualizovat výrazně rychleji než v případě vlastnosti operačního systému.
Funkčnost si můžete vyzkoušet ve webovém testu od Cloudflare. Existuje také řada dalších DoH utilit.
Proč použít HTTPS místo TLS?
Na tuto otázku odpovídá ve svém článku The Benefits of HTTPS for DNS Patrick McManus z Mozilly. Základní vlastnosti obou protokolů jsou stejné, oba šifrují komunikaci mezi klientem a resolverem. V mnoha případech jsou si obě varianty rovnocenné a řeší problém stejně dobře. Důležité ovšem je, v čem se DoT a DoH liší. Tím je právě použití HTTPS, které umožňuje využít obrovskou škálu existujících nástrojů a rozšířené infrastruktury.
To také umožnilo tak rychlý nástup DoH, protože je možné stavět na existujících knihovnách, CDN, proxy serverech, load balancerech a implementacích v nejrůznějších programovacích jazycích. HTTP je jednoduše všude, proto je snadné nad ním stavět další z mnoha aplikací.
Lze tak využít výhodných vlastností použitého protokolu, kdy například HTTP/2 rovnou řeší multiplexaci datových toků a umožňuje jejich prioritizaci. Stejně tak je možné jen úpravou knihoven využívat protokolu QUIC a zvýšit tak výkon. Podobně bude možné využít vlastnosti Server Push a poslat klientovi odpovědi ještě dříve, než se na ně zeptá.
Hlavní výhodou DoH tedy je, že HTTP je všude a velmi rychle se rozvíjí. Bez nutnosti další standardizace a duplicitní práce na implementacích tak bude možné i v budoucnu těžit z dalších vylepšení.
Centralizace DNS infrastruktury
DoH zavádí nový pojem „důvěryhodný rekurzivní resolver“, protože těsněji spojuje prohlížeč s konkrétním poskytovateli služby. Mozilla zatím provádí experimenty se společností Cloudflare a záměrně neříká, jak bude vypadat výchozí nastavení resolverů. Jednak je vše ještě příliš živé a ve fázi testování a vytváření dohod, zároveň bude možné si výchozí nastavení změnit a vybrat si vlastní služby DNS resolveru.
Volba důvěryhodného resolveru ale úplně změní přístup k DNS. Dnes musíte ve výchozím stavu věřit nastavení DHCP v místní síti, které vám zvolí důvěryhodného prostředníka pro získávání DNS odpovědí. V budoucnu budete muset věřit aplikaci, že správně na základě vlastních kritérií zvolila rozumně. Vzniká tak potenciál nepříjemné centralizace, která nám dnes způsobuje potíže v případě certifikačních autorit. V budoucnu k nim zřejmě přibudou ještě předvybrané DNS autority, což by mohlo přinést podobné nepříjemnosti.
Reakce na DoH jsou zatím velmi smíšené. Na jedné straně se tím daří rozjíždět přínosnou debatu o potřebě šifrovat DNS, zároveň někteří oprávněně argumentují ztrátou kontroly nad DNS. Moje síť, moje pravidla. Provozovatelé sítí se bojí, že ztratí další část moci nad vlastní sítí, jako se to děje při prudkém rozšiřování TLS a HTTPS.
Vznikají ale i další nové otázky, které se týkají například legislativy. Nebudou státy nutit tvůrce aplikací, aby používali státem řízené DoH servery? Co síťová neutralita v případě CDN? DoH servery uvnitř CDN budou mít tendenci směrovat uživatele na služby uvnitř domovské sítě, přestože při použití tradičního modelu DNS by existovaly výhodnější varianty. Vznikne nová legislativa, která bude vlastnosti DoH serverů regulovat?
DoH mění překvapivě mnoho a může v mnoha ohledech ovlivnit celý internet. Nic ale ještě není definitivní, infrastruktura serverů bude teprve vznikat a je možné, že se nakonec prosadí úplně jiný model. Vše je otevřené, zkoušejte DoT a DoH servery na vlastní infrastruktuře. Další detaily naleznete na webu DNS Privacy Project.
Článek vychází z přednášky Sary Dickinsonové It's DNS Jim, But Not as We Know It z RIPE77.
ČLÁNKY DO MAILU