Bajecny svet elektronickeho podpisu | online podpora stejnojmenne knihy z Edice CZ.NIC

8.3.2         SSL komunikace

Velmi podobnému účelu, a to zabezpečené komunikaci mezi dvěma stranami, slouží i řešení, které si můžeme označit jako SSL komunikaci. Specifikem je ale to, že jde o asymetrickou komunikaci mezi jednou stranou, která vystupuje jako server, a druhou stranou, která vystupuje jako klient.

Ačkoli jde o univerzální řešení, které mohou využívat různé aplikační protokoly, nejčastěji se s ním setkáme ve spojitosti s webem, neboli se službou World Wide Web. Serverem je pak webový server a klientem webový browser, resp. prohlížeč. Stejně tak by se ale mohlo jednat například o poštovní server a poštovního klienta či o FTP server a FTP klienta atd.

To, co SSL komunikace nabízí, jsou obecně tři různé přínosy: 

·         autentizace serveru vůči klientovi (aby klient měl jistotu, že komunikuje s tím, s kým si myslí, že komunikuje)

·         identifikace klienta vůči serveru (aby si mohl být jist server)

·         šifrování komunikace mezi klientem a serverem.

V praxi ale mohou být (a obvykle jsou) využívány jen dva přínosy, resp. cíle: autentizace serveru vůči klientovi a šifrování komunikace mezi klientem a serverem. Autentizace klienta vůči serveru je volitelná, protože mnohdy nemusí být ani potřebná. Nebo spíše: identifikace a autentizace klienta je často řešena jinak - a to samostatně, nikoli jako přímá součást SSL komunikace.

Obvykle je to tak, že nejprve je navázána zabezpečená komunikace mezi klientem a serverem na bázi SSL, v rámci které se server autentizuje vůči klientovi (a veškerá jejich vzájemná komunikace je nadále šifrována). Teprve následně, když již mezi oběma stranami existuje možnost zabezpečené komunikace, dochází k autentizaci klienta vůči serveru. Přesněji na straně klienta se autentizuje konkrétní uživatel - a to vůči konkrétní aplikaci, která běží na daném serveru. 

Z této představy vycházely i příklady přihlašování, které jsme si popisovali v části 8.2. Všechny měly společné to, že by měly být používány až poté, co bylo mezi oběma stranami navázáno zabezpečené spojení prostřednictvím SSL komunikace.

To, že takovéto zabezpečené spojení mezi klientem a serverem existuje, pozná uživatel webového browseru podle několika příznaků. Jedním z nich je jméno protokolu v URL odkazu na server: již nejde o (nezabezpečený) protokol HTTP, díky kterému URL odkazy začínají na http://. Nyní již jde o zabezpečený protokol HTTPS, kvůli němuž příslušná URL začínají na https://.

Vedle toho různé webové browsery indikují existenci zabezpečené SSL komunikace i dalším způsobem, například ikonkou v podobě visacího zámku: Internet Explorer jej zobrazuje v adresovém řádku vpravo od URL odkazu, Firefox zase vpravo dole. Firefox pak přidává ještě grafické zvýraznění adresy serveru uvnitř adresového řádku, vlevo od URL odkazu:

Pro obrázek ve větší kvalitě klikněte na odkaz pod číslem obrázku v legendě

Indikace zabezpečeného SSL spojení s webovým serverem

Obrázek 8 - 18: Indikace zabezpečeného SSL spojení s webovým serverem

Kliknutím na příslušný indikátor pak lze získat detailnější informace o certifikátu, kterým se server autentizuje. V případě Internet Exploreru je to ikonka visacího zámku, v případě Firefoxu barevně zvýrazněná doména vlevo od URL odkazu:

Pro obrázek ve větší kvalitě klikněte na odkaz pod číslem obrázku v legendě

Detailnější informace o serverovém certifikátu

Obrázek 8 - 19: Detailnější informace o serverovém certifikátu

 Zabezpečené SSL spojení mezi klientem a serverem přitom vzniká následujícím postupem:

·         klient nejprve pošle serveru výzvu k navázání SSL spojení a domluví se na detailech tohoto spojení[13]

·         server poskytne klientovi svůj (serverový) certifikát. Klient vyhodnotí jeho platnost a dále pokračuje jen tehdy, pokud tento certifikát shledá platným

·         klient vygeneruje dočasný tajný klíč, který zašifruje veřejným klíčem serveru (ten získal z jeho certifikátu), a takto zašifrovaný klíč pošle serveru. Pokud je požadována i autentizace klienta (což obvykle není), připojí klient k zašifrovanému klíči i svůj certifikát[14]

·         klient i server využijí dočasného tajného klíče k vygenerování „řádného“ tajného klíče, kterým pak šifrují svou vzájemnou komunikaci.

Z pohledu koncového uživatele je většina těchto kroků neviditelná – až na dvě výjimky. Jednou z nich je (v praxi spíše výjimečný) požadavek na autentizaci klienta ještě v rámci navazování SSL spojení. V takovém případě je uživatel svým browserem vyzván k výběru toho svého certifikátu, kterým se hodlá vůči serveru autentizovat.

 

Druhou výjimkou, která se obecně týká každého uživatele, je vyhodnocení platnosti certifikátu serveru[15]. To probíhá standardním způsobem, který jsme si popisovali v kapitole 3, a tedy i s posouzením důvěryhodnosti tohoto certifikátu – oproti obsahu toho úložiště, se kterým pracuje právě používaný browser.

Právě zde ale může nastat nepříjemný problém: ačkoli může být certifikát serveru jinak „zcela v pořádku“, browser nemusí mít dostatečné informace k tomu, aby jej mohl prohlásit za důvěryhodný. Nejspíše proto, že „nezná“ tu certifikační autoritu, která jej vydala (neboť nemá její kořenový certifikát ve svém úložišti důvěryhodných kořenových certifikátů).

Stejně tak ale většinou nemá důvod považovat certifikát za nedůvěryhodný. Ve smyslu toho, co jsme si popisovali v kapitole 3, pak browser musí konstatovat „nevím“, neboli že nedokáže posoudit důvěryhodnost toho certifikátu, kterým se server prokazuje.

V praxi tato situace může nastávat častěji, než by si kdo přál, a to kvůli problému s počáteční náplní úložišť důvěryhodných certifikátů a s aktualizací této náplně. Viz podrobnější diskuse celého problému v 5. kapitole, v částech 5.4.3 a 5.4.4.

V ČR potkal tento problém datové schránky: server, na kterém běžel webový portál datových schránek, se prokazoval serverovým certifikátem, který mu vydala certifikační autorita PostSignum. Její kořenový certifikát ale nebyl součástí počáteční náplně snad žádného z používaných webových browserů, a ani do nich nebyl automaticky načítán. A tak browsery, používané prvními uživateli datových schránek, zcela správně dospěly k závěru, že o důvěryhodnosti příslušného serveru nemají dostatek informací.

Jak se ale má zachovat webový browser v situaci, kdy by měl navázat zabezpečené SSL spojení s konkrétním serverem, ale není schopen vyhodnotit jeho certifikát jako důvěryhodný? A když současně nemá žádný důvod, kvůli kterému by jej mohl považovat za nedůvěryhodný[16]?

Zřejmě jediným možným řešením je sdělit vše uživateli a nechat na něm, jak rozhodne.

Určitý problém je ale v tom, jakým způsobem to webové browsery svým uživatelům sdělují. Většinou totiž uživateli naznačují spíše to, že příslušný server je nedůvěryhodný – a nikoli že o jeho důvěryhodnosti nemají dostatek informací.

Pro obrázek ve větší kvalitě klikněte na odkaz pod číslem obrázku v legendě

Hlášky webových browserů, když nemají dostatek informací k hodnocení důvěryhodnosti serverových certifikátů

Obrázek 8 - 20: Hlášky webových browserů, když nemají dostatek informací k hodnocení důvěryhodnosti serverových certifikátů

Běžný uživatel si pak nemusí správně domyslet, kde je skutečná podstata problému – že vůbec nemusí být v nedůvěryhodnosti serveru, ale že může být i v nastavení jeho browseru a jím používaného úložiště důvěryhodných certifikátů.


[13] Například na tom, jaké kryptografické algoritmy budou společně používat.

[14] Spíše ale certifikát uživatele, který klientský program právě používá.

[15] Jde o systémový certifikát, kterému se obvykle říká „SSL certifikát“ či „serverový certifikát“

[16] Například kvůli revokaci příslušného certifikátu, případně kvůli zařazení tohoto certifikátu či certifikátu jeho vydavatele mezi nedůvěryhodné (v systémovém úložišti MS Windows)



© Jiří Peterka, 2011, profil na Google+
Valid HTML 4.01 Transitional Ověřit CSS!
3A2E
5665
6E6F
7661
6E69
2E3A
0D0A
5475
746F
206B
6E69
6875
2076
656E
756A
6920
7376
6520
7A65
6E65
2049
7265
6E65
2C20
7379
6E6F
7669
204A
6972
696D
7520
6120
6463
6572
6920
4576
652E
0D0A
5620
5072
617A
652C
204C
5032
3031
3020
4A69
7269
2050
6574
6572
6B61