Ars Technica publikovala zajímavý článek o HTTPS protokolu a případu, který dost výrazně snižuje bezpečnostní hodnotu tohoto protokolu. Abychom si o tom mohli popovídat, je nutné se blíže seznámit s jeho základy. Až doposud byla HTTPS komunikace považována za bezpečnou - až do problému s certifikační autoritou Comodo. Ale zpět k základům:
Bezpečnost HTTPS zajišťují dvě věci:
- kódování - zajišťující, že nikdo nebude rozumět komunikaci mezi klientem a serverem
- autentifikace - zajišťující, že si klient může ověřit, že skutečně komunikuje se serverem o kterém si myslí, že s ním komunikuje.
Problém je však v začátku komunikace se serverem. Každý potřebuje zakódovat informaci, kterou posílají druhému, avšak oba potřebují stejný kódovací klíč. Pochopitelně, nemohou poslat svůj klíč, protože by mohl být odposlechnut. Naštěstí chytrá matematika dovoluje oběma stranám odeslat kódovací klíč bez toho, aniž by byl odposlechnut.
Jak zabránit odposlechu
Představme si situaci, kdy klient odešle informace serveru. V tuto chvíli klient neví, zda se hovoří přímo se serverem nebo s někým jiným. Pokud nemáte zaručeno s kým komunikujete, může se stát následující: Třetí strana může předstírat, že se jedná o například bankovní server. Klient v dobré víře odešle přihlašovací údaje pro přihlášení do banky. Třetí strana pohodlně dešifruje data, provede analýzu, zašifruje je pro odeslání na právoplatný bankovní server. Bankovní server autorizuje klienta a odešle oznámení serveru třetí strany v domnění, že se jedná o klienta. Třetí strana pak obsah zprávy dešifruje, analyuje a zašifruje jej pro klienta. Klient tak nemusí vůbec poznat, že se nebaví přímo se serverem banky. Toto je způsob útoku, který se označuje jako man-in-the-middle (muž uprostřed). HTTPS komunikace a protokoly, které stojí za ní by takové útoky, měly eliminovat.
Zde právě přichází na řadu certifikáty. Certifikáty jsou příkladem použití kryptografie za pomoci veřejného klíče. Při běžném šifrování je stejný klíč používán pro kódování i dekódování dat. Pokud znáte klíč, můžete kódovat i dekódovat data, jak potřebujete. Kryptografie pomocí veřejného klíče však používá dva klíče. Jeden soukromý, který se udržuje v bezpečí a veřejný, který je sdílen se světem. Každý klíč funguje pouze jedním směrem. Můžete data zakódovat veřejným klíčem ,ale rozšifrovat je lze pouze soukromým. Naopak data zakódovaná soukromým klíčem lze dekódovat pouze veřejným klíčem.
Jak funguje SSL
Kryptografie pomocí veřejného klíče je velmi silným nástrojem, protože umožňuje vytvářet důvěru. Pokud je možné veřejný klíč použít k dekryptování kousku informace, pak je jisté, že informace byla původně zašifrována odpovídajícím soukromým klíčem. A právě tento mechanismus je zabudován do SSL. Server publikuje certifikát - data obsahující informace o jménu společnosti, veřejný klíč a některé další kousky informací - a když se klient připojuje na server, posílá serveru některé informace zakódované pomocí veřejného klíče z certifikátu. Server je pak dekóduje za pomoci soukromého klíče. Tato informace je pak dostatečná pro kódování následující komunikace.
Protože pouze server zná soukromý klíč - a tak pouze server může dešifrovat informaci zakódovanou soukromým klíčem - pro klienta je to dostatečný důkaz, že komunikuje se správným majitelem certifikátu. To však dosud nestačí k tomu, aby zabránilo útoku man-in-the-middle. Proto je nutné provést ještě trochu další práce. Třetí strana si může vytvořit vlastní pár veřejného a soukromého klíče.
Řešením je důvěra
Aby bylo možné zajistit, že server je skutečně banky (nebo kohokoliv jiného s certifikátem), vytvořil se řetěz důvěryhodných certifikátů. Pro ověření autentičnosti a identifikace samotných certifikátů, jsou tyto certifikáty spojeny s důvěryhodným zdrojem certifikátů. Místo jednoduchého generování certifikátu (označovaných jako "self-signed" certifikáty), je nutné využít služeb Certifikační Autority (CA), která umožňuje vygenerování certifikátu. Každý certifikát, který CA vygeneruje je označen, že pochází od CA za pomocí kryptografie veřejného klíče popsané výše. Každý www prohlížeče nebo obecně systém obsahuje seznam důvěryhodných certifikačních autorit a jejich klíčů, které přímo nebo nepřímo odkazují na tzv. Root certifikát - kořenový certifikát, kterým CA podepisuje všechny své vydané certifikáty. Tento způsob podepisování totiž umožňuje několik úrovní certifikátů. Proto se můžete setkat s tím, že příslušná certifikační autorita vydala 1. root certifikát a několik dalších certifikátů, které lze ověřit pomocí root certifikátu. Certifikáty vydané certifikační autoritou pak mohou být podepsány jedním z těch "dalších" certifikátů a nikoliv přímo root certifikátem. Abychom to zjednodušili. V prohlížeči pak certifikáty mohou tvořit stromovou strukturu (proto se také hovoří o root certifikátu).
V praxi se setkáváme systémy mají vlastní seznam certifikátů, které výrobci operačního systému označili jako bezpečné. Podmínky pro přidání certifikátu do operačního systému bývají velmi přísné. Podmínky pro Mac OS X jsou například zde (http://www.apple.com/certificateauthority/ca_program.html). Mezi jiným se požaduje audit, maximální množství certifikátů které je možné akceptovat a hlavně je vyžadována podpora pro CRL - tedy seznam zrušených certifikátů.
V principu každá CA může vydat certifikát, pokud organizace splní podmínky odesláním notářsky ověřených papírů či podobných mechanismů. To znamená, že certifikát vystavený například pro Českou spořitelnu bude vydán pouze České spořitelně. Některé certifikáty obsahují rozšíření nazývané Extended Validation (EV), které vyžadují vyšší stupně identifikace (a pochopitelně i ceny) před tím, než jsou vydávány. Certifikační Autorita by tak neměla vydat certifikát, který reprezentuje Českou spořitelnu, když se nejedná o Českou spořitelnu.
A to je konečně poslední věc, která je schopná kompletně znemožnit útok man-in-the-middle. Ačkoliv třetí strana může mít svůj vlastní certifikát, který se tváří jako server ke kterému se klient připojuje, nemůže vytvořit spojení s žádným kořenovým certifikátem certifikační autority. CA vydávají certifikáty jen právoplatným majitelům. A protože www prohlížeče nedůvěřují certifikátům podepsaných kořenovými certifikáty, které nemají v seznamu, třetí strana se nemůže potají dostat mezi komunikaci klienta a serveru - takový pokus způsobí varování a chybu ve www prohlížeči. Stejnou chybu, kterou lidé zaznamenají také v případě českého elektronického podpisu. Jednoduše proto, že kořenový certifikát používaný pro elektronický podpis není v seznamu kořenových certifikátů.
Nyní tedy již víme, jak to celé funguje. Každá část je nezbytná pro to, aby komunikaci fungovala. Bez řetězu důvěry nelze věřit autorizaci certifikátů a bez autorizace certifikátů nelze věřit šifrování a bez šifrování není žádná ochrana před odposlechem. Matematika v pozadí celého procesu je velmi robustní a lze říci že je to nejsilnější článek celého řetězu. Bohužel je příliš mnoho důvěry vkládáno na bedra kořenových certifikátů. Pokud CA začne vydávat certifikáty, které by neměla, lidem kterým by neměla, celý systém začne kolabovat. Hacker tak může fungovat jako man-in-the-middle a klientský prohlížeč bude důvěřovat jeho certifikátu. Nebude zde žádné varování a vše bude pracovat, jako by se nic nedělo.
Kolosální chyba certifikační autority Comodo
A to je přesně to, co provedla certifikační autorita Comodo. Devět krát. Uživatelský účet, který náležel "důvěryhodnému" partnerovi společnosti Comodo v jižní Evropě byl hacknutý a použitý účet byl zneužit k vytvoření devíti podvodným certifikátům. Není bez zajímavosti, že certifikáty byly vydány pro servery mail.google.com, www.google.com, login.yahoo.com, login.skype.com, addons.mozilla.org,login.live.com a "global trustee" (což není platné doménové jméno a tak není zcela zřejmé k čemu může být tento certifikát použit).
Comodo a ve svém prohlášení trvá na tom, že společnost samotná nebyla napadena a její systémy jsou bezpečné. Hacknutý účet byl zrušen a společnost provedla "další audit a kontrolu" blíže neurčené podoby.
Ještě před veřejným prohlášením společnosti Comodo, bezpečnostní expert a vývojář Toru Jacob Appelbaum dokumentoval specifické změny, které se objevují v Mozzile Firefoxu a Chromium (open source alternativa Google Chrome) při práci s certifikáty. 16. března Chromium patchovalo blacklist šesti certifikátů (což znamená, že je bude prohlížeč odmítat i v případě, že se odkazují na legitimní kořenový certifikát). O dvanáct hodin později, Google vydal důležitou aktualizaci Chrome, které zahrnuje nově přidané blacklistované certifikáty. Ve stejný den byly provedeny změny ve Firefoxu (změna, která pravděpodobně zdržela vydání Firefoxu 4). Další detektivní práce provedená Applebaumem pak ukazuje, že blacklistované certifikáty byly vydány dealerem Comoda ze Salt Lake City - UserTrust.
Comodo nijak neobjasnilo jak se podařilo nabourat účet. Není jasné, jaká je spojitost mezi uživatelským účtem z jižní Evropy a dealerem v Utahu. Jedna věc je však zcela zřejmá. Celý systém není zcela důvěryhodný.
Certifikáty však byly navrženy tak, aby do určité míry byly schopné odolat takovýmto útokům. Kořenové certifikáty, ty které obsahuje operační systém a WWW prohlížeče obsahují URL odkazující na Certficate Revocation List (CRL). Jak již název napovídá, jedná se o seznam certifikátů, příslušné CA, které byly z různých důvodů zrušeny. Každý program, který používá certifikáty, by pak měl překontrolovat, zda není certifikát na tomto seznamu. Aktualizací tohoto mechanismu je OCSP, který se také používá a EV certifikáty vyžadují využití OCSP protokolu. Takže když jsou špatné certifikáty objeveny, mělo by být možné jednoduše je zrušit a vše bude v pořádku.
Bohužel nikoliv. Zrušení certifikátu (revocation) je prakticky k ničemu. Pokud server s CRL nebo (OCSP server) řekne prohlížeči, že má momentálně interní chybu, místo aby prohlížeč odmítl všechny certifikáty, prohlížeč pouze potichu certifikátu důvěřuje. Občas zde mohou být drobné náznaky, že je něco v nepořádku. Například EV certifikát nezpůsobí zelený příkazový řádek, ale spojení se uskuteční. To je klasický příklad designu, který klade větší důraz na spolehlivost než na bezpečnost. A v tomto případě je to velký problém, protože pokud je útočník man-in-the-middle v pozici, aby mohl odposlouchávat vaši komunikaci, zcela jistě bude také v pozici, aby mohl zabránit komunikaci se servery certifikační autority. Způsob jakým je implementováno ověřování CRL tak otevírá vrátka pro útoky typu man-in-the-middle.
Identifikace útočníků
Jedním z mála detailů, které Comodo zveřejnil byla IP adresa, která byla použita útočníky. Ukazoval na Teherán v Iráku. Comodo tvrdí, že jeden z certifikátů byl testována iránském serveru. Pokud budeme předpokládat, že se jedná o skutečnou identitu útočníků a ne jen pokus o její maskování, pravděpodobně někdo v Iránu - možná vláda, možná nikoliv - si přál poslouchat komunikaci lidí v Iránu. Vydané certifikáty byly určeny pro komunikační služby a jednalo by se o relativně triviální způsob jak se dostat k přihlašovacím údajům účtů na Google, Yahoo či hotmailu. Právě zaměření na komunikaci ukazuje záměr odposlouchávat než krást informace o kreditiních kartách atp.
Despotickým režimům nezbývá než používat tento způsob odposlouchávání, navíc součástí standardní sady kořenových certifikátů bývají i státní certifikáty jako (UAE Etisalat, který je znám tím, že provádí špionáž a cenzuru dle požadavků vlády) a pokud vláda může vydat svůj vlastní certifikát, může provést útoky man-in-the-middle stejným způsobem - a jsou zde důkazy, že to vlády (alespoň některé) dělají. V takových případech ani seznam zrušených certifikátů nepomůže.
Když je důvěra prolomena
Není to však první případ, kdy byl vystaven certifikát chybně. Svého času Verisign vydala certifikát člověku, který se maskoval jako zaměstnanec Microsoftu. Certifikát umožňoval podepsání kódu a třetí strana tak mohla produkovat programy, které vypadaly jako programy Microsoftu. Objevily se chyby v algoritmech při implementaci atp. Tyto chyby se však postupně podařilo odstranit.
Útok na společnost Comodo je horší. Jacob Applebaum zjistil, že jeden z certifikátů (login.yahoo.com) byl skutečně použit a neschopnost odvolat certifikát se ukazuje jako velkým problémem. Jednoduše řečeno, model kdy určité společnosti získávají absolutní kontrolu nad tím čemu má prohlížeč věřit nefunguje. Útok na jakoukoliv certifikační autoritu ohrožuje všechny uživatele, stejně jako zahrnutí méně důvěryhodné certifikační autority do seznamu důvěryhodných autorit.
Odklon od tohoto modelu bude během na dlouhou trať. Komerční povaha certifikační autorit bude tlačit k tomu, aby se zachoval stávající systém. Společnosti nebudou chtít investovat peníze do dalšího software, zejména, pokud je již investovaly do současného. Objevují se návrhy na drobné opravy stávajícího systému například svázat příslušnou certifikační autoritu s certifikátem, což by ve finále znamenalo, že pouze jedna certifikační autorita by mohla vydat certifikát pro doménu. Pokud by pak chtěl někdo provést útok man-in-the-middle, znamenalo by to, že by se musel nabourat do příslušné certifikační autority.
Řešení pro problémy zrušených certifikátů může být jednodušší. Minimálně ve smyslu, že nevyžaduje žádné radikální změny v tom jak SSL pracuje - stačí zajistit, že certifikáty budou platné jen několik dní a vytvořit automatické procesy na jejich aktualizaci. To sice vytvoří břemeno pro CA, ale zmenší dobu, po kterou bude možné certifikáty zneužívat. Nepomůže to lépe zabezpečit certifikační autority, ale zcela jistě to pomůže vyřešit problémy u případu Comodo.
Závěrem
Je tedy dobré vědět, že HTTPS protokol, stejně jako další služby využívající SSL (bezpečné verze protokolů SMTP,POP3,IMAP, Jabber a další) poskytují dostatečnou ochranu proti příležitostnému odposlouchávání například v kavárně. Pokud by jste však na nich byli doslova životně závislí - nedělejte to. Tak kvalitní zabezpečení tato komunikace nepřináší. Zkušenosti ukazují, že centralizovaný model důvěry nefunguje.
Odkazy z novinek:
Odkazy z Tipů a Triků:
