Grafické rozhraní pro OpenVPN. Pavel Hasenöhrl

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Bakalářská práce Grafické rozhraní pro OpenVPN Pavel Hasenöhrl Vedoucí práce: Ing. Jan Kubr Studijní program: Softwarové technologie a management, Bakalářský Obor: Softwarové inženýrství 26. května 2010

2 iv

3 v Poděkování Zde bych rád poděkoval vedoucímu této práce Ing. Janu Kubrovi za čas strávený na konzultacích, hodnotné připomínky a taky za to, že mi dal možnost realizovat se v rámci této bakalářské práce.

4 vi

5 vii Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne

6 viii

7 Abstract This bachelor project deals with design, implementation and testing of a multiplatform (Windows and Linux) graphical user interface for the OpenVPN program. In contrast to similar GUI this one supports management of either VPN client and server, supports routed and ethernet bridging modes and includes a system for automatic distribution of certificates and network settings. This solution described here encapsulates usage of the OpenSSL program. In combination with OpenVPN it has an ambition to become a good alternative to using other VPN solutions. Abstrakt Tato bakalářská práce se zabývá návrhem, implementací a následným testování multiplatformního (Windows a Linux) grafického uživatelského rozhraní pro program OpenVPN. Narozdíl od jiných takových GUI podporuje správu VPN klienta i serveru, podporuje směrovaný i ethernet bridging mód a obsahuje systém pro automatickou výměnu certifikátů a nastavení sítě. Zde popsané řešení zapouzdřuje použití programu OpenSSL. V kombinaci s OpenVPN má ambice stát se dobrou alternativou k použití jiných řešení pro zprovoznění a správu VPN sítě. ix

8 x

9 Obsah 1 Úvod 1 2 Popis problému, specifikace cíle Cíl Přehled VPN produktů Hamachi Remobo Wippien Microsoft VPN PPTP Microsoft VPN L2TP/IPSec OpenVPN GUI pro OpenVPN OpenVPN GUI OpenVPN-Admin Analýza a návrh řešení Požadavky Systémové požadavky Funkční požadavky Případy užití Struktura aplikace Obecná struktura Konkrétní řešení Automatická distribuce certifikátů PKI IKE Kerberos SSL/TLS Vlastní řešení Exchanger Vyhodnocení Ethernet bridging Realizace Použité technologie Protokol Exchanger xi

10 xii OBSAH Formát zprávy Popis komunikace Problémy Multiplatformnost Kódování řetězců Licence Testování Zaměření testování Konzistence programu Komunikační protokol Multiplatformnost Testovací prostředí Testovací případy Akceptační test Traceability matrices Výsledky testování Závěr Další vývoj A Seznam použitých zkratek 41 B Obsah přiloženého CD 43

11 Seznam obrázků 3.1 struktura aplikace její hlavní části formát zprávy protokolu fungování protokolu pro distribuci certifikátů a parametrů stavový diagram protokolu na straně klienta stavový diagram protokolu na straně serveru xiii

12 xiv SEZNAM OBRÁZKŮ

13 Seznam tabulek 5.1 traceability matrix testovacích případů a funkčních požadavků traceability matrix testovacích případů a systémových požadavků xv

14 xvi SEZNAM TABULEK

15 Kapitola 1 Úvod Poslední dobou, kdy se vysokorychlostní připojení k Internetu stalo dostupné i domácím uživatelům, dbá se i více na bezpečnost přenášených dat, stala se technologie VPN (Virtual Private Network) vyhledávanou a používanou. Na trhu existují mnohá řešení pro různě zručné uživatele, některá jsou komerční, jiná volně dostupná pro nekomerční použití. Běžný uživatel většinou potřebuje rychle vytvořit VPN síť či se připojit do existující VPN sítě pomocí co možná nejméně udájů, ale zároveň očekává bezpečnost a spolehlivost. Já jsem se zaměřil na open source VPN řešení program OpenVPN, který splňuje poslední dva požadavky, ale nevýhodou je jeho zprovoznění a složité nastavení, které není většině uživatelů okenních systémů vlastní. Proto jsem se rozhodl napsat program, který toto nastavení usnadní uživatelům operačního systému Windows, respektive Windows XP. A zároveň udělám verzi pro Linux, aby užívání programu nebylo vázáno pouze na jeden operační systém. 1

16 2 KAPITOLA 1. ÚVOD

17 Kapitola 2 Popis problému, specifikace cíle 2.1 Cíl Cílem je grafická aplikace, která bude fungovat jako rozhraní nad OpenVPN. Bude umět nastavit server a klienty ve směrovaném i ethernet bridging režimu. Podporovanou topologií sítě bude hvězda s centrálním prvkem serverem, nebude podporováno např. propojení dvou sítí tunelem, nebo zpřístupnění vnitřní sítě vzdáleným klientům. Hlavním důvodem je, že běžní uživatelé jinou topologii obyčejně nepotřebují, přidání dalších možností by zesložitilo program a znepřehlednilo nastavení. Důležitou součástí bude také automatická distribuce nastavení VPN sítě a certifikátů, pomocí kterých se budou klienti na VPN serveru autentizovat. Systém automatické distribuce certifikátů musí být bezpečný, ověření klientů bude probíhat pomocí předem domluveného jména a hesla. Ve výsledku by se mělo jednat o kompletní grafické rozhraní usnadňující práci s Open- VPN, ale zároveň nebude pokročilé uživatele nijak omezovat ve volnosti nastavení (libovolné očíslování sítě, vlastní bezpečnostní nastavení, nastavitelné číslo portu,...) 2.2 Přehled VPN produktů Již existují produkty, které používají technologii VPN. Těchto hotových produktů je celá řada a vyvíjejí se určitě další. Proto jsem hledal a prověřoval některé tyto produkty a porovnával je. Snažil jsem se vybrat produkty, které jsou relativně známé a používané Hamachi Program Hamachi umožňuje vytvořit mezi klienty virtuální LAN (Local Area Network). Vytváří VPN tunely mezi všemi klienty, kteří se přihlásili do dané sítě. Výsledná topologie je mesh, kde je propojen každý s každým, což otevírá více spojení, než jak tomu je u architektury klient server. Klientům se přiděluje adresa z veřejného rozsahu /8, což je jednak omezující a není to ani správné. Výhodou je, že není potřeba vlastnit veřejnou adresu, ale na druhou stranu je spojení závislé na serverech třetí strany, které nejsou vždy spolehlivé. Navíc to může představovat bezpečnostní riziko. Program je komerční, ale existuje i verze, která je zdarma k dispozici pro 3

18 4 KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE nekomerční použití (tu také popisuji) ovšem s omezeným počtem současně připojených uživatelů. Více informací je na webových stránkách hamachi2/. Tento produkt je brán, jako určitý vzor pro mé řešení z pohledu jednoduchosti nastavení a uživatelské přívětivosti. Zároveň je mým osobním cílem tento produkt kombinací mého GUI (Graphical User Interface) a programu OpenVPN překonat. výhody: umí broadcast téměř bez potřeby nastavení nevýhody: proprietární komerční řešení závislé na třetí straně adresní rozsah /8 topologie mesh Remobo Remobo se nejvíce podobá programu Hamachi, ale vůbec nic se v něm nenastavuje, proto je velmi nenáročný na uživatele. Funguje to tak, že se vytváří mezi všemi přidanými klienty VPN tunely. Přiděluje také adresy z veřejného rozsahu (tentokrát /8), po každém spuštění ale přiděluje adresu znovu. Program je dostupný pouze v beta verzi, která je zatím zdarma. Více informací je na webových stránkách výhody: žádné nastavování multiplatformní nevýhody: proprietární řešení beta verze neumí broadcast závislé na třetí straně žádné možnosti nastavení

19 2.2. PŘEHLED VPN PRODUKTŮ 5 adresní rozsah /8 nutnost registrace dynamické přidělení adresy topologie mesh Wippien Jedná se o IM (Instant Messaging) klient, který zároveň umožňuje VPN spojení mezi přátely. Klient samotný je zdarma a zdrojové soubory jsou k dispozici pod MIT (Massachusetts Institute of Technology) licencí, ale používá komponenty třetí strany. Navazování spojení a číslování sítí je poněkud zvláštní. Nepodařilo se mi navázat stabilní kanál mezi dvěma klienty. Více informací na výhody: MIT licence nevýhody: ranné stádium vývoje potřeba účtu na jabber komponety třetí strany topologie mesh zvláštní konfigurace Microsoft VPN PPTP VPN řešení zabudované přímo v operačních systémech Windows. Nastavuje se pomocí wizarda. PPTP (Point-to-Point Tunneling Protocol) není ale považován za bezpečný protokol [5]. Více informací na Microsoft TechNet [14]. výhody: součást OS (Operating System) Microsoft Windows klient-server nevýhody: není bezpečný protokol neumí broadcast

20 6 KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE Microsoft VPN L2TP/IPSec Další VPN řešení podporované v operačních systémech Windows. Na rozdíl od PPTP používá L2TP (Layer Two Tunneling Protocol) IPSec (IP Security), takže je bezpečné. Bohužel pro VPN server je nutné mít serverový operační systém např. Windows 2003 Server. Klient je zabudovaný i ve workstation např. Windows XP. Běžní uživatelé si proto vlastní VPN tohoto typu nevytvoří. Více informací na Microsoft TechNet [13]. výhody: součást OS Microsoft Windows bezpečný klient-server nevýhody: potřeba více portů nutný serverový OS OpenVPN OpenVPN je velmi bezpečné řešení pro VPN bezpečnost zajišťuje knihovna OpenSSL. Pracuje ve dvou režimech směrovaném a ethernet bridging, který umožňuje posílání broadcastů, ale server se nastavuje složitěji. Server může provozovat kdokoliv, kdo je dostupný z internetu alespoň přes jeden TCP (Transmission Control Protocol) nebo UDP (User Datagram Protocol) port, odpadá tak závislost na serverech třetích stran. Program má podrobnou, ale složitější konfiguraci. Další nevýhodou je podepisování a distribuce certifikátů, kterou je potřeba dělat ručně. Jedná se open source projekt distribuovaný pod GPL (General Public License) licencí. Více informací na stránkách projektu Tento VPN produkt mnoho dobrých vlastností, nevýhodou je složitá konfigurace, kterou je možné odstranit právě pomocí GUI. výhody: open source bezpečné broadcast UDP nebo TCP multiplatformní podrobná konfigurace klient-server nezávislost na třetí straně

21 2.3. GUI PRO OPENVPN 7 nevýhody: složitější konfigurace distribuce certifikátů 2.3 GUI pro OpenVPN V době, kdy jsem začal pracovat s programem OpenVPN žádné oficiální GUI pro něj neexistovalo. Až když jsem začal pracovat na vlastním řešení, objevily se na stránkách projektu OpenVPN další GUI pro tento program. Většinou se jedná o programy vázané na jednu platformu (Tunnelblick, KVpnc,...). Pouze charakteristika OpenVPN-Admin je nejpodobnější. Můj program ale řeší i distribuci certifikátů a nastavení sítě mezi serverem a klienty, usnadňuje použití režimu ethernet bridging, což ostatní GUI nenabízí. Na Internetu, zejména pak na je mnoho dalších GUI pro program OpenVPN. Některá jsou nová, jiná starší v porovnání s GUI vyvýjeném mnou. Některá vyžadují webový server (OpenVPN Web GUI, MyVPN OpenVPN Web Config,...), další mají jen část funkcionality a nemá smysl je všechny vypisovat, jen příklad několika z nich: Open- VPN Client Windows, FASTOpenVPN-Gui, gopenvpn, OpenVPN GUI Jedná se o jednoduché GUI k programu OpenVPN napsané nad WIN32. Neusnadňuje nastavení jednotlivých parametrů pomocí GUI a nepřidává žadnou další funkcionalitu. Ostatní vlastnosti programu OpenVPN neovlivňuje. Uvedl jsem ho, protože je součástí distribuce OpenVPN pro Windows, díky čemuž je více oficiální než ostatní GUI pro OpenVPN. Více informací na stránkách projektu výhody: open source distribuováno spolu s OpenVPN nevýhody: pouze Windows jen základní vlastnosti neobsahuje nic nového

22 8 KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE OpenVPN-Admin OpenVPN-Admin je GUI napsané ve frameworku Mono. Je tedy k dispozici jak pro platformu Windows, tak Linux. Umožňuje nastavení klienta i serveru, ale neřeší distribuci certifikátů a nastavení sítě. Více informací na stránkách projektu projects/openvpn-admin/. výhody: open source multiplatformní nevýhody: neřeší distribuci certifikátů

23 Kapitola 3 Analýza a návrh řešení 3.1 Požadavky Systémové požadavky SR1: OS Windows XP Program je primárně určen pro operační systém Windows XP, všechny jeho vlasnosti musí fungovat pod tímto systémem. SR1: OS Linux Program bude portován i pod operační systém Linux. GUI by mělo být stejné jako ve verzi pro Windows, ostatní funkce mohou být řešeny jinak. SR2: OpenSSL Program bude umět spolupracovat s programem/knihovnou OpenSSL (kvůli bezpečnostním funkcím) Funkční požadavky FEAT1: Jednoduché nastavení Nejdůležitější parametry pro funkční nastavení sítě by měly být uživateli nabídnuty nejdříve. Uživatel ale musí mít možnost zobrazit si a nastavit i další parametry skrze grafické rozhraní. Jednotlivá pole pro zadání hodnot budou obsahovat výchozí hodnotu, výstižný popisek a nápovědu, kterou si případně uživatel bude moci zobrazit, když si nebude jistý významem pole (např. najetím kurzorem myši na popisek pole). FEAT2: Správa nastavení sítí Systém umožňuje spravovat různé sítě. Nastavení bude ukládáno do adresáře se jménem sítě. V daném adresáři budou i konfigurační soubory pro OpenVPN, privátní klíč a certifikáty. Adresáře s nastavením bude možno ukládat kamkoliv a pro vybrání správné lokace bude sloužit klasický dialog pro uložení souboru. FEAT3: Podpora broadcastů Program bude podporovat nastavení režimu ethernet bridging, kvůli podpoře broadcastů v síti VPN. Nastavení tohoto režimu má jistá specifika, se kterými bude program umět pomoci. 9

24 10 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ FEAT4: Automatická distribuce certifikátů Část programu zajišťuje distribuci certifikátů mezi klienty a serverem. Tato vlastnost je klíčová pro jednoduchou použitelnost tohoto řešení. Zároveň nesmí tato funkce narušit bezpečnost a důvěryhodnost sítě. Server i klienti si vygenerují vlastní privátní klíč, předávat se budou pouze certifikáty a žádosti o podepsání certifikátu. Tato komunikace mezi serverem a konkrétním klientem bude zabezpečena silnou symetrickou šifrou s předem dohodnutým heslem. FEAT5: Logování Aplikace musí umět zaznamenávat události, které nastaly při konfiguraci sítě, distribuci certifikátů, spravování klientů,... Log se bude zobrazovat v okně aplikace a zároveň ukládat do souboru. FEAT6: Stavové informace Aplikace by také měla zobrazovat v jakém stavu se daná síť či připojení k ní nachází. Stavy serveru budou, jestli je inicializovaný, spuštěný, vypnutý, dále, kteří uživatelé se mohou připojit, kteří jsou revokování. U klienta se budou zobrazovat pouze stavy, zda je u serveru autentizován a jestli je připojen. FEAT7: Správa klientů Server bude mít možnost jednotlivé klienty odstranit či zneplatnit jejich certifikáty (revokace). FEAT8: Lokalizace Texty v GUI programu by měly být lokalizovatelné do jiných jazyků. Při prvním spuštění se program zeptá na jazyk, který má používat, a toto nastavení si uloží. FEAT9: Generování konfigurace Z nastavení VPN serveru i klienta bude možné vygenerovat konfigurační soubor ve formátu, jaký používá OpenVPN. Server ještě bude umět vygenerovat konfiguraci pro své klienty (jen ty direktivy, které jsou určeny aktuálním nastavení serveru a klient je nemůže ovlivnit) a bude ji umět poslat klientům na vyžádání, bude se posílat podobně jako certifikáty. 3.2 Případy užití UC1: Vytvoření nové sítě Uživateli je dovoleno vytvořit novou síť (server nebo klienta) v kterémkoliv stavu aplikace. Uživatel vyvolá dialog pro tvorbu serveru/klienta, vybere adresář, kde se vytvoří adresář sítě a zadá její jméno. Vytvořená síť se stane aktivní. V případě chyby se aplikace vrátí do výchozího stavu (stav jako po spuštění). UC2: Otevření sítě Uživatel vyvolá dialog umožňující načíst dříve vytvořenou síť, vybere adresář sítě, kterou chce načíst. Po potvrzení dialogu se síť načte jako aktivní, nebo vyskytneli se nějaký problém, obnoví se výchozí stav aplikace. UC3: Úprava nastavení aplikace Uživatel v dialogu pro nastavení aplikace, který je přístupný vždy, může měnit nastavení aplikace. Obsahuje formulář s parametry aplikace. Každá řádka formuláře obsahuje popisek s nápovědou a vedle popisku je nějaké vstupní pole s hodnotou, kterou lze změnit. Dialog je nutné potvrdit pro uložení provedených změn, celé nastavení se okamžitě uloží do příslušného souboru.

25 3.3. STRUKTURA APLIKACE 11 UC4: Úprava nastavení sítě Aby si uživatel mohl zobrazit nastavení sítě, musí být aktivní nějaká síť (viz UC1 a UC2). Potom si může uživatel vyvolat dialog s nastavením sítě, ten obsahuje formulář s parametry sítě. Každá řádka formuláře obsahuje popisek s nápovědou a vedle popisku je nějaké vstupní pole s hodnotou. Dialog je nutné potvrdit pro uložení provedených změn. Jestliže je zapnutá funkce automatického ukládání, uloží se změny i do příslušného souboru. UC5: Ovládání Uživatel je schopen ovládat a volat funkce aplikace pomocí dialogu s příkazy. Příkazy ve vyvolaném dialogu se liší podle aktivní sítě. U sítě typu klient je uživateli umožněno vygenerovat privátní klíč a žádost o certifikát, spustit výměnu informací se serverem a připojit se k VPN serveru. U sítě typu server je uživateli umožněno vygenerovat privátní klíče a certifikáty, spustit server pro výměnu potřebných informací s klienty, vypnout zmíněný server a spustit VPN server, u serveru v režimu TAP navíc umožňuje nastavit NAT (Network Address Translation) a zrušit NAT. UC6: Správa klientů Klienty sítě lze spravovat pouze při aktivní síti typu server. Uživatel vyvolá dialog pro správu, který umožňuje přidávat a mazat záznamy. Záznam je dvojice jméno heslo. Po každé změně se záznamy ukládají do příslušného souboru. UC7: Logování Logování se provádí automaticky. Uživatel si logované informace může zobrazit vyvoláním příslušného dialogu. 3.3 Struktura aplikace Obecná struktura Jedná se o desktopovou multiplatformní (Windows a Linux) aplikaci s grafickým uživatelským rozhraním. V požadavcích je dále uvedeno, že bezpečnostní funkce budou poskytovány programem/knihovnou OpenSSL, která je dostupná pro obě platformy. Projekt OpenSSL je otevřený, tudíž, zda je implementace skutečně bezpečná, mohou posoudit i další odborníci na toto téma, navíc je známý a uznávaný. Aplikace musí umět spravovat VPN server, stejně tak klienty, proto bude pracovat v několika režimech podle nastavení sítě, která je v daný okamžik aplikací otevřená. Konkrétně se bude jednat o čtyři stavy server/klient v režimu TUN/TAP a ještě stav, kdy není otevřena žádná síť. Každý stav se mezi sebou více či méně liší. Největší odchylky v potřebné konfiguraci aplikace jsou mezi stavy serveru a klienta. Konfigurace režimu server obsahuje serverovou část systému pro automatickou distribuci certifikátů, aplikace v režimu klient zase musí obsahovat klientskou část systému. Server na rozdíl od klienta spravuje své klienty např. jejich přihlašovací informace k systému pro automatickou výměnu certifikátů. Aplikace je navržena tak, že k jedné konkrétní síti se může připojit více klientů a každá síť má vždy jeden server. Skládá se z několika hlavních částí: GUI, systém pro automatickou distribuci certifikátů, programu/knihovny OpenSSL, programu OpenVPN, případně

26 12 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ WMI (Windows Management Instrumentation) (pouze Windows) a souborů pro persistentní uložení potřebných dat. Tato aplikace tvoří jakousi nadstavbu nad programem OpenVPN, který používá klíče a certifikáty vytvářené programem OpenSSL. Zapouzdřuje tak používání těchto programů, tudíž uživatel pak nemusí používat tyto programy přímo, ale používá jednotné grafické rozhraní. Tento přístup má i nevýhody, GUI, jak je navržené, počítá jen s některými funkcemi, tudíž může omezovat použití programu OpenVPN. S tím se však počítá. Částečně struktura aplikace vychází z mé dřívější práce, která řešila specifické nastavení operačního systému a programu OpenVPN pro mód ethernet bridging. Tuto práci jsem dělal v rámci předmětu Y36SPS (Správa počítačových sítí). Výsledek práce je k dispozici na wiki předmětu [4] Konkrétní řešení Program, který obsahuje GUI a propojuje všechny části se nazývá vpntrustee. Systém automatické distribuce certifikátů je vlastním řešením určeným přímo pro danou aplikaci a jmenuje se Exchanger. Je rozdělen do dvou částí serverovou a klientskou, které mezi sebou komunikují zde navrženým protokolem, viz obrázek 3.1. Exchanger je součástí programu vpntrustee. Ve verzi pro Windows se používá služba WMI, která se v programu připojuje pomocí COM (Component Object Model) a dotazování probíhá jazykem WQL (WMI Query Language). Služba WMI je zde použita kvůli získávání jmen síťových rozhraní. OpenVPN, OpenSSL a další programy, které program využívá, se volají ve skriptech spouštěných v interpretu příkazové řádky (cmd Windows, bash Linux). Skripty se vykonávají v rámci hlavního programu či Exchangeru, jak je naznačeno na obrázku 3.1. Skripty spouštějící OpenVPN se ale spouští jako samostatný proces, lze tak např. přejít ke správě jiné sítě, zatímco jedna VPN síť už běží. VpnTrustee si ukládá některé informace na disk. Je zde soubor globální konfigurace, který je určený pro danou instalaci programu a nachází se v adresáři dané instalace. Ostatní soubory má každá síť vlastní, jedná se o soubor obsahující nastavení sítě, logovací soubor a v případě serveru ještě soubor s přihlašovacími informacemi klientů. Všechny tyto soubory jsou textové v kódování UTF 8 (Unicode Transformation Format). 3.4 Automatická distribuce certifikátů Program OpenVPN primárně používá pro zabezpečení důveryhodnosti a autentičnosti komunikačního kanálu mezi serverem a klienty asymetrické šifrování RSA. To je založené na privátním klíči a veřejném klíči. Privátní klíč by měl správně znát jenom jeho majitel (ten kdo ho vygeneroval). Veřejný klíč zase musí znát všichni, to lze obyčejně jen těžko zajistit, útočník může např. podsouvat podvržené veřejné klíče. Jedním ze způsobů je certifikace veřejných klíčů. Veřejný klíč je součástí certifikátu, který také obsahuje identifikační údaje uživatele a další informace. Certifikát je podepsán certifikační autoritou, tento podpis zaručuje, že se nejedná o falzifikát. OpenVPN používá konkrétně PKI (Public Key Infrastructure), která je založená na certifikátech dle ITU-T X.509 [8].

27 3.4. AUTOMATICKÁ DISTRIBUCE CERTIFIKÁTŮ 13 vpntrustee Server Mode Workstation vpntrustee Client Mode Workstation Global Configuration File vpntrustee vpntrustee Global Configuration File Network Configuration File Script WQL Exchanger Server WMI (Windows) Script Exchanger Protocol Script Exchanger Client WMI (Windows) WQL Script Network Configuration File Log File Script OpenSSL OpenSSL Script Log File Logins File OpenVPN VPN tunnel OpenVPN Obrázek 3.1: struktura aplikace její hlavní části Pro úplnost OpenVPN umožňuje zabezpečit komunikaci i předsdíleným statickým klíčem, který musí být přítomen na obou komunikujících stanicích. Ovšem tento způsob neumožňuje rozeznat klienty mezi sebou, tudíž je vhodný pouze pro point-to-point VPN. To je také důvod, proč předsdílený klíč zde nebude použit. Vytvoření a bezpečná vyměna certifikátů je kromě nastavení nejvetší problém pro většinu začínajících uživatelů programu OpenVPN. Bezpečnost je zde důležitá, protože na distribuci certifikátů pak záleží bezpečnost VPN sítě. Automatizace tohoto procesu pak skryje tento krok náročný na provedení před uživatelem a usnadní mu tak práci. Je nutné vybrat správný protokol, případně nástroj, který to je schopný zajistit. Zároveň by bylo dobré, kdyby bylo možné přenášet i nastavení VPN sítě ze serveru na klienta PKI PKI je infrastruktura veřejných klíčů, která by se zde mohla využít. Certifikáty by se mezi serverem a klientem mohly posílat v otevřené podobě pomocí znamých protokolů jako FTP (File Transfer Protocol), SCP (Secure Copy Protocol), RCP (Remote Copy Protocol),... Jestli je certifikát pravý se zjistí ověřením podpisu certifikátem důvěryhodné certifikační autority a autentizace se provede porovnáním identifikačních polí v certifikátu.

28 14 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Nevýhoda je, že všichni klienti i server musí mít své certifikáty podepsané důvěryhodnou certifikační autoritou, což je problém. Nelze předpokládat, že si každý zařídí takovýto certifikát. Proto v této aplikaci bude certifikační autoritou server a autentizace bude zaručena pomocí nějakého bezpečného protokolu. výhody: ideální řešení nevýhody: nelze zde použít IKE IKE (Internet Key Exchange) je protokol sloužící pro ustanovení bezpečnostní asociace používané IPSec. Používá framework pro autentizaci a výměnu klíčů ISAKMP (Internet Security Association and Key Management Protocol), části Oakley a SKEME (Secure Key Exchange Mechanism) [2]. Jedná se o komplexní protokol. Protokol IKE používá UDP port 500. Vzhledem k tomu, že během vytváření bezpečnostní asociace se přenáší veřejné klíče a mohou se přenášet certifikáty [3], by teoreticky šel protokol IKE z tohoto hlediska použít. Bohužel IKE je příliš svázáno s IPSec, nelze nebo je obtížné použít IKE samostatně, a byl by proto velký problém ho použít v této aplikaci. Neexistuje nebo alespoň mi není známa multiplatformní otevřená implementace IKE. Protokol je potřeba správně nakonfigurovat. Navíc klient nemá certifikát, dokud mu server nepodepíše žádost o certifikát, bylo by otázkou, jestli by šlo IKE pro toto použití nějakým způsobem ohnout a zda by to bylo ještě bezpečné. Existuje ještě IKEv2, které má různá vylepšení, existují i jeho implementace, ale z pohledu použití v dané aplikaci je na tom stejně jako původní IKE. výhody: komplexní protokol nevýhody: svázané s IPSec chybí multiplatformní implementace nastavování

29 3.4. AUTOMATICKÁ DISTRIBUCE CERTIFIKÁTŮ Kerberos Kerberos je protokol, který řeší autentizaci klienta a serveru přes nezabezpečený komunikační kanál. Klient žádá autentizační server o tiket, který v poslední fázi obsahuje kromě jiných informací časové razítko, čas expirace tiketu a klíč [15], který může být použit pro šifrování další komunikace. Existuje implementace Kerberos V5 pro volné použití vyvinutá na MIT. Verzi 4 tohoto protokolu už není vhodné používat, protože používá dnes již slabou šifru DES (Data Encryption Standard) [9]. Kerberos V5 běží standardně na portu 88. V UNIXových systémech existují standardní nástroje, které umí použít Kerberos a šifrovat komunikaci pomocí dohodnutého klíče např. program rcp, který by se mohl použít pro danou aplikaci. Bohužel verzi pro Windows, která by uměla totéž, jsem nenašel. Pro přenos certifikátů by pak bylo zapotřebí šifrovat data ručně a posílat je přes existující nebo vlastní protokol pro přenos souborů, otázkou je, zda by pak byla zaručena integrita dat. výhody: autentizace free multiplatformní implementace z MIT nevýhody: instalace a nastavování následný přenos dat SSL/TLS SSL (Secure Sockets Layer), respektive TLS (Transport Layer Security) používá Open- VPN pro zabezpečení svého kanálu. SSL/TLS umí ověřit identitu serveru a klienta na základě certifikátu, zde je ovšem stejný problém, který by měl řešit právě tento systém (podepsané certifikáty nejsou k dispozici). Protokol SSL/TLS by při výměně certifikátů zajišťoval šifrování komunikace symetrickou šifrou na základě hesla. Jsou zde dvě možné varianty. Použít program pro výměnu souborů založený např. na SFTP (Secure File Transfer Protocol), HTTPS (Hypertext Transfer Protocol Secure),... To by vyžadovalo najít a použít nějaké jednoduché implementace pro Windows a Linux. Bylo by ovšem nutné jimi podmínit použití celé aplikace. Druhá možnost je použít SSL/TLS přímo v kódu a jednoduché, takto šifrované, přenášení souborů si napsat sám. Např. knihovna Qt ve svém síťovém modulu nabízí třídu QSslSocket, která použití SSL/TLS usnadňuje. To je varianta, která mi příjde ze zatím uvedených nejvíce optimální. výhody: běžný způsob zabezpečení komunikace

30 16 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ Vlastní řešení Exchanger Vlastní řešení zahrnuje šifrování a integritu přenášených zpráv, definování informací, které se budou přenášet, způsob autentizace. Šifrování a integrita zpráv bude zajištěna knihovnou s kryptografickými funkcemi projektu OpenSSL. Bude použito silné šifrování AES (Advanced Encryption Standard) s délkou klíče 256 bitů v módu CBC (Cipher Block Chaining). Integrita bude zaručena integritním nepadělatelným kódem HMAC (Keyed-Hash Message Authentication Code), konkrétně HMAC SHA 1 [7]. Klient bude autentizován na základě jména a hesla. Z hesla bude odvozen klíč pro AES a HMAC. Jelikož pouze klient a server budou znát heslo, neměly by zprávy jít rozluštit ani pozměnit jiným subjektem. V rámci tohoto protokolu bude možné bezpečně přenášet certifikáty, žádosti o certifikát i nastavení VPN sítě. výhody: jednoduché řešení přímo pro konkrétní aplikaci nejsou potřeba další programy nevýhody: možnost chyby návrhu či implementace Vyhodnocení Bohužel využití PKI se společnou důvěryhodnou certifikační autoritou zrovna pro tento účel není možné. Ten, kdo by chtěl mít svoji VPN síť takto seriózní, pravděpodobně nebude ani potřebovat takovýto program pro pomoc s vytvořením VPN sítě. Nepočítá se s použitím programu v enterprise prostředí. Pro systém automatické distribuce certifikátů vyšlo IKE jako naprosto nevhodné. Ani by nebylo možné provést všechny potřebné kroky v rámci tohoto protokolu, natož použít nějakou implementaci IKE pro tento účel. Zpočátku se jevil jako dobrý nápad použití protokolu Kerberos. Kerberos jako takový by vyřešil autentizaci, ale zde by mohl být problém ve výměně potřebných informací. Dalším proti je potřeba nainstalovat a zkonfigurovat příslušný program, to by byla další zátěž pro uživatele. Vlastní protokol, který řeší šifrování a integritu po svém se může zdát jako bezpečnostní risk. Jedná se však o relativně jednoduchý protokol a bezpečnostní funkce, které zde budou použité, pakliže budou správně použité, zaručí bezpečnost porovnatelnou s mnohem komplexnějšími protokoly. Samozřejmě stejného a pravděpodobně i jistějšího výsledku by mohlo být dosaženo pomocí SSL/TLS vrstvy. SSL/TLS ale řeší mnoho dalších věcí, které se zde nevyužijí. Proto především pro názornost navrhnu kompletně vlastní protokol. SSL/TLS vrstva může být použita v dalších verzích aplikace.

31 3.5. ETHERNET BRIDGING Ethernet bridging Režim ethernet bridging se obtížněji zprovozňuje narozdíl od směrovaného režimu. Aby funkce aplikace byly konzistentní, je nezbytné, aby z uživatelova pohledu bylo jedno, jestli VPN síť pracuje na 2. nebo 3. vrstvě OSI (Open Systems Interconnection) modelu. Rozdíl ovšem je, že v režimu ethernet bridging funguje broadcastový provoz i protokoly jako IPX (Internetwork Packet Exchange). Tento režim používá na straně serveru síťový most, kterým přemostí TAP rozhraní a další virtuální či fyzická síťová rozhraní. Ovšem je zde problém, když se použije fyzické rozhraní používané pro přístup do sítě, zvláště sítě Internet, může to být bezpečnostní riziko a zároveň se pro očíslování sítě musí použít určitý adresní rozsah. Na Windows jsem vymyslel následující řešení tohoto problému, které nijak neomezuje uživatele v nastavení sítě VPN. TAP adaptér se přemostí spolu s virtuálním loopback adaptérem. Na síťovém mostu se nastaví libovolná adresa z nějakého privátního rozsahu a pomocí NAT (Network Address Translation) s přesměrováním portu VPN z rozhraní připojeného do Internetu na tento síťový most je možné tuto privátní síť zpřístupnit. V tomto bodě předpokládám, že nebude problém aplikovat stejné řešení na platformě Linux. Výcházím z toho, že NAT, loopback adaptér i síťový most zde existují.

32 18 KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ

33 Kapitola 4 Realizace 4.1 Použité technologie Program je napsán v jazyce C++, zejména kvůli autorově zkušenostem s tímto jazykem. Jako další aspekt tohoto výběru může sloužit velký počet šifrovacích knihoven (pro účely komunikačního protokolu), jednoduché volání API (Application Programming Interface) funkcí OS (nakonec nebylo tak úplně potřeba, ale je lepší mít tyto možnosti), dobrá přenositelnost kódu mezi platformami. Abych dodržel podmínku multiplatformnosti programu, použil jsem framework Qt. Vývoj probíhal na OS Microsoft Windows XP SP3 32-bit verze v prostředí Microsoft Visual Studio 2005 Standard Edition, které bylo zvoleno nejen kvůli dobré autorově zkušenosti s ním, ale kvůli formátu knihoven. Linker MSVC (Microsoft Visual C++) používá knihovny ve formátu.lib, ve kterém je dostupná většina zkompilovaných knihoven v aktuálních verzích, kdežto balík MinGW (konkrétně linker ld) používá knihovny ve formátu.a, formáty sice lze mezi sebou převést, ale zbytečně by se to tím mohlo zesložitit. Překlad a ladění na linuxové platformě probíhal v prostředí Qt Creator Návrh software, konkrétně UML (Unified Modeling Language) diagramy, jsem vytvářel v Microsoft Office Visio 2007, není to sice uznávaný CASE (Computer-Aided Software Engineering) nástroj, ale pro vizualizaci diagramů naprosto postačuje. Veškeré vytvořené diagramy jsou součástí elektronické přílohy této práce. Framework Qt ve verzi jsem překompiloval, protože není k dispozici zkompilovaná verze knihoven pro MSVC Existuje sice verze pro MSCV 2008, ale zde je hlavně problém v debug verzi knihoven, které jsou slinkovány s vyšší debug verzí MSVCRT (Microsoft Visual C++ Run-Time knihovny), která se distribuuje pouze s instalací MSVC Program z celého frameworku využívá pouze knihovny QtCore4 a QtGui4, respektive QtCored4 a QtGuid4. Jako knihovnu s bezpečnostními funkcemi jsem vybral prověřenou knihovnu crypto, která je mimojiné součástí programu OpenSSL, konkrétně libeay32 (Windows) a libcrypto (Linux). Dále ve verzi pro Windows používám technologii WMI, která je v kódu přístupná přes COM rozhraní. 19

34 20 KAPITOLA 4. REALIZACE 4.2 Protokol Exchanger Protokol, který bude zajišťovat automatickou distribuci certifikátů a parametrů sítě, je mojí vlastní záležitostí. Z hlediska logiky a toku dat jde o half-duplex v jednom okamžiku vždy jedna strana poslouchá a ta druhá vysílá. Lze jej tedy jednoduše popsat jako stavový automat. Je založen na protokolu TCP, který je spojově orientovaný a spolehlivý. Předpokládá se tedy, že data budou chodit ve formě datového proudu v pořadí a neduplikovaná. Na této vrstvě musí protokol detekovat ukončení spojení, chyby soketu způsobí okamžité ukončení spojení. Jelikož celá komunikace je jeden dlouhý datový proud, je potřeba nějakým způsobem oddělovat jednotlivé zprávy. Zároveň je nutné rozeznávat jednotlivé typy zpráv. K těmto účelům slouží hlavička, která se skládá z pole obsahujícího délku zprávy a pole pro její typ. Za hlavičkou je vlastní obsah zprávy a na konci zprávy je pole s kódem HMAC, viz obrázek 4.1. Stanice se ověřují jménem a heslem. Na serveru je úložiště, kde jsou dvojice jméno heslo pro všechny povolené klienty. Jméno se používá pro rozlišení klientů a vyběr správného hesla na straně serveru. Klíč pro zde použitou symetrickou blokovou šifru AES i nepadělatelný integritní kód HMAC se odvozuje z hesla a je pro obě funkce stejný. Konkrétně se pro odvození klíče použije hashovací funkce SHA 1 (Secure Hash Algorithm 1). Tady by možná mohl být bezpečnostní problém v takovémto odvození klíče, ale narozdíl od DES, AES nemá slabé klíče [6] Formát zprávy Protokol pracuje se zprávami, které mají předepsaný formát. Všechny části: hlavička, data a HMAC jsou přítomny ve všech zprávách. Formát zprávy je znázorněn na obrázku 4.1. Hlavička LENGTH Neznaménkové čtyřbajtové číslo v síťovém pořadí bajtů určující počet zbývajících bajtů zprávy za hlavičkou (součet počtu bajtů polí DATA a HMAC). TYPE Jeden bajt určující typ zprávy, respektive její obsah. DATA Vlastní obsah zprávy. Je to posloupnost bajtů proměnné délky. Obsah může být v otevřeném tvaru, nebo je šifrovaný. HMAC Za daty je přilepen nepadělatelný integritní kód HMAC SHA 1, má fixní velikost 20 bajtů. Kód vznikne z hlavičky a dat, tudíž hlavička a data jsou chráněny proti podvržení.

35 4.2. PROTOKOL EXCHANGER 21 LENGTH (4B) TYPE (1B) DATA HMAC (20B) Obrázek 4.1: formát zprávy protokolu Popis komunikace Komunikace tímto protokolem probíhá mezi klientem a serverem. Celý proces je rozdělen do několika kroků, v každém kroku se komunikuje vždy jen jedním směrem jedna stanice vysílá, druhá přijímá. Které zprávy a jakým směrem jsou posílány, je popsáno na obrázku 4.2. Během procesu mohou nastat různé chyby (ukončené spojení, chyba soketu, chyba při čtení souboru, neplatná zpráva,...) Když nějaká chyba nastane, spojení je ukončeno stranou, která chybu detekovala. Jednotlivé kroky jsou rozepsány dále z pohledu klienta a serveru. Jednotlivé stavy na straně klienta ilustruje obrázek 4.3 a na straně serveru to je obrázek 4.4. Krok 1 Klient iniciuje TCP spojení se serverem. Poté klient pošle zprávu, kde data obsahují nezašifrované jméno klienta. Klient čeká, dokud není celá zpráva odeslána (to zjistí od nižší vrstvy soketu), než přejde do dalšího kroku. To je z důvodu, aby se komunikace nezasekla, kdy druhá strana čeká na konec zprávy, zatímco ta první čeká na zprávu v dalším kroku. Na druhé straně server očekává zprávu se správně nastaveným typem, přečte jméno klienta a zjistí, zda je jméno definované na serveru. V případě, že je jméno definováno, použije přidružené heslo pro další komunikaci a přejde do další fáze. Jinak server ukončí spojení. Krok 2 Server pošle zprávu s určitými parametry sítě VPN, které jsou potřeba pro úspěšné připojení k VPN serveru. Tyto parametry se serializují a tato data jsou již před odesláním

36 22 KAPITOLA 4. REALIZACE šifrována, protože obě stanice již znají klíč, který mají použít. Než přejde do další fáze, ujistí se, že celá zpráva byla odeslána. Klient přijímá zprávu s parametry. Když ji celou přečte, spočítá HMAC hlavičky a dat a porovná ho s HMAC, který přišel se zprávou. Jestliže se liší, druhá strana nepoužila stejný klíč, nebo byla zpráva změněna komunikace bude ukončena. Následuje rozšifrování dat a načtení parametrů do nastavení klienta. Klient přejde k dalšímu kroku, zde je klient jistý, že komunikuje se správným serverem. Krok 3 Klient pošle žádost o certifikát CSR (Certificate Signing Request), předtím ho případně ještě vygeneruje společně s privátním klíčem. Zase se ujistí, že zpráva byla poslána než přejde k dalšímu kroku. Zde může nastat chyba, kdy nelze přečíst nebo vygenerovat soubor se žádostí o certifikát ukončení komunikace. Server přijímá zprávu se žádostí o certifikát. Jestliže HMAC u zprávy souhlasí, ví i server, že komunikuje se správným klientem. Server musí žádost podepsat certifikační autoritou CA (Certificate Authority). Zde může nastat chyba, kdy se žádost nepodaří podepsat, to má za následek ukončení komunikace, jinak vznikne certifikát CRT (Certificate) a server přejde do následujicí fáze. Krok 4 Server pošle certifikát certifikační autority CA CRT, aby klient mohl ověřit pravost certifikátu serveru. Jako pokaždé se ujistí, že zpráva byla poslána než přejde k dalšímu kroku. Zde by neměl nastat problém, ale v případě, že se nepodaří načíst soubor CA CRT, spojení se ukončí. Klient přijímá zprávu obsahující CA CRT, u které nejdříve zkontroluje HMAC, poté rozšifruje, uloží soubor na disk a přejde k dalšímu kroku. Krok 5 V posledním kroku server pošle certifikát klienta CRT, platí totéž co v předchozím kroku. Poté, co je celá zpráva odeslána, začne server ukončovat spojení. Klient očekává zprávu s CRT, stále se kontroluje HMAC, data se rozšifrují a jako v předchozím kroku se CRT uloží na disk. Klient začne také ukončovat spojení. Spojení na obou stranách bude uzavřeno a celý proces končí. 4.3 Problémy Při implementaci aplikace se vyskytly nějaké potíže, s některými nebylo těžké se vypořádat, jiné přetrvaly. Zde bych rozebral ty nejzásadnější Multiplatformnost Z toho, jestli bude kód aplikace přenositelný a bude fungovat stejně na obou platformách, jsem měl největší obavy. S použitým frameworkem Qt jsem neměl žádné zkušenosti. Místo síťového modulu Qt jsem použil sokety, které se chovají na obou platformách stejně, což jsem měl už vyzkoušené. Nakonec s překladem programu na obou platformách nebyl žádný problém.

37 4.3. PROBLÉMY 23 Dalším aspektem přenositelnosti celého řešení je propojení s dalšími programy. To je zde realizováno pomocí skriptů, jednotlivé interprety příkazové řádky nejsou stejně mocné (cmd neumí tolik funkcí jako bash), v tom ale problém nebyl, ve Windows nebylo pokročilé funkce potřeba. Program OpenSSL je na obou platformách shodný (nebo alespoň použité funkce se chovají stejně). Znatelná odchylka nastala až ve zprovoznění režimu ethernet bridging programu OpenVPN. Způsob, který funguje na Windows (síťový most, loopback adaptér a NAT), na Linuxu nefunguje, což jsem nepředpokládal. Nelze přidat loopback rozhraní do síťového mostu, to je problém, protože aby toto řešení fungovalo, musí být kromě TAP rozhraní přemostěno další rozhraní. Další takové rozhraní není obyčejně dostupné. Naštěstí zde funguje přímé použití bez síťového mostu. Je stále nutné použít NAT Kódování řetězců Největší problém, na který jsem narazil je kódování řetězců. Qt nabízí třídu pro řetězce QString, která umí pracovat v UNICODE, převádět mezi různým typem kódování např. ASCII (American Standard Code for Information Interchange), UTF 8, UTF 16, UCS 4 (Universal Character Set),... Takže v rámci stejného programu není s řetězci žádný problém. Obyčejně bych UNICODE nepoužíval v takovéto aplikaci. Aplikace ale musí spolupracovat s dalšími programy, předávat jim parametry. Některé z těchto parametrů musí být v UNICODE, zejména pak na platformě Windows, kde se používá pro názvy souborů a adresářů, ale i síťových rozhraní. Parametry je potřeba ukládat do souborů, to ovšem není přiliš velký problém s použitím UTF 8, stejným způsobem se přenáší řetezce přes síť Exchanger protokolem. Programy jsou zde volány pomocí skriptů, které se spouští v interpretu příkazové řádky (ve Windows to je cmd, na Linuxu to je bash). Všechny potřebné parametry se předávají jako argumenty skriptu. Interpret je spuštěn v novém procesu vytvořeném pomocí třídy QProcess. QProcess vezme argumenty předané v programu, kde jsou reprezentovány pomocí QString, a předá je API funkcím v kódování podle dané platformy. Zde nastává ten největší problém. Skriptům spouštěným na platformě Windows se argumenty předají v UTF 16, zatímco na platformě Linux podle nastavených lokále. Programy, které slouží pouze dané platformě (mkdir, netsh,...), očekávají vstup v daném kódovaní. Problém nastává hlavně s programem OpenSSL, který očekává jako vstup ASCII řetězec, nebo při použití přepínače -utf8 řetězec kódovaný v UTF 8 nelze tedy přímo použít UTF 16 řetězce. Ve Windows se tedy pro argumenty skriptů místo UNICODE použije mechanismus kódových stránek [11]. Protože certifikáty vytvořené OpenSSL se posílají mezi stanicemi, kde mohou být rozdílné platformy, lokále či kódové stránky (CP852 CP1250, CP1252,...), může docházet v souvislosti s tímto k potížím. Nejjednodušším řešením problému je používat pouze znaky ASCII pro parametry, které s tímto souvisí. Jedná se zejména o tyto parametry: název sítě, jméno klienta, kód země, jméno města. Zatím se jedná pouze o doporučení, není to v aplikaci nijak zakázáno. Je možné, že v dalších verzích se podaří problém odstanit převedením určitých argumentů skriptu na UTF 8.

38 24 KAPITOLA 4. REALIZACE 4.4 Licence Důležitou otázkou při vyvýjení software je, pod jakou licencí uvolnit své dílo. Bohužel tento aspekt je leckdy opomíjen. Podle mého názoru to je tím, že studenti se ve škole učí díla vytvářet, ale už ne, jak s nimi dále nakládat, chránit je, využívat díla jiných autorů,... Každopádně tento software vyvýjím, aby sloužil co nejvíce uživatelům. Nemám v úmyslu poskytovat tento software exklusivně žádnému dalšímu subjektu. Neočekávám žádné finanční příjmy z této aktivity, proto chci, aby byl software dostupný všem zcela zdarma. Ještě bych dodal, že chci zveřejnit zdrojový kód hlavně z důvodu, aby si každý mohl ověřit, že se software nesnaží úmyslně poškodit jeho uživatele, dále aby případně mohl zdrojový kód posloužit ke vzdělávacím účelům. Software tedy bude tzv. open source. Protože software používá knihovny jiných autorů jedná se o framework Qt, který je distribuován pod LGPL (Lesser General Public License), dále knihovnu OpenSSL, která je distribuovaná pod duální Apache style licencí. Tyto skutečnosti omezují možnosti, jakou použít pro svoje dílo licenci. LGPL říká, že odvozené dílo musí použít stejnou licenci (tedy LGPL), je zde však možnost použití jiné i nesvobodné licence v případě, že se nejedná o odvozené dílo, ale pouze o práci, která používá knihovnu. Ovšem zde se názory, co je to či ono, liší. Abych se vyhnul podobným nejednoznačnostem ve svém software, použiji licenci GPL, se kterou je LGPL kompatibilní [1]. Pro knihovnu OpenSSL, která se přilinkovává, musím uvést výjimku, protože není pod licencí kompatibilní s GPL (GPL toto umožňuje). Další omezení přidává vývojové prostředí (Microsoft Visual Studio 2005 Standard Edition), které jsem použil a které mi bylo poskytnuto s akademickou licencí. Zde je omezení, že se nesmí použít ke komerčním účelům [12]. Samotná GPL licence toto nezaručuje, je možné takto šířené programy komerčně prodávat, ale jelikož budu software poskytovat zdarma pomocí Internetu, věřím, že i tato podmínka bude splněna.

39 4.4. LICENCE 25 Network CLIENT NAME open form EXCHANGER CLIENT PARAMETERS encrypted CLIENT CSR encrypted CA CRT encrypted EXCHANGER SERVER CLIENT CRT encrypted Obrázek 4.2: fungování protokolu pro distribuci certifikátů a parametrů

40 26 KAPITOLA 4. REALIZACE Sending name sended Receiving parameters received Generating key pair succeeded socket error Sending CSR error sended error Receiving CA CRT socket error error received error Receiving CRT socket error error received Disconnecting socket disconnected Disconnected Obrázek 4.3: stavový diagram protokolu na straně klienta

41 4.4. LICENCE 27 Receiving name received Sending parameters sended Receiving CSR socket error received error Signing CSR socket error succeeded error Sending CA CRT error sended error Sending CRT error sended Disconnecting socket disconnected Disconnected Obrázek 4.4: stavový diagram protokolu na straně serveru

42 28 KAPITOLA 4. REALIZACE

43 Kapitola 5 Testování Testování je velice důležitá část vývoje každého software i jiných činností. Jedná se o proces, kdy se testovaný program spouští s úmyslem najít chyby a ověřit jeho kvalitu. Kvalitou se rozumí míra splnění požadavků kladených na daný software. Jsou to požadavky sepsané podle prání a potřeb zákazníka, stejně tak požadavky, které nemusí být nikde uvedeny, ale jsou předpokládány např. stabilita programu, žádné nežádoucí postranní efekty (trojské koně, malware), Zaměření testování Testování je samo o sobě časově nákladnou činností. Svědčí o tom i poměr testerů k vývojářům. Ten je nejčastěji 1:3 podle průzkumu QAI s 20th Annual Software Testing Conference ze září roku 2000 [16]. Podle uvedeného poměru bych měl mít k dispozici třetinu testera, proto nemůžu věnovat testování tolik času, kolik by bylo potřeba, stejně nikdy nelze otestovat všechno. Navíc podle Pareto principu 20% příčin způsobí 80% defektů [10]. Je absolutně nezbytné vybrat jen malou množinu testů, která pokryje co nejlépe, co možná nejvíce těch nejdůležitějsích částí software. Vybral jsem následující části, jsou v seřazeny podle jejich závažnosti (severity): konzistence programu komunikační protokol multiplatformnost Konzistence programu Testování konzistence programu bude spočívat v testování GUI, čili jeho tzv. oklikáním, podle určitých scénářů. Kromě pozorování změn v GUI (řetězce v polích, stavy tlačítek, chování při změně velikosti okna,...) se budou také sledovat případné změny v souborech, které program vytváří (změny v konfiguračních souborech, chybějící/přebývající soubory,...). 29

44 30 KAPITOLA 5. TESTOVÁNÍ Důležitou otázkou je, zda se tyto testy budou provádět manuálně či by se neměly automatizovat. Využití automatizace testů bych viděl při regresních testech, ale vzhledem k tomu, že pro automatické testování GUI je nutný speciální nástroj např. IBM Rational Robot a tvorba skriptů + jejich údržba jsou časově náročné, bude se testování GUI provádět manuálně. Avšak pro kontrolu stavu souborů lze případně vytvořit relativně jednoduché skripty, které kontrolu usnadní. Tímto způsobem testovaný program bude sledován nástrojem pro testování správy paměti např. program IBM Rational PurifyPlus nebo Valgrind. Toto je důležité u tzv. unmanaged kódu, což je tento případ. Lze tak odhalit případné memory leaks, které mohou kromě paměťové efektivity negativně ovlivnit stabilitu programu. V souvislosti s těmito testy by mohla být otestována efektivita kódu a provedena kontrola pokrytí kódu aplikace. Pro oba tyto testy je potřeba potřeba aplikaci spustit ve speciálním programu. První zmíněný test by mohl být proveden např. v programu IBM Rational Quantify jehož výstupem je graf volání funkcí s vyznačením těch funkcí, ve kterých se strávilo nejvíce času. Na jeho základě by se tak odhalit potenciální bottleneck, kdy program zbytečně dlouho čeká, i když by nemusel, či deadlock, kdy některé vlákno uvízne v některé funkci až do konce programu. Takto program otestovat je rozhodně dobré pro ověření stability (odhalení deadlock), případně následnou optimalizaci kódu (hledání bottleneck). Ke kontrole pokrytí kódu aplikace slouží např. program IBM Rational PureCoverage. Výstup z takovéhoto typu programu je schopen vyjádřit, kolikrát byla jaká funkce za celou dobu běhu testovaného programu volána, přesně kolik řádků funkce bylo vykonáno a na základě toho lze najít kód, který není nikdy vykonán. Tento test se používá nejčastěji v kombinaci s jednotkovými testy a kontroluje se tak jejich pokrytí. Avšak pro tento případ by připadalo v úvahu použití, kdy by se kód na základě tohoto testu optimalizoval. Zejména z časových důvodů toto ale provádět nehodlám Komunikační protokol K otestování funkčnosti komunikačního protokolu bude za potřebí alespoň dvou instancí testovaného programu, jedna bude nastavená jako server, druhá jako klient. Jelikož komunikační protokol používá TCP sockety, je potřeba ověřit správné navázání a ukončení každého spojení. Dále je třeba kontrolovat data, která chodí navázaným komunikačním kanálem. K tomuto účelu se nejlépe hodí síťový analyzátor Wireshark, který umožňuje sledovat TCP stream. Komunikační protokol musí fungovat za normálních provozních podmínek, musí být ovšem také odolný vůči chybám i záměrným útokům. Jelikož všechna data kromě paketu se jménem jsou šifrována a celý paket je chráněný proti přepsání nepadělatelným integritním kódem HMAC, budou útoky spočívat ve změně hlavičky, konkrétně prvních čtyř bajtů, které obsahují délku paketu za hlavičkou. Lze tak zapříčinit, že nebude možno sestavit paket z datového proudu správně.