11   SSL a TLS

Protokol SSL (Secure Sockets Layer) vytvořila firma Netscape. Firma Microsoft vytvořila obdobný protokol PCT. V praxi se ujal protokol SSL verze 3. Oficiálním protokolem Internetu se však stal protokol TLS (RFC-2246: Transport Layer Security protocol) vycházející z protokolu SSL verze 3 (z popisu protokolu pochopíte, že se jedná o SSL verze 3.1). Protokol SSL verze 3 a protokol TLS jsou si velice blízké, avšak klient TLS se nedomluví se serverem SSL a opačně. Jak klient, tak server musí být konfigurovány buď pro podporu protokolu SSL nebo protokolu TLS.

Oba protokoly SSL i TLS používají architekturu klient/server.

Pro zajímavost stojí ještě uvést, že existuje obdoba protokolu TLS pro technologii WAP mobilních telefonů označovaná jako WTLS (Wireless TLS). WTLS je přímo odvozeno od TLS, takže veškeré principy popsané v této kapitole většinou platí též pro WTLS. Protokol WTLS má i některá rozšíření. Např. může běžet i nad protokolem UDP.

Protokol S/MIME řeší zabezpečení elektronické pošty na aplikační vrstvě. Protokoly TCP/IP původně nikterak neřešily problematiku zabezpečení přenášených dat. Klasický model protokolu TCP/IP v sobě nezahrnuje žádnou vrstvu, která by se touto problematikou zabývala. Na obr. 11-1 je znázorněno vložení vrstvy SSL (resp.TLS) do modelu protokolů TCP/IP.

Obr. 11-1 Vrstva SSL (resp. TLS) se vkládá mezi aplikační vrstvu a protokol TCP

Vrstva SSL (resp. TLS)  řeší zabezpečení přenášených dat; je vložena mezi aplikační protokol a protokol TCP.  Vrstva SSL nikterak nezkoumá data, která jsou jí zasílána aplikační vrstvou – prostě je zabezpečí a předá protokolu TCP. Tj. vrstva SSL nerozpozná, zda-li zabezpečovaná data se skládají z nějakých aplikačních relací.

Vrstva SSL proto ani nemůže provádět zabezpečení na úrovni aplikačních relací např. pomocí elektronického podpisu. Prostě přebírá od aplikační vrstvy paket po paketu a zabezpečuje jednotlivé pakety. U každého paketu je vrstva SSL schopna zajistit jeho privátnost (šifrování), integritu dat a autorizaci dat (nikoliv elektronický podpis). Autorizace dat se provádí na základě kontrolního součtu počítaného z dat a sdíleného tajemství.

Při navazování spojení vrstva SSL (resp. TLS) vždy provádí autentizaci serveru. Autentizace klienta je volitelná. Jen pro zajímavost: protokol WTLS umožňuje teoreticky navázat spojení i bez autentizace serveru (i klienta).

Komunikace protokolem SSL/TLS mezi klientem a serverem je plně duplexní, tj. skládá se z komunikace od klienta na server a v opačném směru ze serveru na klienta. To není nic překvapujícího, to je běžná vlastnost protokolu TCP. Zajímavé je, že SSL/TLS používá pro každý směr komunikace jiné symetrické šifrovací klíče a jiné tajemství pro výpočet kontrolního součtu.

Další zvláštností protokolů SSL/TLS je formát dat. Ten není ASCII (jedná se o šifrovaná data), ale nejedná se ani o BER či DER kódování. Data protokolů jsou v podstatě pevného formátu a popisují se jakýmsi intuitivním jazykem vytvořeným jen pro účely těchto protokolů. My se nebudeme zabývat definicí tohoto popisu, ale využijeme intuitivnost tohoto jazyka. Tj. je vcelku jasné, co norma míní, pokud bychom však potřebovali danou informaci znát naprosto přesně, pak je nutné sáhnout k RFC-2246.

Tento intuitivní jazyk připomíná jazyk C. Pro mne jediným zádrhelem bylo, že některé proměnné mohou mít proměnou délku. Typickým případem je proměnná obsahující certifikát. V takovém případě se na počátek přidává pole obsahující délku proměnné. Tj. v případě certifikátu se certifikát kóduje do dvou polí: pole délky a vlastní DER kódovaný certifikát, který v DER kódování opět obsahuje délku (hned za typem)! Pole délka je tak dlouhé, jak nejdelší může být příslušná položka. Prakticky např. pro certifikát 3 B.

Další zajímavostí je termín „elektronický podpis“, který zde není míněn ve smyslu zákona o elektronickém podpisu; tímto termínem se zde míní:

·         V případě algoritmu RSA soukromým klíčem šifrovaná 36bitová struktura vzniklá ze dvou kontrolních součtů podepisovaných dat. První kontrolní součet je pomocí algoritmu SHA a druhý kontrolní součet je algoritmem MD-5.

·         V případě algoritmu DSS se použije pouze kontrolní součet algoritmem SHA (20 bajtů).

Přehled vlastností SSL/TLS:

 

Často se setkáváme se zabezpečením protokolu HTTP pomocí vrstvy SSL, takového řešení se označuje jako protokol HTTPS (nezaměňovat s protokolem S-HTTP, což je jiný, dodnes málo běžný typ zabezpečení protokolu HTTP!).

Pro pochopení funkce SSL je třeba se na tuto vrstvu podívat podrobněji. SSL se skládá ze 4 dílčích protokolů:

  1. Protokol Record Layer Protocol  (RLP), který je z pohledu aplikačních protokolů onou „vrstvou SSL“ (na obrázku 11-2 jsou jako aplikační protokoly uvedeny protokoly LDAP a HTTP). Protokol RLP bere data od aplikačních protokolů, šifruje je a počítá z přenášených fragmentů kontrolní součet. Druhý účastník spojení protokolem RLP ověřuje kontrolní součet, dešifruje data a předává je aplikačnímu protokolu.
    Protokol RLP se nezabývá problémy jako je typ použitého šifrovacího algoritmu, stanovení šifrovacího klíče atd. Vše má připraveno protokolem HP v tzv. aktuální protokolové svitě a dalších parametrech zpracování.
  2. Handshake protocol (HP) se z hlediska protokolu RLP tváří jako další aplikační protokol. Jeho pakety se balí do protokolu RLP. Protokolem HP si oba účastnící připraví protokolovou svitu (typ šifrovacího protokolu a protokol pro výpočet kontrolního součtu), dohodnou se na komprimačním algoritmu a vymění si data pro výpočet hlavního tajemství. Z hlavního tajemství se pak odvodí symetrické šifrovací klíče a sdílené tajemství pro výpočet kontrolního součtu (MAC secret). Protokol HP všechny tyto informace připraví nikoliv do aktuální svity, ale do tzv. připravované svity.
  3. Protokol Change Cipher Specification Protocol (CCSP) je velice jednoduchý protokol. Poté, co protokol HP připraví novou protokolovou svitu a všechna potřebná data pro činnost protokolu RLP, je třeba zkopírovat připravené parametry zpracování na aktuální parametry zpracování a začít šifrovat podle nových parametrů. Protokol CSP se skládá pouze z jediné zprávy „zkopíroval jsem připravovanou svitu na aktuální -  nyní je šifrováno podle nové svity“.
  4. Dojde-li k jakémukoliv zádrhelu v komunikaci, pak je tu k dispozici Alert Protocol (AP), kterým jedna strana může signalizovat závadu druhé straně. AP lze s trochou nadsázky přirovnat k protokolu ICMP na vrstvě IP.

Obr. 11-2 Soustava protokolů SSL (resp. TLS)

Každá strana komunikace (klient i server) tedy udržuje dvakrát některé parametry komunikace ve svých datových strukturách. Jednou udržuje aktuální data používaná protokolem RLP a podruhé připravovaná data protokolem HP.

Klient se serverem pro komunikaci zřizují tzv. relaci (session), relace může zahrnovat jedno nebo více spojení (connection). Pro úplnost je třeba ještě dodat, že mezi dvěma počítači může být současně zřízeno i více relací.

Klient i server ve svých strukturách udržují následující informace:

Otázka je, jak se tajemství pro výpočet kontrolního součtu a symetrické šifrovací klíče stanoví. Přesný postup je popsán v příslušné normě. Zjednodušeně se postupuje tak, že se vytvoří blok klíčů (obr. 11-3) a z něj se postupně odsekává:

 

Pokud se používá tzv. exportní software, který neumožňuje používat plnou délku šifrovacích klíčů, pak před použitím klíčů se použije procedura, která provede zmrzačení příslušných klíčů na požadovanou délku.

Obr. 11-3 Z bloku klíčů se postupně odsekávají sdílená tajemství pro výpočet kontrolního součtu, symetrické šifrovací klíče a případně inicializační vektory

Blok klíčů se vytvoří pseudonáhodnou funkcí, do které vstupuje:

 

Jádrem toho, že je blok klíčů znám pouze klientovi a serveru a nikomu jinému, je hlavní tajemství (master_secret), které se počítá pomocí pseudonáhodné funkce z tzv. předběžného tajemství (PreMasterSecret) a opět z náhodných čísel ClientHello a ServerHello.

 

Pseudonáhodná funkce je podrobně popsána v normách popisujících protokoly SSL a TLS. Je nutné upozornit, že pseudonáhodná funkce pro protokol TLS je mírně odlišná od pseudonáhodné funkce používané protokolem SSL. Pseudonáhodná funkce je použita proto, aby bylo obtížné předpovědět výsledek. Jedná se však o pseudonáhodnou funkci a nikoliv náhodnou funkci, protože ji klient i server aplikují na sobě nezávisle na stejná data a musí dospět k shodnému výsledku – jinak by nebyli schopni dešifrovat data druhé strany.

 

Opět bych mohl napsat, že jádrem tajemství je předběžné tajemství (PreMasterSecret). Předběžné tajemství generuje klient do zprávy ClientKeyExchangeMessage. Jeho generace závisí na použité asymetrické šifře. Existuje varianta jak jej určit v případě, že server používá certifikát s veřejným klíčem algoritmu RSA i pro případ, že server i klient používají Diffie-Hellmannův algoritmus (prakticky jsem se však s Diffie-Hellmannovým algoritmem při této komunikaci nesetkal).

 

V případě algoritmu RSA se to provede jednoduše. Klient vygeneruje dostatečně dlouhé náhodné číslo, které šifruje veřejným klíčem z certifikátu serveru, a výsledek (PreMasterSecret) předá serveru ve zprávě  ClientKeyExchangeMessage.

 

Jinými slovy do výpočtu bloku klíčů vstupuje: veřejným klíčem serveru šifrované předběžné tajemství a náhodná čísla ClientHello a ServerHello, která jsou přenášena nezabezpečeně. Pokud je použit algoritmus RSA, pak stačí mít k dispozici pouze certifikát serveru, z něhož se využije veřejný klíč pro přenos zprávy ClientKeyExchangeMessage. V případě algoritmu RSA pro vybudování bezpečného kanálu, který zajišťuje privátnost i integritu přenášených dat není třeba certifikát uživatele. V případě, že se použije certifikát uživatele, pak se využije pouze k autentizaci uživatele vůči serveru a k ničemu jinému.

 

V případě, že se nevyužívá certifikát klienta, tak klient přistupuje na SSL/TLS server jako anonymní uživatel. Hovoříme pak o anonymním SSL/TLS serveru. Anonymní SSL/TLS server se vždy autentizuje klientovi za využití certifikátu serveru. Klient si je tedy jist, s jakým serverem komunikuje, kdežto z hlediska serveru se jedná o anonymního uživatele.

 

Když se použije anonymní SSL (resp. TLS) server, tak to ještě neznamená, že aplikační server využívající SSL/TLS komunikaci je anonymní. V anonymním SSL/TLS kanálu mezi klientem a serverem je možné provozovat na aplikační vrstvě např. HTTP (či POP3, IMAP4, LDAP apod.) server s autentizací pomocí jména uživatele a hesla. V tomto případě se jméno i heslo již přenáší zabezpečeným kanálem a padají veškeré možnosti odchycení hesla popsané v kapitole 3.

11.1         Record Layer protocol

Record layer protocol přebírá data od aplikačních protokolů a před tím, než je sám předá vrstvě TCP, tak provede:

Obr. 11-4 SSL Record Layer Protocol (MAC = kontrolní součet)

Kontrolní součet se nepočítá pouze z fragmentu (resp. komprimovaného fragmentu), ale fragment se pro výpočet kontrolního součtu zřetězí s tajemstvím pro výpočet kontrolního součtu (write_MAC_secret), které je utajované podobně jako jsou utajovány symetrické šifrovací klíče. Chtěl-li by útočník pozměnit obsah přenášeného fragmentu, pak k změněnému fragmentu není schopen vypočítat (a podvrhnout) kontrolní součet  neboť nezná tajemství pro výpočet kontrolního součtu.

 Záhlaví RLP se skládá ze tří položek.

  1. Typu přenášených dat specifikujícího, jedná-li se o data aplikačního protokolu (např. HTTP) nebo o služební data vrstvy TLS/SSL, tj. data některého ze služebních protokolů tvořícího vrstvu SSL/TLS, tj. z protokolů HP, AP či CCSP. Typ dat je dlouhý 1 B.
  2. Verze, která se skládá ze dvou bajtů. V první bajt obsahuje verzi a druhý nějaké jemnější dělení. Prakticky se však  můžeme setkat s hodnotami: 2.0 pro SSL verze 2; 3.0 pro SSL verze 3. a 3.1 pro TLS verze 1.
  3. Délky fragmentu, po jeho případné komprimaci a šifrování. Pole délka fragmentu je dlouhá 2 B (= 16 b). Tj. fragment by teoreticky mohl být dlouhý až 216 B. Ježe díky kompresi se fragment může teoreticky i prodloužit, tak je třeba jistá rezerva.

Na obrázku 11-5 je znázorněn RLP fragment protokolu SSL.

Obr. 11-5 Record Layer protocol

Pro ilustraci jsem MS Network Monitorem odchytil i jeden paket protokolu TLS (jedná se o první paket TLS protokolu – před tímto paketem ještě předcházely tři nedatové pakety, kterými bylo navázáno samo TCP spojení):

00000030                    16 03 01 00 3B 01 00 00 37 03       ....;...7.

00000040  01 FE 35 46 51 28 0D 7B F8 92 F6 70 F5 20 2A DE ..5FQ(.{...p..*.

00000050  42 38 F8 D6 E1 18 CB 29 74 C6 32 0A C5 7C 1C 09 B8.....)t.2..|..

00000060  10 00 00 10 00 04 00 05 00 0A 00 09 00 64 00 62 .............d.b

00000070  00 03 00 06 01 00                               ......         

V odchyceném paketu TLS je vidět, že protokol TLS používá verzi 3.1.

Význam prvních pěti bajtů tvořících záhlaví protokolu RLP je vcelku evidentní. Zajímavé je něco úplně jiného, totiž jedná se o počáteční data, kterými klient navazuje (nebo obnovuje) spojení se serverem. Jelikož klient se serverem ještě nejsou dohodnuti na žádném algoritmu pro kompresi, žádném algoritmu pro výpočet kontrolního součtu ani žádném šifrovacím algoritmu, tak RLP protokol nemůže provádět žádné zabezpečení, tj. komunikace běží nekomprimovaně, nešifrovaně a bez kontrolního součtu. Přesněji řečeno: každý klient i server je nucen pro to, aby byl schopen navázat relaci, podporovat protokolovou svitu SSL_NULL_WITH_NULL_NULL („žádné šifrování a žádný kontrolní součet“), rovněž musí podporovat komunikaci bez komprese.

V kapitole o protokolu HP si právě na tomto úvodním nešifrovaném dialogu protokol HP rozebereme. Vřele doporučuji všem zájemcům o pochopení SSL obdobný postup. Pro úplnost jen dodávám, že je třeba odříznout záhlaví linkové vrstvy, IP vrstvy i TCP vrstvy. V následujícím rámu je pak zobrazen původní paket z MS Network Monitoru. Spojení jsem navazoval s https://pb.ipb.cz. 

11.2         Alert protocol

Alert protokol je jednoduchý protokol, kterým se účastníci komunikace vzájemně informují o chybách v SSL-komunikaci. Rozeznávají se dvě úrovně závažnosti:

  1. Upozornění, po kterém může komunikace dále pokračovat.
  2. Fatální chyba, po které se komunikace  ukončuje.

Obr. 11-6 SSL Alert protocol

Protokol TLS používá pochopitelně verzi 3.1, ale zejména má bohatší repertoár chyb:

enum {

           close_notify(0),

           unexpected_message(10),

           bad_record_mac(20),

           decryption_failed(21),

           record_overflow(22),

           decompression_failure(30),

           handshake_failure(40),

           certificate_not_available(41),

           bad_certificate(42),

           unsupported_certificate(43),

           certificate_revoked(44),

           certificate_expired(45),

           certificate_unknown(46),

           illegal_parameter(47),

           unknown_ca(48),

           access_denied(49),

           decode_error(50),

           decrypt_error(51),

           export_restriction(60),

           protocol_version(70),

           insufficient_security(71),

           internal_error(80),

           user_canceled(90),

           no_renegotiation(100),

           (255)

       } AlertDescription;

11.3         Change cipher specification protocol

CCSP je protokol skládající se pouze z jedné zprávy. Tato zpráva signalizuje, že došlo ke zkopírování datové struktury s připravovanými parametry zabezpečení spojení do aktuální struktury, kterou používá protokol RLP. Veškerá data, která následují za touto zprávou, jsou již zabezpečena za využití nového šifrovacího klíče, nového tajemství pro výpočet kontrolního součtu atd.

Slovně bychom mohli zprávu Change cipher specification vyjádřit jako „změna šifrovacího klíče“. Jen je třeba dodat, že tuto změnu provádí klient a server na sobě nezávisle, tj. jedna strana provede změnu ve svém směru komunikace a druhá třeba až za okamžik - za svou zprávou Change cipher specification.

TCP segment může obsahovat zprávu  Change cipher specification uprostřed, tj. část RLP-fragmentu předcházející tuto zprávu je šifrována jinak než část RLP-fragmentu za touto zprávou.

Obr. 11-7 SSL Change cipher specification

Na obr. 11-7 je schématicky znázorněn paket protokolu SSL Change cipher specification (protokol TLS používá verzi 3.1). 
 

11.4         Handshake protocol (HP)

Protokol HP je jádrem SSL. HP zabezpečuje:

Komunikace v HP protokolu se skládá z tzv. zpráv. Rozeznávají se dva základní případy komunikace protokolem HP:

  1. Navazování nové relace, tj. server přiděluje nový identifikátor relace.
  2. Obnovení relace (použije se původní identifikátor relace). Tento případ je v podstatě zjednodušením předchozího případu,. tj. používají se jen některé zprávy.

Nadále se omezíme na popis podmnožiny protokolů SSL/TLS využívající k autentizaci certifikáty dle PKI  s veřejnými klíči pro algoritmus RSA.

Struktura HP paketu připomíná RLP paket. V záhlaví jsou jakoby stejné informace. Rozdíl je mj. v tom, že HP paket už může být šifrován i se svým záhlavím.

Obr. 11-8 SSL Handshake Protocol

Na předchozím obrázku je v paketu RLP uložena zpráva typu ClientHello o délce 4B16. Nyní nám půjde o objasnění jednotlivých typů zpráv.
 

11.4.1             Zřízení nové relace

Zřízení nové relace (obr. 11-9) je  proces, kdy dochází k autentizaci účastníků i k výměně všech dat potřebných pro výpočet hlavního tajemství.

Autentizace serveru se provádí vždy. Autentizace klienta se provádí pouze v případě, že server není anonymní.

Zpráva ClientHello obsahuje nevyplněné identifikační číslo relace. Identifikační číslo relace přiděluje server ve zprávě ServerHello. Zprávy ClientHello a ServerHello obsahují náhodná čísla ClientRandom a ServerRandom vstupující do procesu výpočtu sdíleného tajemství. Dále klient nabídne podporované kryptografické algoritmy a server si ve zprávě ServerHello z nich vybere.

Server posílá klientovi svůj certifikát ve zprávě Certificate (resp. může poslat řetězec certifikátů až ke kořenovému certifikátu). Server může odeslat zprávu CerificateRequest, kterou žádá klienta o jeho certifikát. Nakonec server odešle prázdnou zprávou ServerHelloDone, kterou signalizuje klientu, že nyní je řada na něm, tj. očekává reakci klienta.

Klient v případě, že chce na server přistupovat neanonymně, odesílá serveru svůj certifikát (resp. řetězec certifikátů). Dále následuje zcela klíčová zpráva ClientKeyExchange. Tato zpráva obsahuje veřejným klíčem z certifikátu serveru šifrované předběžné tajemství (PreMasterSecret), ze kterého se počítá hlavní tajemství (master secret). Tím se také provede autentizace serveru. Podvržený server, který k veřejnému klíči nevlastní odpovídající soukromý klíč, nemůže získat správné PreMasterSecret (nedokáže jej dešifrovat).

Obr. 11-9 Zřízení nové relace protokolem HP

Při zjednodušeném výkladu principu SSL se často říká, že SSL používá pro šifrování zpráv symetrickou šifru. Šifrovací klíč pro symetrickou šifru generuje klient. Proto aby symetrický šifrovací klíč mohl klient bezpečně předat serveru po nezabezpečeném Internetu, tak jej šifruje veřejným klíčem z certifikátu serveru, tj. asymetrickou širou, a odešle serveru.

Skutečnost je ale taková, že takto vznikne pouze PreMasterSecret, ze kterého se spočítá master_secret. Z master secret, ClientRandom a ServerRandom se spočte špalek dat, ze kterého se teprve odsekávají šifrovací klíče.

Takže nyní jak klient, tak i server vzájemně znají své symetrické šifrovací klíče i tajemství pro výpočet kontrolního součtu. Jak klient tak server používají každý své (tj. každý jiné) šifrovací klíče i tajemství pro výpočet kontrolního součtu.

V případě, že klient přistupuje neanonymně na server, pak musí prokázat svou totožnost, tj. identifikovat se. Klient prokazuje svou totožnost ve zprávě CertificateVerify. Nejprve vytvoří kontrolní součet počítaný mj. z hlavního tajemství (master_secret) a z obsahu všech zpráv od zprávy ClientHello. Tento kontrolní součet je schopen vytvořit jen klient a server (jen ti znají sdílené tajemství). Klient ve zprávě CertificateVerify odesílá elektronický podpis z tohoto řetězce. Server si pak ověří totožnost klienta na základě ověření (verifikace) tohoto elektronického podpisu.

Závěr je pak již zcela obdobný jako u obnovování spojení, tj. protokolem Change cipher specification se signalizuje „přechod na nové šifrovací klíče“ a zpráva Finished navazování spojení končí. Dále již běží přenos vlastních aplikačních dat, který je šifrován. Každý RLP fragment obsahuje též kontrolní součet zabezpečující integritu přenášených dat (už zprávy Finished byly šifrovány). 

 

11.4.2             Obnovení relace

Jednodušším případem komunikace mezi klientem a serverem je obnovení již dříve existující relace (obr. 11-10). Kdy se s takovým případem setkáváme? Obnovením se většinou nemyslí (i když se to nevylučuje) obnovení spojení např. po závadě na komunikačních linkách - to je záležitost nižšího protokolu, v našem případě protokolu TCP. Spíše se zde bude jednat o trochu jiný případ. Představte si, že si prohlížíte webové stránky na HTTPS serveru. Při vydání požadavku na stažení webové stránky musí být navázána relace. První stránka se skládala z celé řady objektů (textů, obrázků či zvuků), pro stažení každého z těchto objektu v protokolu HTTP/1.0 se navazuje samostatné spojení protokolem TCP. Po stažení všech objektů stránky se všechna TCP spojení uzavřou. (Pro úplnost dodejme, že v protokolu HTTP/1.1 je běžnější všechny objekty téže stránky stahovat jedním spojením.)

Obr. 11-10 Obnovení relace protokolem HP

Poté si staženou webovou stránku prohlížíme na obrazovce. Během prohlížení není navázáno žádné spojení - není ani jasné, zda-li budeme další informace požadovat z téhož nebo jiného HTTPS serveru. V případě, že požadujeme další stránku z téhož serveru, pak se pro stažení nových objektů navazují nová TCP spojení a protokolem  SSL (resp. TLS) se tentokráte relace obnovuje. O tom, zda-li bude relace obnovována, rozhoduje nastavení klienta (obnovuje se zpravidla pouze tehdy, pokud byl klientův program ukončen a znovu nastartován -  to lze však pravděpodobně změnit v konfiguraci klienta).

Při obnovování spojení klient odešle serveru zprávu ClientHello. Zpráva ClientHello obsahuje náhodné číslo ClientRandom vstupující do výpočtu sdíleného tajemství. Zejména však zpráva ClientHello obsahuje identifikátor obnovované relace. Dále zpráva ClientHello obsahuje seznam kryptografických algoritmů podporovaných klientem.

Server odpovídá zprávou ServerHello obsahující náhodné číslo ServerHello vstupující též do výpočtu sdíleného tajemství. Zpráva ServerHello obsahuje opět identifikátor obnovované relace a zejména kryptografické algoritmy, které si server vybral z těch, které klient podporuje. V případě, že server zamítne obnovit relaci či si nevybere z nabízených kryptografických algoritmů, pak server neodpoví zprávou ServerHello, ale protokolem Alert a uzavře TCP-spojení.

V případě, že server spojení neuzavře, odešle protokolem Change cipher specification informaci, že „přešel na nové šifrovací klíče“ a pošle zprávu Finished obsahující kontrolní součet ze všech zpráv od zprávy ClinetHello. Klient už jen pošle potvrzující zprávu Change cipher specification a Finished, kterými výměnu zpráv potvrdí. Dále již běží přenos vlastních aplikačních dat, který je šifrován. Každý RLP fragment obsahuje též kontrolní součet zabezpečující integritu přenášených dat (už zprávy Finished byly šifrovány). 

Nyní si rozebereme jednotlivé zprávy podrobněji. Pro ilustraci použijeme zprávy, které jsem opět odchytil na LAN pomocí MS Network Monitoru (nebudu však uvádět již kompletní výpis z MS Network Monitoru).

ClientHello

Zpráva ClientHello je tvořena:

  1. Opět verzí dlouhou 2B.
  2. 32 B dlouhým náhodným číslem (ClientRandom) generovaným klientem. Toto náhodné číslo se skládá ze dvou částí:
  3. Identifikátorem relace (SessionID). Při prvním navazování nového spojení je tato položka nulová, protože SessionID určuje server. V případě, že se spojení obnovuje, pak toto pole obsahuje číslo obnovované relace.
  4. Protokolové svity jsou dvojbajtové řetězce identifikující šifrovací protokol a protokol pro výpočet kontrolního součtu. Klient v této zprávě popisuje všechny jím podporované protokolové svity. Říká: "Já podporuji následující svity. Servere, vyber si z nich jednu a tu mi pošli ve zprávě ServerHello". První dva bajty vyjadřují délku řetězce předávaných protokolových svit.
  5. Podporové kompresní algoritmy. První bajt vyjadřuje počet podporovaných kompresních algoritmů klientem. Každý následující bajt pak popisuje jeden podporovaný algoritmus.

Obr. 11-11 Zpráva ClientHello

 

V intuitivním jazyce normy má zpráva ClientHello tvar:

 

       struct {

           ProtocolVersion client_version;

           Random random;

           SessionID session_id;

           CipherSuite cipher_suites<2..2^16-1>;

           CompressionMethod compression_methods<1..2^8-1>;

       } ClientHello;

Kde:

           struct {

              uint32 gmt_unix_time;

              opaque random_bytes[28];

           } Random;

V kapitole o protokolu RLP jsme uvedli příklad RLP paketu, který v sobě nesl zprávu ClientHello (obr. 11-5). Z tohoto příkladu odřízneme záhlaví protokolů IP, TCP, záhlaví fragmentu RLP (16 03 00 00 4F) a záhlaví protokolu HP (01 00 4B – viz obr.  11-8) a získáme zprávu ClientHello):

03 00 34 F3 C2 D1 1E AD 65 2B 7A 2F 95 A5 F0 68 AA 8E 55 F8 53 B3 B3 AC
C7 9E E9 0C B6 5C 62 A8 BE 9F 20 03 99 14 66 7F DE 5A 47 10 19 F6 47 C7
4D 15 6A 4A 43 3A BA B1 65 82 AC 98 52 68 7D 06 EE 2D E1 00 04 00 03 00
06 01 00 

Na počátku jsou první dva bajty určující verzi: 03 00.

Následuje 32 bajtů náhodného čísla ClientRandom tvořeného 4 B vyjadřujícími datum a čas plus 28 B z generátoru náhodných čísel: 34 F3 C2 D1 1E AD 65 2B 7A 2F 95 A5 F0 68 AA 8E 55 F8 53 B3 B3 AC C7 9E E9 0C B6 5C 62 A8 BE 9F

První bajt Session ID specifikuje délku, následující bajty pak identifikátor relace: 2016=3210   03 99 14 66 7F DE 5A 47 10 19 F6 47 C7 4D 15 6A 4A 43 3A BA B1 65 82 AC 98 52 68 7D 06 EE 2D E1

Pole protokolových svit je uvozeno dvojbajtovou délkou, za kterou následují jednotlivé dvojice bajtů specifikujících šifrovací protokol a protokol pro výpočet kontrolního součtu:  00 04   00 03  00 06.  Z následující tabulky protokolových svit pak zjistíme, že klient podporuje dvě svity (4 bajty): SSL_RSA_EXPORT_WITH_RC4_40_MD5 a SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5. Tj. autentizaci pomocí RSA omezené exportními pravidly USA, šifrovací protokoly RC4 nebo RC2 s exportními omezeními na délku klíče 40 bitů a kontrolní součet bude počítán podle algoritmu MD5.

Pole podporovaných kompresních metod je uvozeno 1B délky následovaným jednobajtovými identifikacemi jednotlivých kompresních protokolů : 01 00 (tj. bez komprese)

Tabulka protokolových svit

     CipherSuite SSL_NULL_WITH_NULL_NULL                = 00 00 
          (tato svita je používána zejména na počátku komunikace) 
     CipherSuite SSL_RSA_WITH_NULL_MD5                  = 00 01
     CipherSuite SSL_RSA_WITH_NULL_SHA                  = 00 02
     CipherSuite SSL_RSA_EXPORT_WITH_RC4_40_MD5         = 00 03
     CipherSuite SSL_RSA_WITH_RC4_128_MD5               = 00 04
     CipherSuite SSL_RSA_WITH_RC4_128_SHA               = 00 05
     CipherSuite SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5     = 00 06
     CipherSuite SSL_RSA_WITH_IDEA_CBC_SHA              = 00 07
     CipherSuite SSL_RSA_EXPORT_WITH_DES40_CBC_SHA      = 00 08
     CipherSuite SSL_RSA_WITH_DES_CBC_SHA               = 00 09
     CipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA          = 00 0A
     CipherSuite SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA   = 00 0B
     CipherSuite SSL_DH_DSS_WITH_DES_CBC_SHA            = 00 0C
     CipherSuite SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA       = 00 0D
     CipherSuite SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA   = 00 0E
     CipherSuite SSL_DH_RSA_WITH_DES_CBC_SHA            = 00 0F
     CipherSuite SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA       = 00 10
     CipherSuite SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA  = 00 11
     CipherSuite SSL_DHE_DSS_WITH_DES_CBC_SHA           = 00 12
     CipherSuite SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA      = 00 13
     CipherSuite SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA  = 00 14
     CipherSuite SSL_DHE_RSA_WITH_DES_CBC_SHA           = 00 15
     CipherSuite SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA      = 00 16
     CipherSuite SSL_DH_anon_EXPORT_WITH_RC4_40_MD5     = 00 17
     CipherSuite SSL_DH_anon_WITH_RC4_128_MD5           = 00 18
     CipherSuite SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA  = 00 19
     CipherSuite SSL_DH_anon_WITH_DES_CBC_SHA           = 00 1A
     CipherSuite SSL_DH_anon_WITH_3DES_EDE_CBC_SHA      = 00 1B
     CipherSuite SSL_FORTEZZA_KEA_WITH_NULL_SHA         = 00 1C
     CipherSuite SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA = 00 1D
     CipherSuite SSL_FORTEZZA_KEA_WITH_RC4_128_SHA      = 00 1E 



Pro úplnost se ještě rozebereme případ zprávy ClientHello protokolu TLS:  

 

(16 03 01 00 3B 01 00 00 37) 03 01 FE 35 46 51 28 0D 7B F8 92 F6 70 F5 20 2A DE

42 38 F8 D6 E1 18 CB 29 74 C6 32 0A C5 7C 1C 09  10 00 00 10 00 04 00 05 00 0A 00 09 00 64 00 62 00 03 00 06 01 00            

 

V kulatých závorkách je uvedeno záhlaví protokolů RLP a HP. Verze zprávy je 03 01 (protokol TLS). Dále následuje opět 32 bajtů náhodného čísla ClientRandom.

 

Jelikož se jedná o zprávu, kterou nežádáme o obnovení relace, ale o zřízení nové relace, tak je identifikátor relace nulové délky (00).

 

Dále následuje počet bajtů protokolových svit: 1016 = 1610.  Klient nabízí protokolové svity:

·         00 04 - TLS_RSA_WITH_RC4_128_MD5

·         00 05 - TLS_RSA_WITH_RC4_128_SHA

·         00 0A - TLS_RSA_WITH_3DES_EDE_CBC_SHA

·         00 09 - TLS_RSA_WITH_DES_CBC_SHA

·         00 64 - ?

·         00 62 - ?

·         00 03 - TLS_RSA_EXPORT_WITH_RC4_40_MD5

·         00 06 - TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5

 

Pro určení protokolových svit se použije předchozí tabulka pro protokol SSL, pouze se řetězec SSL nahradí řetězcem TLS (pouze protokolové svity používající mechanismus FORTEZZA nejsou v protokolu TLS podporovány).

ClientHello verze 2

Pokud si v konfiguraci Vašeho prohlížeče zatrhnete, že chcete používat SSL nejenom verze 3, ale i verze 2 (obr. 11-12) a budete monitorovat komunikaci Network monitorem, pak budete překvapeni, že klient navazuje spojení zprávou ClientHello, ale SSL verze 2 (obdobně komunikuje i Netscape).

 

Obr. 11-12 Konfigurace MS Internet Exploreru

Klient vzhledem k tomu, že je zpětně kompatibilní s SSL verze 2, začíná komunikaci zprávou ClientHello verze 2, kde pouze v poli verze uvádí verzi 3.0.

Nebudeme se zabývat prvními 2B, tj. záhlavím protokolu RLP verze 2. (25 šestnáctkově vyjadřuje délku zprávy).

00000030                    80 25 01 03 00 00 0C 00 00 00       .%........
00000040  10 02 00 80 04 00 80 00 00 03 00 00 06 90 9F A1 ................
00000050  01 CC FA 9E CC 86 C0 DB AF DB 3F EE 8F          ..........?..

Zpráva ClientHello verze 2 má strukturu:

ServerHello

Zpráva ServerHello obsahuje:

Obr. 11-3 Zpráva ServerHello

       struct {

           ProtocolVersion server_version;

           Random random;

           SessionID session_id;

           CipherSuite cipher_suite;

           CompressionMethod compression_method;

       } ServerHello;

Pro ilustraci si Network monitorem opět odchytíme odpověď serveru klientovi: 

16 03 00 00 4A 02 00 00 46 03 00 34 F3 D0 18 4C 49 D9 E1 07 A6 C4 0D 8D A1 BD 09 53 C7 1B B8 51 8F E9 56 2B 7A FF 41 D9 E8 13 10 20 03 99 14 66 7F DE 5A 47 10 19 F6 47 C7 4D 15 6A 4A 43 3A BA B1 65 82 AC 98 52 68 7D 06 EE 2D E1 00 03 00

Záhlaví RLP fragmentu je 16 03 00 00 4A. Zde 16 specifikuje Handshake Protocol, 03 00 určuje verzi 3.0 a 4A16=7410vyjadřuje délku RLP fragmentu.

Záhlaví HP protokolu je 02 00 00 46. Zde 02 specifikuje zprávu  ServerHello a 00004616=7010 vyjadřuje délku zprávy.

Verze záhlaví protokolu HP je opět 03 00.

Náhodné číslo (ServerRandom) je dlouhé 32 bajtů: 34 F3 D0 18 4C 49 D9 E1 07 A6 C4 0D 8D A1 BD 09 53 C7 1B B8 51 8F E9 56 2B 7A FF 41 D9 E8 13 10.

Identifikátor relace začíná jedním bajtem specifikujícím délku identifikátoru (2016=3210) následovaným vlastním identifikátorem relace: 20 03 99 14 66 7F DE 5A 47 10 19 F6 47 C7 4D 15 6A 4A 43 3A BA B1 65 82 AC 98 52 68 7D 06 EE 2D E1.

Pak následuje serverem vybraná protokolová svita (jedna z těch které nabízí klient - v případě, že by si server nevybral, pak neodpoví zprávou ServerHello, ale Alert protokolem a následuje ukončení spojení). V našem případě server zvolil svitu 00 03, tj. podle tabulky SSL_RSA_EXPORT_WITH_RC4_40_MD5.

Poslední bajt obsahuje serverem zvolený komprimační algoritmus. V tomto případě volba 00 signalizuje, že komprese nebude použita.
 

11.4.3             Zprávy ServerHello, Certificate, CertificateRequest a ServerHelloDone

I když jsme zprávu ServerHello již popsali, tak se vrátíme ke skutečnosti, že tato zpráva je jen součástí bloku zpráv, kterými odpovídá server klientu na zprávu ClientHello. Server odpovídá jedním nebo několika TCP segmenty obsahujícími jeden RLP fragment, který však v sobě obsahuje tři zprávy protokolu HP:

Vše je uvozeno záhlavím protokolu RLP. Nyní uvádím výpis paketu (IP i TCP záhlaví jsou již odříznuta), ve kterém jsem za RLP záhlavím a jednotlivými zprávami vložil pro větší přehlednost vždy nový řádek. RLP záhlaví obsahuje typ přenášených dat (1610=Protokol HP, 0300=verze 3.0, 024B16=délka dat):

Záhlaví RLP:
00000030                    16 03 00 02 4B

Zpráva ServerHello:
                                           02 00 00 46 03       ....K...F.
00000040  00 34 F8 1D 68 B2 8F DE EB 72 3B E9 FD 94 AD B8 .4..h....r;.....
00000050  84 C3 7A AE C8 47 7B 89 1A 01 BB CA 3A 39 10 6F ..z..G{.....:9.o
00000060  1A 20 0B 79 5E 44 F4 3E 8F A5 61 75 29 19 52 3C ...y^D.>..au).R<
00000070  FA 01 61 31 8C 3F 2F 3C 48 0F 87 C9 1E 31 B7 19 ..a1.?/<H....1..
00000080  7D 4A 00 03 00

Zpráva Certificate:
                         0B 00 01 F9 00 01 F6 00 01 F3 30 }J.............0
00000090  82 01 EF 30 82 01 58 A0 03 02 01 02 02 01 0B 30 ...0..X........0
000000A0  0D 06 09 2A 86 48 86 F7 0D 01 01 04 05 00 30 45 ...*.H........0E
000000B0  31 0B 30 09 06 03 55 04 06 13 02 43 5A 31 11 30 1.0...U....CZ1.0
000000C0  0F 06 03 55 04 0A 13 08 50 56 54 20 61 2E 73 2E ...U....PVT.a.s.
000000D0  31 23 30 21 06 03 55 04 03 13 1A 43 65 72 74 69 1#0!..U....Certi
000000E0  66 69 6B 61 63 6E 69 20 61 75 74 6F 72 69 74 61 fikacni.autorita
000000F0  20 49 2E 43 41 30 1E 17 0D 39 37 31 32 31 36 31 .I.CA0...9712161
00000100  30 30 35 35 32 5A 17 0D 39 38 30 36 31 37 31 30 00552Z..98061710
00000110  30 35 35 32 5A 30 45 31 0B 30 09 06 03 55 04 06 0552Z0E1.0...U..
00000120  13 02 43 5A 31 11 30 0F 06 03 55 04 0A 13 08 50 ..CZ1.0...U....P
00000130  56 54 20 61 2E 73 2E 31 0D 30 0B 06 03 55 04 0B VT.a.s.1.0...U..
00000140  13 04 49 2E 43 41 31 14 30 12 06 03 55 04 03 13 ..I.CA1.0...U...
00000150  0B 63 65 72 74 2E 69 63 61 2E 63 7A 30 5A 30 0D .cert.ica.cz0Z0.
00000160  06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 49 00 ..*.H.........I.
00000170  30 46 02 41 00 A8 0E E9 04 32 FF 71 40 93 F1 4F 0F.A.....2.q@..O
00000180  D1 95 42 FD 97 8A 58 EA 27 66 47 63 1C BC FD 93 ..B...X.'fGc....
00000190  28 54 F5 A4 C6 11 FB B5 EA E4 B6 79 EB 8E 55 2C (T.........y..U,
000001A0  78 0F 3D 3B FC 3F 96 53 AF 4E F2 A1 4C 6F 5C 3C x.=;.?.S.N..Lo\<
000001B0  6C 8E C7 F2 A9 02 01 03 A3 35 30 33 30 11 06 03 l........5030...
000001C0  55 1D 23 04 0A 16 08 49 43 41 4B 45 59 2E 31 30 U.#....ICAKEY.10
000001D0  1E 06 09 60 86 48 01 86 F8 42 01 0D 04 11 16 0F ...`.H...B......
000001E0  57 57 57 20 73 65 72 76 65 72 20 49 2E 43 41 30 WWW.server.I.CA0
000001F0  0D 06 09 2A 86 48 86 F7 0D 01 01 04 05 00 03 81 ...*.H..........
00000200  81 00 26 C5 AA 60 9E 19 A9 70 AF E3 BC 62 09 D2 ..&..`...p...b..
00000210  96 93 21 B0 EF 0B 98 3A 43 62 7C 3F 24 63 45 9D ..!....:Cb|?$cE.
00000220  1E 22 C5 27 C8 73 79 7F 80 3A 0A E2 EA 02 F3 F8 .".'.sy.:......
00000230  FE 30 EC 8F 22 CD E1 43 23 48 3E 13 10 69 88 34 .0.."..C#H>..i.4
00000240  BA 03 65 5D AA E5 C8 62 1B 8C AA 24 A4 6D 6C 4B ..e]...b...$.mlK
00000250  C2 51 BE 9A B0 70 FE 8A 5C 29 F3 DF 50 BF 44 51 .Q...p..\)..P.DQ
00000260  B9 46 56 64 D0 1E 34 88 7A 86 74 48 54 F1 87 E6 .FVd..4.z.tHT...
00000270  54 15 D2 05 55 0E 36 2E 2E B8 44 03 CE 0D 11 BE T...U.6...D.....
00000280  6E 2A

Zpráva ServerHelloDone:
                0E 00 00 00                               n*....
 

ServerHello

V našem příkladě (předchozí výpis) zpráva ServerHello obsahovala:
                                 02 00 00 46 03
00 34 F8 1D 68 B2 8F DE EB 72 3B E9 FD 94 AD B8
84 C3 7A AE C8 47 7B 89 1A 01 BB CA 3A 39 10 6F
1A 20 0B 79 5E 44 F4 3E 8F A5 61 75 29 19 52 3C
FA 01 61 31 8C 3F 2F 3C 48 0F 87 C9 1E 31 B7 19
7D 4A 00 03 00

Kde záhlaví protokolu HP je tvořeno typem zprávy (02=ServerHello) a délkou zprávy protokolu HP (00004616)
Dále následuje vlastní zpráva ServerHello:

 

Server Certificate

Zpráva Certificate má jednoduchou strukturu:

 

       struct {

           ASN.1Cert certificate_list<0..2^24-1>;

       } Certificate;

 

Připomeňme však, že položka ASN.1Cert i sama struktura Certificate jsou proměnné délky, tj. budou mít na počátku pole délka.

 

Zpráva Certificate může obsahovat řetězec certifikátů až ke kořenovému certifikátu. Kořenový certifikát obsahovat nemusí, protože ten musí mít klient k dispozici (v případě, že by klient akceptoval bez kontroly kořenové certifikáty, pak by mu bylo velice snadné podvrhnout řetězec certifikátů). Zajímavé je, že se nejedná o množinu certifikátů (ve které nezáleží na pořadí), ale certifikáty musí být seřazeny jeden za druhým, jak na sebe navazují. Tj. první certifikát musí být certifikát odesilatele (tj. v tomto případě certifikát serveru).

 

Z hlediska kapitoly 8 se tedy nejedná o DER kódovanou množinu certifikátů, ale DER-kódované jsou jen jednotlivé certifikáty. Řetězce už jsou kódovány v režii SSL/TLS.

 

Zpráva Certificate obsahuje na počátku záhlaví protokolu HP, kde první bajt 0B specifikuje, že se jedná o zprávu Certificate, a další tři bajty (00 01 F9) pak specifikují délku zprávy Certificate:

0B 00 01 F9

Zpráva Certificate obecně neobsahuje jeden certifikát, ale řetězec certifikátů až ke kořenové certifikační autoritě. Dále tedy následuje tříbajtová délka tohoto řetězce certifikátů. Každý certifikát v tomto řetězci opět začíná tříbajtovou délkou certifikátu. Jelikož náš příklad obsahuje pouze jeden certifikát, tak před ním je délka jakoby zdvojená:

00 01 F6 (délka řetězce certifikátů) 00 01 F3 (délka certifikátu). Lépe řečeno, když si k těmto dvěma délkám přimyslíme ještě délku ze záhlaví HP paketu, pak je délka ztrojená.

Vlastní certifikát je v DER kódování:
                                             30
82 01 EF 30 82 01 58 A0 03 02 01 02 02 01 0B 30
0D 06 09 2A 86 48 86 F7 0D 01 01 04 05 00 30 45
31 0B 30 09 06 03 55 04 06 13 02 43 5A 31 11 30
0F 06 03 55 04 0A 13 08 50 56 54 20 61 2E 73 2E
31 23 30 21 06 03 55 04 03 13 1A 43 65 72 74 69
66 69 6B 61 63 6E 69 20 61 75 74 6F 72 69 74 61
20 49 2E 43 41 30 1E 17 0D 39 37 31 32 31 36 31
30 30 35 35 32 5A 17 0D 39 38 30 36 31 37 31 30
30 35 35 32 5A 30 45 31 0B 30 09 06 03 55 04 06
13 02 43 5A 31 11 30 0F 06 03 55 04 0A 13 08 50
56 54 20 61 2E 73 2E 31 0D 30 0B 06 03 55 04 0B
13 04 49 2E 43 41 31 14 30 12 06 03 55 04 03 13
0B 63 65 72 74 2E 69 63 61 2E 63 7A 30 5A 30 0D
06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 49 00
30 46 02 41 00 A8 0E E9 04 32 FF 71 40 93 F1 4F
D1 95 42 FD 97 8A 58 EA 27 66 47 63 1C BC FD 93
28 54 F5 A4 C6 11 FB B5 EA E4 B6 79 EB 8E 55 2C
78 0F 3D 3B FC 3F 96 53 AF 4E F2 A1 4C 6F 5C 3C
6C 8E C7 F2 A9 02 01 03 A3 35 30 33 30 11 06 03
55 1D 23 04 0A 16 08 49 43 41 4B 45 59 2E 31 30
1E 06 09 60 86 48 01 86 F8 42 01 0D 04 11 16 0F
57 57 57 20 73 65 72 76 65 72 20 49 2E 43 41 30
0D 06 09 2A 86 48 86 F7 0D 01 01 04 05 00 03 81
81 00 26 C5 AA 60 9E 19 A9 70 AF E3 BC 62 09 D2
96 93 21 B0 EF 0B 98 3A 43 62 7C 3F 24 63 45 9D
1E 22 C5 27 C8 73 79 7F 80 3A 0A E2 EA 02 F3 F8
FE 30 EC 8F 22 CD E1 43 23 48 3E 13 10 69 88 34
BA 03 65 5D AA E5 C8 62 1B 8C AA 24 A4 6D 6C 4B
C2 51 BE 9A B0 70 FE 8A 5C 29 F3 DF 50 BF 44 51
B9 46 56 64 D0 1E 34 88 7A 86 74 48 54 F1 87 E6
54 15 D2 05 55 0E 36 2E 2E B8 44 03 CE 0D 11 BE
6E 2A

Odskočíme-li si do kapitoly 8, pak můžeme certifikát převést do tvaru (jedná se o certifikát serveru):

SEQUENCE
    30 82 01 ef
  SEQUENCE
     30 82 01 58
   cont [ 0 ]
      a0 03
    INTEGER           :02
       02 01 02
   INTEGER           :0B
      02 01 0b
   SEQUENCE
      30 0d
    OBJECT            :md5withRSAEncryption
       06 09 2a 86 48 86 f7 0d 01 01 04
    NULL
       05 00
   SEQUENCE
      30 45
    SET
       31 0b
     SEQUENCE
        30 09
      OBJECT            :countryName
         06 03 55 04 06
      PRINTABLESTRING   :CZ
         13 02 43 5a
    SET
       31 11
     SEQUENCE
        30 0f
      OBJECT            :organizationName
         06 03 55 04 0a
      PRINTABLESTRING   :PVT a.s.
         13 08 50 56 54 20 61 2e 73 2e
    SET
       31 23
     SEQUENCE
        30 21
      OBJECT            :commonName
         06 03 55 04 03
      PRINTABLESTRING   :Certifikacni autorita I.CA
         13 1a 43 65 72 74 69 66 69 6b 61 63 6e 69 20 61 75 74 6f 72
         69 74 61 20 49 2e 43 41
   SEQUENCE
      30 1e
    UTCTIME           :971216100552Z
       17 0d 39 37 31 32 31 36 31 30 30 35 35 32 5a
    UTCTIME           :980617100552Z
       17 0d 39 38 30 36 31 37 31 30 30 35 35 32 5a
   SEQUENCE
      30 45
    SET
       31 0b
     SEQUENCE
        30 09
      OBJECT            :countryName
         06 03 55 04 06
      PRINTABLESTRING   :CZ
         13 02 43 5a
    SET
       31 11
     SEQUENCE
        30 0f
      OBJECT            :organizationName
         06 03 55 04 0a
      PRINTABLESTRING   :PVT a.s.
         13 08 50 56 54 20 61 2e 73 2e
    SET
       31 0d
     SEQUENCE
        30 0b
      OBJECT            :organizationalUnitName
         06 03 55 04 0b
      PRINTABLESTRING   :I.CA
         13 04 49 2e 43 41
    SET
       31 14
     SEQUENCE
        30 12
      OBJECT            :commonName
         06 03 55 04 03
      PRINTABLESTRING   :cert.ica.cz
         13 0b 63 65 72 74 2e 69 63 61 2e 63 7a
   SEQUENCE
      30 5a
    SEQUENCE
       30 0d
     OBJECT            :rsaEncryption
        06 09 2a 86 48 86 f7 0d 01 01 01
     NULL
        05 00
    BIT STRING
       03 49 00 30 46 02 41 00 a8 0e e9 04 32 ff 71 40 93 f1 4f d1
       95 42 fd 97 8a 58 ea 27 66 47 63 1c bc fd 93 28 54 f5 a4 c6
       11 fb b5 ea e4 b6 79 eb 8e 55 2c 78 0f 3d 3b fc 3f 96 53 af
       4e f2 a1 4c 6f 5c 3c 6c 8e c7 f2 a9 02 01 03
   cont [ 3 ]
      a3 35
    SEQUENCE
       30 33
     SEQUENCE
        30 11
      OBJECT            :X509v3 Authority Key Identifier
         06 03 55 1d 23
      OCTET STRING
         04 0a 16 08 49 43 41 4b 45 59 2e 31
     SEQUENCE
        30 1e
      OBJECT            :Netscape Comment
         06 09 60 86 48 01 86 f8 42 01 0d
      OCTET STRING
         04 11 16 0f 57 57 57 20 73 65 72 76 65 72 20 49 2e 43 41
  SEQUENCE
     30 0d
   OBJECT            :md5withRSAEncryption
      06 09 2a 86 48 86 f7 0d 01 01 04
   NULL
      05 00
  BIT STRING
     03 81 81 00 26 c5 aa 60 9e 19 a9 70 af e3 bc 62 09 d2 96 93
     21 b0 ef 0b 98 3a 43 62 7c 3f 24 63 45 9d 1e 22 c5 27 c8 73
     79 7f 80 3a 0a e2 ea 02 f3 f8 fe 30 ec 8f 22 cd e1 43 23 48
     3e 13 10 69 88 34 ba 03 65 5d aa e5 c8 62 1b 8c aa 24 a4 6d
     6c 4b c2 51 be 9a b0 70 fe 8a 5c 29 f3 df 50 bf 44 51 b9 46
     56 64 d0 1e 34 88 7a 86 74 48 54 f1 87 e6 54 15 d2 05 55 0e
     36 2e 2e b8 44 03 ce 0d 11 be 6e 2a
 

CertificateRequest

Touto zprávou žádá server klienta o jeho certifikát. Součástí zprávy je seznam podporovaných typů certifikátů a seznam certifikačních autorit, kterým server důvěřuje.

Tato zpráva se skládá ze dvou polí:

Na zprávu CertificateRequest klient odpoví zprávou Certificate, která má stejný formát jako zpráva Certificate serveru. Pokud klient požadovaný certifikát nemá, pak to ještě nemusí způsobit fatální chybu, protože server může podporovat zároveň autentizaci certifikátem i anonymní přístup.

 

Zpráva CertificateRequest má následující strukturu:
 

       struct {

           ClientCertificateType certificate_types<1..2^8-1>;

           DistinguishedName certificate_authorities<3..2^16-1>;

       } CertificateRequest;

kde

       enum {

           rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),

           (255)

       } ClientCertificateType;

 

Opět Network Monitorem jsem odchytil zprávu CertificateRequest:

 

0D 00 01 7A 02 01 02 01 75 00 50 30 4E 31 0B 30 09 06 03 55 04 06 13 02 43 5A 31 2C 30 2A 06 03 55 04 03 13 23 49 2E 43 41 20 2D 20 53 74 61 6E 64 61 72 64 20 72 6F 6F 74 20 63 65 72 74 69 66 69 63 61 74 65 20 30 31 31 11 30 0F 06 03 55 04 0A 13 08 50 56 54 20 61 2E 73 2E 00 5F 30 5D 31 0B 30 09 06 03 55 04 06 13 02 43 5A 31 11 30 0F 06 03 55 04 0A 13 08 50 56 54 20 61 2E 73 2E 31 11 30 0F 06 03 55 04 0B 13 08 32 30 30 30 30 39 30 31 31 28 30 26 06 03 55 04 03 13 1F 43 65 72 74 69 66 69 6B 61 63 6E 69 20 61 75 74 6F 72 69 74 61 20 49 2E 43 41 20 30 30 30 39 00 5F 30 5D 31 0B 30 09 06 03 55 04 06 13 02 43 5A 31 11 30 0F 06 03 55 04 0A 13 08 50 56 54 20 61 2E 73 2E 31 11 30 0F 06 03 55 04 0B 13 08 31 39 39 39 30 39 30 31 31 28 30 26 06 03 55 04 03 13 1F 43 65 72 74 69 66 69 6B 61 63 6E 69 20 61 75 74 6F 72 69 74 61 20 49 2E 43 41 20 39 39 30 39 00 5F 30 5D 31 0B 30 09 06 03 55 04 06 13 02 43 5A 31 11 30 0F 06 03 55 04 0A 13 08 50 56 54 20 61 2E 73 2E 31 11 30 0F 06 03 55 04 0B 13 08 32 30 30 30 30 33 30 31 31 28 30 26 06 03 55 04 03 13 1F 43 65 72 74 69 66 69 6B 61 63 6E 69 20 61 75 74 6F 72 69 74 61 20 49 2E 43 41 20 30 30 30 33           

 

Zpráva obsahuje:

 

 

SEQUENCE         

    30 4e

  SET              

     31 0b

   SEQUENCE         

      30 09

    OBJECT            :countryName

       06 03 55 04 06

    PRINTABLESTRING   :CZ

       13 02 43 5a

  SET               

     31 2c

   SEQUENCE         

      30 2a

    OBJECT            :commonName

       06 03 55 04 03

    PRINTABLESTRING   :I.CA - Standard root certificate 01

       13 23 49 2e 43 41 20 2d 20 53 74 61 6e 64 61 72 64 20 72 6f

       6f 74 20 63 65 72 74 69 66 69 63 61 74 65 20 30 31

  SET              

     31 11

   SEQUENCE         

      30 0f

    OBJECT            :organizationName

       06 03 55 04 0a

    PRINTABLESTRING   :PVT a.s.

       13 08 50 56 54 20 61 2e 73 2e

 

 

SEQUENCE         

    30 5d

  SET              

     31 0b

   SEQUENCE         

      30 09

    OBJECT            :countryName

       06 03 55 04 06

    PRINTABLESTRING   :CZ

       13 02 43 5a

  SET              

     31 11

   SEQUENCE         

      30 0f

    OBJECT            :organizationName

       06 03 55 04 0a

    PRINTABLESTRING   :PVT a.s.

       13 08 50 56 54 20 61 2e 73 2e

  SET              

     31 11

   SEQUENCE         

      30 0f

    OBJECT            :organizationalUnitName

       06 03 55 04 0b

    PRINTABLESTRING   :19990901

       13 08 31 39 39 39 30 39 30 31

  SET              

     31 28

   SEQUENCE         

      30 26

    OBJECT            :commonName

       06 03 55 04 03

    PRINTABLESTRING   :Certifikacni autorita I.CA 9909

       13 1f 43 65 72 74 69 66 69 6b 61 63 6e 69 20 61 75 74 6f 72

       69 74 61 20 49 2e 43 41 20 39 39 30 39

 

 

SEQUENCE         

    30 5d

  SET              

     31 0b

   SEQUENCE         

      30 09

    OBJECT            :countryName

       06 03 55 04 06

    PRINTABLESTRING   :CZ

       13 02 43 5a

  SET              

     31 11

   SEQUENCE         

      30 0f

    OBJECT            :organizationName

       06 03 55 04 0a

    PRINTABLESTRING   :PVT a.s.

       13 08 50 56 54 20 61 2e 73 2e

  SET               

     31 11

   SEQUENCE         

      30 0f

    OBJECT            :organizationalUnitName

       06 03 55 04 0b

    PRINTABLESTRING   :20000901

       13 08 32 30 30 30 30 39 30 31

  SET              

     31 28

   SEQUENCE         

      30 26

    OBJECT            :commonName

       06 03 55 04 03

    PRINTABLESTRING   :Certifikacni autorita I.CA 0009

       13 1f 43 65 72 74 69 66 69 6b 61 63 6e 69 20 61 75 74 6f 72

       69 74 61 20 49 2e 43 41 20 30 30 30 39

 

 

SEQUENCE         

    30 5d

  SET              

     31 0b

   SEQUENCE         

      30 09

    OBJECT            :countryName

       06 03 55 04 06

    PRINTABLESTRING   :CZ

       13 02 43 5a

  SET              

     31 11

   SEQUENCE         

      30 0f

    OBJECT            :organizationName

       06 03 55 04 0a

    PRINTABLESTRING   :PVT a.s.

       13 08 50 56 54 20 61 2e 73 2e

  SET              

     31 11

   SEQUENCE         

      30 0f

    OBJECT            :organizationalUnitName

       06 03 55 04 0b

    PRINTABLESTRING   :20000301

       13 08 32 30 30 30 30 33 30 31

  SET              

     31 28

   SEQUENCE         

      30 26

    OBJECT            :commonName

       06 03 55 04 03

    PRINTABLESTRING   :Certifikacni autorita I.CA 0003

       13 1f 43 65 72 74 69 66 69 6b 61 63 6e 69 20 61 75 74 6f 72

       69 74 61 20 49 2e 43 41 20 30 30 30 33

 

 

 

ServerHelloDone

Tato zpráva protokolu HP má jednoduchý formát - neobsahuje žádná data. Vždy má tvar:
0E 00 00 00

11.4.4             Zprávy Certificate, ClientKeyExchange a CertificateVerify

Klient odpovídá serveru zprávami:

Klient Certificate

Struktura této zprávy je shodná se strukturou zprávy Server Certificate. V případě, že klient nemá odpovídající certifikát, pak vrací tuto zprávu prázdnou. Pokud server certifikát klienta striktně vyžaduje, pak Alert protokolem signalizuje fatální chybu.

 

Uvedeme si alespoň počátek zprávy odchycené MS Network Monitorem:

 

00000030                    16 03 00 04 9A 0B 00 03 CC 00       ..........

00000040  03 C9 00 03 C6 30 82 03 C2 30 82 02 AA A0 03 02 .....0...0......

00000050  01 02 02 03 01 F2 4B 30 0D 06 09 2A 86 48 86 F7 ......K0...*.H..

00000060  0D 01 01 05 05 00 30 4E 31 0B 30 09 06 03 55 04 ......0N1.0...U.

00000070  06 13 02 43 5A 31 2C 30 2A 06 03 55 04 03 13 23 ...CZ1,0*..U...#

00000080  49 2E 43 41 20 2D 20 53 74 61 6E 64 61 72 64 20 I.CA.-.Standard.

00000090  72 6F 6F 74 20 63 65 72 74 69 66 69 63 61 74 65 root.certificate

...

 

Kde:

·         16 je v RLP protokolu typ dat: protokol HP

·         03 00 je verze protokolu RLP: 3.0 (tj. SSL)

·         04 9A je délka RLP paketu (neobsahuje pouze zprávu Client Certificate)

·         0B 00 03 CC je záhlaví protokolu HP: 0B zpráva Certificate; 00 03 CC je délka zprávy Certificate.

·         00 03 C9 je délka řetězce certifikátů

·         00 03 C6 je délka certifikátu

·         Dále následuje certifikát klienta v DER-kódování.

ClientKeyExchange

Zpráva ClientKeyExchange je v našem příkladu uvedena záhlavím RLP fragmentu 16 03 00 00 44, kde 16 je protokol HP, 03 00 verze a 00 44 šestnáctkově délka.

00000030                    16 03 00 00 44 10 00 00 40 5A       ....D...@Z
00000040  E0 15 23 B7 24 70 0E 96 0A CB 28 F2 4D 27 13 D7 ..#.$p....(.M'..
00000050  F1 B5 BF 2A 40 A3 E7 EE 11 07 AB 14 90 5B AE AC ...*@........[..
00000060  79 7B 5E 59 C3 A1 11 15 5C 67 D3 35 32 97 B5 23 y{^Y....\g.52..#
00000070  96 8A 4D D6 A8 D3 7F A9 73 F7 6B 47 1B 75 1A    ..M....s.kG.u.

Vlastní zpráva ClientKeyExchange je uvedena záhlavím protokolu HP: 10 00 00 40, kde 10 specifikuje, že se jedná o zprávu ClientKeyExchange, a 00 00 40 udává délku této zprávy. Obsah zprávy je ve zbylých bajtech. Tato zpráva obsahuje veřejným klíčem serveru šifrované předběžné tajemství (PreMasterSecret), ze kterého se počítá hlavní tajemství (master_secret).

Pro algoritmus RSA má předběžné tajemství tvar:

 

       struct {

           public-key-encrypted PreMasterSecret pre_master_secret;

       } EncryptedPreMasterSecret;

 

Kde:

       struct {

           ProtocolVersion client_version;

           opaque random[46];

       } PreMasterSecret;

 

 

       random

           je 46 náhodně generovaných bajtů.

CertificateVerify

Tuto zprávu použije klient pouze v případě, že zaslal serveru svůj certifikát používající algoritmus, který umožňuje elektronický podpis (tj. nemůže se jednat např. o Diffie-Hellmannův certifikát).

 

Zpráva obsahuje elektronický podpis ze všech zpráv vyměněných mezi klientem a serverem od zprávy ClientHello, nezapočítávaje v to tuto zprávu.

 

                                                       0F                .

00000490  00 00 42 00 40 82 F2 6F 42 9A 45 E8 21 68 FE F3 ..B.@..oB.E.!h..

000004A0  6F 7A 57 58 E5 1A 8B F5 87 51 DC 72 93 37 63 AC ozWX.....Q.r.7c.

000004B0  3E 18 3E 11 F6 51 0C 20 4C 8D 72 C5 CA 87 E0 CB >.>..Q..L.r.....

000004C0  FB 14 E3 B8 54 11 45 BC 2F D7 6C 15 73 9F E0 5B ....T.E./.l.s..[

000004D0  18 F6 38 18 B6

 

Kde:

·         0F 00 00 42 je záhlaví zprávy; 0F signalizuje zprávu CertificateVerify;  00 00 42 je délka zprávy.

·         00 40 je pole délka.

 

 

ChangeCipherSpecification

Zpráva ChangeCipherSpecification  má vždy tvar: 14 03 00 00 01 01.

Zpráva Finished

Server i klient pak jen ukončuje dialog v protokolu HP zprávou Finished, jež je již šifrována (následuje po zprávě ChangeCipherSpecification):

00000030                    16 03 00 00 38 1D 84 FA B4 5D       ....8....]
00000040  3A DF 1C D8 9E 73 4B FB 59 98 09 D6 F7 29 EA FE :....sK.Y....)..
00000050  95 BC 1B 61 3A 31 4C 4C 77 09 11 F5 27 D3 1A A4 ...a:1LLw...'...
00000060  85 FB 26 0F 04 EB 6F 34 50 D5 8E 80 1C 2B 78 B9 ..&...o4P....+x.
00000070  BE F7 90                                        ...

Ze záhlaví RLP fragmentu předcházející vlastní zprávu Finished jsme schopni poznat pouze, že se jedná o HP protokol (16) verzi (03 00) a délku, která je šestnáctkově 00 38. Dále už je vše šifrováno.

Obsahem datové části zprávy Finished  je opět kontrolní součet ze všech předchozích zpráv od zprávy ClientHello. Tentokrát však nešifrované asymetrickým klíčem, protože zpráva je posílána už šifrována symetrickým klíčem.

V případě protokolu SSL jsou opět počítány dva kontrolní součty: jeden MD-5 a druhý SHA-1. V případě protokolu TLS kontrolní součet MD-5 vstupuje společně s hlavním tajemstvím a obsahem zprávy Finished jako argument do pseudonáhodné funkce.

 

11.4.5             ServerKeyExchange

Tato zpráva je jistou obdobou zprávy ClientKeyExchange a používá se pouze v případě, že použité algoritmy neumožňují pomocí zprávy ClientKeyExchange vybudovat blok klíčů.

11.4.6              HelloRequest

HelloRequest je prázdná málo běžná zpráva, kterou server upozorňuje klienta, že je na čase, aby klient odeslal zprávu ClientHello. Jedině klient totiž může odeslat zprávu ClientRequest, kterou HP protokol začíná výměnu zpráv, která vede k ustanovení nových šifrovacích klíčů.