Práce Aplikací S Certifikáty Veřejných Klíčů-El

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 webo-
vý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 Úvod ............................................................................................................................................................. 1
2 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
3 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
4 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 spra-
vovat 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é vlastnic-
tví chránit.
Jedním z nejdůležitějších požadavků je dnes zajištění bezpečné komunikace s interneto-

vý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 apli-
kace 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 ser-
very. 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 sa-
motnou kryptografií, dále pak certifikáty veřejných klíčů podle standardu X.509 a následně uka-
zuji práci protokolů SSL a TLS. Nakonec se věnuji standardu pro S/MIME, který je nepostrada-
telný 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 aspek-
tů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í algo-
ritmus, 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. Dru-
hým je potom klíč veřejný, který se používá pro šifrování a ověřování digitálního podpisu. Samo-
zř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 infra-
struktura 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 asy-
metrické 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ě identifiko-
vat 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á. Obsa-
hovala 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í vlast-
ní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 indi-
kovat, 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 stra-
nu, 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ře-
nosy (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 je-
ho 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ře-
tí 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 samot-
né š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 in-
formace má již od HP.
Handshake protocol se aktivuje ihned po navázání spojení a zajišťuje identifikaci komu-

nikují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í), se-
znam 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í me-
todu, které jsou vybrané ze seznamu obdrženého v kroku jedna, náhodné číslo a svůj certifi-
ká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žada-
vek 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 po-
tvrzení 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 komunika-

ci – 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 Multi-
part/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 zob-
razení 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 sa-
motná š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řes-
nou 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í autori-
ta 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řede-
vší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ě zabez-
pečeného připojení, tak v případě, kdy kořenový certifikát není zařazen mezi důvěryhodné certi-
fikač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 nao-
pak 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án-
ky 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 in-

formací 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 testova-
cí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í (Nastave-
ní/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 doda-
teč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
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 Hlav-
ní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ída-
jí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 ne-
pracuje. 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živate-
lů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í nasta-
vení 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 sku-
teč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
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 ne-
dostupné CRL, které zobrazí už jen jeden další prohlížeč. Toto upozornění sice není přesné, přes-
to 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í cer-
tifiká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 certi-
fiká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 nepo-
krač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 vy-
svě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 pro-
hlížeč dostatečných výsledků. Dále kladně hodnotím korektní chybovou zprávu v případě zařa-
12
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 spo-
jení. 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 zobraze-
na až po obnovení stránky. U revokovaného certifikátu je potřeba počkat, než vyprší dříve staže-
ný 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řede-
vším blíže nevysvětlený otazník v případě důvěryhodného certifikátu a dále pak nemožnost zob-
razení 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 sou-
kromí (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é in-
formace 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 jedi-
ný 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
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 neindi-

kuje 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 po-
kročilejšími nastaveními. V tomto ohledu nabízí Safari nejméně voleb ze všech testovaných pro-
gramů.
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. Pro-
to celková bezpečnost soukromého klíče závisí na nastavení pravidel v rámci tohoto OS. Zabez-
peč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ěry-
hodné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živate-
le 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ž vy-
prší dříve stažený CRL. V ostatních případech je pro správnou chybovou zprávu nezbytné obno-
vení stránky.
14
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ýsled-
ky dosahuje podobné kvality jako Google Chrome, avšak uživatelským rozhraním hluboce zao-
stá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 ad-
resu, 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 nepra-
cuje 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í cho-
vá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 šifrova-
15
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ůvod-
ně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 vy-
chází. Oba tyto prohlížeče opět dosáhly vesměs podobné výsledky, a to navzdory tomu, že pod-
pora 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 odposlech-
nuta třetí stranou. V některých případech se sice může jednat o redundantní informaci, ale cel-
kově 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 pod-
pora 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ů, zby-
lá 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řípa-
dech, což považuji za velmi špatný výsledek. Na druhou stranu, správné upozornění na nedůvě-
16
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 spo-
jení 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 nere-
levantní.
17
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 nedo-
stupnosti 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ému-
koli 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 certifi-
ká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 po-
slední testuji schopnost klienta pracovat s hashovací funkcí SHA-2, přesněji SHA-512. Zde hod-
notí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
 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 srozumitel-
nost 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í:
 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ší.
4.2 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ástro-
je/Možnosti/Zabezpečení/Zabezpečená pošta). Tyto volby jsou ovšem jen velmi omezené. Nega-
tivně 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 podepi-
sová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 digi-
tálním podpisu. Problém ovšem nastává při využití funkce SHA-2. Klient tuto funkci nedokáže
20
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ý. Stej-
ný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ěry-
hodný. 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í certifi-
ká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ě hod-
notím jako krok správným směrem. Nicméně při vytváření podpisu klient tuto funkci stále ne-
podporuje. 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 zabez-
peč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
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í digi-
tá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 certifi-

ká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 pod-
pisu, přesto je to skvělý výsledek. Na druhou stranu přesně naopak končí test certifikátu s rozdíl-
nou e-mailovou adresou. V tomto případě není zobrazeno žádné upozornění a podpis je považo-
vá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 infor-
mací, ž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ů hle-
dali 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ěřova-
ní. 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 toho-
to 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 podrob-
ností 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, ne-
pracuje 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
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íce-
ná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 certi-
fiká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řípa-
dě 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 (Opti-
ons/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 šifrova-
cí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 soukro-
mé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í. Nej-
větší slabinou tohoto klienta je pak práce s CRL. Odvolaný certifikát je označen jako důvěryhod-
ný a indikace nedostupného CRL také není zobrazena. To považuji za vážné bezpečnostní nedo-
statky.
23
Výsledky třetí sady jsou opět stejné jako v případě dříve testovaných e-mailových klien-
tů. 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í ji-
nak 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 negativ-
ní 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 podepsa-
né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šťast-
ně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 nedo-
stupné CRL pak také neupozorňuje. Oba tyto nedostatky považuji za vážný bezpečnostní pro-
blé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 va-
riantou 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.8 Becky! Internet Mail 2.21.04

E-mailový klient Becky! Internet Mail ve své základní verzi nepodporuje digitální podpis ani šif-
rovanou 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še-
ní 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ču-
je 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 nepra-
cuje 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 chy-
bová 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
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 žád-
ný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 testo-
vaných e-mailových klientů totiž správně vyhodnocuje situaci, kdy v době podpisu nebyl certifi-
kát ještě platný, zatímco v čase stažení e-mailu už platný byl. Takto přijatý e-mail je tedy korekt-
ně 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 zobra-
zena 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 infor-
maci, ž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 ne-
nabí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 nedopo-
ruč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 upo-
zorně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 ote-
vřením tohoto e-mailu. Cením si pak také snadného zobrazení certifikátu a podrobností o podpi-
su. 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
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ů. Cel-
ková 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 pro-
středím sice dvakrát nenadchne, ale bezpečnostní funkce patří k těm nejlepším. Na druhou stra-
nu 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ůso-
bem chrání soukromý klíč. Čtyři z nich pak dokonce obsahují vlastního správce certifikátů. Ko-
rektní 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ý certi-
fiká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 porov-
návají platnost podpisu vůči aktuálnímu časovému údaji. Žádný z nich nebere v úvahu dobu vy-
tvoř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
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
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 infor-
mačních technologií. Dále jsem se zaměřil především na zabezpečenou komunikaci s interneto-
vý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 testo-
vá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í sa-
dy, přičemž jsem vycházel jednak z vlastních zkušeností a jednak z podrobné analýzy všech po-
tenciá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 nasta-
vením po instalaci, v rámci něhož může být vypnuta kontrola CRL, nebo dokonce podpora proto-
kolu 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 podpo-
rová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 ne-
platného certifikátu. Jako problém vidím také to, že veškeré ověřování platnosti, popřípadě zařa-
zení 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 bez-
pečnostních kritérií a požadavků. I čtenáři, který v současnou chvíli má již svůj oblíbený pro-
gram, 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ře-
devší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 Cryptogra-
phy. 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 technolo-

gií elektronického podpisu. Brno: Computer Press, 2006. ISBN 80-251-0828-7.
[4] SCHMEH, K. Cryptography and Public Key Infrastructure on the Internet. Hobo-
ken: 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: <http://www.itu.int/rec/dologin_pub.asp
?lang=e&id=T-REC-X.509-200508-I!!PDF-E&type=items>.
[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:
<http://tools.ietf.org/html/rfc3279>.
[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: <http://tools.ietf.org/html/rfc3280>.
[8] FARRELL, S., HOUSLEY, R. RFC 3281 An Internet Attribute Certificate Profile for
Authorization [online]. 2002. [cit. 2. dubna 2010]. Dostupné na: <http://tools.
ietf.org/html/rfc3281>.
[9] FREIER, A. O., KARLTON, P., KOCHER, P. C. The SSL Protocol Version 3.0 [online].
1996. [cit. 8. února 2010]. Dostupné na: <http://www.mozilla.org/projects/
security/pki/nss/ssl/draft302.txt>.
[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: <http://tools.ietf.org/html/rfc2246>.
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: <http://tools.
[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: <http://tools.
[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: <http://tools.ietf.org/html/rfc3850>.
[15] RAMSDELL, B. RFC 3851 Secure/Multipurpose Internet Mail Extensions (S/MIME)

Version 3.1 Message Specification [online]. 2004. [cit. 26. února 2010]. Dostup-
né na: < http://tools.ietf.org/html/rfc3851>.
[16] RAMSDELL, B., TURNER, S. RFC 5751 Secure/Multipurpose Internet Mail Exten-
sions (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: <http://tools.ietf.
org/html/rfc3156>.
[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: <http://wiki.
maxthon.com/index.php/What_is_Maxthon>.
[21] About Wyzo [online]. [cit. 3. prosince 2009]. Dostupné na: <http://www.
wyzo.com/about>.
[22] SeaMonkey Project [online]. [cit. 5. prosince 2009]. Dostupné na: <http://www.
seamonkey-project.org/about>.
[23] OpenSSL Documents [online]. [cit. 6. ledna 2010]. Dostupné na: <http://www.
openssl.org/docs>.
33

Práce Aplikací S Certifikáty Veřejných Klíčů-El

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Práce Aplikací S Certifikáty Veřejných Klíčů-El

Uploaded by

Copyright:

Available Formats

MASARYKOVA UNIVERZITA

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

V Brně, 11. května 2010

Vedoucí práce: doc. RNDr. Václav Matyáš, M.Sc., Ph.D.

Jedním z nejdůležitějších požadavků je dnes zajištění bezpečné komunikace s interneto-

Třetí kapitola se zabývá testováním webových prohlížečů. Nejprve popisuji přípravy

testovacích sadách. Rozhodujícím hodnotícím kritériem je korektní práce s certifikáty veřejných

Již v devatenáctém století zformuloval Auguste Kerckhoffs princip, který v kryptografii

2.1.1 Symetrická kryptografie

Hlavní nevýhodou symetrické kryptografie je nutnost velkého množství klíčů a potřeba

klíčů. To znamená, že pro šifrovanou komunikaci ve středně velké firmě o 50 zaměstnancích by

2.1.2 Asymetrická kryptografie

Asymetrická kryptografie umožňuje šifrování dat, a především také realizaci digitálního

Největší nevýhodou asymetrické kryptografie je její pomalost ve srovnání s kryptografií

2.2 Certifikát podle standardu X.509

 jedinečný identifikátor vlastníka certifikátu;

Obr. 2.1: Certifikát podle standardu X.509

2.3 Protokoly SSL a TLS

Protokol SSL/TLS zajišťuje autentizaci obou komunikujících stran pomocí asymetrické

Protokol SSL/TLS se nachází mezi aplikační a transportní vrstvou referenčního ISO/OSI

Handshake protocol se aktivuje ihned po navázání spojení a zajišťuje identifikaci komu-

Alert protocol zabezpečuje přenos varování v případě jakéhokoliv problému v komunika-

 výměna klíčů: RSA, Fortezza, Diffie-Hellman;

2.4 Standard S/MIME

V případě zprávy s digitálním podpisem je první část samotná zpráva a po ní následuje

Standard pro S/MIME využívá asymetrickou kryptografii a je používán pro end-to-end

Testování webových prohlížečů

Testování proběhlo na počítači s operačním systémem Microsoft Windows 7.

3.1 Příprava testování

Po vytvoření dostatečného počtu certifikátů a zprovoznění webového serveru jsem mohl

 certifikát je vydaný pro rozdílnou doménu;

V poslední sadě testuji možnosti webových prohlížečů odhalit zneplatnění certifikátu

 zařazení certifikátu na CRL;

V rámci všech zmiňovaných testů se také zaměřuji na srozumitelnost předkládaných in-

3.2 Výsledky testování

3.2.1 Opera 10.10

3.2.2 Google Chrome 3.0.195.2

Google Chrome nedisponuje vlastním správcem certifikátů a pracuje s certifikáty, které

3.2.3 Internet Explorer 8.0

Internet Explorer neobsahuje vlastního správce certifikátů a pracuje přímo s certifikáty

3.2.4 Maxthon 2.5.11.3353

Skutečná přednost prohlížeče ovšem spočívá v tom, že si zvládl korektně poradit

3.2.5 Lataza Browser 3.3

Prvním takovýmto rozdílem je skutečnost, že Lataza Browser žádným způsobem neindi-

3.2.6 Safari 4.0.4

Na druhou stranu, Safari poskytuje kvalitní bezpečnostní funkce. Nedisponuje vlastním

3.2.7 Mozilla Firefox 3.5.6

Mozilla Firefox disponuje vlastním správcem certifikátů. Pokud se uživatel rozhodne

3.2.8 Wyzo 3.0.1

Za zmínku stojí nedostatečné upozornění v případě zabezpečeného spojení. V panelu

Celkový dojem tohoto prohlížeče je spíše negativní. Co se týče bezpečnosti a uživatelské-

3.2.9 SeaMonkey 2.0.1

Jednou z mála výjimek je indikace zabezpečeného spojení. To je signalizováno malým

3.2.10 Netscape Navigator 9.0.0.6

3.3 Zhodnocení výsledků testování

Celkové výsledky dosažené jednotlivými prohlížeči přehledně shrnuje tabulka 3.1.

Tab. 3.1: Výsledky dosažené jednotlivými prohlížeči

Testování e-mailových klientů

Testování proběhlo na počítači s operačním systémem Microsoft Windows 7. Jedinou

4.1 Příprava testování

Někteří z testovaných e-mailových klientů nepodporují S/MIME v základní verzi. Proto

 certifikát je vydán pro jinou e-mailovou adresu;

 e-mail, který je nejprve zašifrovaný a teprve poté podepsaný;