Možnosti šifrované komunikace v prostředí MS Windows 7

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Možnosti šifrované komunikace v prostředí MS Windows 7 BAKALÁŘSKÁ PRÁCE Stanislav Špaček Brno, jaro 2014

2 Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal a nebo z nich čerpal, v práci cituji s uvedením úplného odkazu na příslušný zdroj.

3 Poděkování Tímto bych chtěl poděkovat RNDr. Marku Kumpoštovi, PhD. za vedení mé bakalářské práce. Zároveň děkuji Mgr. Karolovi Kubandovi za jeho rady, čas věnovaný konzultacím a pomoci při vypracování praktické části.

4 Shrnutí Cílem práce je prozkoumání, porovnání a doporučení možností šifrovaného VPN spojení pomocí protokolů nativně podporovaných operačním systémem Microsoft Windows 7. První část práce se zabývá autentizačními a kryptografickými algoritmy, nezbytnými k ustavení zabezpečeného spojení k privátní síti. Druhá část se podrobněji věnuje popisu VPN protokolů z hlediska zabezpečení, průchodnosti přenosovou sítí a míře podpory na zařízeních s odlišným operačním systémem. Třetí a poslední část práce je pak věnována konfiguraci serveru s operačním systémem FreeBSD tak, aby bylo možné připojit se k němu postupně pomocí všech VPN protokolů podporovaných ve Windows 7. Annotation The aim of this bachelor's thesis is examination, comparation and recommendation of a VPN connection using protocols natively supported by operating system Microsoft Windows 7. The first part of this thesis deals with authentication and cryptographic algorithms necessary to establish a secure connection to a private network. The second part is focused on the description of VPN protocols in terms of security, throughpuu of the interlaced network and the level of support on devices with an operating system different from Windows 7. The third and final part is devoted to configuration of a server running FreeBSD so that it can be connected to by a client, using all VPN protocols supported by Windows 7.

5 Klíčová slova autentizace, FreeBSD, IKEv2, L2TP, PPTP, SSTP, šifrování, VPN, Windows 7 Keywords authentication, encryption, FreeBSD, IKEv2, L2TP, PPTP, SSTP, VPN, Windows 7

6 Obsah Úvod Autentizační a šifrovací protokoly Autentizační protokoly Password Authentication Protocol Microsoft Challenge-Handshake Authentication Protocol Microsoft Challenge-Handshake Authentication Protocol v Internet Key Exchange v Šifrovací protokoly Microsoft Point-To-Point Encryption Protocol IP Security Secure Socket Layer/ Transport Layer Security VPN protokoly podporované Windows PPTP, Point-to-Point Tunneling Protocol L2TP, Layer 2 Tunneling Protocol SSTP, Secure Socket Tunneling Protocol IKEv2, Internet Key Exchange v Srovnání VPN protokolů Konfigurace serveru a klienta PPTP Server Klient Výsledek L2TP Server Klient Výsledek SSTP Server Klient Výsledek IKEv Server

7 3.4.2 Klient Výsledek Závěr Slovník zkratek Literatura a zdroje Příloha A, Konfigurační soubory PPTP Příloha B, Konfigurační soubory L2TP Příloha C, Konfigurační soubory SSTP Příloha D, Konfigurační soubory IKEv

8 Úvod Virtuální privátní síť, neboli VPN, nalézá v současné době mnoho různých využití. Soukromé, kde může sloužit pro vzdálený přístup do domácí sítě z jakéhokoli místa s přístupem k Internetu, i komerční. V komerční sféře značně zjednodušuje práci ve chvíli, kdy je potřeba zabezpečená komunikace mezi více různými pobočkami jedné společnosti. Vytvoření virtuální sítě v tomto případě poskytuje alternativu k položení fyzické sítě mezi pobočkami, což je řešení jak finančně, tak administrativně náročné a mnohdy úplně nemožné. Správně konfigurovaná virtuální privátní síť by měla být ekvivalentní lokální síti. Měla by umožňovat využití veškerých dat, zařízení a jiných služeb k ní připojených bez ohledu na to, kde se fyzicky nachází. V případě přístupu ke zdroji ve stejném fyzickém segmentu virtuální sítě probíhá komunikace stejně jako by probíhala po síti místní. Pokud je ovšem vyžadován přístup ke zdroji v jiném segmentu, musí se server vypořádat s přenosem soukromých dat přes veřejně dostupnou síť. Během něj je prioritou zajištění autentizace a dostatečné úrovně zašifrování přenosu při zachování co nejvyšší přenosové rychlosti tak, aby byla pokud možno zachována iluze přímého lokálního spojení. Práce se věnuje využití virtuálních privátních sítí v prostředí Windows 7, s nímž se lze na uživatelských zařízeních setkat nejčastěji. Tento operační systém funkčně nahradil oblíbený systém Windows XP, jehož podpora skončila v dubnu Protože Windows 8 zatím nepřináší natolik zásadní inovace, aby se k němu vyplatilo přejít soukromým uživatelům a firmám, zůstává systém Windows 7 nejpoužívanějším operačním systémem na trhu. Oproti tomu v komerční sféře se lze stále častěji setkat s využitím open-source softwaru, který není zatížen žádnými licenčními poplatky. V oblasti operačních systémů jsou často využity systémy postavené na jádru Unix, jako například FreeBSD. Praktická část této práce počítá právě s využitím systému FreeBSD jako VPN serveru. První a druhá kapitola práce se zabývá VPN protokoly z teoretického hlediska. Autentizační a šifrovací algoritmy popsané v první kapitole zajišťují autenticitu, integritu a důvěrnost dat během jejich přenosu veřejnou sítí. Bez těchto vlastností by existence VPN postrádala smyslu a proto mají pro její funkci zásadní význam. Při popisu algoritmů je věnována pozornost jejich již známým zranitelným místům a slabinám vůči některým typům útoků. Druhá kapitola pak obsahuje popis protokolů pro ustavení virtuální privátní sítě dostupných ve Windows 7. Zabývá se jimi z hlediska využití autentizačních a šifrovacích algoritmů, zmíněných v první kapitole, a rozebírá vlastnosti přenosové sítě, vyžadované pro jejich provoz. Třetí kapitola navazuje na předchozí dvě předvedením VPN protokolů v praxi. Obsahuje návody na konfiguraci serveru založeného na operačním systému FreeBSD tak, aby bylo možné připojit se k němu ze vzdálených klientských Windows 7 počítačů. Postup je vždy rozdělen na části konfigurace serveru, konfigurace klienta a na část dosaženého výsledku. Poslední jmenovaná část hodnotí vždy náročnost zprovoznění protokolu a případné nedostatky vzniklé chybějící dokumentací či špatnou kompatibilitou. Závěr práce shrnuje teoretické vlastnosti protokolů a konfrontuje je s výsledky dosaženými při provozu v praktické části. Obsahuje zhodnocení protokolů na základě jejich sledovaných vlastností a doporučení odpovídajícího řešení pro různé typy VPN. 3

9 Téma této bakalářské práce bylo vypsáno ve spolupráci s firmou Trusted Network Solutions, která se zabývá poradenstvím v oblasti bezpečnosti síťových spojení a vývojem softwaru zajišťujícího odolnost proti útokům zvenčí pro firemní sítě i jednotlivé uživatele. 4

10 1. Autentizační a šifrovací protokoly Pro správnou interpretaci všech bezpečnostních vlastností a funkcí, které musí být součástí každého VPN protokolu, se první kapitola věnuje autentizaci a šifrování. Různé protokoly VPN totiž podporují odlišné bezpečnostní algoritmy a jejich pochopení značně ulehčí porozumění problematice ustavení VPN spojení. Všechny následující bezpečnostní protokoly jsou součástí některého protokolu VPN. 1.1 Autentizační protokoly Protokoly náležící do této kapitoly zajišťují ověření identity účastníků zabezpečeného spojení. Často je také jejich výstupem klíč, od kterého se odvozují podřazené klíče k pozdějšímu zašifrování komunikace. V případě neprovedení procesu autentizace by se za klienta s povolením přístupu do sítě mohl vydávat kdokoliv, což by de facto zničilo koncept privátní sítě. Protože řada útoků cílí právě na přisvojení si identity uživatele s oprávněním přístupu jako na cíl jednodušší, než přímé prolamování šifry spojení, neměl by být výběr autentizačního protokolu nikterak podceněn. Následující výčet představuje protokoly obsažené ve vestavěném VPN klientském softwaru Windows 7. Protože není cílem této práce podrobně se věnovat autentizačním algoritmům, jejich popis se omezuje na postup samotné autentizace a zmínění zranitelností vůči různým typům útoku. Podrobnější informace lze získat v některé z dostupných publikací [1] Password Authentication Protocol Základní verze autentizačního algoritmu, kterou je možné použít v protokolech založených na PPP, jako PPTP, L2TP a SSTP. Poskytuje pouze tu nejslabší formu ověření identity, kdy klient odesílá své identifikační údaje přenosovou sítí jako čistý, nijak nešifrovaný, text [2]. V prvním kroku autentizace klient pošle serveru žádost o spojení obsahující své jméno a heslo. Server tyto údaje ověří a odpoví v druhém kroku potvrzením či zamítnutím spojení. Na první pohled viditelnou slabinou takového postupu je možnost přečtení všech přihlašovacích údajů z odchyceného paketu klienta. Útočníkovi pak již nic nebrání tyto údaje zneužít a převzít identitu a oprávnění postiženého uživatele. Jedinou výhodou protokolu jsou snad jen zanedbatelné nároky na výpočetní výkon. Využití se omezuje na situace, kdy není dostupné řešení ve formě jiného protokolu Microsoft Challenge-Handshake Authentication Protocol Tento protokol byl vydán Microsoftem jako náhrada předchozího PAP v situacích vyžadujících určitou míru jistoty o totožnosti autentizovaného. Princip ověření spočívá v systému výzva-odpověď (challenge-response) [3]. Poskytuje autentizaci klient-server pro síťové služby systémů Microsoft Windows, mezi které patří i spojení PPTP, L2TP a SSTP. Vznikl modifikací algoritmu CHAP a používá velmi podobnou strukturu zpráv: 5

11 Obrázek 1 Schéma operací protokolu MsCHAP Každá MsCHAP zpráva má rozměr přesně jednoho PPP paketu a obsahuje následující položky: typ zprávy, identifikátor, délku zprávy a data. Povoleny jsou čtyři typy zprávy Challenge, Response, Success a Failure. Identifikátor k sobě jednoznačně přiřazuje zprávy typu Challenge a Response. Klient nejprve kontaktuje server se zájmem o spojení. Server odpovídá zprávou Challenge, která nese jako data náhodný řetězec znaků dlouhý 8 bytů. Klient pak spočítá 24B odpověď provedením funkce LANMAN nad obdrženým řetězcem, s využitím sdíleného hesla [4]. Poté hashuje řetězec ještě jednou funkcí MD4, opět za použití stejného hesla. Serveru odesílá dvě zprávy, jednu s výsledkem LANMAN, druhou s výsledkem MD4. Server porovná hashe získané od klienta se svými, pokud se alespoň jeden z nich shoduje, odpovídá zprávou typu Success, v opačném případě zprávou typu Failure. Tento postup může být v průběhu spojení opakován v libovolných intervalech. Slabinou protokolu je v první řadě užití funkce LANMAN, ke které se po zjištění fundamentálních bezpečnostních vad pouze přidala MD4, z důvodu zachování zpětné kompatibility. Heslo je při zpracování vždy převedeno do upper-case, takže pokud nemá dostatečnou délku a nepoužívá speciální symboly, stává se velice zranitelné slovníkovými útoky a útoky hrubou silou [5]. Druhý bezpečnostní problém se skrývá ve funkci MD4, jež je náchylná k útoku kolizí (collision attack) [6]. Ten spočívá v nalezení různých řetězců takových, aby MD4(řetězec1) = MD4(řetězec2). Jako poslední vadu bych zmínil spoléhání se na jedinou utajenou informaci sdílené heslo. Všechny ostatní, jako například uživatelské jméno, jsou posílány mezi serverem a klientem nezašifrované. Případný útok tak stačí cílit výhradně na jediný šifrovaný údaj. Jako důsledek těchto snadno zneužitelných vad protokolu není jeho užití k autentizaci doporučeno. 6

12 1.1.3 Microsoft Challenge-Handshake Authentication Protocol v2 Protokol MsCHAPv2 měl plně nahradit MsCHAP poté, co v něm byly odhaleny zásadní bezpečnostní chyby designu. Slabiny předchůdce opravuje zejména následujícími změnami: 1. Hash funkce LANMAN není nadále podporována a již není obsahem autentizačních zpráv. K funkci MD4 se místo ní přidává SHA1. 2. Jedinou autentizační výměnou dojde k ověření totožnosti serveru i klienta. Protokol MsCHAP vyžadoval provést handshake klient-server a poté server-klient. 3. Pro šifrování odchozích a dešifrování příchozích dat jsou použity různé klíče. Vyjmenované změny si vyžádaly změnu schématu výměny zpráv mezi serverem a klientem. Některé prováděné hashovací operace ale lze vyhodnotit jako zbytečné, či alespoň zbytečně složité. Postup výměny autentizačních zpráv a kroky prováděné samostatně jednotlivými stanicemi proto přehledněji popisuje následující seznam operací a obrázek. Obrázek 2 Schéma operací protokolu MsCHAPv2 1. Klient kontaktuje server s žádostí o spojení. 2. Server odpovídá náhodným 16B řetězcem ServerChallenge. 3. Klient vygeneruje vlastní 16B náhodný řetězec ClientChallenge. 4. Klient vygeneruje 8B ChallengeHash ze ServerChallenge, ClientChallenge a uživatelského jména. 5. Klient spočítá MD4 hash sdíleného hesla NTHash. 6. Klient vytvoří 24B ChallengeResponse z ChallengeHash za použití hesla uživatele v hashované podobě. Heslo je, stejně jako u MsCHAP, zarovnáno na 21 B a rozděleno na 3 klíče. 7

13 7. Výsledná odpověď serveru sestává z ChallengeResponse, ClientChallenge a uživatelského jména. 8. Server za pomoci sdíleného hesla ověří obsah odpovědi a pokud se shoduje s jeho výpočtem, klient je autentizovaný. 9. Server se klientu autentizuje zprávou obsahující hash ClientChallenge vytvořený pomocí hashe sdíleného hesla a dvou konstantních textových řetězců. Zejména postup v kroku 9, kde server počítá dvakrát za sebou SHA1 hash demonstruje zbytečné využití výpočetního výkonu a de facto zpomaluje celý autentizační proces. Stejně tak sporný přínos má přidání magických konstant "Magic server to client constant" a "Pad to make it do more than one iteration" na konec hashovaných řetězců [7]. Protokol MsCHAPv2 se, přes svou neefektivní konstrukci, dal považovat za bezpečný, pokud bylo zvoleno dostatečně silné heslo, přestože stále jako jeho předchůdce spoléhal pouze na utajení sdíleného hesla. Na bezpečnostní konferenci Defcon v červenci roku 2012 bezpečnostní expert Moxie Marlinspike představil postup značně snižující odolnost proti útoku hrubou silou. Tento postup popsal o něco později v článku na serveru cloudcracker.com [8]. Marlinspike ukazuje, jak využít útok typu divide-and-conquer na tři DES klíče, které vznikly rozdělením hashe sdíleného hesla. Zatímco čistý bruteforce attack na hash by měl složitost přibližně 2 128, útok divide-and-conquer ji snižuje na součet ( ). Ještě mnohem lepšího účinku lze dosáhnout, pokud útočník využije faktu, že třetí klíč je efektivně pouze dva znaky dlouhý, zbylé byly doplněny nulami. Po zjištění této části klíče zbývá 14 B posledních dvou a za použití algoritmu prezentovaného Marlinspikem se složitost snižuje až na pouhých 2 56, což odpovídá jedné úrovni šifrování DES. Marlinspike dále poskytuje nástroje nezbytné k prolomení této šifry v čase kratším než 24 hodin. V současnosti jsou tedy veřejnosti dostupné nástroje, které umí prolomit autentizaci MsCHAPv2 ve velice krátkém čase. Jeho použití je nadále doporučeno Microsoftem pouze v kombinaci s protokolem PEAP [9] Internet Key Exchange v2 Poznámka: Tato podkapitola se věnuje pouze průběhu ustavení SA 1. Informace o VPN protokolu se stejným názvem naleznete v druhé kapitole. Posledním z řady čistě autentizačních protokolů je IKEv2 [10]. Zajišťuje ustavení bezpečnostního přiřazení (SA) mezi dvěma stanicemi výběr šifrovacího protokolu a dohodnutí klíčů pro další komunikaci. Princip protokolu vychází z předchozího IKE, oproti němu ale představuje několik vylepšení. 1. Sjednocuje původně několik dokumentů RFC se specifikacemi IKE do jediného. 2. Snižuje počet vyměněných zpráv při autentizaci z devíti na čtyři zprávy ve dvou fázích IKE_SA_INIT a IKE_AUTH. 1 Z anglického výrazu Security Association bezpečnostní přiřazení. Označuje souhrn bezpečnostních atributů a algoritmů, na nichž je postavena chráněná komunikace mezi dvěma stanicemi. 8

14 3. Obsahuje funkci Dead Peer Detection, která povoluje zrušit ustanovenou SA, pokud klient neodpovídá. 4. Lze povolit obranu proti DoS útokům pomocí cookie zpráv. Obrázek 3 Výměna zpráv IKEv2 Schéma zpráv na obrázku ilustruje průběh ustavení SA. První výměna obsahuje seznam podporovaných šifrovacích algoritmů, pole s hodnotou Diffie-Hellman výměny klíčů a tzv. nonce náhodný řetězec párující k sobě dvojice request/response, zajišťující ochranu proti útokům přehráním (replay attack). Pokud je využita funkce obrany proti DoS útokům, může si server vyžádat od klient potvrzení zasláním zprávy obsahující tzv. cookie opět náhodně vygenerovaný řetězec. Pokud jej klient odešle zpět, potvrdí tím, že nejen zasílá žádosti o spojení, ale rovněž i čeká na odpověď. Druhá fáze již probíhá v zašifrované podobě a zprávy nesou autentizační informace stanic. Ověření totožnosti může proběhnout pomocí certifikátu nebo PSK. Zároveň tyto zprávy vytvoří pomocí identifikátorů podřízené šifrované spojení, tzv. CHILD_SA, po kterém bude probíhat přenos dat mezi stanicemi. Toto podřízené spojení bývá zpravidla zašifrováno dle protokolu IPsec. Nespornou výhodou protokolu IKEv2 je zašifrování celé komunikace ihned po výměně prvních dvou zpráv. Žádné autentizační informace díky tomu nejsou posílány ve formě plain textu a nedají se zjistit prostým odposlechem. Útokům man-in-the-middle lze do jisté míry odolat s využitím oboustranné autentizace ověřením náplně Auth ve třetí a čtvrté zprávě a replay útokům zamezuje použití identifikátoru zprávy (nonce). IKEv2 ve výsledku poskytuje zdaleka nejvyšší úroveň bezpečnosti autentizace ze všech tří představených protokolů. 1.2 Šifrovací protokoly Pokud klient úspěšně projde fází autentizace, vyvstává potřeba zabezpečit přenos dat mezi ním a zbytkem soukromé sítě proti zachycení a přečtení útočníkem. Protože datový paket může cestou veřejnou sítí odchytit téměř kdokoliv, důvěrnost dat je nutné zachovat jejich převedením do formy čitelné pouze adresátu. Tuto funkci zajišťují kryptografické protokoly, 9

15 šifrující data podle klíče známého pouze koncovým stanicím, obvykle některou ze symetrických blokových šifer. Následující protokoly poskytují důvěrnost dat přenášených v rámci virtuální privátní sítě. Kromě prvního jmenovaného, MPPE, mohou poskytnout i funkci autentizace před začátkem přenosu. V rámci VPN protokolů jsou ale často použité v kombinaci s některým z autentizačních algoritmů. Protože si tato práce neklade za cíl podrobně analyzovat procesy šifrování dat, je tento postup popsán u složitějších protokolů pouze povrchně, s důrazem na případné zranitelnosti vůči útoku. Podrobnější informace o šifrovacích protokolech a konkrétních šifrách lze získat v některé z publikací jim přímo věnované Microsoft Point-To-Point Encryption Protocol Šifrovací protokol MPPE byl navržen Microsoftem k zabezpečení vytáčených připojení [11]. Nejčastěji používaný k zašifrování tunelovaného přenosu PPTP mezi stanicemi Windows. Zajišťuje ale pouze důvěrnost dat, spolehlivost autentizace závisí na sdruženém autentizačním protokolu, kterým může být MsCHAP nebo MsCHAPv2. Tyto protokoly také generují informace, z nichž pak MPPE odvodí iniciální klíče k zašifrování komunikace. Klíče mohou mít délku 40-bit, 56-bit nebo 128-bit. Odvození MPPE klíčů po úspěšném dokončení autentizace MsCHAPv2 probíhá podle několika kroků (řetězce jsou označeny stejně jako ve schématu autentizace): 1. MPPE vytvoří společný SHA1 hash z řetězců NThash (16B), 24B odpovědi obdržené od druhé stanice a 27B magické konstanty "This is the MPPE Master Key". 2. Výsledek je zkrácen na 16 B master klíč. 3. Z master klíče vznikne pár klíčů SHA1 hashováním 16B master klíče, 40B řetězce 0x00, 84B magické konstanty a dalšího 40B řetězce 0xF2. RFC definuje různé konstanty pro klíč klient-server a server-klient, takže vygenerované klíče se pro oba směry liší. 4. Oba vzniklé klíče jsou před použitím zkráceny na 16 B. Zranitelné místo protokolu může ležet právě v užití magických konstant k vygenerování šifrovacích klíčů. Obzvláště při využití 40-bit klíče, kdy je horních 24 B klíče pro potřeby funkce RC4 nastaveno pevně na 0xD1269, což funkci značně oslabuje [7]. Vzhledem k tomu, že protokol MPPE vždy vyžaduje přítomnost jedné z verzí protokolu MsCHAP, který však bez kombinace s jiným protokolem (například EAP) poskytuje pouze nízkou úroveň zabezpečení, možnosti jeho využití jsou značně omezené. V současné době se s ním lze setkat prakticky výhradně u PPTP spojení IP Security IPsec je kompletní sada protokolů k zajištění komunikační bezpečnosti na sítích IPv4 i IPv6, do obou IP protokolů byl dodán jako volitelný modul. Veškeré funkce IPsec tedy probíhají na třetí (síťové) vrstvě modelu ISO/OSI. Protokol skrze autentizaci stanic a zašifrování každého zasílaného paketu poskytuje autenticitu, integritu i důvěrnost přenášených dat. Od svého vydání v roce 1993 byl několikrát přepracován a vybaven dalšími moduly, takže dokumentů 10

16 RFC s jeho specifikacemi existuje větší množství. Za stěžejní lze považovat RFC 2401 a 2411[12] [13]. K zabezpečení přenosu slouží zejména části protokolu Authentication Header (AH) a Encapsulating Security Payload (ESP). Před použitím některé z nich musí být mezi komunikujícími stanicemi ustaveno bezpečnostní přiřazení, jež určí i počáteční šifrovací klíče. Pak mohou být data obalena hlavičkou AH, ESP nebo i oběma. AH poskytuje, na rozdíl od ESP, pouze záruku zachování integrity [14]. Pokud mají být data utajena před potenciálním útočníkem, musí být zašifrována pomocí ESP [15]. Umístění IPsec hlaviček v rámci paketu závisí na zvoleném módu. Protokol nabízí buď transportní, nebo tunelovací. V transportním módu se AH nebo ESP hlavička zařadí za IP adresu cíle. Veškeré následující hlavičky jsou pak chráněny na úrovni jim předřazené IPsec hlavičky. V důsledku ale zůstává nechráněná původní IP adresa cíle, což může představovat bezpečnostní riziko. Tunelovací mód obalí IPsec hlavičkou celý datový paket včetně původní hlavičky IP. Nová IP adresa pak může paket směrovat na zabezpečený hraniční server, který se postará o odstranění IPsec obalu a datový paket zašle již nezabezpečený k cíli. Obrázek 4 Paket chráněný Authentication Header Hlavička AH obsahuje pouze několik informací. Next header nese informace o typu protokolu vyšší vrstvy (zpravidla TCP nebo UDP), Security parameters index obsahuje identifikátor SA po kterém komunikace probíhá a Sequence number označuje pořadí zprávy v komunikaci (brání útokům přehráním). Authentication data obsahují kontrolní hash, spočítaný z šifrovacího klíče a obsahu paketu pomocí funkce SHA1. Jakákoli změna paketu v průběhu přenosu, včetně změny adresy v předřazené IP hlavičce, je pak cílovou stanicí detekována při kontrole tohoto hashe. Tato vlastnost nedovoluje provoz IPsec AH přes jakoukoli formu NAT [16]. 11

17 ESP v tunelovacím módu zajišťuje všechny vlastnosti zabezpečení dat autenticitu, integritu i důvěrnost. Transportní mód oproti tomu postrádá garanci autenticity a integrity. Konstrukce paketu chráněného ESP se od AH mírně liší, hlavička ESP je totiž rozdělena na tři části: ESP Header, ESP Trailer a ESP Auth. Obrázek 5 Paket chráněný Encapsulated Security Payload ESP Header obsahuje parametry Security parameters index a Sequence number se stejným významem jako u AH. ESP Trailer s parametry Padding a Pad length zarovnává paket na délku použité blokové šifry. ESP Auth pak nese pouze hash přenášených dat, shodný s AH. Velmi zásadním rozdílem oproti AH je ale absence vnější IP hlavičky v kontrolním součtu. IPsec ESP tedy lze provozovat i přes lokální zařízení NAT. Kryptografická metoda šifrující obsah IPsec ESP komunikace není v RFC přesně specifikována. Záleží na výběru v průběhu ustavování SA. Lze se setkat nejčastěji se symetrickými blokovými šiframi DES, 3DES, Blowfish a AES, z nichž za nejsilnější je považována AES. Délka klíče AES může dosahovat 256-bit, s volitelnými kratšími klíči 192- bit a 128-bit a šifrování provádí na 128-bit datových blocích a doba nutná k prolomení takové šifry bez jakékoliv znalosti o klíči se pohybuje od let pro nejkratší klíč až do let pro nejdelší [17] Secure Socket Layer/ Transport Layer Security Bezpečnostní protokol Secure Socket Layer, který, obdobně jako IPsec, zajišťuje autenticitu, integritu a důvěrnost dat [18]. Po několika aktualizacích byl v roce 1996 nahrazen novějším protokolem Transport Layer Security, založeným na stejném principu [19]. Pracuje na čtvrté (transportní) vrstvě ISO/OSI modelu a používá jak symetrické kryptografie k zašifrování přenášených dat, tak asymetrické při autentizaci, ve formě x.509 certifikátů. Nasazení protokolu závisí na existenci hierarchie certifikačních autorit (CA) a infrastruktury veřejných klíčů (PKI). Každá stanice, například server, který potřebuje potvrdit svou identitu, vygeneruje vlastní certifikát navázaný na jeho FQDN a zašle jej k ověření některé CA. 12

18 Jakmile se pak k takovému serveru připojuje klient, server mu zašle kopii svého certifikátu a klient si jej může ověřit u podepsané CA. Následně se stejným postupem může prokázat i klient. V průběhu autentizace dojde k odvození klíče symetrické šifry pro další komunikaci. TLS handshake probíhá v následujících krocích [20]: 1. Klient odešle serveru žádost o navázání zabezpečeného spojení s údaji o podporovaných šifrách a verzí protokolu a další detaily SA. 2. Server odpovídá výběrem šifrovacího algoritmu, potvrzením SA a vlastním certifikátem k ověření. Může také požadovat certifikát klienta. 3. Klient ověří certifikát a pokud není platný spojení ukončí, jinak za použití dohodnutých detailů SA vytvoří master klíč spojení, zašifruje jej veřejným klíčem serveru a odešle jej. Pokud server vyžadoval certifikát, zašle i ten. 4. Server dešifruje master klíč svým privátním klíčem. 5. Klient i server z master klíče vygenerují tzv. master secret za použití pseudonáhodné funkce a z něj pak odvodí symetrické klíče pro zašifrování další komunikace. 6. Klient odešle dvě oddělené zprávy. První informuje server, že veškerá další komunikace bude zašifrovaná. Druhá obsahuje zprávu o ukončení fáze autentizace. Server odpoví stejným způsobem. Různé verze SSL i TLS projevily náchylnost k některým typům útoků. Útok typu rollback se pokouší donutit server k použití co nejslabšího typu šifry. Pokud server souhlasí, útočníkovi stačí pokusit se tuto šifru prolomit offline na odchycených paketech. Podobný útok využívá zpětnou kompatibilitu mezi SSL 3.0 a 2.0 a donutí server použít starší verzi s několika známými bezpečnostními chybami [21]. Dále byla v nedávné době objevena kritická chyba v zabezpečení OpenSSL verze 1.0.1, umožňující útočníkovi zcizit uživatelská data a soukromé klíče. Nese označení Heartbleed (postihuje OpenSSL komponent Heartbeat), oficiální kód chyby CVE Nejnovější verze 1.0.1g již tuto chybu odstraňuje. Vzhledem k závažnosti chyby a možným následkům by postižené servery měly co nejdříve přejít na novou verzi programu OpenSSL [22]. 13

19 2. VPN protokoly podporované Windows 7 Využití virtuální privátní sítě se sebou nese výhodu přístupu zvenčí ke zdrojům dostupným na soukromé síti při relativně nízkých nárocích na správu poté, co byly nastaveny hraniční servery. Tyto servery mohou být nakonfigurovány pro neustálé statické spojení, jako v případě spojení dvou vzdálených poboček, v tzv. Site-to-Site VPN, nebo naslouchají na portech specifikovaných VPN protokolem a dynamicky přijímají připojení od vzdálených uživatelů v tzv. Point-to-Site VPN. Některé protokoly zmíněné v dalších kapitolách podporují obě konfigurace, nicméně Site-to-Site nastavení jsou k dispozici pouze v operačních systémech Microsoft Windows Server. Protože se práce věnuje šifrovaným spojením mezi počítači využívajícími operační systém Microsoft Windows 7, bude teoretická i praktická část soustředěna převážně na možnosti z hlediska Point-to-Site VPN. Obrázek 6 Site-to-Site VPN Obrázek 7 Point-to-Site VPN Pokud jsou klientské počítače vybaveny operačním systémem Windows 7, existuje několik možností výběru protokolu pro vytvoření virtuální sítě. Nejjednodušší volbou je protokol PPTP [23], který patří k součástem systémů Windows již od roku Zabezpečení, které poskytuje, už ale v současné době nezaručuje příliš vysokou odolnost dat proti změně nebo 14

20 přečtení během přenosu. O stupeň lepší zabezpečení poskytují protokoly L2TP a SSTP [24]. Výhodou L2TP je šifrování dat pomocí protokolu IPsec, ale oproti PPTP má vyšší režijní nároky. Zabezpečení SSTP je na srovnatelné úrovni a navíc spojení zajišťovaná tímto protokolem dokáží projít skrz část firewallů, která by zastavila spojení přes předchozí protokoly. Protože se ale jedná o protokol vyvíjený Microsoftem, jeho podpora na zařízeních od jiných výrobců je slabší. Nejmodernějším protokolem obsaženým ve Windows 7 je IKEv2 [25]. Podporuje IPsec šifrování a má implementovánu funkci automatického obnovení spojení při výpadku přenosové sítě. Rozbor VPN protokolů v této kapitole se věnuje fázím navázání spojení a přenosu dat. Dále uvádí podmínky, které musí být splněny k provozu protokolu. Jedná se o nároky v podobě otevřených portů, kde každý protokol vyžaduje otevření portů se specifickým číslem jak na všech zařízení přenosové sítě, jimiž prochází, tak na straně serveru. Třetím sledovaným hlediskem je bezpečnost s ohledem na podporované autentizační a šifrovací algoritmy z první kapitoly. V posledním odstavci lze nalézt shrnutí výhod a nevýhod pro každý protokol. 2.1 PPTP, Point-to-Point Tunneling Protocol RFC 2637, definující vlastnosti protokolu, bylo vydáno v červenci roku 1999 sdružením několika společností v čele s Microsoftem. PPTP má implementovány všechny služby očekávané od VPN, ale šifrování přenosu a autentizace jsou na nejnižší úrovni ze všech čtyř zde představených protokolů. Hlavní výhodou je relativně snadná konfigurace ve srovnání s ostatními dostupnými protokoly a stále ještě velice široká podpora mezi zařízeními různých výrobců. Z těchto důvodů je protokol obzvláště vhodný pro ustavení domácí VPN, kde umožňuje připojit širokou škálu zařízení s operačními systémy Unix, ios, Android a jiné. Šifrování přenosu bylo v roce 2012 prolomeno útokem hrubou silou, použití pro jakékoli spojení vyžadující důvěrnost nebo autentičnost přenášených dat není nadále doporučeno [9]. Point-to-Point Tunneling Protocol vznikal ve druhé polovině 90. let, tedy v době, kdy bylo stále ještě běžné vytáčené připojení k Internetu pomocí telefonní linky a modemu. Obrázek 8 Klasické vytáčené spojení V tomto druhu připojení byl jeho poslední úsek, mezi ISP a klientem, zprostředkován protokolem Point-to-Point Protocol (PPP). IP pakety totiž nebylo možné posílat samotné po koncové telefonní lince, obalené hlavičkou PPP však ano. Pokud klient potřeboval vyšší rychlost připojení, mohl využít agregace linek tzv. Multilink PPP, ovšem tato funkce 15

21 vyžadovala správné sdružování linek patřících jednomu klientu na straně ISP. Řešení tohoto problému vyústilo v protokol PPTP, který rozdělil Network Access Server na dvě zařízení, PPTP Access Concentrator (PAC) a PPTP Network Server (PNS). Obrázek 9 Tunelované vytáčené spojení Ustavení spojení tedy probíhalo následovně. Po vytočení linky byl nejprve klient připojen na PPTP Access Concentrator, který si vyžádal autentizaci a pak vytvořil PPTP tunel k PNS. Ten mohl sdružit linky se shodnou autentizací a poté zajistit efektivní směrování další komunikace. Vytáčené spojení od klienta díky tomuto rozdělení mohlo končit v lokálním PAC a nemuselo dosahovat až k samotnému NAS, což znamenalo úsporu nákladů při značných vzdálenostech mezi klientem a NAS. PPTP protokol tedy nebyl původně vyvíjen pro vytváření virtuálních sítí, byť se k tomuto účelu ukázal jako vhodný. Aby bylo možné PPTP využít, musí být mezi potenciálními koncovými body dostupná IP konektivita. Protože jakýkoli VPN tunel typicky probíhá Internetem, nepřináší tato vlastnost v praxi obvykle žádné omezení. Na všech mezilehlých síťových prvcích také musí být povoleny porty TCP 1723 pro kontrolní kanál a IP Protocol ID 47 pro datové spojení. PPTP spojení nebude funkční v případě umístění klienta za NAT, který není konfigurován na přeposílání GRE paketů. Ten sice povolí ustavení kontrolního kanálu, ale zahodí všechna přenášená data. Rovněž v případě připojení přes webový proxy server (WPS) nebude pokus o spojení úspěšný [26]. Pokud jsou splněny všechny podmínky kladené na přenosovou síť může být zahájen pokus o připojení k serveru. Protokol k vytvoření VPN využívá dva kanály. První je kontrolní a běží na protokolu TCP. Po tomto kanálu zasílají koncové stanice zprávy oznamující začátek nebo konec přenosu dat a potvrzují příjem. Dále umožňuje zasílání zpráv o změně stavu linky mezi oběma konci a neustále po něm probíhají keep-alive zprávy pro detekci selhání spojení. Každý pokus o PPTP přenos je tedy zahájen vytvořením TCP spojení mezi vzdáleným uživatelem a lokálním PPTP serverem na portu Vzápětí je vytvořeno i kontrolní spojení pomocí zpráv Start-Control-Connection-Request a Start-Control-Connection-Reply. Po ustavení kontrolního kanálu může být vytvořen druhý, sloužící již k vlastnímu přenosu dat. Ten probíhá za pomoci protokolu GRE následovně: 16

22 Obrázek 10 PPTP paket Původní IP datagram je zašifrován některou z metod, kterou poskytuje protokol PPP a je k němu přidána odpovídající hlavička. K výsledku je dále přidána hlavička GRE jednoduchého protokolu k zabalení dat pro přenos přes IP sítě. GRE je pro potřeby PPTP mírně modifikován. Poslední hlavička výsledného paketu patří protokolu IP a obsahuje adresu zdroje a adresu cíle. Výsledek již může být odeslán do přenosové sítě k doručení. Při zpracování paketu na straně PPTP serveru jsou postupně odebírány hlavičky až zbývá pouze zašifrovaný paket PPP. Ten server umí dešifrovat a získá datagram s lokální IP adresou cíle, kterému jej přepošle. Jak naznačilo schéma paketu putujícího nezabezpečenou sítí, PPTP šifrování přímo neřeší. Veškerou starost o bezpečnost nechává na podřízeném protokolu PPP. Ten musí v první řadě zajistit autentizaci stanic a poté zašifrovat každý paket směrovaný vytvořeným tunelem. Pro autentizaci je možné zvolit mezi několika možnostmi, z nichž ale část již poskytuje naprosto nedostačující zabezpečení. Nedoporučuje se výběr Password Authentication Protocol (PAP) nebo Microsoft Challenge Handshake Authentication Protocol (MsCHAPv1). Oba protokoly vykazují zásadní chyby a jsou náchylné k prolomení ve velmi krátkém čase. O něco lepší stupeň zabezpečení zaručuje MsCHAPv2, který opravuje většinu chyb svého předchůdce a umožňuje autentizaci pomocí uživatelského jména a hesla. Nejvyššího možného zabezpečení lze dosáhnout s Extensible Authentication Protocol. Ten umožňuje využít autentizaci s ověřením identity pomocí certifikační autority či MsCHAPv2 jméno a heslo nebo kombinaci obou možností. Zároveň definuje určité postupy pro přenos a uchovávání autentizačních dat, nadále zvyšující odolnost vůči útoku zvenčí. O šifrování PPP rámců se stará jediný protokol Microsoft Point-To-Point Encryption Protocol. K zašifrování dat využívá algoritmus RSA RC4 na klíčích 40-bit, 56-bit nebo 128- bit. Přesná délka klíčů je dohodnuta při ustavení spojení a v průběhu se již nemění. Oproti tomu samotné klíče je možné, a doporučené, měnit v určitých intervalech, nejčastěji až 1 různý klíč na paket. Přestože nejnovější aktualizace zabezpečovacích postupů odstranily většinu zásadních chyb v implementaci protokolu PPTP při použití doporučeného nastavení, stále zbývá několik trhlin obsažených v konstrukci protokolu samotného. Například neexistuje žádná ochrana proti slovníkovým útokům při použití přihlašovacího jména a hesla. To při stále stoupajícím výkonům osobních počítačů klade stále větší nároky na složitost hesla a zvyšuje náchylnost k podlehnutí slovníkovému útoku. Navíc kontrolní TCP spojení nepodléhá autentizaci 17

23 a zprávy po něm zasílané nejsou nijak zašifrovány, což zjednodušuje podvržení nebo modifikaci těchto zpráv a vytváří prostor k jejich zneužití [9]. Protokol PPTP tedy umožňuje poměrně jednoduché vytvoření VPN sítě s plnou funkcionalitou a slabším až průměrným zabezpečením. Plně dostačuje tam, kde bezpečnost není primárním cílem a výpadky dostupnosti v některých lokalitách nezpůsobí žádné škody v domácím využití, pro testovací účely atp. Pro využití v komerční sféře bude vhodnější vybrat některý ze tří zbývajících protokolů L2TP, SSTP, IKEv L2TP, Layer 2 Tunneling Protocol Související RFC 2661 vyšlo již v roce 1999, tedy téměř současně s RFC definujícím PPTP, ale v operačních systémech Windows je podporován až od verze Tento VPN protokol vznikl kombinací vlastností dvou již existujících protokolů. Prvním byl již zmíněný PPTP od Microsoftu, druhým pak L2F vyvinutý Cisco Systems. Jako jeho předchůdce umožňuje rozdělit NAS na dvě zařízení, tentokrát L2TP Access Concentrator (LAC) a L2TP Network Server (LNS) a poskytuje i naprosto stejné výhody, tedy oddělení konce vytáčeného L2 spojení (končí na LAC) od konce PPP spojení (přerušeno až na LNS) a podporu multilink. Přenášeným protokolem je v základu opět PPP, zajišťující autentizaci a šifrování, takže největší výhodou L2TP při použití v jeho základní verzi je schopnost vytvořit tunel přes jakoukoli síť podporující přepínání paketů. Je ovšem možné využít L2TP v kombinaci s protokolem IPsec, který se postará o autentizaci a šifrování namísto PPP, přičemž téměř všechny ostatní vlastnosti zůstanou zachovány. Použití IPsec omezí L2TP tunely pouze na sítě poskytující IP konektivitu, standardní tunel VPN ale typicky probíhá přes Internet, který tento požadavek splňuje. Kombinace protokolů L2TP a IPsec nese oficiální označení L2TP/IPsec a je představena v RFC 3193 [27]. Díky protokolu IPsec poskytuje zabezpečení na velice dobré úrovni a je proto často používaná pro vytváření VPN tam, kde PPTP již nedostačuje. Protože použití základní verze L2TP se sebou nese pouze nepatrné zlepšení bezpečnosti a neexistuje jiný důvod pro jeho preferenci, dále se ve své práci věnuji pouze L2TP za současného použití protokolu IPsec. Jedním z efektů obalení tunelovaných dat do IPsec je vyšší průchodnost skrz firewally nacházející se na veřejné síti mezi stanicemi a tedy mimo naši kontrolu. Není totiž nutné, aby byl port UDP 1701 pro L2TP tunel otevřen na všech těchto zařízeních, postačuje jeho dostupnost na koncových stanicích. Po veřejné síti IPsec komunikuje na portu UDP 500, přes který je ustavena vazba SA, a přes IP Protocol ID 50/51 pro ESP/Authentication Trailer. Tyto porty a protokoly zpravidla nebývají na přenosové síti blokovány, nicméně jejich dostupnost je nutnou podmínkou k úspěšnému uskutečnění spojení. Kontaktovat L2TP server není možné ze zařízení připojených přes WPS a pro průchod přes NAT musí server podporovat funkci NAT-Traversal. Tato funkce umožní v první fázi vyjednávání IPsec klíčů zjistit přítomnost NAT a za pomoci komunikace přes port UDP 4500 zajistit přístup do L2TP VPN. Samozřejmě port UDP 4500 musí být dostupný u klienta, serveru a po celé trase veřejnou sítí [28]. Ustavení L2TP tunelu mezi koncovými body probíhá následovně. Nejprve je nutné vytvoření kontrolního kanálu. Jeho význam je stejný jako u PPTP, tedy zasílání oznámení o vysílání, 18

24 příjmu, změně vlastností linky atp. Probíhá pomocí protokolu UDP na portu 1701 a v případě ztráty paketu se zprávou podporuje přeposlání. Pořadí kontrolních paketů je udržováno pomocí sekvenčních čísel v hlavičce každého takového paketu. Pokud některý dorazí mimo určené pořadí, je zahozen. Data jsou následně přenášena pomocí stejného protokolu i portu, ale na rozdíl od kontrolních zpráv nejsou datové pakety číslovány a pořadí tak nemusí být zachováno. Žádost o vytvoření je zahájena zprávou Start-Control-Connection-Request na kterou by měla protistrana odpovědět Start-Control-Connection-Reply, klient pak ještě jednou potvrdí zprávou Start-Control-Connection-Connected. Součástí výše uvedených zpráv může být volitelný 3-way handshake, podporovaný přímo L2TP a zajišťující autentizaci na úrovni MsCHAPv1. Po těchto třech krocích je možné pokračovat vytvořením datového spojení (session). Jeden L2TP tunel může obsahovat teoreticky až jednosměrných session a mezi dvěma stanicemi může existovat libovolné množství tunelů. Každý z tunelů ale musí mít vlastní kontrolní kanál. Session je pak vytvořena žádostí o povolení k přenosu a jejím potvrzením na kontrolním kanálu příslušného tunelu. Původní IP pakety od klienta posílané do některé session jsou obaleny hlavičkami několika různých protokolů v pořadí ilustrovaném na obrázku. Obrázek 11 L2TP paket PPP rámec tentokrát není zašifrován, spoléhá na ochranu zprostředkovanou některou z vyšších vrstev, jinak se shoduje s PPP rámcem protokolu PPTP. Dále je přidána L2TP hlavička s identifikačním číslem tunelu a příslušné session. ID tunelu se přiřazuje každé stanicí nezávisle, takže každý konec jednoho tunelu bude mít obvykle rozdílný identifikátor. Tyto ID jsou přiřazeny a sděleny protistraně při vytvoření kontrolního spojení. Následující hlavička UDP obsahuje pouze číslo portu 1701 pro zdroj i cíl. IP hlavička obsahuje adresy zdroje a cíle, které jsou použity pro směrování paketu veřejnou sítí. Za IP hlavičku je přiřazena hlavička protokolu IPsec, ta obsahuje informace o algoritmech použitých k zajištění autentizace, integrity a důvěrnosti dat. Za zašifrovanými daty se nachází Encapsulated Security Payload (ESP) s daty zarovnávajícími obsah na délku nutnou pro zvolené blokové šifrování a Authentication Trailer umožňující per-packet ověření totožnosti příjemce a odesilatele. 19

25 Obrázek 12 L2TP/IPsec paket Použití protokolu IPsec přidává k navázání tunelového L2TP spojení několik akcí, nezbytných pro zajištění určité úrovně zabezpečení. Nejprve je nutné vytvoření tzv. Security Association (SA). Tato vazba určuje typ a délku použitých šifrovacích klíčů, druh šifrovacích algoritmů a další parametry. Pro IPsec bývá zpravidla realizována přes protokol Internet Key Exchange (IKE). Po dohodnutí bezpečnostních parametrů SA může být vytvořen zabezpečený kanál pomocí IPsec ESP v transportním módu. Teprve po těchto krocích lze zahájit vyjednávání se vzdáleným serverem o ustavení L2TP tunelovaného připojení. Díky protokolu IPsec jsou chráněna nejen přenášená data, ale také i veškeré informace o tunelovaném přenosu, což znemožňuje útočníkovi snadno zjistit typ probíhající komunikace. Protokol L2TP vykazuje vyšší bezpečnost přenášených dat a vyšší průchodnost přenosovou sítí než protokol PPTP. V rámci jednoho tunelu také může probíhat více než jedna session, takže tento tunel může sloužit pro přenos více VLAN. Pravděpodobně jedinou nevýhodou oproti svému předchůdci je potenciálně nižší rychlost přenosu. Tu se sebou nese využití protokolu IPsec, který má oproti PPP mnohem vyšší režijní náklady na zajištění zabezpečení. Přes tuto negativní vlastnost je zvýšení bezpečnosti natolik výrazné, že preference L2TP před PPTP je doporučená ve všech případech snad kromě jednoduchých domácích VPN sítí. 2.3 SSTP, Secure Socket Tunneling Protocol Po výrazném zvýšení bezpečnosti poskytovaných VPN služeb, které přineslo L2TP, zbývalo vyřešit problém dostupnosti spojení mezi klientem a serverem. Nedostupnost serveru velice často způsobil jeden z následujících důvodů: 1) Na cestě mezi klientem a serverem se nachází zařízení blokující některý z portů nutných pro komunikaci užitého VPN protokolu. 2) Klient se pokouší připojit z místa se soukromým IP adresovým prostorem a zařízení NAT nepodporuje, nebo má zakázáno přeposílání paketů užitého VPN protokolu. 3) Připojení klienta k přenosové síti (Internetu) je zprostředkováno webovým proxy serverem. SSTP měl tyto problémy odstranit, což se díky využití protokolu SSL/TLS povedlo. SSL/TLS je totiž vyžadován pro zabezpečenou HTTP komunikaci (HTTPS) a je proto propouštěn a přeposílán prakticky všemi zařízeními zajišťující směrování v Internetu. Protokol byl představen společností Microsoft v roce RFC nebylo nikdy vydáno, což ve svém důsledku zavinilo pomalejší rozšíření do zařízení konkurenčních společností a tím i slabší podporu mimo operační systémy Windows. V těch je obsažen ve všech verzích od 20

26 Windows Vista Service Pack 1 a Windows Server Dokumentace k protokolu SSTP byla nedávno uvolněna a nyní je volně dostupná na internetových stránkách Microsoftu. Kromě vysoké průchodnosti dále umí vytvořit tunel přes sítě založené na aktualizované verzi protokolu IPv6 a dokáže IPv6 pakety také přenášet uvnitř tunelu. Nutné podmínky, které musí přenosová síť splnit jsou tentokrát minimální. SSTP má pouze jediný požadavek, potřebuje na zařízeních po celé své trase otevřený port TCP 443. Poradí si i s web proxy serverem a NAT bez jakýchkoli úprav jakéhokoli z účastnících se zařízení. Vytvoření zabezpečeného tunelu se tentokrát skládá z více kroků a několika málo volitelných možností. Jednotlivé kroky jsou očíslovány podle pořadí, ve kterém se musí vykonat. 1) Klient kontaktuje SSTP server na jeho veřejné IP adrese na TCP portu 443. Je vytvořeno TCP spojení. 2) Klient odesílá iniciační zprávu protokolu SSL/TLS žádající o ustavení zabezpečeného spojení. V tuto chvíli se musí server prokázat zasláním svého certifikátu. 3) Obdržený certifikát je klientem ověřen. Pokud odpovídá, klient může zvolit klíč relace a zašifrovaný jej odeslat serveru. Jako volitelný krok je možné v této fázi vyžadovat autentizaci klienta jeho vlastním certifikátem. 4) SSTP server obdrží klíč k SSL komunikaci, všechny další zprávy již mohou být zašifrovány. 5) Proběhne request-response vytvoření HTTPS spojení iniciované klientem. 6) Může být vytvořen SSTP tunel zprávou Call-Connect-Request (klient) a Call-Connect- Ack (server). Tento tunel slouží jak pro přenos dat, tak i kontrolních zpráv. 7) V této fázi se autentizuje klient pomocí některé metody, kterou poskytuje protokol PPP. Pokud je úspěšná, klient dostane přidělenu lokální IP adresu a získá přístup k funkcím uvnitř VPN. Obrázek 13 SSTP paket Před odesláním dat tunelem k cílové stanici je nutné postupně je obalit hlavičkami protokolů využitých k přenosu. Výstupní aplikační data nejprve dostanou číslo cílového portu a poté IPv4 nebo IPv6 hlavičku podle verze IP protokolu běžící na VPN síti. Následuje obalení protokolem PPP a SSTP hlavička. Ta obsahuje verzi protokolu, bit určující zda se jedná o kontrolní zprávu a délku připojených dat. Všechna tato data se posílají výhradně zašifrovaná klíčem relace SSL. Druhá TCP hlavička obsahuje číslo portu TCP 443 a nakonec je přiřazena výslednému paketu i druhá IP hlavička s veřejnou adresou SSTP serveru. I tato IP adresa může být verze IPv6 nebo IPv4 podle typu přenosové sítě. V rámci přenosové sítě může útočník tedy zjistit pouze zdrojovou a cílovou adresu a typ přenášené komunikace SSL. Informace o tunelovaném připojení je skrytá v zašifrované části. 21

27 Protokol SSL vyžaduje k autentizaci použití certifikátů ověřených certifikační autoritou. Jedná se o jeden z nejbezpečnějších způsobů autentizace a v případě využití možnosti povinného ověření totožnosti klienta již v SSL fázi poskytuje velmi vysokou míru ochrany. Každý klient připojující se k takovému SSTP serveru ale musí mít instalovaný vlastní ověřitelný certifikát. Vzrůstají tedy nároky na správu takové sítě. SSTP předčí protokoly PPTP a L2TP téměř ve všech ohledech. Poskytuje spolehlivější spojení dostupné i přes síťové prvky blokující ostatní protokoly a autentizace i šifrování je na mnohem vyšší úrovni. Přes tyto výhody má využití protokolu i svá úskalí. Vzhledem k tomu, že byl dlouhou dobu považován chráněným vlastnictvím Microsoftu, nebyl integrován do ostatních operačních systémů. Pokud je tedy nutné do VPN sítě připojit i zařízení s operačním systémem jiným než Microsoft Windows, je třeba využít podpůrný software třetí strany. To může představovat další zvýšení nároků na správu sítě a dotyčných zařízení, pokles spolehlivosti, bezpečnostní problémy atp. Jako další nevýhodu oproti předchozím protokolům lze zmínit chybějící podpora vytváření Site-to-Site VPN spojení. 2.4 IKEv2, Internet Key Exchange v2 Jinak také VPN Reconnect nebo Agile VPN. Jedná se o poslední z řady protokolů dostupných ve Windows 7, v nichž byl poprvé představen, a jeho konstrukce je zaměřena zejména na řešení problému mobility. V případě vzdáleného přístupu ze zařízení, které je v pohybu, může nastat situace, kdy klient na okamžik ztratí spojení k přenosové síti. Jako příklad lze uvést uživatele s notebookem a 3g mobilním připojením k Internetu v jedoucím autě. Jakmile dojde ke ztrátě signálu mobilní sítě, byť pouze na okamžik třeba při průjezdu tunelem, ustavené spojení k VPN serveru je ukončeno. Obnovení a restart všech v tu dobu probíhajících datových přenosů musí uživatel provést manuálně. K řešení obdobných problémů byl k IKEv2 přidán protokol Mobility and Multihoming Protocol (MOBIKE). Ten umožňuje změnit IP adresy již ustaveného tunelu, tedy u existujícího bezpečnostního přiřazení (SA). Mobilní klient tak zůstává připojen k serveru při přechodu mezi různými přístupovými body. Obdobně může při pádu rozhraní použitého k vyjednání tunelového spojení využít jiné, pokud jím disponuje a rozhraní je připojeno k přenosové síti. Mobilní zařízení se tak může libovolně pohybovat mezi přístupovými body i bezdrátovými sítěmi a plynule přecházet mezi wi-fi, 3g (nebo jakýmkoli jiným mobilním připojením, jako starší GPRS nebo EDGE) a fyzickým spojením jako Ethernet při zachování původní autentizace. Protokol MOBIKE je do IKEv2 ve Windows 7 integrován skrze tzv. Mobility Manager, který se stará automaticky o výše uvedené funkce a nechá se do jisté míry konfigurovat uživatelem. Klient může nastavit dobu, po kterou MOBIKE vyčkává na obnovení síťové konektivity, nebo podporu mobility úplně vypnout. Mobility Manager umožňuje VPN tunel přepínat mezi třemi stavy. Stav Connected odpovídá ostatním VPN protokolům a umožňuje přenos dat a funkci aplikací komunikujících se zařízeními v privátní síti. Pokud dojde k pádu rozhraní či jakémukoli jinému problému způsobujícímu nedostupnost VPN serveru a zároveň není dostupné žádné jiné aktivní rozhraní, přepne manager tunel do stavu Dormant. Všechny datové přenosy jsou pozastaveny, nicméně pokud dojde k obnovení spojení, mohou 22

28 pokračovat od bodu přerušení. Jakmile manager detekuje nějaké aktivní rozhraní, přepne tunel do stavu Waiting -to-reconnect a pokouší se kontaktovat VPN server. Pokud server odpoví, tunel přechází zpět do Connected stavu [29]. Protože zabezpečení IKEv2 spoléhá na IPsec, neposkytuje natolik robustní průchodnost přenosovou sítí jako SSTP. Ta, jakož i požadavky na dostupné porty, odpovídá spíše L2TP. IKEv2 vyžaduje otevřený port UDP 500 pro datové přenosy, případně i UDP 4500 pokud server i klient podporují IPsec NAT-Traversal. Posledním požadavkem je port IP Protocol ID 50 pro IPsec ESP. IKEv2 tunel dokáže projít přes NAT při použití NAT-Traversal verze protokolu IPsec. V takovém případě se chová obdobně jako L2TP (viz podkapitola L2TP nutné podmínky). Pokud se klient ovšem nachází za web proxy serverem, nebude schopen IKEv2 VPN server kontaktovat. Pokud jsou splněny všechny podmínky kladené na přenosovou síť může být zahájen pokus o připojení k serveru. Jako první krok při ustavování spojení musí být domluveno bezpečnostní přiřazení (SA). Vyžadováno je ustavení dokonce minimálně dvou SA. Jedno pro IKEv2 jako kontrolní kanál spravující druhý typ podřízených SA. Tato podřízená bezpečnostní přiřazení se nazývají CHILD_SA a pro potřeby IKEv2 VPN se řídí protokolem IPsec. Vyjednávání se skládá ze dvou fází. V první fázi, IKE_SA_INIT, klient kontaktuje server na portu UDP 500, zpráva obsahuje seznam algoritmů podporovaných klientem pro šifrovanou komunikaci. Server může spojení odmítnout v případě, že se v přijatém seznamu nenachází žádný společný algoritmus. Pokud žádost o spojení přijme, odešle klientu potvrzovací zprávu s šifrovacím algoritmem, který bude použit. Obě zprávy také obsahují Diffie-Hellman výměnu k ustavení tzv. master klíče. Po této výměně je veškerá další IKEv2 komunikace zašifrovaná, ale žádná z koncových stanic se zatím neautentizovala. Autentizaci má na starost druhá fáze, IKE_AUTH, která ověří totožnost stanic podle certifikátu nebo pomocí PSK. Zároveň dojde automaticky k ustavení první CHILD_SA. IKEv2 umožňuje později vytvořit další pomocí kontrolních zpráv. Ty mohou být zasílány právě po úspěšné autentizaci obou zařízení a slouží k vytváření, rušení a změnu parametrů jednoho nebo i více IPsec tunelů a musí striktně dodržovat pravidlo request/response (jsou vždy párové). Vytvoření CHILD_SA může zahájit kterákoli z autentizovaných stanic zasláním kontrolní zprávy CREATE_CHILD_SA, protějšek akceptuje odpovědí stejnou zprávou. Pouze v těchto dvou zprávách dojde k dohodnutí bezpečnostních parametrů, odvození prvních IPsec klíčů z master klíče IKEv2 a výběru šifrovacího algoritmu pro nově vzniklé SA. Tunelové spojení k serveru je pak připraveno k přenosu dat. Ukončení spojení může vyvolat rovněž kterýkoli z účastníků a to dvěma způsoby. Zrušením některé CHILD_SA kontrolní zprávou DELETE_PAYLOAD s příslušným identifikátorem, nebo celého IKEv2 kanálu toutéž zprávou, obsahující na místě identifikátoru nulu. Při terminaci kanálu dojde i k automatickému ukončení všech jemu podřízených CHILD_SA spojení. 23

29 Standardní datový paket přenášený tunelem mezi klientem a serverem vypadá následovně: Obrázek 14 IKEv2 paket Původní IP hlavička cílového zařízení v privátní síti a data jsou zašifrovány protokolem IPsec. Nová přidělená IP adresa odpovídá adrese IKEv2 serveru a hlavička Encapsulated Security Payload provádí stejnou funkcí jako u L2TP, tedy zarovnává data na určitou délku. Největší výhodou oproti předchozím protokolům je bezesporu podpora mobility. Nejen že dovoluje uživatelům pohybovat se a při tom měnit přístupové body do sítě. Výhodu přináší i statickým uživatelům ve formě automatické změny rozhraní v případě pádu původního. To vše vždy bez nutnosti znovu zadávat autentizační informace. Poskytovaná úroveň zabezpečení je srovnatelná s L2TP (IPsec) a tedy velice dobrá. Jako nevýhoda se nabízí snad pouze nižší průchodnost přenosovou sítí, kterou, opět obdobně jako u L2TP, zaviňuje IPsec. Ovšem pouze ve srovnání s SSTP, jenž jediný dokáže projít skrz web proxy server. IKEv2 také podporuje vytváření výhradně Point-to-Site VPN. 24