Jsou to čtyři roky, co byl dokumentem RFC 6698 standardizován protokol DANE. Smyslem tohoto protokolu bylo zavést větší pořádek do infrastruktury veřejných klíčů, které se používají zejména při autentizaci šifrovaných přenosů na internetu, jako například webového protokolu HTTPS. Současná praxe používá k ověřování identity protistrany důvěryhodné certifikační autority, které pro danou entitu vystaví certifikát. K tomu by mělo teoreticky dojít jen po řádném ověření držitele. Praxe je ale často jiná; většina certifikátů používá nejnižší stupeň ověření zvaný DV, kdy autorita pouze na dálku (s využitím mimo jiné protokolu DNS) ověřuje, zda žadatel drží doménové jméno, pro které žádá certifikát.
DANE naráží na problémy koncových sítí
Protokol DANE zavádí nový typ DNS záznamu zvaný TLSA. Ten umožňuje vystavit otisky TLS certifikátů v systému DNS. Každý účastník šifrované komunikace si tak může dotazem do DNS nejen zjistit IP adresu, na kterou se má spojovat (což musí dělat už teď), ale i ověřit, že protistrana posílá správný certifikát. Jde tedy o plnohodnotnou náhradu DV certifikátů, kde navíc k ověření držení doménového jména nedochází pouze jednorázově před vydáním certifikátu, ale průběžně při každém spojení.
Aby bylo jisté, že TLSA záznamy vystavil skutečně oprávněný držitel doménového jména, vyžaduje protokol DANE použití technologie DNSSEC. Ta přidává k DNS zprávám elektronický podpis a umožňuje tak detekovat případnou manipulaci s DNS daty na cestě. V protokolu DNSSEC je také kámen úrazu, který nasazení protokolu DANE na webu zásadním způsobem komplikuje.
Aby byl DNSSEC účinný, musí majitelé doménových jmen své domény podepsat a uživatelé musí podpisy validovat. Počet podepsaných domén v české národní top-level doméně .cz se dlouhodobě pohybuje kolem čtyřiceti procent, zhruba stejné procento českých uživatelů podle statistik laboratoří APNIC je připojeno za DNSSEC validující DNS resolver. Přesto drtivá většina uživatelů neprovádí validaci na svém počítači, či alespoň na zařízení ve své správě; validaci za ně provádí buď jejich poskytovatel připojení, nebo nějaký třetí poskytovatel veřejného DNS, jakým je třeba známá adresa 8.8.8.8 provozovaná Googlem. Takováto validace je sice lepší než vůbec žádná, ale rozhodně ji nelze brát jako dostatečně bezpečnou pro ověřování tak citlivých dat, jakými jsou právě třeba otisky TLS certifikátů.
Nutnou podmínkou pro plné nasazení protokolu DANE tak je dostat do koncového systému funkční validaci DNSSEC. Teoreticky by takovou validaci mohl provádět přímo operační systém, nebo třeba webový prohlížeč. Jenže něco takového je téměř nemožné provést univerzálně, tak aby validace fungovala všude tam, kde doteď funguje obyčejné DNS. Krutou daň si zde vybírá snaha o kompatibilitu DNSSECu s původním protokolem DNS – protokol používá stejné číslo portu a stejné zprávy, jen rozšířené o nový obsah a nový význam.
V praxi se bohužel ukazuje, že internet je plný podivných krabiček, které si o sobě myslí, že umí DNS, ovšem ve skutečnosti zvládají jen velmi omezenou podmnožinu DNS protokolu a všechno ostatní, včetně DNSSEC podpisů, buď zahazují, nebo alespoň znehodnocují. Svou zkušenost ostatně mají i uživatelé routeru Turris, který validaci provádí. I v tak malém vzorku, jakým je 2000 instalací napříč ČR, narazilo několik procent uživatelů na nefunkčnost validace, způsobenou nejčastěji zastaralou nebo špatně nakonfigurovanou DNS infrastrukturou poskytovatele připojení.
Musí DNSSEC používat DNS?
Možným řešením, jak se vyhnout podobným problémům, je přenášet DNSSEC zprávy jiným protokolem, takovým, který nebude zatížený třiceti lety historie a ideálně ještě takovým, který bude data šifrovat, aby byla menší pravděpodobnost, že do nich budou nějaké třetí strany zasahovat.
Jednou možností je třeba šifrované DNS, které zavádí RFC 7858 z května letošního roku. Jedná se vlastně o běžný DNS protokol zabalený do TLS na novém čísle portu 853. Vzhledem k tomu, jak mladý je tento standard, je možné očekávat, že každý, kdo jej bude implementovat, nebude mít problém se správným transportem DNSSEC dat. Na druhou stranu, není moc reálné předpokládat že nový protokol na novém čísle portu bude fungovat v každé síti, kde teď funguje DNS. Zvlášť když šifrovaná povaha protokolu dává možnost použít jej k tunelování libovolných dat. To ovšem nebrání používat jej oportunisticky, všude tam, kde jen to bude možné, a přepínat na staré DNS jen tam, kde to bude nezbytné.
Google Public DNS over HTTPS
Další možností, jak získat do koncového systému nezkažené DNS, je tunelovat DNS data protokolem, který má obecně asi největší průchodnost. Takovým protokolem bezesporu je HTTPS. Velmi zajímavá je v tomto ohledu služba Public DNS-over-HTTPS, kterou nedávno bez větších oznámení spustil Google. Tato služba, jak název napovídá, zpřístupňuje DNS zprávy prostřednictvím protokolu HTTPS a to jak v lidsky čitelné podobě, tak i jako JSON API. Ačkoli existují už i experimentální implementace pro použití této služby jako výchozího DNS resolveru pro všechny druhy dotazů, takové použití zřejmě nebude trhat rekordy ve výkonnosti.
Nabízí se však použití podobné služby pouze pro DNSSEC dotazy, které jsou náchylné na poškození při přepravě běžným DNS protokolem. Dovedu si třeba představit, že internetový prohlížeč se této služby dotáže pouze na příslušný TLSA záznam během validace certifikátu. Dokonce lze vynechat opětovnou validaci podpisů na straně klienta, protože spojení pomocí HTTPS zajišťuje autenticitu přenášených dat, takže zprávě o výsledku validace na straně Google je možné věřit. Tedy přinejmenším, půjde-li o prohlížeč z dílny Google.
Eliminace 1024bitového RSA v DNSSECu
Jedním z dalších argumentů, kterým Adam Langley vloni zdůvodňoval nepodporu protokolu DANE v prohlížeči Chrome, byla závislost systému DNSSEC na 1024bitovém RSA klíči, který sice dosud není prolomený, ale můžeme ho považovat za nalomený; útočník s dostatečným rozpočtem (v roce 2003 se uvádělo 10 milionů USD) jej dokáže za dostatečně dlouhou dobu (1 rok) prolomit.
Na rozdíl od PKI se však v případě DNSSEC nikdy 1024bitové RSA klíče nepoužívají dlouhodobě. Byl kvůli tomu vyvinut celý koncept dvojice klíčů ZSK a KSK, tak aby bylo možné slabé klíče (které jsou používány pro omezení velikosti dat) měnit automaticky po několika týdnech. To je podstatný rozdíl třeba proti kořenovému certifikátu certifikační autority, který má běžně platnost 10 let.
Problém 1024bitového RSA má své řešení. Tím je použití algoritmů, založených na eliptických křivkách, které generují dostatečně krátké a silné podpisy. Jejich podpora je na vzestupu, už nyní jsou takto podepsané DNS zóny běžně provozovány.
Zbývá však eliminovat 1024bitové RSA v horních patrech hierarchie, která jsou logicky poněkud konzervativní a zatím stále setrvávají u RSA. Kořenová zóna, která tvoří pevný bod důvěry celého DNSSEC stromu, doposud používá dvojici RSA klíčů o délce 2048 a 1024 bitů. I tady však dojde ke změně. Od 1. října 2016 bude druhý klíč vyměněn za nový délky 2048 bitů. Pokud k obdobnému kroku přistoupí i správci některých domén prvního řádu, padne i druhý argument, proč prohlížeče dosud protokol DANE nepodporují. Dočkáme se tedy konečně skutečné podpory?
(Článek byl původně napsán pro CESNET blog.)
ČLÁNKY DO MAILU