VPN i PKI
VPN coraz częściej staje się wartością dodaną każdej sieci biznesowej. Szeroki dostęp do Internetu pozwala wykorzystać VPN oraz inwestycje w sieci lokalne do poszerzenia usług wewnętrznych na zewnątrz tej infrastruktury (głównie dla partnerów, klientów oraz pracowników). Możliwość korzystania z sieci wewnętrznej firmy poprzez Internet nosi nazwę tunelowania VPN.
VPN pozwala na dwie rzeczy: dostęp do sieci wewnętrznej dla upoważnionych do tego osób (VPN poszerza w sposób bezpieczny LAN); szyfrowanie całego ruchu sieciowego. Normalnie w Internecie jest możliwe podsłuchanie komunikacji, VPN uniemożliwia tego rodzaju szpiegostwo. Do tej pory był możliwy dostęp do zasobów wewnętrznych sieci np. poprzez dostęp typu dial-up ale było to bardzo zawodne i drogie rozwiązanie.
Technologia VPN
Tunel VPN łączy dwie lokacje. W tym przypadku użytkownika oraz zdalną sieć wewnętrzną. Kiedy użytkownik zewnętrzny pragnie połączyć się do sieci lokalnej poprzez VPN i korzystać z jej zasobów musi się najpierw przedstawić (zweryfikować, zautentykować). Po udanej autentykacji serwis VPN nawiązuje bezpośrednie połączenie z serwisem VPN na serwerze zdalnym. Taki kanał nosi nazwę tunelu poprzez Internet pomiędzy dwoma sieciami. Od tego momentu każdy komunikat sieciowy między tymi dwoma sieciami będzie przechodził przez ten właśnie kanał. Usługi VPN na obu końcach tego kanału będą dodatkowo szyfrowały i deszyfrowały wszystkie komunikaty. Jest wiele implementacji VPN, każda ma swoje wady i zalety. Dwie najpopularniejsze technologie konstruowania kanału VPN to:
- P2PTP lub PPTP (Point to point tunneling protocol)
- L2TP/IPSec (Layer 2 tunneling protocol with IPSec)
MS oczywiście implementował obie te technologie , ale jest jeszcze trzecia OpenVPN autorstwa James Yonan. Dlaczego ta trzecia? Dlatego:
- PPTP jest protokołem MS i na początku rozwoju miał wiele kłopotów z bezpieczeństwem, obecnie zostały one usunięte ale pojawił się problem kłopotów we współpracy z innymi platformami. Np. protokół ten używa do konstrukcji kanału VPN i pakietów danych protokołu tzw. GRE (general routnig encapsulation) i niektóre routery blokują tego rodzaju ruch sieciowy. OpenVPN do konstrukcji pakietów w tunelu VPN używa wyłącznie protokołu UDP oraz TCP.
- L2TP/IPSec nie dostarcza bezpieczeństwa, jedynie jest protokołem enkapsulującym dane, IPSec służy do szyfrowania i autentykacji stron. Ma jeszcze jedną wadę - VPN realizowany przy pomocy L2TP/IPSec nie może działać w środowisku NAT (Network Address Translation) działających na niektórych routerach. NAT wykorzystywany jest w małych sieciach i routerach obszaru SOHO (small office/hme office). Nowe routery DSL wspierają już NAT poprzez Universal Plug and Play (UPnP) NAT Traversal ale nie są jeszcze popularne. Protokół L2TP/IPSec jest skomplikowany w konfiguracji i konserwacji dlatego, że jest częścią większej infrastruktury sieciowej i działa na niższej warstwie. PPTP działa na wyższym poziomie i łatwiej zlokalizować i wykryć w nim problemy.
- OpenVPN wydaje się pozbawiony powyższy wad i na dodatek jest łatwiejszy w instalacji (wystarczy UDP i/lub TCP). Do zabezpieczeń używa SSL (Secure Socket Layer) protokół opracowany przez Netscape. Od 1999 roku SSL został przemianowany na TLS (transport layer security) przez Internet Engineering Task Force (IETF). Bezpieczeństwo TLS wzmocnione jest przez technologię certyfikatów X.509. W najnowszej co prawda beta wersji OpenVPN 2.0 dodano niezwykle cenną właściwość - walidację podczas procesu autentykacji certyfikatów z listą odwołanych certyfikatów (CRL - Certificate Revocation List), inną nowością jest to, że usługa VPN uruchamia się jako jeden proces.
OpenVPN stosuje TLS do uzyskania bezpieczeństwa, sam protokół TLS w trakcie procesu weryfikacji i szyfrowania polega na cyfrowym obiekcie zwanym certyfikatem X.509. Po właściwym skonfigurowaniu PKI można również udostępnić wiele innych zabezpieczonych w ten sposób usług np. web services (uslugi sieciowe) i pocztę.
Technologią podstawową do zapewnienia bezpieczeństwa jest kryptografia oparta na kluczy publicznym - polega na bezpiecznej komunikacji wykorzystującej dwa rożne klucze: klucz publiczny dostępny każdemu oraz klucz prywatny zastrzeżony jedynie dla właściciela. Oba klucze są generowane na podstawie skomplikowanego algorytmu kryptograficznego. Mają one pożyteczną właściwość: zaszyfrowanie komunikatu jednym kluczem jest możliwoe do odczytania przy pomocy drugiego klucza. Tzn. po wygenerowaniu pary kluczy, użytkownik może odszyfrować kluczem publicznym komunikat zaszyfrowany kluczem prywatnym i na odwrót.
Przykładowy scenariusz:
- Obiekt A wysyła zaszyfrowaną wiadomość do obiektu B, obiekt B wygenerował swoją parę kluczy i przekazał klucz publiczny m.in. do obiektu A, przy zaszyfrowaniu obiekt A korzysta z klucza publicznego B.
- Obiekt B otrzymuje wiadomość i tylko on deszyfruje ją swoim kluczem prywatnym
- Uwaga 1: dopóki obiekt B trzyma w sekrecie swój klucz prywatny tylko on może deszyfrować wiadomości od różnych osób szyfrujących jego kluczem publicznym
- Uwaga 2: czy w przypadku odwrotnym kiedy obiekt B chce wysłać zaszyfrowaną wiadomość przeznaczoną wyłącznie dla obiektu A. Jak wiadomo w Internecie wszystkie komunikaty można przechwycić, jedynie te zaszyfrowane są niedostępne dla osób niepowołanych. Czy można skorzystać z istniejących kluczy obiektu B? Otóż nie, gdyby obiekt B wysłał komunikat do obiektu A szyfrując go swym kluczem prywatnym do WSZYSCY w Internecie mający jego klucz prywatny. Wniosek - NADAWCA chcąc wysłać do kogoś zaszyfrowaną wiadomość musi ją zaszyfrować kluczem publicznym ODBIORCY.
Cyfrowe certyfikaty
Widać w tym scenariuszy jeden mankament - brak możliwości zarządzania kluczami PUBLICZNYMI (a nie prywatnymi). Skąd NADAWCA wie, że wysyła wiadomości i szyfruje je właściwym kluczem publicznym ODBIORCY (strona trzecia może podsunąć NADAWCY fałszywy klucz, dzięki czemu NADAWCA szyfrując nim dane jest w błędzie myśląc, że one mogą być odszyfrowane przez właściwego ODBIORCĘ - nosi to nazwę maskarady). W tym celu wymyślono cyfrowy certyfikat, który jest strukturą danych weryfikującą klucz publiczny i zawiera:
- Nazwisko właściciela klucza publicznego
- Nazwisko urzędu certyfikacyjnego potwierdzającego autentyczność klucza
- Właściwy klucz publiczny
- Cyfrowa suma kontrola certyfikatu zaszyfrowana kluczem prywatnym urzędu certyfikacyjnego
Urząd certyfikacyjny gwarantuje autentyczność klucza publicznego (tj. że należy do strony żądającej certyfikatu zwanej też PODMIOTEM - subject). Strony wystawiająca certyfikat nosi nazwę WYSTAWCY (issuer). Format certyfikatu zgodnego z X.509 zakodowuje te nazwy zgodnie ze specjalną syntaktyką -DN (distinguish names).
WYSTAWCA tworząc certyfikat zbiera informacje o stronie żądającej go, tworzy ciąg: nazwa strony żądającej dane + klucz publiczny żądającej strony + swoją własną nazwę i oblicza sumę kontrolną takiej struktury. Urząd certyfikacyjny szyfruje wynik tej sumy kontrolnej przy pomocy swego własnego klucza prywatnego i dopisuje to do struktury certyfikatu.
Od tej chwili każdy może sprawdzić czy dany klucz publiczny udostępniony w Internecie faktycznie należy do WYSTAWCY. Mówiąc ogólnikowo UC przechowuje unikalne świadectwo autentyczności CERTYFIKATU, jest ono nieznane innym stronom.
Struktura Klucza Publicznego
PKI jest to zespół oprogramowania, baz danych oraz usług sieciowych pozwalających organizacji na wystawienie, opublikowanie oraz odwołanie certyfikatu cyfrowego.
