Práce aplikací s certifikáty veřejných klíčů

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Práce aplikací s certifikáty veřejných klíčů BAKALÁŘSKÁ PRÁCE Radim Ošťádal Brno, 2010

2 Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. V Brně, 11. května 2010 Vedoucí práce: doc. RNDr. Václav Matyáš, M.Sc., Ph.D. ii

3 Poděkování Chtěl bych touto cestou poděkovat vedoucímu své bakalářské práce, panu doc. RNDr. Václavu Matyášovi, M.Sc., Ph.D., za jeho cenné připomínky, ochotu a trpělivost při vedení mé bakalářské práce. iii

4 Shrnutí Práce se zabývá využitím certifikátů veřejného klíče podle standardu X.509, a to především při zabezpečování komunikace pomocí protokolu SSL/TLS, a při zabezpečení elektronické pošty pomocí standardu S/MIME. Hlavním cílem práce je zmapovat rozdíly mezi jednotlivými webovými prohlížeči a ovými klienty na poli bezpečnosti a chyby, které dělají při práci s certifikáty veřejných klíčů. iv

5 Klíčová slova Bezpečnost, certifikát, digitální podpis, ový klient, S/MIME, SSL/TLS, webový prohlížeč v

6 Obsah 1 Úvod Základní pojmy Kryptografie Symetrická kryptografie Asymetrická kryptografie Certifikát podle standardu X Protokoly SSL a TLS Standard S/MIME Testování webových prohlížečů Příprava testování Výsledky testování Opera Google Chrome Internet Explorer Maxthon Lataza Browser Safari Mozilla Firefox Wyzo SeaMonkey Netscape Navigator Zhodnocení výsledků testování Testování ových klientů Příprava testování Výsledky testování MS Outlook Express Windows Live Mail MS Outlook Mozilla Thunderbird Netscape Mail 9.0a The Bat Mulberry Becky! Internet Mail Eudora FoxMail vi

7 4.3 Zhodnocení výsledků testování Závěr Seznam použité literatury vii

8 Kapitola 1 Úvod V dnešní době pronikají informační technologie do nepřeberného množství odvětví. V mnoha oblastech přebírají roli hlavního komunikačního kanálu a jejich prostřednictvím začínáme spravovat stále více veřejných i soukromých informací. Zatímco ještě před pár lety patřily k nejběžnějším komunikačním prostředkům telefon a pošta, dnes je to . Zatímco dříve lidé museli do banky chodit, dnes většina z nich používá internetové bankovnictví. Prostřednictvím informačních technologií přistupujeme ke stále citlivějším informacím, jejichž hodnota neustále narůstá. V důsledku toho před námi vyvstává otázka, jak tyto informace a potažmo své vlastnictví chránit. Jedním z nejdůležitějších požadavků je dnes zajištění bezpečné komunikace s internetovými servery. Zde potřebuje uživatel také vědět, zda se nejedná o podvodný server, který se z něj snaží vylákat soukromé informace. Požadavek na bezpečnou komunikaci splňují internetové servery využívající zabezpečené spojení pomocí protokolu Secure Sockets Layer (SSL), popřípadě pomocí jeho následníka Transport Layer Security (TLS). Dalším neméně důležitým požadavkem je ochrana elektronické pošty, kterou je možné zajistit pomocí digitálního podpisu. Pro zajištění bezpečné komunikace s internetovými servery i pro zabezpečení elektronické pošty je v dnešní době zcela nezbytná infrastruktura veřejných klíčů (Public Key Infrastructure, PKI). Při zajišťování bezpečnosti v rámci sítě Internet hrají významnou roli aplikace, které pro prohlížení webových stránek či přijímání a odesílání ové pošty používáme. Jedná se především o webové prohlížeče a ové klienty. V této práci se zaměřuji právě na tyto aplikace a snažím se odhalit jejich nedostatky při práci s certifikáty veřejných klíčů. Zabývám se také kvalitou uživatelského prostředí a podobou a adekvátností informací, které jsou předkládány uživateli v případě bezpečnostních rizik. Jako úvod do problematiky slouží druhá kapitola, v níž definuji základní pojmy. Mezi ně patří certifikáty veřejných klíčů podle standardu X.509 a standard Secure/Multipurpose Internet Mail Extensions (S/MIME), který je nezbytný pro práci se zabezpečenou poštou založenou na PKI. V obou případech se zabývám vývojem těchto standardů i aktuální situací. Dále se věnuji protokolům SSL a TLS, které jsou používány pro zabezpečenou komunikaci s internetovými servery. Tato kapitola nabízí také úvod do kryptografie, se kterou souvisí celá práce. Třetí kapitola se zabývá testováním webových prohlížečů. Nejprve popisuji přípravy na testování a metodiku provedení samotných testů, které sdružuji do jednotlivých testovacích sad. Hlavní část kapitoly představují dosažené výsledky deseti webových prohlížečů v těchto 1

9 1. ÚVOD testovacích sadách. Rozhodujícím hodnotícím kritériem je korektní práce s certifikáty veřejných klíčů, avšak prohlížeče srovnávám i po stránce uživatelské přívětivosti. Na závěr nabízím shrnutí výsledků a celkové zhodnocení. Ve stejném duchu jako kapitola třetí navazuje i kapitola čtvrtá, která se věnuje testování šestnácti ových klientů. Poslední kapitola nabízí shrnutí celé práce a jejích cílů. Dále pak prezentuje dosažené výsledky a jejich přínos. 2

10 Kapitola 2 Základní pojmy V této kapitole definuji základní pojmy, které jsou nezbytné pro pochopení dalšího textu práce, a především výsledků testování, prezentovaných v dalších kapitolách. Nejprve se zabývám samotnou kryptografií, dále pak certifikáty veřejných klíčů podle standardu X.509 a následně ukazuji práci protokolů SSL a TLS. Nakonec se věnuji standardu pro S/MIME, který je nepostradatelný při práci se zabezpečenou poštou založenou na infrastruktuře veřejných klíčů. 2.1 Kryptografie Kryptografie je věda zabývající se studiem matematických technik, vztahujících se k aspektům informační bezpečnosti, jako jsou důvěrnost, integrita, ověřený původ dat a autentizace jednotlivých entit [1]. Spolu s kryptoanalýzou, která se zabývá luštěním šifer bez znalosti tajného klíče, je součástí vědy zvané kryptologie. Již v devatenáctém století zformuloval Auguste Kerckhoffs princip, který v kryptografii platí dodnes. Bezpečnost kryptosystému nesmí záviset na utajování algoritmu. Ten musí být veřejně znám a bezpečnost musí záviset pouze na utajovaném klíči [1]. V dnešní době hovoříme o tzv. výpočetní bezpečnosti, která spočívá ve skutečnosti, že útočník nemá dostatek výpočetní síly a času na rozluštění šifry. Mezi problémy, pro které v dnešní době neexistuje efektivní algoritmus, patří například diskrétní logaritmus nebo faktorizace velkých čísel. Kryptografii můžeme na základě druhu použitých klíčů rozdělit na tři části. Jedná se o symetrickou kryptografii, asymetrickou kryptografii a další primitiva, mezi které patří například hashovací funkce, jednosměrné permutace nebo generátory náhodných čísel [1] Symetrická kryptografie Počátky symetrické kryptografie se datují kolem roku 2000 př. n. l. [2]. Symetrické metody jsou založené na sdílení společného tajemství klíče. Z toho ale přímo vyplývá problém ustanovení takového tajemství. Problém bezpečného přenosu zprávy je v tomto případě pouze převeden na problém bezpečného přenosu tajného klíče. Tuto situaci můžeme řešit jinými prostředky, jako například osobním setkáním, nebo nějakou infrastrukturou, zajišťující distribuci klíčů. Všechny podobné přístupy se ale v globálním měřítku ukázaly jako nevhodné [2]. Symetrické šifry můžeme rozdělit na blokové a proudové. Proudové šifry šifrují každý znak otevřeného textu zvlášť, nejčastěji po jednotlivých bitech. Blokové šifry naopak pracují 3

11 2.1. KRYPTOGRAFIE s bloky dat fixní délky a používají pevně zvolenou transformaci. Proudové šifry jsou většinou rychlejší a mají jednodušší hardwarové implementace. Často se používají v telekomunikačních aplikacích, kde lze jen velmi omezeně využívat vyrovnávací paměť. Jejich využití je výhodné také v prostředí, kde je velká pravděpodobnost chyby při přenosu, protože nedochází k propagaci této chyby do dalších dat. Blokové šifry mohou naopak plnit funkci Message Authentization Code (MAC) nebo hashovacích funkcí. Hlavní nevýhodou symetrické kryptografie je nutnost velkého množství klíčů a potřeba jejich distribuce. Aby spolu kupříkladu mohlo komunikovat n subjektů, je potřeba mít n (n 1) 2 klíčů. To znamená, že pro šifrovanou komunikaci ve středně velké firmě o 50 zaměstnancích by bylo potřeba sdílet 1225 různých klíčů. Na druhou stranu mezi výhody patří nízká výpočetní náročnost symetrických šifer. Jejich použití je vhodné také v takových případech, kdy šifrovaná data nikam neposíláme, jako například při ochraně souborů na osobním počítači Asymetrická kryptografie Na rozdíl od symetrické kryptografie je ta asymetrická velmi mladá. Její počátky lze hledat v roce 1977, kdy byl představen RSA kryptosystém, založený na nemožnosti efektivně faktorizovat velká čísla. Ve skutečnosti byly základy asymetrické kryptografie položeny ještě o několik let dříve Cliffordem Cocksem. Jeho výzkum byl však ještě do nedávné doby utajován [2]. Asymetrická kryptografie umožňuje šifrování dat, a především také realizaci digitálního podpisu. Každá entita zde disponuje dvěma klíči. Prvním je klíč soukromý, který se používá pro dešifrování zprávy nebo pro vytváření digitálního podpisu. Musí být držen v tajnosti. Druhým je potom klíč veřejný, který se používá pro šifrování a ověřování digitálního podpisu. Samozřejmostí je pak nemožnost odvodit soukromý klíč z klíče veřejného. Asymetrická kryptografie sama o sobě neřeší autenticitu veřejného klíče. Je tedy potřeba rozhodnout, zda daný veřejný klíč patří opravdu dané entitě. Řešením tohoto problému je infrastruktura veřejných klíčů [3], která je v dnešní době nejrozšířenějším prostředkem pro zajištění důvěryhodnosti digitálního podpisu. Mezi hlavní výhody asymetrické kryptografie patří především potřeba menšího počtu klíčů, než je tomu u kryptografie symetrické. Má-li každá entita jeden veřejný a jeden soukromý klíč, znamená to, že pro n entit je zapotřebí 2n klíčů. Ve stejné situaci jako v předcházejícím příkladu by tedy firma o 50 zaměstnancích potřebovala pro zajištění bezpečnosti 100 klíčů, což je podstatně méně než Největší nevýhodou asymetrické kryptografie je její pomalost ve srovnání s kryptografií symetrickou. Proto se nejčastěji využívají dohromady, přičemž text je zašifrován symetrickou šifrou s náhodným klíčem. Klíč je pak zašifrován pomocí asymetrické šifry. V případě digitálního podpisu je nejprve vytvořen hash zprávy fixní délky a ten je následně podepsán s využitím asymetrické kryptografie. 4

12 2.2 Certifikát podle standardu X CERTIFIKÁT PODLE STANDARDU X.509 Standard X.509 byl původně navržen jako autentizační rámec pro X.500 adresáře [4]. Ty mají hierarchickou strukturu a jednotlivé atributy mohou být přiděleny osobám, počítačům, společnostem nebo jednotlivým tiskárnám. To znamená, že každou entitu lze jednoznačně identifikovat a každá může mít svůj soukromý a veřejný klíč. Tento návrh předpokládá hierarchickou strukturu certifikačních autorit. Certifikát podle standardu X.509 lze najít na obrázku 2.1. První verze standardu X.509 se objevila již v roce 1988 jako první návrh pro PKI [4]. Byla vydána organizací International Telecommunication Union, Telecommunication Standardization Sector (ITU-T) spolu s mezinárodní organizací pro standardizaci (ISO). To umožnilo její globální přijetí a rozšíření. První verze byla velmi jednoduchá a v dnešní době je již nedostatečná. Obsahovala pouze 7 polí: verze certifikátu; sériové číslo certifikátu; algoritmus, kterým je certifikát podepsán; jméno certifikační autority, která certifikát vydala; identita vlastníka certifikátu; veřejný klíč vlastníka certifikátu; platnost certifikátu. Druhá verze byla představena o pět let později, v roce 1993, a přinesla jen minimální změny [4]. Obsahovala pouze dvě nová pole: jedinečný identifikátor vlastníka certifikátu; jedinečný identifikátor certifikační autority. Druhá verze problémy spojené s první verzí nevyřešila. Pole, která byla v praxi zapotřebí, v této verzi stále chyběla [4]. Třetí verze byla představena v roce 1996 a kompletní specifikaci lze najít v ITU-T Recommendation X.509, popřípadě pod označením ISO/IEC [5]. Jejím největším a nejdůležitějším přínosem je podpora rozšíření. Je definována syntax, která umožňuje vytváření vlastních rozšíření certifikátu. Tím jsou odstraněny hlavní nedostatky obou předešlých verzí, ale zároveň se objevuje jistá nekompatibilita. Každé rozšíření má jméno a pole, které má za úkol indikovat, zda se jedná o kritické nebo volitelné rozšíření. Aplikace, která neumí pracovat s rozšířením označeným jako kritické, musí takovýto certifikát ihned zamítnout. Na druhou stranu, pokud se jedná o rozšíření volitelné, může ho ignorovat. Aby nedošlo k nekontrolovatelnému růstu rozšíření, bylo v roce 1997 čtrnáct z nich fixováno a staly se součástí standardu [4]. V dnešní době se v prostředí Internetu nepoužívá přímo standard X.509, ale jeho mutace pro potřeby Internetu, označovaná jako internetový profil normy X.509 [3]. Internetový profil X.509 je specifikován v několika RFC, konkrétně to jsou RFC 3279 [6], RFC 3280 [7] a v RFC 3281 [8]. Mezi protokoly, které nejčastěji využívají certifikáty X.509, patří především SSL, TLS, S/MIME, Internet Protokol Security (IPSec), Secured Shell (SSH) a zabezpečené elektronické přenosy (SET). 5

13 2.3. PROTOKOLY SSL A TLS Obr. 2.1: Certifikát podle standardu X Protokoly SSL a TLS Protokoly SSL a TLS jsou využívány pro zabezpečenou komunikaci mezi klientem a serverem. Vytváří rámec pro použití šifrovacích a hashovacích funkcí. Protokol SSL byl vyvíjen společností Netscape Communications, která publikovala tři jeho verze. První verze byla jen testovací, teprve druhá byla použita v praxi. Stále však obsahovala bezpečnostní chyby, z nichž nejvýznamnější byla náchylnost na útok man in the middle [10]. Třetí verze byla představena v roce 1996 a její specifikaci můžeme najít v dokumentu The SSL Protocol Version 3.0 [9]. Z této verze potom vychází protokol TLS, který je v současné době nejvíce rozšířen a podporován [10]. Celkem existují tři verze, mezi kterými jsou jen minimální rozdíly. Specifikaci verze 1.0 můžeme najít v RFC 2246 [11], verze 1.1 v RFC 4346 [12] a specifikaci poslední verze 1.2 v RFC 5246 [13]. Protokol SSL/TLS zajišťuje autentizaci obou komunikujících stran pomocí asymetrické kryptografie, integritu zpráv pomocí MAC a důvěrnost šifrováním veškeré komunikace zvolenou symetrickou šifrou. Protokol SSL/TLS se nachází mezi aplikační a transportní vrstvou referenčního ISO/OSI modelu a skládá se ze dvou hlavních částí. Těmi jsou Record layer protocol (RLP) a Handshake 6

14 2.3. PROTOKOLY SSL A TLS protocol (HP). Součástí HP jsou ještě dva další pomocné protokoly Change cipher specification protocol (CCSP) a Alert protocol (AP) [10]. Record layer protocol zpracovává aplikační data, provádí fragmentaci, kompresi a samotné šifrování dat. Na druhé straně pak data opět dešifruje a ověřuje kontrolní součty. Protokol RLP se nestará o typ použitého šifrovacího algoritmu nebo stanovení šifrovacího klíče. Tyto informace má již od HP. Handshake protocol se aktivuje ihned po navázání spojení a zajišťuje identifikaci komunikujících stran, ustanovení šifrovacích algoritmů, kompresních algoritmů a dalších atributů. Dále pak vytváří master secret, ze kterého jsou odvozeny šifrovací klíče, iniciační vektory a MAC. Průběh protokolu je následující: 1. Klient se chce připojit k serveru a posílá zprávu ClientHello, která obsahuje číslo nejvyšší verze podporovaného SSL/TLS, číslo sezení (je prázdné, pokud se jedná o nové sezení), seznam podporovaných šifer a kompresních metod a náhodné číslo. 2. Klient čeká na odpověď v podobě zprávy ServerHello, která bude obsahovat číslo nejvyšší verze SSL/TLS, kterou podporuje server i klient. Dále bude obsahovat šifru a kompresní metodu, které jsou vybrané ze seznamu obdrženého v kroku jedna, náhodné číslo a svůj certifikát veřejného klíče (server může také požadovat autentizaci klienta). 3. Klient ověří certifikát serveru a to, zda všechny šifry vyhovují. Nyní pošle serveru požadavek na výměnu klíčů. Ta se liší podle toho, zda je použit algoritmus RSA, Diffie-Hellman nebo Fortezza. Ve všech případech budou na konci server i klient sdílet společné 48bytové premaster secret. Z toho pak odvodí master secret. Z master secret a náhodných čísel z ClientHello a ServerHello se pak odvodí dva klíče sezení pro šifrování zpráv, dva pro MAC a dva iniciační vektory pro použití symetrické šifry v CBC režimu. Nakonec klient pošle potvrzení zvolených šifer. Od této chvíle bude již komunikace šifrovaná a klient pošle zprávu, že končí tuto fázi. V případě, že server vyžadoval autentizaci klienta, byla provedena v tomto kroku. 4. Nakonec pošle server potvrzení použitých šifer a zprávu o ukončení této fáze, čímž HP končí. Change cihper specificatin protocol je jednoduchý protokol, který obsahuje jen jedinou zprávu. Ta říká, že došlo ke změně šifrovacích parametrů a nyní se budou již používat ty nové. Lze jej zavolat i po konci úvodní fáze. Alert protocol zabezpečuje přenos varování v případě jakéhokoliv problému v komunikaci obsahuje pole závažnost varování a popis problému. Používané algoritmy: výměna klíčů: RSA, Fortezza, Diffie-Hellman; proudové symetrické šifry: RC4 s délkami klíčů bitů; blokové symetrické šifry: DES, DES40, 3DES, IDEA, Fortezza; hashovací algoritmy: MD5, SHA. 7

15 2.4. STANDARD S/MIME 2.4 Standard S/MIME Koncept bezpečné pošty jako první definuje Security Multiparts for MIME [3]. Jsou to typy Multipart/Signed pro digitálně podepsanou zprávu a Multipart/Enrypted pro šifrovanou zprávu. V obou případech je původní zpráva rozdělena na dvě části. To v případě podpisu umožňuje zobrazení zprávy i bez podpory S/MIME. V případě zprávy s digitálním podpisem je první část samotná zpráva a po ní následuje digitální podpis této zprávy. Povinnými parametry jsou Micalg, který definuje algoritmus pro výpočet otisku dat, a Protocol, který určuje protokol, jímž je specifikován digitální podpis v druhé části. Použití standardu S/MIME určuje následující hodnota: Protocol: Application/pkcs7- signature. V případě šifrované zprávy určuje první část použitý způsob šifrování a druhá část je samotná šifrovaná zpráva. Standard pro S/MIME využívá asymetrickou kryptografii a je používán pro end-to-end zabezpečení ových zpráv [3]. Samotné zabezpečení zprávy provádí odesílatel a poté je již zpráva přenášena nezabezpečeným kanálem. Protokol S/MIME zajišťuje autentizaci, integritu, nepopiratelnost odeslání a důvěrnost. Aktuální verze protokolu S/MIME je dnes 3.1 a její přesnou specifikaci můžeme najít v normách RFC 3850 [14] a RFC 3851 [15]. Na začátku roku 2010 byla navíc zveřejněna nová verze 3.2, která je definována v RFC 5751 [16]. Pro digitální podpis využívá typ Multipart/Singned, pro šifrování pak elektronickou obálku typ EnvelopedData. Od verze 3.1 navíc podporuje komprimovanou zprávu typ CompressedData. Tyto tři typy lze libovolně kombinovat. Nakonec zmíním v dnešní době stále ještě rozšířenou aplikaci Pretty Good Privacy (PGP) [17], která pracuje s tzv. sítí důvěry bez centrální důvěryhodné třetí strany. Přesnou specifikaci lze nalézt v RFC 3156 MIME Security with OpenPGP [18]. Přesto je v dnešní době nejrozšířenější a nejvýznamnější standard S/MIME postavený na PKI. 8

16 Kapitola 3 Testování webových prohlížečů V této kapitole se věnuji testování webových prohlížečů. Nejprve nastíním samotné přípravy na testování, dále uvádím seznam testů s jejich podrobným popisem. Nakonec prezentuji výsledky dosažené jednotlivými webovými prohlížeči. Cílem testování bylo odhalit nedostatky webových prohlížečů při práci s certifikáty veřejných klíčů. Zaměřuji se také na kvalitu uživatelského prostředí a na informace, které jsou předkládány uživateli v případě bezpečnostních rizik. Testování proběhlo na počítači s operačním systémem Microsoft Windows Příprava testování Pro samotné testování bylo nutné mít k dispozici velké množství certifikátů veřejných klíčů a k nim příslušné soukromé klíče. Z tohoto důvodu jsem vytvořil vlastní certifikační autoritu (CA) ServerRootCA. Při tvorbě této CA jsem využil nástroj OpenSSL a vycházel jsem přitom z návodu, který je uveden v knize Velký průvodce infrastrukturou PKI [3]. Tato certifikační autorita byla v době testování importovaná jako důvěryhodná v daných prohlížečích, případně v samotném operačním systému. Jako další jsem připravil testovací webové stránky, které běžely na webovém serveru Apache. Při nastavení webového serveru a při konfiguraci protokolu SSL jsem vycházel především z dokumentace k tomuto nástroji a z návodu v knize Administering and Securing the Apache Server [19]. Po vytvoření dostatečného počtu certifikátů a zprovoznění webového serveru jsem mohl přistoupit k samotnému testování. Provedené testy jsou tématicky rozděleny do tří testovacích sad. V první sadě testů se zabývám podporou zabezpečení obecně. Hodnotím, jaké nabízí prohlížeč bezpečnostní nastavení a volby, jakým způsobem pracuje s certifikáty veřejných klíčů a také, jak chrání soukromý klíč importovaného osobního certifikátu. Dále si všímám přívětivosti uživatelského prostředí a zabývám se upozorněními, které jsou zobrazeny jak v případě zabezpečeného připojení, tak v případě, kdy kořenový certifikát není zařazen mezi důvěryhodné certifikační autority. V poslední části této sady ověřuji, zda jednotlivé webové prohlížeče pracují 9

17 3.2. VÝSLEDKY TESTOVÁNÍ i s certifikáty, při jejichž vydávání byla použita hashovací funkce Secure Hash Algorithm 2 (SHA-2), konkrétně SHA-512. Ve druhé testovací sadě se věnuji situacím, kdy certifikát veřejného klíče není z nějakého důvodu platný. V první sadě nebyl kořenový certifikát zařazen mezi důvěryhodné CA. Zde naopak kořenový certifikát mezi důvěryhodné CA zařazený je, ale problémy s certifikátem mají jiný charakter. Postupně testuji tyto situace: certifikát je vydaný pro rozdílnou doménu; certifikát je podepsaný sebou samým a v tomto případě není zařazen mezi důvěryhodné certifikační autority; certifikát je zařazen na platný Certificate Revocation List (CRL); platnost certifikátu již skončila; certifikát ještě platit nezačal. Posledním testem této sady je schopnost webových prohlížečů odhalit nedostupný CRL a dát tuto skutečnost nějakým způsobem na vědomí uživateli. V poslední sadě testuji možnosti webových prohlížečů odhalit zneplatnění certifikátu během probíhajícího SSL spojení. Při samotném testování jsem aktivně procházel webové stránky ještě dalších deset minut po zneplatnění certifikátu. Důvodem bylo dát webovému prohlížeči šanci tuto skutečnost odhalit. Konkrétní způsoby zneplatnění certifikátu během probíhajícího SSL spojení jsou následující: zařazení certifikátu na CRL; odebrání kořenového certifikátu ze seznamu důvěryhodných CA; skončení platnosti certifikátu. V posledním testu této sady se zabývám podporou oboustranné autentizace při navazování SSL spojení. V rámci všech zmiňovaných testů se také zaměřuji na srozumitelnost předkládaných informací i pro nezkušeného uživatele. 3.2 Výsledky testování V této části prezentuji výsledky, dosažené jednotlivými webovými prohlížeči. Nejprve se vždy věnuji tomu, jaké bezpečnostní volby aplikace nabízí. Dále se postupně zabývám všemi testovacími sadami a nakonec nabízím celkový pohled na testovaný webový prohlížeč Opera Webový prohlížeč Opera sdružuje veškeré bezpečnostní volby v záložce Zabezpečení (Nastavení/Pokročilé volby/zabezpečení). Kladně hodnotím princip Hlavního hesla pro Operu, které je nutné pro jakoukoli změnu v rámci bezpečnostních nastavení. Na toto heslo jsou kladeny dodatečné požadavky na sílu, konkrétně 6 znaků, z čehož musí být alespoň jeden nepísmenný znak. Toto jsou v dnešní době velmi slabé požadavky. Navíc toto heslo není potřeba zadat například při nastavování akceptovaných parametrů pro SSL, kde bych jeho zadání z bezpečnostních dů- 10

18 3.2. VÝSLEDKY TESTOVÁNÍ vodů očekával. Opera v celkovém srovnání nabízí vůbec nejvíce nastavitelných možností na poli bezpečnosti. Jako příklad může sloužit právě volba konkrétních algoritmů pro SSL. Opera dále disponuje přehledným správcem certifikátů. Soukromý klíč je chráněn Hlavním heslem pro Operu a při jeho importování je vyžadováno heslo pro přístup k soukromému klíči. Tato ochrana je více než dostatečná. Na druhou stranu může nastat problém v případě, kdy je prohlížeč využíván více uživateli a každý z nich zde má importovaný vlastní soukromý klíč. Za takové situace je toto řešení nepřípustné. V případě webové stránky, která poskytuje nedůvěryhodný certifikát, je zobrazeno upozornění, že certifikační řetězec není úplný. Toto je odpovídající reakce. Problém však nastane po zařazení kořenového certifikátu mezi důvěryhodné CA. Opera pak bez dalších upozornění stránku načte a skrytě indikuje blíže nespecifikovanou chybu: Nepodařilo se ověřit identitu webového místa. Posledním testem této sady je podpora funkce SHA-2, se kterou Opera pracuje bez jakýchkoli problémů. Ve druhé sadě testů se Opera úspěšně zvládá vypořádat s rozdílným doménovým jménem i s certifikátem, který byl podepsaný sebou samým. Podobně si pak poradí i s certifikátem, který ještě nezačal platit, nebo jehož platnost již skončila. Ve všech případech je zobrazena příslušná chybová zpráva a možnosti pokračovat, vrátit se zpět a zobrazit podrobnosti o certifikátu. V těchto případech nelze prohlížeči nic vytknout. Webový prohlížeč Opera ovšem nepracuje s CRL. Nejenže neupozorňuje na nedostupný CRL, ale nedokáže ani odhalit, že je daný certifikát umístěn na platném CRL. Toto považuji za vážnou bezpečnostní chybu, která by měla hrát významnou roli při výběru webového prohlížeče. V rámci třetí testovací sady Opera žádným způsobem nedetekuje vypršení certifikátu ani odebrání kořenové CA ze seznamu důvěryhodných CA. V obou případech je spojení považováno za bezpečné. Pro zobrazení správné chybové zprávy je nutný restart celého prohlížeče. Zařazení certifikátu na CRL během SSL spojení jsem netestoval z toho důvodu, že Opera s CRL vůbec nepracuje. Oboustrannou autentizaci prohlížeč také nezvládá a zobrazená zpráva informuje, že se nepodařilo dokončit zabezpečenou operaci. Celkově je Opera uživatelsky velmi příjemný webový prohlížeč, který navíc nabízí i prostor pro jemnější nastavení bezpečnostních pravidel. Tyto možnosti jsou ve srovnání s ostatními prohlížeči velmi rozsáhlé, a proto bych Operu doporučil spíše zkušenějším uživatelům Google Chrome Webový prohlížeč Google Chrome nabízí jen velmi omezené možnosti v rámci nastavení bezpečnostních pravidel (Nastavení/Pod pokličkou/zabezpečení). Mezi ně patří možnost používat SSL ve verzi 2.0 (přednastaveno na ANO) a kontrolovat odvolání certifikátu (přednastaveno na NE). Tyto možnosti jsou například ve srovnání s Operou velmi chudé. Mimo to bych počáteční nastavení očekával přesně naopak. Google Chrome nedisponuje vlastním správcem certifikátů a pracuje s certifikáty, které jsou uloženy ve standardních úložištích operačního systému (OS). Z toho přímo vyplývá i skutečnost, že ochrana soukromého klíče závisí pouze na bezpečnostních pravidlech v rámci OS. Zabezpečené připojení je indikováno zřetelným způsobem vlevo vedle webové adresy. Velkou předností prohlížeče jsou pak veškeré varovné zprávy. Tyto zprávy jsou koncipovány přímo pro uživatele, který o SSL/TLS a PKI vůbec nic neví. Dokonce zde můžeme najít i srovnání 11

19 3.2. VÝSLEDKY TESTOVÁNÍ se situacemi z každodenního života. Problémy jsem nezaznamenal ani při použití hashovací funkce SHA-2. Google Chrome zvládl první sadu testů na výbornou a v podstatě mu nelze nic vytknout. V druhé sadě testů navazuje Google Chrome na dobré výsledky ze sady první. Všechny testy dopadly dobře. Opět považuji za důležité zmínit výstižné a propracované chybové zprávy. Zvláštní pozornost pak věnuji práci prohlížeče s CRL. Zde bych rád zdůraznil upozornění na nedostupné CRL, které zobrazí už jen jeden další prohlížeč. Toto upozornění sice není přesné, přesto si ho velmi cením. Prohlížeč je schopen si poradit i s odvolaným certifikátem. Poslední testovací sadu již Google Chrome tak dobře nezvládl. Ani jedno zneplatnění certifikátu během probíhajícího SSL spojení jím není odhaleno. Ve všech případech je spojení považováno i nadále za bezpečné. V případě vypršení certifikátu a odebrání kořenového certifikátu z důvěryhodných CA je korektní chyba zobrazena po obnovení stránky. V případě revokace certifikátu nepomůže ani restart celého prohlížeče. To je pravděpodobně způsobeno tím, že nový CRL je stažen až po vypršení platnosti toho předchozího. V rámci tohoto testu jsem nastavil platnost na jeden den a po uplynutí této doby je certifikát již zamítnut. Při oboustranné autentizaci nabízí prohlížeč seznam osobních certifikátů, které jsou importovány v OS. Celkově dává prohlížeč Google Chrome přednost uživatelské přívětivosti před možností složitějších nastavení. I přes problematické řešení některých bezpečnostních hrozeb považuji práci tohoto prohlížeče s certifikáty za dostatečnou a vzhledem k dokonalým chybovým zprávám bych jej jednoznačně doporučil především méně zkušeným uživatelům Internet Explorer 8.0 Webový prohlížeč Internet Explorer sdružuje všechny bezpečnostní volby v oddíle Zabezpečení (Nastavení/Možnosti Internetu/Zabezpečení). Lze zde najít rozmanité funkce, které zahrnují výběr verze SSL/TLS a kontroly odvolání certifikátu. Ta je stejně jako v případě Google Chrome vypnuta. Obdobně jako u něj je v rámci původního nastavení povolen i protokol SSL ve verzi 2. Opět bych čekal, že kontrolování CRL bude po instalaci zapnuto a použití SSL verze 2 vypnuto. Prohlížeč nabízí přibližně dalších deset možností nastavení, která jsou co do rozsahu jakýmsi kompromisem mezi Operou a Google Chrome. Internet Explorer neobsahuje vlastního správce certifikátů a pracuje přímo s certifikáty uloženými ve standardních úložištích OS. Proto má také na ochranu soukromého klíče vliv jen nastavení OS. V případě nedůvěryhodného kořenového certifikátu je zobrazena chybová zpráva přes celou stránku s příslušným popisem chyby. Důrazně je doporučeno stránku opustit a nepokračovat. Stejným způsobem jsou řešeny i všechny další bezpečnostní chyby. Negativně ovšem hodnotím nemožnost zobrazení podrobností o certifikátu. V případě důvěryhodného certifikátu je stránka načtena a prohlížeč ji skrytě označí otazníkem. Toto chování není ani náznakem vysvětleno, což považuji za vážný prohřešek vůči uživatelům. Práce s funkcí SHA-2 nedělá prohlížeči Internet Explorer žádné problémy. Druhou sadu testů zvládl Internet Explorer o poznání lépe. Zde zaznamenávám jen jediný problém, a to v případě nedostupného CRL. Ve všech ostatních testech (rozdílné webové jméno; odvolaný certifikát; vypršený certifikát; certifikát, jehož platnost ještě nezačala) dosahuje prohlížeč dostatečných výsledků. Dále kladně hodnotím korektní chybovou zprávu v případě zařa- 12

20 3.2. VÝSLEDKY TESTOVÁNÍ zení certifikátu na CRL. I v případě této chyby však stále chybí možnost zobrazení certifikátu ještě před načtením požadované stránky. To výrazně snižuje komfort práce s tímto prohlížečem. Poslední testovací sada se zabývá zneplatněním certifikátu během probíhajícího SSL spojení. Ani jedna z testovaných situací není prohlížečem detekována. V případě vypršení certifikátu a odstranění kořenového certifikátu ze seznamu důvěryhodných CA je chybová zpráva zobrazena až po obnovení stránky. U revokovaného certifikátu je potřeba počkat, než vyprší dříve stažený CRL. Teprve poté je stažen nový a zobrazena chybová zpráva. S oboustrannou autentizací si již Internet Explorer poradí bez problémů a nabízí seznam osobních certifikátů, uložených ve standardních úložištích OS. Celkově působí Internet Explorer mírně rozporuplným dojmem. Na mysli mám především blíže nevysvětlený otazník v případě důvěryhodného certifikátu a dále pak nemožnost zobrazení podrobností o certifikátu, který je označen jako nedůvěryhodný. To vše v kontrastu s příjemným uživatelským prostředím a výraznými chybovými zprávami Maxthon Webový prohlížeč Maxthon je nadstavbou prohlížeče Internet Explorer, přesněji jádra tohoto prohlížeče [20]. Při nastavování bezpečnostních pravidel lze najít záložku Zabezpečení a soukromí (Nástroje/Nastavení Maxthon/Zabezpečení a soukromí). Jediná volba, kterou zde Maxthon nabízí, je vymazání historie při jeho zavírání. Nastavení tohoto prohlížeče je potom přímo závislé na nastavení Internet Exploreru. Všechny testy provádím z důvodu kompatibility s identickým nastavením, jako při testování Internet Exploreru. Přes všechny skutečnosti, které jsem uvedl v předchozím odstavci, se chování prohlížeče Maxthon v některých situacích od chování Internet Exploreru výrazně liší. Jedná se především o rozdílný textový obsah chybových zpráv a také o to, kdy prohlížeč ověřuje platnost certifikátu. Rozdíl, kterého si lze povšimnout na první pohled, je zobrazení chybové zprávy v podobě vyskakovacího okna. S tím také souvisí kvalita zobrazeného textu. Ve většině případů se jedná o dostatečnou chybovou zprávu. Dovolím si zde pouze upozornit na tu, která je zobrazena v případě nedůvěryhodného kořenového certifikátu. Tato zpráva říká, že nejsou dostupné informace o revokaci daného certifikátu. Postrádám zde ovšem jakoukoli informaci o tom, že se jedná o nedůvěryhodný certifikát a uživatel by mu neměl důvěřovat. Chybová zpráva naopak navádí k tomu, aby uživatel certifikátu věřil. To může vést, především v případě nezkušeného uživatele, k bezděčnému přeskočení takovéto zprávy. Skutečná přednost prohlížeče ovšem spočívá v tom, že si zvládl korektně poradit s vypršením certifikátu a odebráním kořenového certifikátu ze seznamu důvěryhodných CA během probíhajícího SSL spojení. V obou případech byla okamžitě zobrazena korektní chybová zpráva. Tento výsledek hodnotím velice kladně především proto, že tuto situaci zvládl jako jediný ze všech testovaných prohlížečů. Další dva testy této sady už měly identický průběh jako v případě prohlížeče Internet Explorer. Celkově by se mohlo zdát, že Maxthon dosáhl lepších výsledků než Internet Explorer. Podle mého názoru tomu tak není, především díky hodně nepřesné chybové zprávě, zobrazené v případě nedůvěryhodného kořenového certifikátu. Je velmi pravděpodobné, že bude daleko 13

21 3.2. VÝSLEDKY TESTOVÁNÍ více těch uživatelů, kteří se touto zprávou nechají zmást, než těch, kteří ocení ohlášení chyby v případě zneplatnění certifikátu během již navázaného SSL spojení Lataza Browser 3.3 Webový prohlížeč Lataza Browser je také nadstavbou prohlížeče Internet Explorer. Při řešení bezpečnosti i v bezpečnostních nastaveních v podstatě kopíruje chování prohlížeče Maxthon. Opět tedy záleží na konfiguraci Internet Exploreru, kterou i pro tento test zachovávám stejnou. Z výše zmíněných důvodů uvádím jen výsledky těch testů, ve kterých se chování obou prohlížečů liší. Prvním takovýmto rozdílem je skutečnost, že Lataza Browser žádným způsobem neindikuje zabezpečené připojení. Tento prvek výrazně snižuje uživatelský komfort. Prohlížeč dále neopakuje dobré výsledky sesterského prohlížeče Maxthon v případě, kdy je certifikát během SSL spojení odstraněn ze seznamu důvěryhodných CA, popřípadě skončí jeho platnost. Celkově se Lataza Browser řadí mezi slabší prohlížeče, které neoslní ani uživatelským prostředím. Z hlediska bezpečnosti navíc nevidím jediný důvod, proč dát tomuto prohlížeči přednost například před Maxthonem, se kterým toho má tolik společného Safari Webový prohlížeč Safari v podstatě nenabízí vůbec žádné bezpečnostní volby. Vše je po instalaci automaticky přednastaveno. Tento prohlížeč ocení spíše uživatelé, kteří se nechtějí zabývat pokročilejšími nastaveními. V tomto ohledu nabízí Safari nejméně voleb ze všech testovaných programů. Na druhou stranu, Safari poskytuje kvalitní bezpečnostní funkce. Nedisponuje vlastním správcem certifikátů a pracuje přímo s certifikáty uloženými ve standardních úložištích OS. Proto celková bezpečnost soukromého klíče závisí na nastavení pravidel v rámci tohoto OS. Zabezpečené spojení indikuje ikonou zámku, která je umístěna vedle pole pro zadání webové adresy. V případě nedůvěryhodného certifikátu je zobrazena zpráva s informací, že se jedná o nedůvěryhodný web. Chybí zde však podrobnější popis chyby a doporučení, jak se zachovat. Negativně hodnotím také to, že naprosto stejná zpráva je zobrazena i ve všech ostatních testech. Vždy bez jakéhokoli vysvětlení nebo informace o příčině chyby. Práci s funkcí SHA-2 zvládá stejně dobře jako všechny ostatní testované prohlížeče. Výsledky druhé testovací sady jsou poněkud monotónní. Ve všech případech nedůvěryhodného certifikátu je zobrazena stejná chybová zpráva. Kladně lze chápat fakt, že je zobrazena, ovšem stále chybí jakékoli podrobnosti. Kladně však hodnotím indikaci nedostupného CRL. Safari byl druhý a zároveň poslední prohlížeč, který v tomto případě nějakým způsobem uživatele upozornil. Třetí sada nepřinesla opět žádné překvapení. Při oboustranné autentizaci nabízí Safari vyskakovací okno s nabídkou osobních certifikátů uložených v OS. V případě zařazení certifikátu na CRL během SSL spojení je podobně jako u předcházejících prohlížečů nutné počkat, než vyprší dříve stažený CRL. V ostatních případech je pro správnou chybovou zprávu nezbytné obnovení stránky. 14

22 3.2. VÝSLEDKY TESTOVÁNÍ Celkově nabízí Safari ten komfort, že ho není potřeba dodatečně konfigurovat. Na druhou stranu, absence jakýchkoli nastavení a bližší specifikace chyb kazí celkový dojem. Svými výsledky dosahuje podobné kvality jako Google Chrome, avšak uživatelským rozhraním hluboce zaostává Mozilla Firefox Webový prohlížeč Mozilla Firefox nabízí veškeré bezpečnostní volby v záložce Šifrování (Možnosti/Rozšířené/Šifrování). Mezi nimi lze najít použití protokolu SSL verze 3 a protokolu TLS ve verzi 1. Obě tyto možnosti jsou po instalaci povoleny. Kromě vestavěného správce certifikátů kladně hodnotím i možnost nastavení Ověření certifikátů. Toto nastavení se bohužel týká jen protokolu Online Certificate Status Protocol (OCSP). Na základě této skutečnosti lze předpokládat, že prohlížeč nepodporuje ověřování certifikátů pomocí CRL. Toto se následně i potvrdí. Mozilla Firefox disponuje vlastním správcem certifikátů. Pokud se uživatel rozhodne importovat osobní certifikát se soukromým klíčem, musí znát heslo pro přístup k tomuto klíči. Toto heslo je zachováno i pro další použití. Velmi kladně hodnotím chybové zprávy, které jsou zobrazeny v případě neplatného certifikátu. Ty se propracováním a přehledností téměř blíží prohlížeči Google Chrome, i když jeho kvalit ještě nedosahují. Dále si u těchto zpráv cením toho, že je nelze jen odklikat a svou strukturou nutí uživatele, aby si je opravdu přečetl a zamyslel se nad nimi. Zabezpečené spojení je potom indikováno nalevo od webové adresy. Mozilla Firefox si navíc zvládá poradit i s funkcí SHA-2. V rámci druhé testovací sady zvládl prohlížeč Mozilla Firefox rozdílnou doménovou adresu, sebou samým podepsaný certifikát, expirovaný certifikát a stejně tak i certifikát, který ještě platit nezačal. Ve všech případech je opět zobrazena propracovaná chybová zpráva. V případě pokračovaní na nedůvěryhodný web z této chybové zprávy, je potřeba přidat výjimku s jednorázovou nebo trvalou platností. Jak jsem již na začátku předeslal, prohlížeč Mozilla Firefox nepracuje s CRL a revokovaný certifikát považuje za důvěryhodný. Toto je podle mého názoru největší bezpečnostní nedostatek, na který jsem u tohoto prohlížeče narazil. V poslední testovací sadě Mozilla Firefox neodhalí ani jeden případ zneplatnění certifikátu během probíhajícího SSL spojení. Navíc nepomáhá ani obnovení stránky a pro korektní chování je nutný restart celého prohlížeče. Při vyžadované autentizaci klienta nabízí Mozilla Firefox osobní certifikáty, které jsou importovány v prohlížeči. Webový prohlížeč Mozilla Firefox lze považovat za přiměřený kompromis mezi Google Chrome, který nedává uživateli žádný prostor, a Operou, která nabízí nastavení přesahující možnosti obyčejného uživatele Wyzo Webový prohlížeč Wyzo je postaven na stejném jádře jako prohlížeč Mozilla Firefox [21]. V podstatě pak také kopíruje veškeré možnosti nastavení a nepřináší vůbec nic nového. Vlastní chování je potom také velmi podobné a liší se jen v maličkostech. Za zmínku stojí nedostatečné upozornění v případě zabezpečeného spojení. V panelu nad adresou je umístěn bílý čtvereček, který na první pohled neevokuje žádnou souvislost se zabezpečením. Po nějaké době zkoumání lze odhalit, že po kliknutí zobrazí informaci o šifrova- 15

23 3.3. ZHODNOCENÍ VÝSLEDKŮ TESTOVÁNÍ ném spojení. Další rozdíl oproti prohlížeči Mozilla Firefox je v chybových zprávách, které jsou o něco méně přehledné. Tuto změnu hodnotím jako krok zpět. Posledním rozdílem je potom závěrečný test, ve kterém Wyzo, na rozdíl od Mozilla Firefox, není schopný navázat spojení při oboustranné autentizaci. Celkový dojem tohoto prohlížeče je spíše negativní. Co se týče bezpečnosti a uživatelského prostředí, nevidím jediný důvod, proč mu dát přednost před Mozillou Firefox. Proto bych ho také nikomu nedoporučil SeaMonkey Webový prohlížeč SeaMonkey je vystavěn na stejném základu jako aplikace Mozilla Firefox [22]. Veškerá bezpečnostní nastavení odpovídají nastavením tohoto prohlížeče. V rámci testovaných situací pak můžeme najít jen nepatrné rozdíly v chování obou prohlížečů. Jednou z mála výjimek je indikace zabezpečeného spojení. To je signalizováno malým zámečkem vpravo dole, který není na první pohled zcela viditelný. Druhým a zároveň posledním rozdílem je chování při oboustranné autentizaci, kdy není možné navázat spojení s odůvodněním, že se strany nemohly dohodnout na parametrech pro SSL. Opět lze tedy říci, že tento prohlížeč nepřináší ve srovnání s Mozillou Firefox vůbec nic nového a je s ohledem na bezpečnost horší volbou Netscape Navigator Webový prohlížeč Netscape Navigator je předchůdce prohlížeče Mozilla Firefox, který z něj vychází. Oba tyto prohlížeče opět dosáhly vesměs podobné výsledky, a to navzdory tomu, že podpora pro Netscape Navigator skončila již v roce Tato skutečnost naznačuje, že od této doby nepřinesl vývoj Mozilly Firefox žádné zlepšení relevantních bezpečnostních funkcí. Přes to všechno lze najít mírné rozdíly v chování obou prohlížečů. První odlišností je upozornění při vstupu na stránku, která se prokázala důvěryhodným certifikátem. V takovém případě je zobrazeno vyskakovací okno s informací, že data nemohou být jednoduše odposlechnuta třetí stranou. V některých případech se sice může jednat o redundantní informaci, ale celkově není určitě na škodu. Druhým a posledním rozdílem je potom to, že Netscape Navigator není schopen navázat spojení při vyžadované autentizaci klienta. Prohlížeč Netscape Navigator by si neměl zvolit žádný uživatel už z toho důvodu, že podpora této aplikace oficiálně skončila. Do budoucna lze navíc ze stejného důvodu očekávat přibývání bezpečnostních nedostatků. 3.3 Zhodnocení výsledků testování První testovací sadu zvládla většina testovaných webových prohlížečů dobře. Zmíním zde jen některé statistické informace. Polovina prohlížečů disponuje vlastním správcem certifikátů, zbylá polovina využívá klasických úložišť OS. Všechny testované prohlížeče prokázaly dostatečnou ochranu soukromého klíče. Indikace důvěryhodného spojení byla korektní pouze v šesti případech, což považuji za velmi špatný výsledek. Na druhou stranu, správné upozornění na nedůvě- 16

24 3.3. ZHODNOCENÍ VÝSLEDKŮ TESTOVÁNÍ ryhodný certifikát bylo zobrazeno v devíti případech. Dobrým signálem je i to, že s funkcí SHA-2 zvládlo pracovat všech deset testovaných prohlížečů. Dobrými výsledky pokračovala i druhá sada testů. Rozdílné doménové jméno, certifikát podepsaný sebou samým, vypršený certifikát a certifikát, jehož platnost ještě nezačala. To jsou čtyři situace, ve kterých obstály všechny prohlížeče, což je skvělý výsledek. O poznání hůře pak skončila část testů týkající se CRL. Upozornění na nedostupný CRL zobrazily pouze dva prohlížeče Google Chrome a Safari. Ani u nich však nebyl zobrazen přesný popis chyby. Revokovaný certifikát pak odhalila pouze polovina testovaných prohlížečů. Toto je celkově velmi špatný výsledek a z hlediska bezpečnosti zcela nedostačující. V rámci poslední sady testů zvládá oboustrannou autentizaci šest prohlížečů. Zbylé čtyři se nebyly schopny dohodnout na parametrech pro SSL. Zneplatnění certifikátu během SSL spojení pak skončilo vůbec nejhoršími výsledky. Revokovaný certifikát neodhalil ani jeden prohlížeč. Jak jsem již dříve předeslal, je to pravděpodobně tím, že nové CRL je staženo až po skončení platnosti toho původního. Odebrání kořenového certifikátu ze seznamu důvěryhodných CA a skončení platnosti certifikátu pak zaznamenal jediný prohlížeč, a to Maxthon. Výsledky této části poukazují na to, že ověřování certifikátu je provedeno jen při navazování SSL spojení a o další platnost se již prohlížeče nestarají. Celkové výsledky dosažené jednotlivými prohlížeči přehledně shrnuje tabulka 3.1. Do celkového skóre jednotlivých prohlížečů, které je uvedeno v posledním řádku tabulky, nejsou započítány výsledky prvního testu, který se zabýval vlastním správcem certifikátů a je tedy nerelevantní. 17

25 3.3. ZHODNOCENÍ VÝSLEDKŮ TESTOVÁNÍ Tab. 3.1: Výsledky dosažené jednotlivými prohlížeči 18

26 Kapitola 4 Testování ových klientů V této kapitole se zabývám testováním ových klientů. Nejprve seznamuji čtenáře s průběhem příprav, provedených před samotným testováním, dále představuji seznam realizovaných testů s přesným popisem jednotlivých částí. Nakonec prezentuji výsledky dosažené konkrétními ovými klienty. Cílem testování bylo, stejně jako v předchozí kapitole, odhalit nedostatky aplikací při práci s certifikáty veřejných klíčů. Důraz kladu na uživatelskou přívětivost a srozumitelnost informací a varování předkládaných uživateli. Testování proběhlo na počítači s operačním systémem Microsoft Windows 7. Jedinou výjimkou byl MS Outlook Express, který byl testován na Windows XP, a to z důvodu jeho nedostupnosti na Windows Příprava testování Pro účely tohoto testování jsem vytvořil novou certifikační autoritu, abych se vyvaroval jakémukoli prolínání či pozůstatkům z testování předchozího. Při vytváření této CA jsem opět vycházel z návodu v knize Velký průvodce infrastrukturou PKI [03], ovšem při vydávání samotných certifikátů jsem čerpal především z dokumentace k nástroji OpenSSL [23]. Někteří z testovaných ových klientů nepodporují S/MIME v základní verzi. Proto bylo nejprve nutné doinstalovat příslušné pluginy. Pro samotné testování používám následující čtyři testovací sady. V rámci první testovací sady hodnotím především práci ových klientů s certifikáty veřejných klíčů, jejich správu a dodatečná bezpečnostní nastavení, která aplikace nabízejí. Zabývám se ochranou soukromého klíče a zobrazením u s platným podpisem. Jako součást tohoto testu hodnotím také možnosti zobrazení certifikátu a podrobností o podpisu. Jako poslední testuji schopnost klienta pracovat s hashovací funkcí SHA-2, přesněji SHA-512. Zde hodnotím jak schopnost přijmout takovýto , tak schopnost použít tuto funkci při vytváření digitálního podpisu. V neposlední řadě posuzuji i přívětivost uživatelského prostředí. V druhé testovací sadě se věnuji situacím, kdy je certifikát z nějakého důvodu neplatný. Předpokladem je umístění kořenového certifikátu mezi důvěryhodné CA. Konkrétní problémy spojené s certifikátem jsou následující: 19

27 4.2. VÝSLEDKY TESTOVÁNÍ certifikát je vydán pro jinou ovou adresu; certifikát je umístěn na platný CRL; platnost certifikátu již skončila; certifikát ještě platit nezačal. Posledním testem této sady je schopnost ového klienta odhalit nedostupný CRL a dát tuto skutečnost nějakým způsobem na vědomí uživateli. Zde se zaměřuji především na srozumitelnost a korektnost zobrazovaných chyb, které by měly být jasné i méně zkušeným uživatelům. V rámci další sady testů se zabývám situacemi, kdy byl certifikát v době podpisu platný, avšak v době čtení již platný není. Konkrétním důvodem zneplatnění certifikátu je jeho odvolání nebo skončení doby jeho platnosti. Dále se věnuji opačné situaci, kdy je certifikát v době podpisu neplatný, ale v době čtení již platit začal. Posledním testem této části je posílání u mezi časovými pásmy. Přesně se jedná o certifikát, který je zařazen na CRL v 10 hodin Central European Time (CET) a odeslání a podepsání u je provedeno ve 12CET. je potom přijat a čten v 8 hodin místního času, což odpovídá 14CET. Cílem těchto testů je určit, vůči jakému časovému údaji se provádí kontrola podpisu, a zda je vůbec zohledněn čas podepsání, čas přijetí a čas čtení u. Poslední sada testuje chování ových klientů při současném použití digitálního podpisu i šifrování. Dále se v této části zabývám nestandardními situacemi, ke kterým ovšem může někdy dojít. Konkrétní výčet provedených testů je následující: , který je nejprve zašifrovaný a teprve poté podepsaný; , který je nejprve podepsaný a teprve poté zašifrovaný; třikrát po sobě podepsaný ; podepsaný dvěma uživateli, z nichž se v jednom případě ová adresa shoduje a ve druhém se liší. 4.2 Výsledky testování V této podkapitole prezentuji výsledky, dosažené jednotlivými ovými klienty. Nejprve vždy uvádím, jaké bezpečnostní volby aplikace nabízí. Dále se postupně zabývám konkrétními sadami testů a nakonec nabízím celkový pohled na testovaného ového klienta MS Outlook Express MS Outlook Express nabízí veškeré bezpečnostní volby v záložce Zabezpečená pošta (Nástroje/Možnosti/Zabezpečení/Zabezpečená pošta). Tyto volby jsou ovšem jen velmi omezené. Negativně navíc hodnotím nastavení pro kontrolu odvolaných certifikátů, která je v tomto případě vypnuta. Za zmínku potom už stojí jen možnost nastavení automatického šifrování nebo podepisování každé odchozí zprávy. ový klient MS Outlook Express nenabízí vlastního správce certifikátů a pracuje přímo s certifikáty uloženými v OS. To znamená, že se nemusí starat o ochranu soukromého klíče. Kladně hodnotím upozornění na digitálně podepsaný , které je zobrazeno přes celou obrazovku ještě před samotným otevřením tohoto u. Je zde navíc podrobný popis pro méně zkušené uživatele. Ti zkušenější zase ocení snadné zobrazení certifikátu a podrobností o digitálním podpisu. Problém ovšem nastává při využití funkce SHA-2. Klient tuto funkci nedokáže 20