Protokol TLS a jeho použití v praxi

Západočeská univerzita Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky

Protokol TLS a jeho použití v praxi Přenos dat

13. prosince 2004 Vypracoval: Petr Dvořák (A01125) E-mail: [email protected]

Protokol TLS a jeho praktické použití

1. Zadání (T/I) • • • • • • •

popis TLS - rozdělení na vrstvy k čemu slouží další protokoly používané TLS - symetrické, asym. šifry, hešovací funkce (AES, RSA, SHA ...) oveřování pravosti certifikátu (modely důvěry X.509 a OpenPGP) TLS v praxi - knihovny pro TLS komunikaci (OpenSSL a GnuTLS) použití TLS v existujících programech rozdíly mezi TLS a SSL.

2. Základní pojmy Kryptografie Nauka o tom jak šifrovat. Kryptoanalýza Nauka o hledání slabin v šifrování. Klíč Klíč slouží k parametrizaci šifrovacího algoritmu tak, aby si šifrovaný text mohl přečíst pouze ten, kdo zná klíč. Klíčem je většinou řetězec znaků. Certifikát Obsahuje veřejný klíč se jménem majitele. Součástí certifikátu jsou i další informace. Např. kdo ho vydal, kým je podepsán, jaká je jeho platnost apod. Server se jím jednoznačně identifikuje klientovi (nebo naopak). Je pak na druhé komunikující straně, aby si ověřila tento certifikát a podle toho se rozhodla pokračovat v komunikaci. Asymetrická kryptografie Využívá dvou klíčů. Jeden pro šifrování (ten je veřejně známý tzv. veřejný klíč) a jeden pro dešifrování (ten zná pouze majitel - jde o tzv. privátní klíč). Symetrická kryptografie Používá stejný klíč pro šifrování i dešifrování. Hešovací funkce Vytvoří jakýsi otisk vstupních dat. Slouží pro kontrolu integrity resp. toho, že vstupní data, jichž je několikanásobně větší množství, nebyla změněna. Blokové šifrování Při tomto šifrování se text, který chceme zašifovat, rozdělí do bloků o stejné velikosti. Každý blok se šifruje pomocí klíče pokaždé stejnou transformací. Proudové šifrování Proudová šifra pracuje s každým znakem textu zvlášť. Podstatný rozdíl oproti blokovým šifrám je ten, že se z klíče vygeneruje posloupnost, pomocí níž se na každý znak textu aplikuje jiná transformace. CBC (Cipher Block Chainning) Je způsob šifrování blokovými šiframi. Označme: • OT - text, který chceme zašifrovat • ŠT - zašifrovaný text • IV - inicializační vektor • Ek - šifrování • Dk - dešifrování

~2~


Na začátku se 1. blok šifrovaného textu získá na základě 1. bloku otevřeného textu OT 1 a inicializačního řetězce IV. V ostatních krocích je vstupem blok otevřeného textu OT n a šifrovaný text z předchozího kroku ŠT n-1. Pro dešifrování se musí poslat IV před šifrovaným textem. Samotné odšifrovávání probíhá podobně jako šifrování. Problémy nastávají u posledního bloku, který může být kratší než předcházející. To se řeší doplněním chybějících bytů. Man in the middle Je pojmenování pro útok na komunikaci mezi dvěma subjekty, kdy třetí subjekt tuto komunikaci modifikuje.

Např. Adam a Bára spolu komunikují, avšak zprávy od nich zachytává Joe, který je změní a přepošle.

3. Popis protokolu 3.1. Úvod do TLS Ve veřejných sítích typu TCP/IP není obecně zajistěna ochrana přenášených dat. Rovněž si nemůžeme být jisti s kým vlastně komunikujeme. Je tedy třeba zajist nějaký druh autentizace počítačů, které spolu komunikují a tuto jejich komunikaci zabezpečit proti neoprávněným "posluchačům". V dnešní době toto zajišťuje hojně používaný protokol SSL. Proč tedy vznikl protokol TLS? TLS byl naržen v lednu roku 1999. Nejde tedy o úplnou novinku. Jde o náhradu za SSL. SSL i TLS využívají pro svou funkci další protokoly (šifrování, výměna klíčí, autentizace, hash). V SSL toto rozšiřování vedlo k tomu, že je ve verzi 3 poměrné rozsáhlý a složitý. TLS se snaží tomuto předejít, zachovat jistý řád a používat jen nutné minimum. Vrstvy TLS se v zásobníku protokolů nachází nad transportním. Požadavek je, aby byl spolehlivý resp. spojovaný (např. TCP). Vzhledem k aplikačnímu protokolu, který je nad ním, se chová transparentně. Samotný TLS protokol je také rozdělen do dvou částí: • TLS Record Protocol • TLS Handshake Protocol

~3~


3.2. TLS Record Protocol 3.2.1. Stav spojení Při navazování spojení se klient se serverem dohodnou na určitých parameterch spojení (viz handshake protokol). Tyto parametry pak určují chování record protokolu: • jde o server nebo client • zvolený šifrovací algoritmus • zabezpečovací algoritmus (MAC - viz dále) • algoritmus komprese • 48 B master secret • 32 B náhodně generovaných klientem • 32 B náhodně generovaných serverem • používá se komprese N/A • informace potřebné pro zvolené šifrování • MAC secret - slouží k výpočtu zabezpečovací informace • identifikační číslo zprávy vytvořené record protokolem 3.2.2. Co dělá Record Protocol? Protokol zapoudřuje protokoly vyšších vrstev. Zpracovává zprávy k odeslání v tomto pořadí: • rozděluje data do bloků - fragmentace • volitelně data zakomprimuje • vypočte zabepečovací informaci • šifruje • předá nižší vrstvě A podobně příjmané zprávy: • dešifruje • zkontroluje • dekomprimuje • nazpět sestaví • předá vyšším vrsvám Projděme tedy podrobněji jednotlivé fáze. 3.2.3. Fragmentace Data se rozdělují po blocích o velikosti maximálně 16KB. Více zpráv může být v jednom bloku a naopak jedna zpráva může být rozdělena do více bloků. Každý blok si navíc sebou nese informaci komu se má na vyšší úrovni předat. Jsou 4 možnosti: protokol pro změnu šifrování, signální protokol (zpracovává chyby), handshake nebo aplikační protokol. Pozn.: Někdy se lze setkat s názvoslovým fragmentace = segmentace a blok = segment. 3.2.4.Komprimace Není povinná. Slouží ke zmenšení objemu přenášených dat. Jde o bezzeztrátovou kompresi. Komprimovaná data nesmí přesáhnout velikost 16KB + 1KB (to se stane v případě, kdy byl zvolen špatný komprimační algoritmus a velikost dat paradoxně příliš naroste). V TLS je doporučena komprese DEFLATE (viz Rozšíření TLS). 3.2.5. MAC MAC je jakási kontrolní informace přenášených dat. Získá se použitím některé z hešovacích funkcí - MD5, SHA-1. Jejich vstupem jsou data, MAC secret (viz Šifrování níže) a pořadové číslo bloku. Není přípustné počítat MAC bez MAC secret. Je to z důvodu bezpečnosti, kdy by mohl někdo jiný data pozměnit a podle toho upravit i MAC. Rovněž je zahrnuto pořadové číslo, aby útočník nemohl některé bloky odchytit a jiné zopakovat. Jedná o ochrany proti útokům man-in-the-middle. MAC secret se vypočítá z master secret a náhodně vygenerovaných dat klientem a serverem

~4~


3.2.6. Šifrování Slouží k zašifrování obsahu přenášených dat (včetně MAC). Jsou podporovány proudové (RC4 - 40-bitová a 128-bitová verze) a blokové šifry (RC2, DES, TripleDES, IDEA, v roce 2002 přidány i AES). Blokové šifry smí být použity pouze v módu CBC. Jak se získají klíče? Vezme se některá hešovací funkce. Jejím vstupem je master secret a náhodná data od klienta a serveru (jde o tzv. "osolení" o náhodná data). Dostaneme blok bytů, který si rozdělíme na části. První dvě části budou MAC secret klienta a serveru a další dvě klíče klienta a serveru. Poznamenejme důležitý fakt, že není povinnou volbou. To se hodí v případě, kdy nepotřebujeme šifrovat, ale stačí nám pouze vědět s kým komunikujeme (viz Handshake protokol).

3.3. TLS Handshake Protocol Zajišťuje veškeré vyjednání služeb, které požadujeme po TLS. Pomocí tohoto protokolu se počítače identifikují a dohodnou na způsobu komunikace. TLS Handshake protokol tvoří tři subprotokoly: • Alert protokol • Change Cipher Spec protokol • Handshake protokol 3.3.1. Alert protokol Je to množina zpáv pro vyšší vrstvy, sloužící k indikaci chyby. Pokud je chyba fatální dojde k ukončení spojení. Případná další spojení mohou probíhat dále, ale již nejde pomocí nich založit nové (viz dále). Příkladem takových chyb je např. přijetí chybné MAC nebo chybných dat (to se zjistí např. tím, že data nejdou dekomprimovat), data nelze rozšifrovat, některý z počítačů není schopen použít dostatečně silné šifrování, byl přijat certifikát neznámé certifikační autority, apod. 3.3.2. Change Cipher Spec protokol Tímto protokolem si dávají klient a server najevo, že další komunikace bude probíhat pod vyjednaným šifrováním s vyjednanými klíči. Zpráva o změně se posílá těsně před ukončením handshaku. 3.3.3. Vlastní Handhake protokol Handshake znamená potřesení rukou dvou lidí, kteří se seznamují. Podobně je to i s handsahke protokolem. Při handshaku se oba počítače "představují" vyměňují informace o způsobu komunikace mezi nimi. Tyto informace uchovává record vrstva. Jde např. o: • identifikátor spojení • certifikát počítače, s nímž se komunikuje • způsob komprese dat • algoritmy pro šifrování a hešování • master secret - klíč sdílený komunikujícími stranami • lze vytvořit další spojení? Všechny body budou asi jasné až na poslední. TLS totiž umožňuje na základě jednoho handshaku vytvářet další spojení. To, ale někdy nemusí být vhodné. Proto lze tuto možnost vypnout během navazování spojení. Při psaní aplikace, která využívá TLS se paradoxně nelze úplně spolehnout na bezpečnost handshake protokolu proti útokům. Např. útočník (man-in-the-middle) může znemožnit přístup k portu na němž se komunikuje, pokusit vyjednat spojení, které je chráněno slabou šifrou, případně není vůbec šifrováno, nebo vytvořit spojení, kde se počítače vzájemně neidentifikují. Z toho plyne, že aplikace by měla mít určité požadavky a na nich trvat. Tj. komunikace na určitém portu, použití dostatečně silné šifry a vyžádání certifikátu. Pozn.: Server může klientovi kdykoli poslat žádost o zaslání ClientHello. Tím ho vyzve k novému handshaku. Klient má možnost odmítnout. Pokud klient neodpoví, spojení se přeruší. Tato možnost zaslání žádosti umožňuje změnu šifrování "za běhu". 3.3.4. Jak probíhá handshake Existují dva možné způsoby handshaku. Buď se provede celý handshake nebo se vyjedná nové spojení na základě existujícho.

~5~


Kompletní handshake

Dále následuje popis handshaku znázorněném na obrázku. Spojení iniciuje klient odesláním zprávy ClientHello serveru. Server na to odpoví zprávou ServerHello. V obou se posílají mimojiné informace o použité verzi protokolu, sadě šifer, kterou podporují a náhodně vygenerované řetězce, které se používají ve vrstvě record k výpočtu klíčů. V komunikaci pokračuje server. Pokud se chce identifikovat, pošle svůj certifikát. Pokud jej nepošle nebo poslaný certifikát slouží jen k identifikaci musí navíc poslat klientovi svůj veřejný šifrovací klíč. Tento klíč použije klient k výměně premaster-secret. Pokud server poslal svůj certifkát, může požát klienta o identifikaci. V zaslané zprávě uvede seznam certifikačních autorit, které akceptuje. Poté odešle ServerHelloDone a čeká na odpověď klienta. Klient si po obdržení ServerHelloDone zkontroluje, zda dostal žádost o certifikát. Pokud ano, odešle svůj certifikát. Dále vygeneruje premaster-secret, zašifruje a pošle ho serveru. Pokud klient poslal certifikát, který lze použít k podpisu, pošle ještě zprávu, která slouží k explicitnímu ověření certifikátu. Klient potvrdí serveru, že následující zprávy již bude šifrovat s vyjednanými klíči. Nakonec pošle zašifrovanou zprávu, pomocí které server zkontroluje, že autentizace a výměna klíčů proběhla spávně. Server po přijetí zpráv nahradí aktuální metodu šifrování metodou vyjednanou a klientovi dá vědět. Nakonec ještě pošle kontrolní zprávu. Poté může začít vlastní přenos dat aplikací. Zjednodušený handshake

~6~

Protokol TLS a jeho praktické použití Tento zjednodušený handshake se používá, pokud chce klient se serverem pokračovat v dříve navázaném spojení nebo chce duplikovat existující spojení. Klient zašle zprávu CilentHello s identifikátorem spojení, v němž chce pokračovat. Pokud ho server nenajde začne kompletní handshake. Pokud ho najde potvrdí klientovy, že má nastavenou metodu šifrování podle zadaného spojení a odešle kontrolní zprávu. To samé provede i klient. Poté je možné posílat aplikační data.

3.4. Modely důvěry Někdy chceme vědět s kým vlastně komunikujeme K tomu slouží certifikáty, jež si server s klientem posílají během handshaku. Když ovšem obdržíme certifikát, co s ním dál? Jak zjistit, že patří opravdu tomu, kdo nám jej poslal? Je třeba ho nějak ověřit třetí stranou. Tento problém řeší tzv. modely důvěry. Existují dva odlišné modely, které mají své výhody i nevýhody: • hiearchický • distribuovaný 3.4.1 Hiearchický model - X.509

Princip je zobrazený na obrázku. Přepokladem je, že existuje nějaká instituce tj. certifikační autorita (CA), kterou zná server i klient. Certifikát, který obdrží je podepsán CA. Stačí tedy ověřit podpis CA. Existuje spousta CA (např. Verisign, Microsoft Certificate Server, ... ). Jedna CA může znát více jiných CA. Pokud nezná certifikát pošle jej ostaním CA, kterým důvěřuje. Tak vzniká hiearchická struktura. V ideálním případě se pak dostanem k jedné kořenové CA. V praxi, ale žádná taková neexistuje. Z toho plyne, že klient ale hlavně sever musí mít znát spoustu CA, jinak se prostě nedomluví. Další nevýhodou je, že CA si účtují vysoké poplatky za podepsané certifikáty, což zabraňuje většímu rošíření. Uplatnění tedy najde např. v nějaké firmě, které stačí akceptovat jen své zamětnance, jimž vydala a podepsala vlastní certifikát. Poznamenejme ještě, že tento model je doporučován i v TLS. 3.4.1. Distribuovaný model - OpenPGP Tento model se dá přirovnat k fungování peer-to-peer sítí. Je založen na důvěře, že poskytnuté informace jsou správné. Někdy je nazývána "web of trust" (síť důvěry). Dejme tomu, že máme spoustu známých a s námi chce komunikovat někdo koho neznáme. Zeptáme se, jestli jej náhodou neznají ostatní. Pokud ano, můžem v komunikaci pokračovat, protože to bude s nějvětší pravděpodobností ten, za koho se vydává. Např. Honza se zná s Pavlínou. David zná Honzu a věří mu, že zná dobře své známé. Pavlína napíše Davidovi. Ten se svých přátel zeptá, jestli to je opravdu ona. Honza odpoví, že to Pavlína určite bude a tak ji může v klidu odepsat.

~7~

Protokol TLS a jeho praktické použití Výhodou tohoto modelu je, že si ho můžeme nastavit podle svého. Např. pokud jsme hodně nedůvěřiví, tak si řeknem: "Pokud všichni potvrdili totožnost, avšak jeden ze známých řekne, že jej nezná, odmítnem další komunikaci." Další výhodou je, že za takový klíč či certfikát se neplatí. Certifikát má vlastně neomezené množství podpisujících. Nevýhodou může být, že odpovědnost za ověření vlastně nenese nikdo. Navíc poskytnuté informace nemusejí být aktuální (např. majitel přišel o certifikát a používá jiný). Tento model není součástí specifikace TLS, ale je implementován v některých dostupných knihovnách.

3.5. Rozšíření TLS TLS jako protokol existuje již poměrně dlouho (1999). Proto do něj bylo hlavně v posledních letech přidáno několik vylepšení. Nejzajímavěší zde budou podrobněji popsány. 3.5.1. Kerberos (1999) Krátce pro definování TLS protokolu byla přidána autentifikace pomocí šifer Kerberos. Měli sloužit k "bezpečnému" vyjednání master secret. Jejich délka byla 40 bitů. Šlo o reakci na embargo USA na dlouhé šifry. Tyto šifry by se dnes neměli používat. 3.5.2. Šifry AES (2002) Koncem minulého století docházelo ke snahám o prolomení šifer DES. Tyto snahy byly s narůstajícím výpočetním výkonem celkem úspěšné (existoval komerčně úspěšný odšifrovávací stroj). Jako přechodné řešení byl zvolen TripleDES, což je vlastně DES s tím, že se šifruje třikrát. Pokud se použijí 2 různé klíče (jeden z líčů je použit 2x), je délka zabězpečení 2 x 56b = 112b. Pokud se použijí 3 různé klíče je výsledná dělka 3 x 56b = 168b. To je sice dostačující, ale šifrování třemi klíči je zbytečně výpočetně náročné. Proto v roce 2002 vznikl standard AES. Používá algoritmus Rijndael. Je to symetrická bloková šifra s délkou bloku 128 b (oproti 64 bitům v DES). Umožňuje zvolit délku klíče 128 B, 192 B a 256 B. Do TLS byly začleněny pouze 128- a 256-bytové klíče. 3.5.3. TLS Extensions (2003) Tato rozšíření jsou určená hlavně mobilním zařízením v bezdrátových sítích, které jsou omezeny hardwarově a kvalitou přopojení. Dále umožňuje přidat další bezpečnostní informace. Jak jsou realizovány? Odesílají se během handshaku. Jsou součástí ClientHello a ServerHello (již v TLS 1.0 v nich byla specifikována nevyužitá položka právě pro Extensions). Odeslání jména serveru Při připojení k serveru klient odešle i jméno serveru, k němuž se chce připojit. Toto umožní výběr správného certifikátu a tedy i bezpečné připojení k serveru, na němž běží více virtuálních serverů. Maximální délka fragmentu Toto rošíření dovoluje TLS vyjednat menší velikost bloku record vrstvy. Toto rošíření je určeno klientům omezených velikostí paměti nebo šířkou pásma. Typicky bezdrátové sítě. Odeslání URL místo certifikátu Klient může míto certifikátu poslat pouze adresu, kde se nachází. Pak je nemusí mít uloženy v paměti. Pokud používá více certifikátů, může tak ušetřit velkou část svojí paměti. Použití zkrácené MAC Umožňuje zkrátit výstup hešovací funkce, která počítá MAC na 80b. Tím lze ušetřit šířku pásma. Známé CA Klient může poslat, jaké zná certifikační autority. To umožní předejít opakovaným neúspěšným handshakům. Certificate status request Umožní použít tzv. certificate-status protokol (např. OCSP) k ověření platnosti certifikátu serveru. 3.5.4. Komprese DEFLATE (2004) Tento algoritmus umožňuje zvolit si kompresní pomět a rychlost. Je založen na algoritmu LZ77 s Huffmanovým kódováním. Byl přidán na základě požadavků komunity kolem GnuTLS.

~8~


Lempel-Ziv-Stac (2004) Podobný předcházejícímu. Jeho výhodou je, že jeho kompresní poměr nikdy není horší než 1:1.

3.6. TLS v jiných protokolech TLS se kombinuje s aplikačními protokoly tam, kde se používal nebo ještě používá SSL. Např. ve Windows Server 2003 to jsou: • smtp, imaps, pop3s - pošta • https - stránky • nntps - dikusní skupiny • ldaps - adresářové služby • ftps-data, ftps - přenos souborů • telnets - vzdálený terminál • ms-sql-s - SQL server • tftps - nespojované ftp Asi nemá cenu blíže rozebírat jednotlivé protokoly. Jedná se o zabezpečené verze známých aplikačních protokolů. Zmínil bych zde ale ještě použití TLS ve WLAN. Zde jsou spojení vytvořena pomocí PPP (spojení mezi dvěma zařízeními). Pro autentizaci se používá EAP-TLS. RFC je sice označen jako experimentální, ale v praxi se používá. Byl zvolen i ve Windows XP. Jeho rozšířená modifikace je EAP-TTLS, která navíc vytvoří tunel pro druhý ověřovací algoritmus. TLS lze rovněž použít ke komunikaci ve virtuálních privátních sítích VPN. Zde používá jako levnější náhrada za IPsec. Příkladem konkrétní implementace je OpenVPN.

3.7. Postranní kanály 3.7.1. Co je postranní kanál V 90. letech minulého století se došlo k závěru, že moderní kryptografie je postavena na pevných matematických základech a tím pádem je bezpečná. Kryptoanalytici proto přestali hledat chyby v matematickém modelu, ale zaměřili se na konkrétní implementace. A zde se ukázalo, že obsahují spoustu slabin a poskytují informace, s nimiž se v matematickém modelu nepočítá. Každý nežádoucí způsob výměny informací mezi zabezpečeným systémem okolím je postranní kanály. 3.7.2. Typy Potranních kanálů existuje celá řada. Dají se rozdělit na několik skupiny: • elektromagnetické (např. každý počítač je zdrojemelektomagnetického záření) • časové (průběh operace závisí na vstupních datech) • proudové (např. pokud zadám špatně pin, v zařízeníprochází jíný proud) • chybové (chyba v implementaci systému) 3.7.3. Chybové potranní kanály Můžou být způsobené vlastní chybou sytému. Tzn. systém není spolehlivý. Chyba do nich může být také vnesena špatným protokolem nebo šifrovacím algoritmem. Např. při šifrování pomocí blokových šifer mohou pro stejné bloky textu vzniknout stejné bloky zašifrovaného textu (při použití ECB) anebo naopak zopakovaním některých bloků dojde k změně informace, aniž by útočník znal způsob šifrování (např. zvojením bloku přídáme 3 nuly a tak místo 1 000 Kč pošleme 1 000 000 Kč). TLS proto umožňuje u blokových šifer použít pouze CBC modus. 3.7.4. Doplňování v modu CBC U šifrování pomocí blokových šifer je známý problém doplnění posledního bloku textu na správnou délku (např. předepsaná délka je 8 bytů, ale na poslední blok zbylo jen 7). V TLS se doplňuje od 0 do 255 bytů. Jde o tzv. padding. Např. chceme zašifrovat text ovelikosti 61 bytů. MAC má délku 20 bytů a na uložení délky paddingu potřebujem 1 byte (0 - 255). To je celkem 82 bytů. Budem chtít šifrovat TripleDESem. Jeho délka bloku je 8

~9~

Protokol TLS a jeho praktické použití bytů. Tzn. musíme data doplnit tak, aby jejich délka odpovídala násobkům 8. Zvolíme tedy jedno z čísel 6, 14, 22, ...,254. Jako hodnota bytů použitých jako výplň se zvolí délka paddingu. Např. pro 6 bude konec odesílaných dat vypadat xx 06 06 06 06 06 06 06, kde xx je poslední byte z MAC, následuje 6 x 06 a nakonec délka paddingu 06. 3.7.5. PK při použití RSA v TLS TLS umožňuje nastavit se tak, aby mohl komunikovat s klientem SSLv2. Toto skrývá nebezpečí v okamžiku handshaku, kdy server přijme pre-master secret, ale zjistí, že je pro špatnou verzi. Vyšle chybové hlášení a ukončí spojení. Toto chybové hlášení je zdrojem informace, kterou může útočník využít. Po mnoha takových pokusech, kdy posílá jím pozměněná chybová data se dostane až k privátnímu klíči. Na tento postraní kanál přišli čeští kryptoanalytici Tomáš Rosa a Vlastimil Klima. Podařilo se jim při jednom jejich testu nalézt privátní RSA klíč o délce 1024 bitů za necelých 23 hodin. Doba víceméně závisí jen na výkonnosti serveru. Lze odstranit tak, že se společně s pre-master secret pošle očekávaná verze protokolu. Další řešení je konfigurace serveru (není běžné aby klient posílal tisíce požadavků).

4. TLS v praxi 4.1. Knihovny TLS TLS vzniklo v roce 1999 a od té doby se již hojně rozšířilo v různých programech. Aby se nemusely psát v každám programu stále ty samé funkce vznikly různé knihovny, které TLS implementují. Zde jsou uvedeny 4 nejrozšířenější. Na všech knihovnách je zajímavé to, že obsahují funkce pro práci s TLS i SSL. Oba sice nejsou kompatibilní, ale TLS obsahuje mechanizmy, jak tuto kompatibilitu zajistit. 4.1.1. OpenSSL Céčkovská knihovna. Je nejstaší ze všech zde uvedených knihoven. Původně vznikla jako knihovna implementující SSL. To je vlastně i dnes. Navíc však přibylo TLS. Psaní pro SSL a TLS aplikací se téměř neliší, protože TLS využívá většinu SSL funkcí. Od verze 0.9.7 podporuje i AES šifrování. Lze využít s BSD sockety. Samotné SSL funkce jsou jim velice podobné. Co se dá vytknout této knihovně je mizerná nápověda a to, že neimplemtuje přímo TLS, což může mít jistá bezpečnostní rizika (přejatá ze SSL). Instalace na Linux Není problém stáhnout balíček a nainstalovat: rpm -i ./openssl pro Debian: apt-get install openssl Použití Vygenerování klíčů (RSA, délka 1024): openssl req -newkey rsa:1024 -nodes -keyout server.key -out server.req Vygenerování certifikátu (X.509): openssl x509 -req -signkey server.key -in server.req -out server.pem 4.1.2.GnuTLS Céčkovská knihovna. Implementuje TLS podle standardu. Navíc podporuje i SSL verze 3. Obsahuje wrappery pro OpenSSL. Aplikace tak lze jednoduše předělat pro GnuTLS (použitím hlavičkového soubor openssl.h). Oproti standardu obsahuje rozšíření o podporu OpenPGP. Lze využít nejen BSD sockety. Dle mého názoru je asi nejlepší ze všech zde uvedených. Je již ve stabilní verzi. Má rozněž dobrou nápovědu. Lze použít i pod Windows.

~10~

Protokol TLS a jeho praktické použití Instalace na Linux Instalace už není tak jednoduchá jako u OpenSSL. Jsou potřeba doinstalovat 2 knihovny a samotné GnuTLS. Já jsem instaloval tyto verze: • libgpg-error-1.0 • libgrypt-1.2.0 • gnutls-1.0.22 GnuTLS ještě vyžaduje knihovnu libtasn, ale ta je zpravidla přítomna v systému. Nejednodušší řešení je vše instalovat ze zdrojových kódů: ./configure --prefix=/usr make make install Instalace na Debian Popíši zde ješte instalaci z balíčku na OS Debian v UL402. Zde jsou nekompatibilní verze knihovny ASN.1 a GnuTLS. Proto musí být knihovna ASN.1 nahrazena jinou: dpkg -r --force-depends libtasn1-2 apt-get -f install libtasn1-2-dev libtasn1-2 -t testing apt-get install libgnutls11-dev 4.1.3. NSS Céčkovská knihovna byla vytvořena komunitou kolem Mozilly. Obsahuje podporu TLS i SSL. Má poměrně dobrou nápovědu. Lze použít i pod Windows při psaní vlastních programů. 4.1.4. PureTLS Javovká knihovna. Obsahuje podporu pro TLS i SSL. 4.1.5. JSSE Java Secure Sockets Extension je balíček, pro podporu SSL a TLS v Javě. Je z dílny Sunu. 4.1.6. Chilkat SSL COM komponenta, která podporuje SSL i TLS. Je založana na OpenSSL. Lze použít v C++ i .NET.

4.2. Implementace Součástí semestrální práce jsou 2 implementace serveru a klienta, při nichž bylo použito knihoven OpenSSL a GnuTLS. Obě jsou určeny pro operační systém Linux. Předpokladem je, že v něm budou knihovny naistalovány (viz předchozí kapitola). U OpenSSL je vidět, že jsou rozdíly mezi psaním aplikace TLS a SSL jsou minimální. Naproti tomu GnuTLS implementuje přímo TLS, ale zachovává zpětnou kompatibilitu s SSLv3. Obě implementace fungují stejně. Spustí se server (aby fungoval nejen pod rootem). Pak se spustí klient. Jako parametr má IP nebo jméno serveru. Server mu pošle certifikát. Po handshaku klient pošle řetězec „Tajná zpráva“. Server jej přijme a odešle nazpět. Poté komunikace končí.

4.3. Programy využívající TLS Prohlížeče • Internet Explorer • Firefox (knihovna NSS) • Mozilla (Knihovna NSS) • Lynx (GnuTLS) - textový webový prohlížeč Poštovní klienti • Pine (OpenSSL) • Thunderbird (NSS) • Mozilla (NSS) • Eudora • Evolution (GnuTLS)

~11~

Protokol TLS a jeho praktické použití Poštovní servery • James (JSSE) - javovský SMTP, POP3 Mail server a NNTP News server • SendMail (OpenSSL) Autentizovaný přístup • vzdálený přístup (Windows Server 2003) • přístup k SQL (Windows Server 2003) Ostatní • TLSWrap (OpenSSL) - dovoluje použít stávající FTPklientpro bezpečný přenos • CryWrap (GnuTLS) - wraper pro TCP služby • SafeGossip (OpenSSL) - wraper pro POP, IMAP a SMTP • Hydra (GnuTLS) - webový server • Gaim (GnuTLS) - komunikační program pro icq síť • C-Kermit (OpenSSL) - komunikační program • OpenVPN - slouží k vytváření virtuálních privátních sítí • a mnoho dalších

5. Shrnutí TLS vychází z SSL verze 3. Změny jsou minimální, ale natolik závažné, že oba protokoly nejsou vzájemně kompatibilní. Týkají se hlavně bezpečnosti. V TLS je však popsán mechanismus, jak zajistit zpětnou kompatibilitu. Rozdíly TLS a SSLv3 • Zabezpečení MAC se počítá jinak. • TLS nepodporuje mechanizmus výměny klíčů Fortrezza. • Do Alert protokolu bylo přidáno mnoho nových zpráv. • V TLS není nutné použít všechny certifikáty až ke kořenové certifikační autoritě. Stačí použít některou mezilehlou. • Padding blokových šifer v modu CBC je proměnný (0- 255). V SSL musí být menší než délka bloku. • SSL se jako protokol již nerozvíjí. Rozšíření do něj jsou "dolepovány". • TLS je mnohem striktnější ve svém použití i použití jiných protokolů kvůli bezpečnosti (v RFC jsou popisována bezpečnostní rizika). • + další drobné rozdíly Obecně lze doporučit použití pouze TLS a silné šifry. Pokud to je nutné, podporovat ještě SSLv3. SSLv2 zanáší do TLS bezpečnostní rizika (viz kapitola o Postranních kanálech), proto by se neměl vůbec používat.

6. Závěr Protokol TLS je poměrně zajímavé a jak jsem zjitil, tak rovněž obsáhlé téma. Semestrální práce zahrnovala nastudování tohoto protokolu, vyhledání a instalaci knihoven implementující TLS a napsání programů serverklient pomocí dvou knihoven OpenSSL a GnuTLS. To dle mého názorů znamenalo 3-násobek práce oproti zadáním, kde se píše pouze tutoriál.

7. Zdroje http://www.rfc-editor.org/rfc/rfc2246.txt - The TLS Protocol Version 1.0 http://www.rfc-editor.org/rfc/rfc3268.txt - AES Ciphersuites for TLS http://www.rfc-editor.org/rfc/rfc3546.txt - TLS Extensions http://www.openssl.org/ - OpenSSL http://www.gnutls.org/ - GnuTLS http://java.sun.com/products/jsse/ - Javoská knihovna od Sunu implementující TLS http://www.joe.cz - Stránky Dominika Joe Pantůčka http://cryptography.hyperlink.cz - Stránky Vlastimila Klimy http://crypto.hyperlink.cz/ - Stránky Tomáše Rosy http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/enus/Default.asp?url=/Resources/Documentation/windowsserv/2003/all/techref/en-us/w2k3tr_schan_what.asp - kde se využívá TLS ve Windows Server 2003 http://www.root.cz/clanek/2440 - použití TLS ve virtuálních privátních sítích

~12~

Protokol TLS a jeho použití v praxi

Recommend Documents