Šifrujte, šifrujte, šifrujte, zní teď odevšad parafrázovaná slova klasika. Nástroje na to máme, spousta věcí se dá automatizovat, takže hurá do toho. Šifrování je ovšem jedna věc, ale stejně zásadní je i autentizace. K čemu je nám šifrování, když na druhé straně sedí útočník, který se nám vesele vydává za původní protistranu? Musíme proto zajistit ověření obou stran komunikace, abychom svá tajemství nevyzrazovali leckomu.
Nejčastěji se při tom skloňuje SSL (věděli jste, že i SSH umí certifikáty?), což je logické, protože většina služeb je dnes dostupných po webu. Díky SSL, infrastruktuře veřejného klíče (PKI) a hierarchii certifikačních autorit máme v ruce mocný nástroj, který dokáže vše zvládnout naprosto automaticky. Za správce i za uživatele. Bohužel i tady platí, že je to dobrý sluha, ale velmi zlý pán.
Teoretický úvod
SSL certifikát není vlastně nic jiného, než soubor v konkrétním formátu, který obsahuje několik různých informací: datum platnosti, informace o držiteli, informace o autoritě, veřejný klíč držitele a to celé je podepsané onou autoritou. Certifikát tak vlastně říká: „Já, autorita, potvrzuji, že jsem ověřil existenci subjektu, kterému je tento certifikát vystaven. Držitel privátního klíče může tento certifikát použít k následujícím účelům v této vyhrazené době.“
Je to vlastně úplně stejné jako třeba u pasu. Také tam existuje autorita (stát), která ověřuje identitu osob, a pokud vše souhlasí, vystaví jim pas. V něm je uvedeno, kdo pas vystavil, kdo je držitelem, jak vypadá, kdy je pas platný a jaká má například omezení.
Takový certifikát si samozřejmě může vystavit úplně kdokoliv. Můžete si vytvořit vlastní certifikační autoritu pro celou firmu a tou pak podepisovat vydávané certifikáty pro své zaměstnance. Protože považujete za důvěryhodnou svou autoritu, můžete věřit i tomu, kdo se prokáže jí vydaným certifikátem. Druhou variantou jsou takzvané self-signed certifikáty, které jsou podepsané samy sebou. Ty nemají žádnou autoritu a existují mimo hierarchii jen jako jeden objekt, kterému buď věříte nebo ne.
Jako děti jsme si taky vyráběly své pasy. Stačí k tomu papír, nůžky, sešívačka a pastelky. Namalujete fotku, vyplníte údaje a máte pas své vlastní republiky. Rozdíl mezi tímto a „pravým“ pasem je v tom, že vaše „autorita“ není příliš důvěryhodná a za pytlík bonbónů jste ochotni namalovat takový pas komukoliv. Proto váš pas ostatní státy neakceptují jako platný doklad.
Aby tohle fungovalo, musí existovat seznam autorit, kterým apriori věříme. Jimi vydané certifikáty považujeme za důvěryhodné a přeneseně tak věříme i tomu, kdo se takovým certifikátem prokáže. Seznam důvěryhodných autorit (i s veřejnými klíči) k nám přichází obvykle s operačním systémem a jednotlivými aplikacemi. Problém je, že je za nás vybírá někdo jiný a že je jich moc. Mozilla v tuto chvíli věří 359 autoritám po celém světě, které navíc často delegují svá práva na další a další organizace. Nakonec tak jde o tisíce různých autorit, které mohou vystavovat certifikáty k libovolným webům a službám. Věříme jim všem?
Opět zůstaneme u pasů. Pokud má celník v ruce podrobný manuál k orientaci v autoritách vydávajících pasy, má na něm 196 nezávislých států (číslo se občas liší, ale na tom teď nesejde), které považuje za autoritu oprávněnou vydávat pasy. Kterýkoliv z těchto států může vydat jakýkoliv pas a celník mu (alespoň teoreticky) věří. Může se ovšem stát, že nedopatřením, nátlakem nebo prostě z potřeb daného státu vznikne pas, který je sice „pravý“, ale obsahuje nesprávná data. James Bond by o tom mohl vyprávět. A ono se to opravdu děje.
Celý problém certifikačních autorit je tedy v tom, že my (respektive náš software) jim vlastně bezmezně věříme. Kterákoliv z tisíců autorit může vydat certifikát k jakémukoliv serveru a nám se bude zdát důvěryhodný. Neexistuje žádná vazba doména–autorita. Jakmile je jednou autorita v naší databázi důvěryhodných, může vydávat cokoliv pro kohokoliv. Ono se to běžně neděje, ale může se stát, že nedopatřením, nátlakem nebo prostě z potřeb daného státu…
Naštěstí si tohoto problému všimli jiní a už poměrně dávno. Vzniklo tak několik řešení, která je možné nasadit, abychom zmírnili dopad podvrženého důvěryhodného certifikátu.
TLSA z projektu DANE
Z projektu DANE při IETF vzešel nový DNS záznam TLSA. Ten může obsahovat otisk certifikátu či veřejného klíče, který je pak pevně svázán s konkrétní doménou. Aplikace tak mohou snadno provést dodatečnou kontrolu, která jim umožní ověřit, zda se serverem zaslaný certifikát shoduje s otiskem v zóně. TLSA záznam musí být podepsán pomocí DNSSEC, aby byla informace o certifikátu přenesena bezpečně.
Více v článku: Protokol DANE aneb (z)krocení zlých certifikačních autorit
Implementace je velmi jednoduchá, jde vlastně jen o vygenerování jednoho dalšího záznamu do zóny. Jak vypadá, se můžete podívat jednoduše:
$ dig +short _443._tcp.www.linuxdays.cz tlsa 3 1 1 C03E8D287834E9B615DE0F8022C48BDAF4B4F3B440D37522C8B8993C E9B9031E
Detaily rozebírá RFC 6698, případně už zmíněný článek o DANE. První tři informace určují, o jaký otisk se jedná, zda jím určujete autoritu či konkrétní certifikát. V příkladu uvedená varianta 3 označuje otisk vlastního certifikátu, kterým se server prokazuje.
Implementujeme
Pokud chcete tento záznam pro svůj server vytvořit, budete potřebovat jediné: certifikát získaný ze svého serveru. Ten získáte buď kopií ze serveru, nebo na dálku pomocí švýcarského nožíku OpenSSL:
$ openssl s_client -showcerts -connect www.linuxdays.cz:443 /dev/null|openssl x509 -outform PEM > certifikat.pem
Teď už stačí použít utilitku Swede (napsaná v Pythonu) nebo webový TLSA generátor. Do něj stačí certifikát nakopírovat a vybrat správné parametry.
S utilitou Swede je to ještě jednodušší, umí si sama ověřit DNSSEC podpisy, stáhnout si certifikát a vytvořit potřebný TLSA záznam:
$ swede create --output rfc --usage 3 --selector 1 www.linuxdays.cz No certificate specified on the commandline, attempting to retrieve it from the server www.linuxdays.cz. Attempting to get certificate from 37.205.10.200 M2Crypto does not support SNI: services using virtual-hosting will show the wrong certificate! Got a certificate with Subject: /description=Drwmx3MYVre6VTtN/C=SK/ST=Nitra/L=Sahy/O=\x00T\x00o\x00m\x00\xE1\x01a\x00 \x00S\x00r\x00n\x00a/CN=*.linuxdays.cz/emailAddress=postmaster@linuxdays.cz _443._tcp.www.linuxdays.cz. IN TLSA 3 1 1 c03e8d287834e9b615de0f8022c48bdaf4b4f3b440d37522c8b8993ce9b9031e Attempting to get certificate from 2a01:430:17:1::ffff:613 M2Crypto does not support SNI: services using virtual-hosting will show the wrong certificate! Got a certificate with Subject: /description=Drwmx3MYVre6VTtN/C=SK/ST=Nitra/L=Sahy/O=\x00T\x00o\x00m\x00\xE1\x01a\x00 \x00S\x00r\x00n\x00a/CN=*.linuxdays.cz/emailAddress=postmaster@linuxdays.cz _443._tcp.www.linuxdays.cz. IN TLSA 3 1 1 c03e8d287834e9b615de0f8022c48bdaf4b4f3b440d37522c8b8993ce9b9031e
Ověřujeme
K ověření je možné použít několik metod. Můžeme opět začít pomocí Swede:
$ swede verify www.linuxdays.cz
Received the following record for name _443._tcp.www.linuxdays.cz.:
Usage: 3 (End-Entity)
Selector: 1 (SubjectPublicKeyInfo)
Matching Type: 1 (SHA-256)
Certificate for Association: c03e8d287834e9b615de0f8022c48bdaf4b4f3b440d37522c8b8993ce9b9031e
This record is valid (well-formed).
Attempting to verify the record with the TLS service...
Got the following IP: 37.205.10.200
M2Crypto does not support SNI: services using virtual-hosting will show the wrong certificate!
SUCCESS (Usage 3): The certificate offered by the server matches the TLSA record
The matched certificate has Subject: /description=Drwmx3MYVre6VTtN/C=SK/ST=Nitra/L=Sahy/O=\x00T\x00o\x00m\x00\xE1\x01a\x00 \x00S\x00r\x00n\x00a/CN=*.linuxdays.cz/emailAddress=postmaster@linuxdays.cz
Got the following IP: 2a01:430:17:1::ffff:613
M2Crypto does not support SNI: services using virtual-hosting will show the wrong certificate!
SUCCESS (Usage 3): The certificate offered by the server matches the TLSA record
The matched certificate has Subject: /description=Drwmx3MYVre6VTtN/C=SK/ST=Nitra/L=Sahy/O=\x00T\x00o\x00m\x00\xE1\x01a\x00 \x00S\x00r\x00n\x00a/CN=*.linuxdays.cz/emailAddress=postmaster@linuxdays.cz
Další možností je dostatečně nový GnuTLS:
$ gnutls-cli --dane www.linuxdays.cz … - Status: The certificate is trusted. - DANE: Certificate matches.
Pro hračičky: Pokud si chcete na věci víc sáhnout, můžete TLSA záznam získat pomocí dig (viz výše) a vypočítat si klíč samostatně. Nejprve je z certifikátu (ten už máme) potřeba vyextrahovat veřejný klíč:
$ openssl x509 -noout -pubkey < certifikat.pem > klic.key
Pak stačí ze souboru s klíčem odstranit hlavičku a patičku a následujícím příkazem dekódovat z base64 a prohnat ho SHA funkcí:
$ base64 -d klic.key | sha256sum -b c03e8d287834e9b615de0f8022c48bdaf4b4f3b440d37522c8b8993ce9b9031e
Z uživatelského hlediska je nejpříjemnější rozšíření DNSSEC/TLSA Validátor od CZ.NIC, které vše udělá za vás. Pokud navštívíte web s TLSA, ukáže vám v adresním řádku pěkné ikonky.
Pozor na to, že validátor nenahrazuje klasické PKI v prohlížeči, takže pokud použijete například self-signed certifikát nebo vlastní CA, prohlížeč vás i přes TLSA záznam upozorní na nedůvěryhodnost certifikátu. Vyzkoušet si to můžete na některé z testovacích stránek DANE Test Sites.
Přímou podporu TLSA má také mail server Postfix, takže si jej můžete nakonfigurovat podle návodu Ondřeje Surého. Mail server se pak bude podle TLSA řídit, a pokud bude záznam uveden, bude vyžadovat od serveru platný SSL certifikát.
CAA záznamy s instrukcemi pro certifikační autority
Úplně za jiný konec uchopil problémy současného PKI standard RFC 6844 z dílny známé certifikační autority Comodo. Řeší se tak jen jeden praktický problém současného PKI modelu, totiž že všechny autority jsou z hlediska klienta stejně důvěryhodné, ačkoli jsou v náročnosti autorizace značné rozdíly. Případný útočník tak může pro útok použít nejvíce benevolentní autoritu, kterou bude nepochybně snadnější uvést v omyl.
V současné době se takový problém částečně řeší jakýmsi neveřejným blacklistem, na kterém jsou zapsána obecná slova a doménová jména, která by autority bez důkladného ověření neměly vydávat. Problém je, že seznam je neveřejný a postup k zapsání na něj netransparentní.
RFC 6844 definuje nový typ DNS záznamu CAA, který má umožnit majitelům domény určit, které certifikační autority jsou oprávněné k vydání certifikátů pro danou doménu. To zní podobně jako TLSA záznam s polem usage=0, zásadní rozdíl ovšem je v tom, kdo takové záznamy validuje.
Pro účinnost TLSA záznamů je nutné je validovat na každém koncovém bodě komunikace, což s sebou nese požadavek na DNSSEC validaci. Něco takového je ideální stav, bohužel bude trvat hodně dlouho, než se něco takového stane i realitou. Záznam typu CAA je proti tomu určen pouze pro validaci certifikačními autoritami, a pouze jako poslední krok před vystavením certifikátu. K úspěšnému zavedení stačí tedy přinutit všechny certifikační autority, jejichž počet je mnohonásobně nižší v porovnání s počtem všech koncových bodů.
Dostane-li certifikační autorita pokyn k vydání certifikátu, zkontroluje přítomnost CAA záznamu v doméně. Pokud doména žádný záznam neobsahuje, má se za to, že CAA zde není podporováno a certifikát je vydán. Je-li však CAA záznam přítomen, je k vydání certifikátu potřebné, aby příslušný záznam obsahoval autorizaci pro danou autoritu. Je-li v certifikátu autorizace pro jinou autoritu, je vydání certifikátu odmítnuto a může o tom být automatizovaně podána zpráva ve formátu IODEF.
Jak vypadá CAA záznam
Pro praktickou ukázku se můžeme podívat například na doménu Comodo.com:
comodo.com. IN TYPE257 \# 19 00056973737565636F6D6F646F63612E636F6D
comodo.com. IN TYPE257 \# 35 0005696F6465666D61696C746F3A73736C6162
75736540636F6D6F646F63612E636F6D Po rozkódování generického typu 257 získáme takovouto mnohem srozumitelnější dvojici záznamů:
comodo.com. IN CAA 0 issue "comodoca.com"
comodo.com. IN CAA 0 iodef "mailto:sslabuse@comodoca.com" Tedy certifikát pro comodo.com smí vystavit jen autorita comodoca.com a případné pokusy o vystavení jinou autoritou mají být hlášeny na uvedenou e-mailovou adresu.
Validovati uživatelem zakázáno
Mohlo by se zdát, že informace z CAA záznamů by mohly posloužit nejen certifikačním autoritám, ale i koncovým systémům. Ve skutečnosti standard však právě takové použití zapovídá. Tím hlavním důvodem je, že certifikáty jsou obvykle vystavovány na dlouhou dobu, zatímco CAA záznamy ukazují pouze aktuálně platnou autoritu. Ta se může během času změnit, takže nesoulad mezi CAA záznamem a vydavatelem certifikátu není považován za chybu. Ostatně, pro validování autority koncovým systémem již existuje záznam typu TLSA a je tedy nežádoucí duplikovat jeho funkcionalitu.
Nápad dobrý, realizace pokulhává
Bohužel, přestože byl CAA záznam standardizován už v lednu 2013, stále se nedočkal velké podpory ze strany autorit. Na nich teď je, aby edukovaly své zákazníky o tom, že si mají do své domény CAA záznamy umístit a jaký má být jejich obsah. Z praktického hlediska se pak nejeví jako příliš vhodné umisťování dalších, potenciálně velmi dlouhých DNS záznamů do kořene (apexu) zóny, vzhledem k navýšení zesilujícího faktoru pro útoky zneužívající DNS.
ČLÁNKY DO MAILU