Protokol DANE aneb (z)krocení zlých certifikačních autorit

Jelikož je hlavní díl práce na protokolu DANE dokončen, je pravý čas se krátce podívat, co vedlo k tomu, že pracovní skupina vůbec vznikla, jaké byly a jsou výchozí podmínky, do nichž protokol přichází, jak se používá a jaký kus práce máme ještě před sebou.

Polámaná infrastruktura veřejných klíčů

O tom, že s certifikačními autoritami (dále CA) není tak něco úplně v pořádku a celý současný model infrastruktury veřejných klíčů (dále PKI) tak trochu stojí na hliněných nohou, jsme v posledních letech referovali hned několikrát (například v článcích Věříte opravdu jen důvěryhodným certifikačním autoritám nebo SSL divočina aneb jak se chovají „důvěryhodné“ CA). Kromě implementačních problémů na straně samotných CA, na což dojel například DigiNotar, je jeden z hlavním problémů PKI rovnost všech certifikačních autorit, které máte ve svém úložišti.

Jinými slovy, z pohledu programu, který kontroluje důvěryhodnost certifikátu, je úplně jedno, zda je tento certifikát vydaný firmou Symantec (prodávající pod značkou Verisign/Thawte), již zmíněným DigiNotarem nebo například certifikační autoritou čínského CNNIC. Důvěru v certifikační autoritu buď máte nebo nemáte – a co hůř nejste to ani vy – uživatel, kdo určuje, zda konkrétní CA bude přidána do úložiště, ale většinou je to dodavatel/výrobce operačního systému, konkrétního programu (např. prohlížeče) nebo přímo konkrétního kusu hardware. A v podstatě ani na velmi otevřených platformách, kde se certifikáty v úložišti CA dají editovat, neexistuje jednoduchý způsob, jak toto změnit a zároveň se při používání webu nezbláznit. (Schválně si to zkuste…)

Další jobovka, která přišla ze strany certifikačních autorit, bylo postupné zředění kontrol při vydávání certifikátů. Před lety i při vydávání jednoduchého certifikátu pro web docházelo alespoň k nějakým kontrolám žádajícího subjektu – a to raději pominu fakt, že tyto kontroly byly dle mé zkušenosti založeny na údajích, které CA získala z whois databáze (tedy pomocí plaintextového protokolu). Bohužel časem došlo k tomu (zákazníci to chtějí), že vám dnes k vydání certifikátu úplně stačí fungující emailová adresa, resp. schopnost číst schránku této emailové adresy. Možná si řeknete, že se tyto certifikáty liší v množství údajů, které jsou v nich uloženy. Dovolím si tedy předvést malou názornou ukázku toho, jaký je mezi těmito certifikáty rozdíl (příklady jsou z Google Chrome, ale podobně to vypadá v Mozilla Firefoxu).

Toto je ikona certifikátu, který obsahuje údaje o subjektu (organization-validated, dále OV):

Toto je ikona certifikátu, který obsahuje pouze údaje o doméně (domain-validated, dále DV – ještě se k nim vrátím):

Rozdíly lze vypozorovat až po prostudování detailů certifikátu, což si troufnu tvrdit, že nedělají ani poučenější uživatelé.

Jediný znatelný rozdíl je možné vypozorovat při použití EV certifikátů, které vznikly v roce 2007 v rámci CA/Browser fóra, neformálního sdružení některých certifikačních autorit a některých výrobců prohlížečů, nicméně pokud se nad současnou praxí používání EV certifikátů zamyslíte, tak dojdete ke stejnému závěru – pro běžného uživatele je nadlidský úkol usoudit, zdali konkrétní webová stránka má nebo nemá používat EV certifikát, případně jestli tento certifikát nebyl vyměněn. Udělejte si schválně takový malý test – zkuste si vzpomenout, jestli internetové bankovnictví vaší banky používá EV nebo ne-EV certifikát, a zde do ankety zaklikněte, jestli jste se trefili.

Více zajímavého čtení o stavu HTTPS můžete najít například na stránkách ImperialViolet.org (autorem je Adam Langley, jeden z autorů Google Chrome), případně si poslechněte přednášku Moxieho Marlinspikeho z loňské konference BlackHat. Nedoporučuji dělat před spaním, mohlo by se vám zdát něco ošklivého.

Motivace k novému protokolu

Po této delší filipice proti PKI se můžeme vrhnout na motivaci ke vzniku protokolu DANE. Základní myšlenkou stojící za celým protokolem je jednoduchá úvaha: jedině vlastník domény ví sám nejlépe, jaký certifikát se má pro tuto doménu používat. Tato vcelku jednoduchá myšlenka vznikala a zanikala v IETF poměrně delší dobu (CERT, Schlyter, …), nicméně až s DNSSEC podpisem kořenové zóny byl doplněn ten poslední střípek skládačky, který umožňuje ověřit, zda nedošlo při komunikaci mezi odesílatelem a příjemcem sdělení o certifikátu k jeho pozměnění. V návaznosti na podpis kořenové zóny v červnu 2010 se na IETF v Maastrichtu sešla plná místnost lidí na tzv. barBoF, který jsem v té době svolal, a řekli jsme si, že máme zájem na tomto tématu dále pracovat.

Na dalším setkání IETF už jsme společně s Warrenem Kumarim, mým budoucím spolupředsedou této pracovní skupiny, vedli již oficiální BoF tehdy ještě pojmenovaný KIDNS, a krátce na to byla založena pracovní skupina DANE (více o tomto tématu a procesech v IETF je možné se dočíst v článku Vrána k vráně sedá aneb koťátka, dogy a nápoje v IETF.

Po poměrně bouřlivých diskuzích v začátcích pracovní skupiny se situace postupně stabilizovala a samotný protokol začal dostávat jasnější kontury, které vyústily v jeho vydání jako oficiální internetový standard RFC 6698.

Protokol DANE v plné kráse

O protokolu DANE jste se také již mohli dočíst v menším souhrnu, který vyšel letos na jaře, kdy byl samotný protokol ještě ve fázi návrhu, takže se teď pojďme podrobněji podívat na jeho finální podobu.

Protokol DANE přidává do DNS nový typ nazvaný TLSA (zkratka z TLS Association), který definuje jednak způsob tvorby příslušného doménového jména (kromě dotazovaného jména obsahuje také port a protokol), a také interpretaci samotných dat v záznamu.

Protože na jednom doménovém jménu může být provozováno více aplikací, z nichž každá může mít svůj vlastní certifikát, bylo nutné do protokolu zahrnout možnost zpřesnit, o kterou službu se jedná. Toho bylo docíleno speciálním prefixem v DNS dotazu, který je vytvořen dle následujícího schématu:

_<port>._<ipprotokol>.<domena>

Tedy v případě, že klientská aplikace bude chtít získat TLSA záznam pro službu HTTPS běžící na standardním portu 443 na doméně www.tlsa.cz, tak se bude dotazovat na TLSA záznam pro jméno  _443._tcp.www.tlsa.cz.

Záznam, který získá obsahuje celkem tři parametry a následně samotná binární data pro asociaci (viz ASCII obrázek):

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Cert. Usage  |   Selector    | Matching Type |               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               /
   /                                                               /
   /                 Certificate Association Data                  /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

První 8bitový parametr je „Certificate Usage“ a v současné době může nabývat čtyř hodnot od 0 do 3, přehledněji pak v následující tabulce:

Pokud se podíváte na tabulku, tak lze vidět, že první dvě hodnoty mohou být použity pro zesílení důvěry ve stávající systém PKI, a je také zpětně kompatibilní se současným systémem. Administrátor serveru si nechá vystavit certifikát od existující certifikační autority, a TLSA záznamem pouze určí, která certifikační autorita (nebo v případě typu 1 který konkrétní certifikát) může být použit pro zabezpečenou komunikaci se serverem.

V případě, že by došlo k vystavení podvodného certifikátu jinou certifikační autoritou, bude možné toto v klientské aplikaci (nebo přímo v operačním systému) detekovat a uživatele ochránit před připojením na podvodný server. Sice jsme si ještě nepopsali všechny parametry TLSA záznamu, ale budu rovnou uvádět pro lepší představu příklady.

Pokud bychom chtěli omezit doménu certifikátu používané pro www.nic.cz pouze na takové, které vystavila DigiCert High Assurance EV Root CA, tak by výsledný TLSA záznam vypadal takto:

_443._tcp.www.nic.cz.
IN TLSA 0 1 1
5a889647220e54d6bd8a16817224520bb5c78e58984bd570506388b9de0f075f

V případě, že by správce serveru chtěl vyměnit certifikační autoritu, bude muset přidat na přechodnou dobu druhý TLSA záznam, který bude obsahovat otisk nové certifikační autority, a teprve po výměně certifikátu na serveru starý TLSA záznam odstranit.

V případě druhých dvou hodnot je možné vylepšit stávající praxi interních certifikačních autorit (jednu takovou používá například Debian/SPI) a self-signed certifikátů (zde se dostáváme do nuancí RFC 5280, a pro přesné důvody, proč je toto rozlišeno, doporučuji  přečíst si archív konference DANE).

Jako příklad bych vybral debianí službu buildd.debian.org, kde se zobrazují výsledky sestavování balíčků pro všechny aktuální architektury Debianu:

_443._tcp.buildd.debian.org.
IN TLSA 2 1 1
9b55fd1f30494eac7ba21d7662b94e6468fa9a5c2ae2dd6f6f2f90ab26273376

Od chvíle přidání tohoto záznamu do DNS všechny prohlížeče, které budou rozumět protokolu DANE, přestanou zobrazovat varovná okna a certifikát podepsaný Debian/SPI CA akceptují, jako kdyby měly certifikační autoritu uloženu do úložiště certifikátů.

Druhý parametr v TLSA záznamu je nazvaný selektor a rozlišuje, zda je otisk generován z celého certifikátu (typ 0) nebo pouze z jeho veřejného klíče (typ 1). Na faktický rozdíl narazíte ve chvíli, kdy skončí platnost současného certifikátu a budete jej obnovovat (a privátní klíč zůstane stejný) – v případě použití selektoru 1 nebudete muset znovu generovat nový TLSA záznam, protože veřejný klíč certifikátu zůstává stejný. Opět si to ukážeme na příkladu – tentokrát jsem vygeneroval dva self-signed certifikáty za použití stejného privátního klíče. V případě selektoru 0 budou dva záznamy vypadat takto:

_443._tcp.www.tlsa.cz.
IN TLSA 3 0 1
2f4af1513d4457c0e97f7ebb14eaafe76f612d477e155c2fb63f9aa70017468c

_443._tcp.www2.tlsa.cz.
IN TLSA 3 0 1
92f0e69605585ce9ec509670847921a655db9b98e681f07ad6951e05e8c66415

Zatímco v případě použití selektoru 1 budou záznamy shodné:

_443._tcp.www.tlsa.cz.
IN TLSA 3 1 1
380574cf5a2cc5f2ef03734ba52bf49ea57781302b893505db630adea47d20b6

_443._tcp.www2.tlsa.cz.
IN TLSA 3 1 1
380574cf5a2cc5f2ef03734ba52bf49ea57781302b893505db630adea47d20b6

Třetí a poslední parametr určuje, jakým způsobem bude vytvořen otisk certifikátu. Typ 0 vkládá do TLSA záznamu celý certifikát, zatímco ostatní dva typy používají hashovací funkci – SHA-256 (typ 1) nebo SHA-512 (typ 2).

Rozdíl si opět ukážeme na příkladu, tentokrát se jedná o EE certifikát domény www.nic.cz. Pokud budeme kódovat celý certifikát, dostaneme poměrně dlouhý DNS záznam:

_443._tcp.www.nic.cz.
IN TLSA 1 1 0
30820122300d06092a864886f70d01010105000382010f003082010a028201
0100d48889287826b45508945dad58e552e5e92776567926bb842e52a5bef8
0517087216ba97bb833e26876b10ccb4f2bdcd8d2ec5b3db2a825b2a292907
a101ed5838ca3f61ba5f97c929ee4d035e31ae85dcff64c4fa8b1b3894c6de
3c21730857068caa2cb8670342c37aa67fe05d96c07b22256277bf3f97d5e5
ce959d0fb86dc0949c94172033ca251b9ecd3b6b1e46c545ae166d02b8fec3
8ab82469a6f87ab975b3ddb762fe16ee2b41892a83d4934173f594d05a0b55
4ccbbcc64d048604985bc486c589eb3bce313c6d99deecff8dd66ecd9f7baf
379d1308c7b6143c8529dbd46bf22a2c67e6276be8767c4a6cedf4764d82d2
51b59bd156b513f109d10203010001

V případě použití hashovacích funkcí odpovídá délka otisků délce výstupu příslušných hashovacích funkcí:

_443._tcp.www.nic.cz.
IN TLSA 1 1 1
ef2dbd0fb1785efd174e9072b674b439c1c1b1d2f3afd76c8bcd3c8eb02b56e7

_443._tcp.www.nic.cz.
IN TLSA 1 1 2
b43dd88534c0a26859d19a26a54a502055187de2099f6d35564c55a659
525a52dcb5163c961e233578a3408d57e7c842db22347967058c2396c8
8e7cd367a978

Bezpečnost DANE protokolu

Bezpečnosti nového protokolu bylo věnováno poměrně dost úsilí (ostatně kapitola Security Considerations má v RFC asi pět stran a vážně doporučuji si je přečíst, než se pustíte do vášnivé debaty pod tímto článkem) a v pracovní skupině i v celém IETF se domníváme, že použitím nevzniká žádné nové bezpečnostní riziko. 

Důležitým prvkem je použití DNSSECu, který je naprosto nutný v případech, kdy jakoby vkládáme nový kořen důvěry, protože podvržení TLSA záznamů by znamenalo zásadní narušení bezpečnosti – útočník by mohl s minimálním úsilím oběti namluvit, že je jeho certifikát ten pravý.

V případech, kdy pouze zvyšujeme bezpečnost CA (cert. usage 0 a 1), by teoreticky DNSSEC nebyl nutně potřeba, protože podvržením TLSA záznamů bychom se dostali pouze na současnou úroveň bezpečnosti, ale v rámci zachování příčetnosti autorů dokumentu, předsedů pracovní skupiny i čtenářů toho standardu jsme se rozhodli, že nebudeme situaci komplikovat, a DNSSEC bude povinný i pro tyto případy.

Často slýchanou výtkou (včetně výše zmíněného Moxieho Marlinspikea) je přílišná závislost protokolu na DNS a organizacích, které spravují kořenovou zónu (ICANN/IANA) a TLD (CZ.NIC v případě .CZ). Zde je důležité si uvědomit, že již dnes spoléháte na bezpečnost všech těchto organizací včetně vystavování certifikátů. V případě DV certifikátů, které nejsou při běžné práci nijak odlišitelné od OV certifikátů, již dnes celá bezpečnost stojí a padá s bezpečností DNS, protože vystavení certifikátů je vázáno na prokázání, že máte na doménu nějakou vazbu, což se minimálně u jedné certifikační autority prokazuje tím, že vám zašle e-mail na např. hostmaster@<domena>.

Z toho poměrně jasně vyplývá, že útočník, který ovládne vaše poštovní servery, může velmi snadno získat i certifikát, který se bude jevit jako důvěryhodný, a pokud to udělá šikovně (např. selektivní filtrací pouze emailů od CA), tak nemusíte vůbec nikdy nic zjistit. Z bezpečnostního pohledu opět dochází pouze v vylepšení situace a nikoli k jejímu zhoršení.

Generování TLSA záznamů

Pro generování TLSA záznamů můžete použít šikovnou utilitu swede, která umí generovat všechny typy TLSA záznamů ( --output TLSA), a která byla použita i pro tento článek.

usage: swede create [-h] [--port PORT] [--protocol {tcp,udp,sctp}]
                    [--certificate CERTIFICATE] [--output {generic,rfc,both}]
                    [--usage {0,1,2,3}] [--selector {0,1}] [--mtype {0,1,2}]

optional arguments:
  -h, --help            show this help message and exit
  --port PORT, -p PORT  The port where running TLS is located (default: 443).
  --protocol {tcp,udp,sctp}
                        The protocol the TLS service is using (default: tcp).
  --certificate CERTIFICATE, -c CERTIFICATE
                        The certificate used for the host. If certificate is
                        empty, the certificate will be downloaded from the
                        server
  --output {generic,rfc,both}, -o {generic,rfc,both}
                        The type of output. Generic (RFC 3597, TYPE52), RFC
                        (TLSA) or both (default: generic).
  --usage {0,1,2,3}, -u {0,1,2,3}
                        The Usage of the Certificate for Association. '0' for
                        CA, '1' for End Entity, '2' for trust-anchor, '3' for
                        ONLY End-Entity match (default: 1).
  --selector {0,1}, -s {0,1}
                        The Selector for the Certificate for Association. '0'
                        for Full Certificate, '1' for SubjectPublicKeyInfo
                        (default: 0).
  --mtype {0,1,2}, -m {0,1,2}
                        The Matching Type of the Certificate for Association.
                        '0' for Exact match, '1' for SHA-256 hash, '2' for
                        SHA-512 (default: 1).

Blízká i vzdálenější budoucnost DANE protokolu

I když jsme dokončili základní DANE protokol, tak práce v pracovní skupině není dokončena. Na posledním IETF se pracovní skupina dohodla, že bude pokračovat dále, a bude se věnovat méně triviálním protokolům, které se mohou připojovat na doménové jméno odlišné od toho, které zadal uživatel (SMTP, XMPP/Jabber, SIP).

Většinou jde o to, že tyto protokoly moc dobře nefungují v případě masového hostingu těchto služeb. V zásadě jde o to, že tyto protokoly se musely vypořádat s neexistencí DNSSECu, a jsou poměrně striktní na jméno certifikátu v TLS komunikaci (je to jméno, které vyťukáte do klienta, a nikoli jméno, na které se připojujete). V zásadě dohoda je taková, že je potřeba „opravit“ tyto protokoly, a teprve pak nadefinovat jejich použití v DANE.

Možná vás v tuto chvíli napadne otázka: „Dobře, takže jsem si vygeneroval TLSA záznamy, a bude to teď někomu k něčemu?“ Jednoduchá depresivní odpověď vás asi vzhledem k mládí protokolu napadne hned, nicméně není potřeba házet flintu do žita. Již v průběhy tvorby dokumentu vzniklo pár proof-of-concept implementací (např. Matt McCutchen vytvořil testovací implementaci pro NSS), které v současné době sice neodpovídají finální podobě standardu, ale prokazují, že je možné implementaci vytvořit.

V Laboratořích CZ.NIC také v současné době pracujeme na rozšíření doplňku pracovně nazvaného DanePatrol, který by měl umět doplnit podporu protokolu DANE do prohlížeče Firefox. Také v případě prohlížeče Google Chrome/Chromium předpokládáme, že bude časem podpora protokolu doplněna, i vzhledem k tomu, že můj spolupředseda pro Google pracuje.

Vzhledem k současnému spíše katastrofálnímu stavu domácích routerů (bavili jsme se o implementaci DANE v Google Chrome s Adamem Langleym a dle jeho slov je přibližně 5 % uživatelů, jejichž domácí firewally nepropustí ani DNSSEC, natož nové protokoly), je vše bohužel běh na delší trať, a možná bude potřeba v mezičase nasadit nějaká meziřešení, jako je například DNSSEC stapling.

Držte nám tedy palce, případně rovnou přiložte ruku k dílu!