MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Práce aplikací s certifikáty veřejných klíčů
BAKALÁŘSKÁ PRÁCE
Radim Ošťádal
Brno, 2010
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
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
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 e-mailovými klienty na poli bezpečnosti a chyby, které dělají při práci s certifikáty veřejných klíčů.
iv
Klíčová slova Bezpečnost, certifikát, digitální podpis, e-mailový klient, S/MIME, SSL/TLS, webový prohlížeč
v
Obsah 1 2
3
4
Úvod ............................................................................................................................................................. 1 Základní pojmy ........................................................................................................................................ 3 2.1 Kryptografie ............................................................................................................................................................3 2.1.1 Symetrická kryptografie...................................................................................................................3 2.1.2 Asymetrická kryptografie................................................................................................................4 2.2 Certifikát podle standardu X.509 .................................................................................................................5 2.3 Protokoly SSL a TLS ............................................................................................................................................6 2.4 Standard S/MIME.................................................................................................................................................8 Testování webových prohlížečů ........................................................................................................ 9 3.1 Příprava testování ...............................................................................................................................................9 3.2 Výsledky testování............................................................................................................................................10 3.2.1 Opera 10.10 .......................................................................................................................................10 3.2.2 Google Chrome 3.0.195.2............................................................................................................11 3.2.3 Internet Explorer 8.0 ....................................................................................................................12 3.2.4 Maxthon 2.5.11.3353 ....................................................................................................................13 3.2.5 Lataza Browser 3.3 ........................................................................................................................14 3.2.6 Safari 4.0.4 ..........................................................................................................................................14 3.2.7 Mozilla Firefox 3.5.6 ......................................................................................................................15 3.2.8 Wyzo 3.0.1 ..........................................................................................................................................15 3.2.9 SeaMonkey 2.0.1 .............................................................................................................................16 3.2.10 Netscape Navigator 9.0.0.6 ........................................................................................................16 3.3 Zhodnocení výsledků testování .................................................................................................................16 Testování e-mailových klientů .........................................................................................................19 4.1 Příprava testování ............................................................................................................................................19 4.2 Výsledky testování............................................................................................................................................20 4.2.1 MS Outlook Express.......................................................................................................................20 4.2.2 Windows Live Mail.........................................................................................................................21 4.2.3 MS Outlook 2007 ............................................................................................................................21 4.2.4 Mozilla Thunderbird 2.0.0.23...................................................................................................22 4.2.5 Netscape Mail 9.0a1 ......................................................................................................................23 4.2.6 The Bat 4.2.9.1..................................................................................................................................23 4.2.7 Mulberry 4.0.8 .................................................................................................................................24 4.2.8 Becky! Internet Mail 2.21.04.....................................................................................................25 4.2.9 Eudora 7.1.0.9...................................................................................................................................25 4.2.10 FoxMail 6.5 .........................................................................................................................................26 vi
4.3 Zhodnocení výsledků testování .................................................................................................................27 5 Závěr .......................................................................................................................................................... 30 Seznam použité literatury......................................................................................................................... 32
vii
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 e-mail. 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í e-mailové pošty používáme. Jedná se především o webové prohlížeče a e-mailové 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
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 e-mailový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
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].
2.1.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
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 𝑛 ∗ (𝑛 − 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.
2.1.2 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ž 1225. 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
2.2. CERTIFIKÁT PODLE STANDARDU X.509
2.2
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 9594-8 [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
2.3. PROTOKOLY SSL A TLS
Obr. 2.1: Certifikát podle standardu X.509
2.3
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
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íčů 40-120 bitů; blokové symetrické šifry: DES, DES40, 3DES, IDEA, Fortezza; hashovací algoritmy: MD5, SHA.
7
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/pkcs7signature. 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í e-mailový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
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 7.
3.1
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
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č.
3.2.1 Opera 10.10 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
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.
3.2.2 Google Chrome 3.0.195.2 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
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.
3.2.3 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řa12
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.
3.2.4 Maxthon 2.5.11.3353 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
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í.
3.2.5 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.
3.2.6 Safari 4.0.4 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
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á.
3.2.7 Mozilla Firefox 3.5.6 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.
3.2.8 Wyzo 3.0.1 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 šifrova15
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.
3.2.9 SeaMonkey 2.0.1 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.
3.2.10 Netscape Navigator 9.0.0.6 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 2008. 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
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
3.3. ZHODNOCENÍ VÝSLEDKŮ TESTOVÁNÍ
Tab. 3.1: Výsledky dosažené jednotlivými prohlížeči 18
Kapitola 4
Testování e-mailových klientů V této kapitole se zabývám testováním e-mailový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 e-mailový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 7.
4.1
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 e-mailový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 e-mailový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 e-mailu 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 e-mail, 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
4.2. VÝSLEDKY TESTOVÁNÍ
certifikát je vydán pro jinou e-mailovou 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 e-mailové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í e-mailu 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í e-mailu je provedeno ve 12CET. E-mail 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í e-mailu. Poslední sada testuje chování e-mailový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í:
4.2
e-mail, který je nejprve zašifrovaný a teprve poté podepsaný; e-mail, který je nejprve podepsaný a teprve poté zašifrovaný; třikrát po sobě podepsaný e-mail; e-mail podepsaný dvěma uživateli, z nichž se v jednom případě e-mailová adresa shoduje a ve druhém se liší.
Výsledky testování
V této podkapitole prezentuji výsledky, dosažené jednotlivými e-mailový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 e-mailového klienta.
4.2.1 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. E-mailový 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ý e-mail, které je zobrazeno přes celou obrazovku ještě před samotným otevřením tohoto e-mailu. 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
4.2. VÝSLEDKY TESTOVÁNÍ použít při vytváření podpisu. Mnohem závažnější je však skutečnost, že při přijetí zprávy, kde byla tato funkce použita, nedokáže e-mailový klient zobrazit ani samotný text e-mailu, natož pak ověřit platnost digitálního podpisu. Certifikát vydán pro jinou e-mailovou adresu, certifikát umístěn na platný CRL, platnost certifikátu, která již skončila a certifikát, který ještě platit nezačal. To jsou čtyři testy, které klient zvládá na výbornou. Kladně hodnotím především práci s CRL. Zde ovšem musím zmínit, že bylo potřeba tuto kontrolu nejprve zapnout. Ve všech případech je zobrazena odpovídající chybová zpráva. Posledním testem této sady je potom kontrola nedostupného CRL. Tuto situaci už klient nezvládl a žádné upozornění nezobrazil. Dá se říci, že s třetí sadou testů si klient moc dobře neporadil. Ukazuje se, že platnost podpisu není kontrolována vůči času podepsání, ale v úvahu je brán jen aktuální čas. Proto se může stát, že podpis, který byl včera ještě platný, bude zítra označen jako nedůvěryhodný. Stejným způsobem pracuje klient i s CRL a kontroluje jen to, zda je certifikát zařazen na CRL, nebo není. Čas revokace už nezohledňuje. Navíc z toho přímo plyne, že pokud podepíšeme e-mail v době, kdy certifikát ještě neplatí, pak tento podpis bude za nějakou dobu označen jako důvěryhodný. Tyto výsledky hodnotím velmi negativně a myslím si, že je zde velký prostor pro zlepšení. MS Outlook Express pracuje korektně se zprávou, která je nejprve podepsaná a poté zašifrovaná. Opačnou situaci klient bohužel nezvládá a podpis nelze ověřit. Takto zaslaný e-mail je sice velmi nestandardní, přesto však tento výsledek celkový dojem z e-mailového klienta MS Outlook Express snižuje. Násobně podepsané e-maily jsou pak vyhodnoceny jako neplatné z důvodu, že zpráva byla změněna. Klient se chová korektně v běžných situacích, zatímco ty nestandardní spíše nezvládá. Proto bych ho doporučil méně náročným uživatelům. Navíc u něj postrádám podporu funkce SHA-2, což bude znamenat v nejbližší době stále větší problém.
4.2.2 Windows Live Mail E-mailový klient Windows Live Mail je v podstatě náhradou klienta Microsoft Outlook Express. Součástí OS Windows je počínaje verzí Vista. Bohužel nemohu říct, že by došlo k nějakému výraznějšímu zlepšení v řešení bezpečnosti. Opět je po instalaci vypnuta kontrola odvolání certifikátu, a co se týče nastavení, zůstalo vše zcela stejné. Jedinou změnou je potom bezproblémové ověření e-mailu, při jehož podepisování byla využita hashovací funkce SHA-2. To rozhodně hodnotím jako krok správným směrem. Nicméně při vytváření podpisu klient tuto funkci stále nepodporuje. Celkové hodnocení tedy zůstává velmi podobné, jako v případě klienta MS Outlook Express.
4.2.3 MS Outlook 2007 MS Outlook 2007 sdružuje bezpečnostní volby v Centru zabezpečení (Nástroje/Centrum zabezpečení). Jedná se o manažera, který nabízí opravdu komplexní pohled na bezpečnost. Umožňuje nastavení bezpečnostních pravidel pro odesílané i přijímané e-maily. Navíc je řešen i s ohledem na uživatelskou přívětivost. Mě osobně tento manažer opravdu nadchl. MS Outlook 2007 pracuje s certifikáty v klasických úložištích OS a nedisponuje vlastním správcem certifikátů. To znamená, že o ochranu soukromého klíče se stará také OS. Upozornění 21
4.2. VÝSLEDKY TESTOVÁNÍ na podepsaný e-mail je jasně viditelné a kladně hodnotím i intuitivní možnost zobrazení podrobností o certifikátu a o podpisu. Podpora hashovacích funkcí závisí přímo na tom, jaký používáme OS. Například na Windows 7 je podporována SHA-2 a její použití při vytváření digitálního podpisu je velmi snadné. Problém potom může nastat na Windows XP, který dovoluje použít jen funkci SHA-1 nebo Message-Digest algorithm 5 (MD5). E-mailový klient zobrazuje podrobnou chybovou zprávu v případě revokovaného certifikátu, expirovaného certifikátu i certifikátu, který ještě nezačal platit. V této sadě testů dosáhl MS Outlook 2007 dvou extrémních výsledků. Za chvályhodné považuji to, že jako jediný zobrazuje upozornění na nedostupné CRL. Toto upozornění je sice až ve druhé úrovni podrobností o podpisu, přesto je to skvělý výsledek. Na druhou stranu přesně naopak končí test certifikátu s rozdílnou e-mailovou adresou. V tomto případě není zobrazeno žádné upozornění a podpis je považován za důvěryhodný. Toto je asi nejzávažnější chyba, které se klient během testování dopustil a která kazí celkový dojem z tohoto programu. Výsledky třetí testovací sady kopírují chování klienta MS Outlook Express. Kontrola tedy opět probíhá vůči aktuálnímu časovému údaji. V rámci poslední sady zvládá klient pracovat se šifrovanými e-maily v obou kombinacích. Vícenásobně podepsaný e-mail je potom v obou případech označen jako nedůvěryhodný s informací, že obsah zprávy byl pravděpodobně změněn. Celkově působní MS Outlook 2007 velmi profesionálně a nabízí rozsáhlé bezpečnostní volby. Navíc komplexní pohled na bezpečnost, který poskytuje, bychom u ostatních klientů hledali marně. Tohoto klienta doporučuji především zkušenějším uživatelům, kteří chtějí znát a ovlivnit veškeré aspekty zabezpečené pošty.
4.2.4 Mozilla Thunderbird 2.0.0.23 E-mailový klient Mozilla Thunderbird, stejně jako MS Outlook Express, neposkytuje téměř žádné bezpečnostní volby. To málo, co zde je, lze najít v záložce Certifikáty (Nástroje/Možnosti/Rozšířené/Certifikáty). Mozilla Thunderbird nabízí vlastního správce certifikátů a položku ověřovaní. Stejně jako v případě Mozilly Firefox se jedná pouze o ověření pomocí protokolu OCSP a práce s CRL není podporována. To opět považuji za vážný prohřešek vůči bezpečnosti. Jak jsem již zmínil, Mozilla Thunderbird nabízí vlastního správce certifikátů. Při jakékoli manipulaci se soukromými klíči je pak vyžadováno Heslo pro práci s bezpečnostním SW. I z tohoto plyne, že klient je naprosto nevhodný pro současné používání více uživateli. Kladně hodnotím indikaci podepsané zprávy, která je viditelná na první pohled. Zobrazení certifikátu a podrobností o podpisu je snadné a intuitivní. Funkce SHA-2 však není vůbec podporována a při přijetí se e-mail zobrazuje jako nepodepsaný. Z další testovací sady zvládá Mozilla Thunderbird pouze práci s certifikátem, kterému již skončila platnost. Se všemi ostatními testy má klient nějaký problém. Jak jsem již předeslal, nepracuje s CRL, takže revokovaný certifikát je považován za důvěryhodný a nedostupným CRL se klient také nezabývá. Bohužel podobným výsledkem skončí i certifikát s rozdílnou e-mailovou adresou a certifikát, který ještě platit nezačal. Ve všech těchto případech je certifikát považován za důvěryhodný a podpis za platný. Toto vše jsou vážné bezpečnostní nedostatky a klient se díky nim řadí mezi ty nejméně důvěryhodné. 22
4.2. VÝSLEDKY TESTOVÁNÍ Ve třetí testovací sadě kopíruje Mozilla Thunderbird chování předcházejících klientů. Opět kontroluje pouze aktuální časový údaj. Jeden e-mail je tedy neprávem označen za neplatný a jeden naopak za platný. Další dva testy jsem již neprováděl z důvodu, že aplikace nepracuje s CRL. Mozilla Thunderbird si mírně zlepšuje bilanci zvládnutím všech testů poslední sady. Bezproblémově pracuje se šifrovanými a zároveň podepsanými e-maily, a to v obou variantách. Po předchozích testech také velmi překvapuje bezchybným zobrazením e-mailů, které jsou vícenásobně podepsané. E-mailový klient Mozilla Thunderbird vzbuzuje celkově negativní dojem. Tohoto klienta nikomu nedoporučuji, protože obsahuje vážné chyby při práci se zabezpečenou poštou a s certifikáty veřejných klíčů.
4.2.5 Netscape Mail 9.0a1 E-mailový klient Netscape Mail je založen na stejném základu jako Mozilla Thunderbird. Jeho podpora skončila podobně jako v případě Netscape Navigatoru v roce 2008, přesto jsem v jeho chování neobjevil ani jeden rozdíl v porovnání s Mozillou Thunderbird. Z toho vyvozuji, že v rámci bezpečnosti nedošlo při vývoji Mozilly Thunderbird k žádné relevantní změně. Tento fakt poukazuje na to, že této oblasti není stále věnovaná dostatečná pozornost, což by se mělo změnit. Tohoto e-mailového klienta opět nikomu nedoporučuji. Důvody jsou stejné jako v případě Mozilly Thunderbird a navíc lze očekávat, že díky ukončené podpoře tohoto produktu bude bezpečnostních mezer stále přibývat.
4.2.6 The Bat 4.2.9.1 E-mailový klient The Bat sdružuje bezpečnostní nastavení v záložce S/MIME and TLS (Options/S/MIME and TLS). V nabízených volbách je jakýmsi kompromisem mezi Outlookem 2007 a Mozillou Thunderbird. Kladně hodnotím především možnost volby hashovací funkce a šifrovacího algoritmu. Dále je podporovaná ještě časová známka, která se u ostatních testovaných e-mailových klientů vůbec neobjevuje. The Bat disponuje vlastním správcem certifikátů, který je ale v menu nešťastně umístěný a není snadné ho najít. Pro použití soukromého klíče je nutné zadat heslo pro přístup k soukromému klíči. To je správný přístup, protože umožňuje používání tohoto klienta více uživateli zároveň. Podepsaná zpráva je viditelně označena a cením si snadného zobrazení podrobností o certifikátu a o podpisu. Opravdovou výhodou tohoto klienta je pak interní implementace hashovacích i šifrovacích funkcí, které zahrnují i funkci SHA-2. E-mailový klient zobrazuje podrobnou chybovou zprávu v případě přijetí e-mailu z jiné e-mailové adresy, než je uvedena v certifikátu, v případě expirovaného certifikátu i certifikátu, který ještě platit nezačal. Tyto zprávy nejsou nijak zvlášť propracované, ale svůj účel plní. Největší slabinou tohoto klienta je pak práce s CRL. Odvolaný certifikát je označen jako důvěryhodný a indikace nedostupného CRL také není zobrazena. To považuji za vážné bezpečnostní nedostatky.
23
4.2. VÝSLEDKY TESTOVÁNÍ Výsledky třetí sady jsou opět stejné jako v případě dříve testovaných e-mailových klientů. Celková bilance je tedy platný e-mail, který má být neplatný a neplatný e-mail, který má být platný. Další dva testy, které zahrnují práci s CRL, jsem neprovedl z výše zmíněných důvodů. V rámci poslední sady dosáhl klient výborných výsledků. Přijetí šifrovaného e-mailu je pak navíc výrazně indikováno, včetně příslušného popisu. Násobné podpisy označuje korektně jako platné. V této sadě testů není nic, co bych mohl klientovi vytknout. Celkově působí The Bat profesionálním dojmem. Nabízené funkce ocení spíše pokročilejší uživatelé. Vzhledem k bezchybnému původnímu nastavení je však možné, aby tohoto klienta využívali i méně zkušení uživatelé. Největším nedostatkem klienta je práce s CRL, která kazí jinak velmi dobrý dojem.
4.2.7 Mulberry 4.0.8 E-mailový klient Mulberry ve své základní verzi neobsahuje podporu pro S/MIME. Proto bylo nutné před samotným testováním nejprve nainstalovat odpovídající plugin. Klient nenabízí téměř žádné bezpečnostní volby a v tomto ohledu ho lze přirovnat ke klientovi MS Outlook Express. Navíc celkovým vzhledem působí velmi zmateně a neprofesionálně. Mulberry disponuje vlastním správcem certifikátů. Tento správce opět vzbuzuje negativní dojem a neumožňuje například export certifikátů, což je u ostatních klientů standardní funkce. Další problém jsem zaznamenal při pokusu o import kořenového certifikátu ve formátu Distinguished Encoding Rules (DER). V tomto případě aplikace úplně spadne. Podporovaným formátem je jen Privacy Enhanced Mail (PEM). Pro použití soukromého klíče zůstává zachováno heslo pro přístup k soukromému klíči a je vyžadováno při každém podpisu. Indikace podepsaného e-mailu je viditelná, problém ale nastává při pokusu o zobrazení certifikátu. To je možné jen přes správce certifikátů, kam je tento certifikát automaticky uložen. To ovšem není nejšťastnější řešení. Poslední test se zabývá funkcí SHA-2, která klientem není podporována. Mulberry v rámci první sady jako jediný totálně propadl. V rámci druhé testovací sady si klient korektně poradí s certifikátem pro rozdílnou e-mailovou adresu, s certifikátem, který už expiroval a s certifikátem, který ještě nezačal platit. Na druhou stranu nepracuje s CRL a revokovaný certifikát je tedy považován za platný. Na nedostupné CRL pak také neupozorňuje. Oba tyto nedostatky považuji za vážný bezpečnostní problém. Z výše zmíněných důvodů jsem testy týkající se CRL ve třetí sadě již neprováděl. Zbylé dva testy této sady klient nezvládl. V prvním případě označil platný podpis za neplatný a v druhém ještě hůře neplatný podpis za platný. Poslední testovací sada dělala e-mailovému klientu Mulberry také problémy. Sice zvládl korektně zobrazit e-mail, který byl nejprve podepsaný a teprve poté zašifrovaný, s opačnou variantou si již ale neporadil. Podobně pak zvládl ověřit e-mail, který je třikrát po sobě podepsaný jedním uživatelem, ale dva rozdílné podpisy již nezvládl. Toto jsou opět nedostatečné výsledky. Celkově hodnotím tohoto klienta velmi negativně a rozhodně ho nemohu doporučit. V základní verzi nezahrnuje podporu pro zabezpečenou poštu a i po instalaci příslušného pluginu patří dosažené výsledky testování mezi ty nejhorší. 24
4.2. VÝSLEDKY TESTOVÁNÍ
4.2.8 Becky! Internet Mail 2.21.04 E-mailový klient Becky! Internet Mail ve své základní verzi nepodporuje digitální podpis ani šifrovanou komunikaci. Naštěstí lze najít odpovídající plugin přímo na oficiálních stránkách tohoto klienta. Po instalaci nabízí jen dvě volby (Tools/Plug-Ins Setup/Becky! S/MIME plug-in), a to výběr šifrovacího a hashovacího algoritmu. Tím se řadí na místo klienta s nejméně nabízenými možnostmi. V rámci první testovací sady není práce se zabezpečenou poštou vůbec jednoduchá. Zde se plně projevuje to, že ji klient ve své základní verzi nepodporuje. Podepsaný e-mail je přijat s přílohou smime.p7s a pro ověření je nutné najít tuto funkci v menu a spustit ověření. Toto řešení jednak není uživatelsky příjemné a jednak může v mnoha případech vést k tomu, že e-mail bude považován za nepodepsaný. Toto hodnotím jako velmi nešťastné řešení. Klient pracuje s certifikáty uloženými přímo v OS a bezpečnost soukromého klíče tedy neřeší. Kladně hodnotím schopnost přijmout e-mail podepsaný s použitím funkce SHA-2. Na druhou stranu při vytváření podpisu nabízí klient jen funkce SHA-1 a MD5. E-mailový klient Becky! Internet Mail korektně zamítá certifikát vydaný pro rozdílnou e-mailovou adresu, expirovaný certifikát i certifikát, který ještě nezačal platit. Pro všechny tyto výsledky bylo ovšem nutné nejprve ručně spustit ověření podpisu. Klient navíc nepracuje s CRL a revokovaný certifikát je označen za platný. Stejně tak neindikuje nedostupný CRL. Toto jsou další vážné bezpečnostní nedostatky tohoto klienta. Třetí sadu klient zvládá podobným způsobem jako ostatní testovaní klienti. Opět označuje e-mail podepsaný v době platnosti certifikátu jako nedůvěryhodný a e-mail podepsaný v době neplatnosti certifikátu jako důvěryhodný. Další dva testy byly již zbytečné, protože klient nepracuje s CRL. Z tohoto důvodu jsem je tedy neprovedl. V rámci poslední sady testů si klient zvládl bezproblémově poradit se šifrovanými e-maily, a to v obou variantách. V tomto případě je však nutné e-mail nejprve ručně dešifrovat a poté ručně ověřit podpis. Opět se tedy jedná o proceduru, která rozhodně není uživatelsky příjemná. S vícenásobnými podpisy si klient už neporadí a v obou případech je zobrazena chybová zpráva, že podpis nemohl být ověřen. Uživatelskou přívětivost tohoto klienta hodnotím velmi negativně a celkově dosáhl na tomto poli nejhorších výsledků ze všech testovaných aplikací. Becky! Internet Mail navíc neoslní ani svými funkcemi a obsahuje vážné bezpečnostní nedostatky. To rozhodně nejsou důvody pro volbu tohoto klienta.
4.2.9 Eudora 7.1.0.9 E-mailový klient Eudora v základní verzi neobsahuje podporu pro S/MIME. Tento plugin je ovšem snadno dohledatelný na domovských stránkách prohlížeče. Zde je navíc dostupný i podrobný návod pro jeho instalaci i pro použití nabízených funkcí. Ty jsou opět velmi omezené a nejdůležitější z nich je automatické ověřování podpisu příchozího e-mailu. Tyto funkce přímo odrážejí skutečnost, že se jedná o plugin a ne o přímo podporovanou funkcionalitu. Eudora neobsahuje vlastního správce certifikátů a používá standardní úložiště OS. Proto se také nestará o ochranu soukromého klíče. Zvláštní pozornost věnuji označení důvěryhodného 25
4.2. VÝSLEDKY TESTOVÁNÍ e-mailu. To je provedeno přidáním textu Signature verified do těla vlastní zprávy, což hodnotím jako nevhodné řešení. Především proto, že tento text lze v některých případech velmi snadno přehlédnout. Klient umožňuje přijímat e-maily, při jejichž podepisování byla použita funkce SHA-2. Bohužel takové podpisy už neumí vytvářet. E-mailový klient zobrazuje podrobné chybové zprávy v případě přijetí e-mailu z jiné e-mailové adresy, než je uvedena v certifikátu, v případě expirovaného certifikátu i certifikátu, který ještě platit nezačal. Nešťastným řešením je však jejich opětovné umístění do těla vlastního e-mailu. Klient také nepracuje s CRL. Nedostupný CRL a revokovaný certifikát nejsou tedy žádným způsobem odhaleny. Opět musím konstatovat, že se jedná o vážný bezpečnostní nedostatek. V rámci třetí testovací sady klient Eudora velmi příjemně překvapil. Jako jediný z testovaných e-mailových klientů totiž správně vyhodnocuje situaci, kdy v době podpisu nebyl certifikát ještě platný, zatímco v čase stažení e-mailu už platný byl. Takto přijatý e-mail je tedy korektně považován za nedůvěryhodný. Na druhou stranu, opačnou situaci klient již nezvládl a e-mail s platným podpisem označil jako nedůvěryhodný. Testy týkající se CRL jsem opět z jasných důvodů už neprovedl. E-mailový klient Eudora nezvládá práci se šifrovanou poštou. V obou případech je zobrazena chybová zpráva plugin error. Toto není vysloveně bezpečnostní hrozba, ale na celkovém hodnocení prohlížeče to rozhodně nepřidá. Vícenásobně podepsané e-maily pak klient v pořádku zobrazí a v případě e-mailu podepsaného dvěma různými uživateli pak hodnotím zobrazenou zprávu jako nejlepší v rámci všech testovaných klientů. Zobrazí totiž přesnou informaci, že jeden podpis byl korektně ověřen a ve druhém se neshodují e-mailové adresy. Celkově nabízí Eudora slabší uživatelské prostředí a o přílišném komfortu se u tohoto klienta také mluvit nedá. Na druhou stranu poskytuje určité funkce, které žádný jiný klient nenabízí, což mu rozhodně přidává na hodnocení. Celkové zhodnocení tohoto klienta může být velmi subjektivní s ohledem na konkrétní potřeby uživatele, proto jej jednoznačně ani nedoporučuji, ani nezavrhuji.
4.2.10 FoxMail 6.5 E-mailový klient FoxMail nabízí skromné bezpečnostní volby (Tools/Preference/Security) a svým nastavení připomíná MS Outlook Express. Jedna z voleb je kontrola odvolání certifikátu. I u tohoto klienta je tato možnost po instalaci vypnuta. Toto hodnotím negativně a považoval bych za vhodnější, kdyby byla od začátku zapnuta. Kladně pak hodnotím možnost zapnout upozornění na šifrované zprávy, ve kterých byl použit šifrovací klíč délky 56 bitů a menší. FoxMail nedisponuje vlastním správcem certifikátů a pracuje přímo s certifikáty, umístěnými v klasických úložištích OS. Z tohoto důvodu se také nestará o bezpečnost soukromých klíčů. Kladně posuzuji upozornění na podepsaný e-mail, které je zobrazeno ještě před samotným otevřením tohoto e-mailu. Cením si pak také snadného zobrazení certifikátu a podrobností o podpisu. Klient umí pracovat i s e-maily, při jejichž podepisování byla použita funkce SHA-2. Při vytváření digitálního podpisu ji však použít neumí. E-mailový klient zobrazuje podrobnou chybovou zprávu v případě certifikátu vydaného pro rozdílnou e-mailovou adresu, revokovaného certifikátu, expirovaného certifikátu i certifikátu, který ještě nezačal platit. Jediný problém v rámci této testovací sady je nedostupný CRL, 26
4.3. ZHODNOCENÍ VÝSLEDKŮ TESTOVÁNÍ na který klient žádným způsobem neupozorňuje. Ještě musím podotknout, že před provedením těchto testů bylo nejprve nutné zatrhnout v nastavení položku pro kontrolu CRL. Třetí testovací sada skončila opět stejným výsledkem jako u všech ostatních klientů. Celková bilance klienta FoxMail jsou dva e-maily neprávem označené jako neplatné a jeden e-mail neprávem označený jako platný. Posílání e-mailu mezi časovými pásmy zvládá klient v pořádku. V rámci poslední testovací sady obstál FoxMail na výbornou. Zvládá bez problému obě varianty podepsaného a zároveň šifrovaného e-mailu. Navíc si poradí i s vícenásobnými podpisy a v obou případech je schopen je korektně ověřit. Celkově hodnotím e-mailového klienta FoxMail velmi kladně. Svým uživatelským prostředím sice dvakrát nenadchne, ale bezpečnostní funkce patří k těm nejlepším. Na druhou stranu zde stále postrádám podporu pro funkci SHA-2, což považuji za největší nedostatek tohoto klienta.
4.3
Zhodnocení výsledků testování
V rámci první testovací sady kladně hodnotím především to, že všichni klienti správným způsobem chrání soukromý klíč. Čtyři z nich pak dokonce obsahují vlastního správce certifikátů. Korektní upozornění na e-mail s platným podpisem potom zobrazilo jen osm klientů z deseti. Toto považuji za nedostatečný výsledek. Tato funkce by měla být v dnešní době již standardem, proto jsem očekával, že v tomto testu uspějí všichni klienti. Velmi špatným výsledkem potom skončily testy zabývající se funkcí SHA-2. Pouze šest klientů zvládá zobrazit e-mail, při jehož podpisu byla tato funkce využita. Navíc pouze dva klienti zvládají takovýto podpis vytvořit. V dnešní době, kdy byly již odhaleny bezpečnostní nedostatky funkce SHA-1, je to velmi neuspokojivé číslo. Výsledky druhé sady skončily o něco lépe, přesto největším nedostatkem zůstává stejně jako v případě webových prohlížečů práce s CRL. Pouze čtyři klienti z deseti odhalili revokovaný certifikát a jen jeden upozornil na nedostupný CRL. Toto považuji za velmi vážné bezpečnostní nedostatky. Zbylé tři testy, kterými jsou certifikát pro jinou e-mailovou adresu, expirovaný certifikát a certifikát, který ještě nezačal platit, skončily již s uspokojivými výsledky a většina klientů je zvládla. Třetí testovací sada skončila bohužel výsledky opravdu zoufalými. Všichni klienti porovnávají platnost podpisu vůči aktuálnímu časovému údaji. Žádný z nich nebere v úvahu dobu vytvoření podpisu. Stejně tak i v případě zařazení certifikátu na CRL je hodnocena jen přítomnost či nepřítomnost certifikátu v tomto seznamu a čas odvolání nehraje žádnou roli. Toto lze v některých případech odvolaného certifikátu považovat za prozíravost – to tehdy, kdy vlastník soukromého klíče nahlásil jeho odcizení až ve chvíli, kdy ho již útočník stihl použít. Ovšem v případě, že certifikátu skončila platnost, to považuji za chybu. Stejně je tomu i v případě, kdy certifikát v době vytvoření podpisu ještě neplatí. Devět z deseti klientů takovýto podpis označí později za platný. Poslední sada skončila o poznání lépe – práci se šifrovanou poštou a vícenásobnými podpisy zvládá většina klientů. Přestože v případě pochybení by se nejednalo o vážné bezpečnostní nedostatky, hodnotím tyto výsledky kladně.
27
4.3. ZHODNOCENÍ VÝSLEDKŮ TESTOVÁNÍ Nakonec je třeba zmínit ještě skutečnost, že testováno mělo být původně 16 e-mailových klientů. Dalších šest však nepodporuje zabezpečení pošty podle standardu S/MIME a neexistuje pro ně ani žádné rozšíření nebo plugin. Těmito klienty jsou Opera, Mailer, Zimbra Desktop, PocoMail, Sylphee a Pegasus mail. Tato skutečnost poukazuje na stále slabý důraz na bezpečnost v rámci elektronické pošty. Celkové výsledky dosažené jednotlivými e-mailovými klienty přehledně shrnuje tabulka 4.1. Do celkového skóre jednotlivých e-mailových klientů, 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í.
28
4.3. ZHODNOCENÍ VÝSLEDKŮ TESTOVÁNÍ
Tab. 4.1: Výsledky dosažené jednotlivými e-mailovými klienty 29
Kapitola 5
Závěr Teoretická část bakalářské práce měla za cíl uvést čtenáře do problematiky bezpečnosti informačních technologií. Dále jsem se zaměřil především na zabezpečenou komunikaci s internetovými servery a na zabezpečení elektronické pošty, obojí s pomocí infrastruktury veřejných klíčů a certifikátů podle standardu X.509. Touto problematikou se zabývaly první dvě kapitoly. Hlavním cílem práce potom bylo odhalení chyb při práci jednotlivých webových prohlížečů a e-mailových klientů s certifikáty veřejných klíčů. Přípravou, průběhem a výsledky testování, koncipovaného k odhalování těchto chyb, se zabývaly kapitoly tři a čtyři. Samotné testování se skládalo ze dvou fází. Nejprve jsem sestavil jednotlivé testovací sady, přičemž jsem vycházel jednak z vlastních zkušeností a jednak z podrobné analýzy všech potenciálních problémů, které mohly při práci s certifikátem nastat. Tato fáze byla na jednu stranu velmi obtížná a vyžadovala důkladnou práci s literaturou a jednotlivými standardy, na druhou stranu, a možná právě díky této náročnosti, v ní vidím nejvýznamnější osobní přínos své práce. Druhou fází testování bylo potom samotné technické provedení. Podpora SSL/TLS je v dnešní době již nepostradatelná a tvůrci webových prohlížečů jsou si tohoto faktu velmi dobře vědomi. O tom, že se jedná o již zaběhlou technologii, svědčí také tendence předkládat uživateli stále propracovanější zprávy, které již nemůže bezmyšlenkovitě odklikat. Navíc, na rozdíl od podpory e-mailových klientů protokolu S/MIME, všechny testované prohlížeče protokol SSL/TLS podporovaly. Mezi nejčastější problémy, ke kterým v případě webových prohlížečů docházelo, patřila práce se seznamem odvolaných certifikátů a s certifikáty, které přestaly platit během probíhajícího SSL/TLS spojení. V některých případech se navíc objevoval problém s automatickým nastavením po instalaci, v rámci něhož může být vypnuta kontrola CRL, nebo dokonce podpora protokolu SSLv2. O dobrém trendu potom svědčí rozšířená podpora funkce SHA-2. Výsledky testování e-mailových klientů ukazují, že digitální podpisy nedosáhly takového rozšíření jako zabezpečená komunikace s internetovými servery. Standard S/MIME byl podporován pouze deseti z šestnácti vybraných e-mailových klientů, z toho bylo ve třech případech nutné doinstalovat příslušný plugin. To může svědčit i o nízké informovanosti běžných uživatelů, kteří si nemusejí být vědomi možných bezpečnostních rizik spojených s elektronickou poštou, přestože v případě klasické pošty míru bezpečnosti komunikace odhadnout dokážou.
30
5. ZÁVĚR Nejčastějším problémem při práci s digitálně podepsanými zprávami byla, stejně jako v případě webových prohlížečů, práce s CRL. Navíc se objevovalo i množství dalších problémů, jako například akceptace certifikátu vydaného pro jinou e-mailovou adresu, nebo dokonce neplatného certifikátu. Jako problém vidím také to, že veškeré ověřování platnosti, popřípadě zařazení na CRL, se děje vůči aktuálnímu časovému údaji a není zohledněn čas vytvoření digitálního podpisu, popřípadě čas zařazení na CRL. Práce může sloužit jako návod pro volbu konkrétní aplikace na základě specifických bezpečnostních kritérií a požadavků. I čtenáři, který v současnou chvíli má již svůj oblíbený program, může práce poskytnout informace o přednostech a nedostatcích jím používaných aplikací a o úrovni bezpečnosti, se kterou může počítat. Práce může být také vhodným podkladem pro společnosti, které se zabývají vývojem webových prohlížečů a e-mailových klientů, a to především pro opravu stávajících bezpečnostních problémů.
31
Seznam použité literatury [1]
MENEZES, A. J., OORSCHOT, P., VANSTONE, S. A. Handbook of Applied Cryptography. Boca Raton: CRC-Press, 1996. ISBN 0-8493-8523-7.
[2]
SINGH, S. Kniha kódů a šifer. Přel. KOUBSKÝ, P., ECKHARDTOVÁ, D. Praha: Argo, 2003. ISBN 80-7203-499-5.
[3]
DOSTÁLEK, L., VOHNOUTOVÁ, M. Velký průvodce infrastrukturou PKI a technologií elektronického podpisu. Brno: Computer Press, 2006. ISBN 80-251-0828-7.
[4]
SCHMEH, K. Cryptography and Public Key Infrastructure on the Internet. Hoboken: Wiley, 2003. ISBN: 978-0-470-84745-9.
[5]
ITU-T Recommendation X.509 [online]. Information Technology - Open Systems Interconnection - The Directory: Authentication Framework. Ženeva, 2005. [cit. 2. února 2010]. Dostupné na:
.
[6]
HOUSLEY, R., POLK, W., BASSHAM, L. RFC 3279 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile [online]. 2002. [cit. 2. dubna 2010]. Dostupné na: .
[7]
HOUSLEY, R., POLK, W., FORD, W., SOLO, D. RFC 3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile [online]. 2002. [cit. 2. dubna 2010]. Dostupné na: .
[8]
FARRELL, S., HOUSLEY, R. RFC 3281 An Internet Attribute Certificate Profile for Authorization [online]. 2002. [cit. 2. dubna 2010]. Dostupné na: .
[9]
FREIER, A. O., KARLTON, P., KOCHER, P. C. The SSL Protocol Version 3.0 [online]. 1996. [cit. 8. února 2010]. Dostupné na: .
[10]
OPPLIGER, R. Security Technologies for the World Wide Web. Boston: ARTECH HOUSE, 2003. ISBN 978-1-58053-348-5.
[11]
DIERKS, T., ALLEN, C. RFC 2246 The TLS Protocol Version 1.0 [online]. 1999. [cit. 15. března 2010]. Dostupné na: . 32
SEZNAM POUŽITÉ LITERATURY [12]
DIERKS, T., RESCORLA, E. RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1 [online]. 2006. [cit. 15. března 2010]. Dostupné na: .
[13]
DIERKS, T., RESCORLA, E. RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 [online]. 2008. [cit. 15. března 2010]. Dostupné na: .
[14]
RAMSDELL, B. RFC 3850 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling [online]. 2004. [cit. 26. února 2010]. Dostupné na: .
[15]
RAMSDELL, B. RFC 3851 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification [online]. 2004. [cit. 26. února 2010]. Dostupné na: < http://tools.ietf.org/html/rfc3851>.
[16]
RAMSDELL, B., TURNER, S. RFC 5751 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification [online]. 2010. [cit. 1. dubna 2010]. Dostupné na: < http://tools.ietf.org/html/rfc5751>.
[17]
LUCAS, M. W. PGP & GPG: Email for the Practical Paranoid. San Francisco: No Starch Press, 2006. ISBN 978-1-59327-071-2.
[18]
ELKINS, M., TORTO, D. D., LEVIEN, R., ROESSLER, T. RFC 3156 MIME Security with OpenPGP [online]. 2001. [cit. 26. února 2010]. Dostupné na: .
[19]
APPU, A. Administering and Securing the Apache Server. Ohio: Premier Press, 2002. ISBN 1-59200-003-7.
[20]
What is Maxthon [online]. [cit. 3. prosince 2009]. Dostupné na: .
[21]
About Wyzo [online]. [cit. 3. prosince 2009]. Dostupné na: .
[22]
SeaMonkey Project [online]. [cit. 5. prosince 2009]. Dostupné na: .
[23]
OpenSSL Documents [online]. [cit. 6. ledna 2010]. Dostupné na: .
33
