Zdalny dostęp z przeglądarki

Możliwość dostania się do sieci korporacyjnej z dowolnego miejsca na ziemi nie jest dziś niczym dziwnym. Traktowana jest raczej jako konieczność i trudno wyobrazić sobie co najmniej średnią organizację, która nie korzystałaby z tego wynalazku. Stary to temat i wydaje się, że oklepany, a jednak... Nawet dziś, gdy dochodzi do podjęcia decyzji o wdrożeniu, pojawiają się wątpliwości - najpierw dotyczą wyboru technologii, potem konkretnego rozwiązania.

Przy tej okazji należy odpowiedzieć sobie na szereg pytań dotyczących wydajności, sposobu dostępu, skalowalności i bezpieczeństwa.

Na rynku technologii VPN dostępnych jest przynajmniej kilka standardów - L2FP lub L2F (Layer 2 Forwarding Protocol), PPTP (Point-to-Point Tunneling Protocol), L2TP (Layer 2 Tunneling Protocol), MPLS (Multi Protocol Label Switching), IPSec czy SSL VPN (Secure Socket Layer). Od dłuższego czasu na rynku dominują dwie ostatnie - IPSec VPN oraz SSL VPN.

O rozwiązaniach IPSec napisano już bardzo wiele, natomiast SSL VPN, mimo dynamicznego rozwoju, nadal pozostaje nieco w informacyjnym cieniu swojego sąsiada. Od dawna też toczy się debata o wyższości jednego rozwiązania nad drugim. Według badań prowadzonych przez Gartnera, do końca 2008 roku ok. 90% pracowników korporacji będzie wykorzystywało SSL VPN jako sposób na zdalny dostęp do zasobów firmy. Z tego powodu właśnie VPN-owi z przeglądarki poświęcimy nieco uwagi i spojrzymy, jak wygląda od strony technologicznej oraz funkcjonalnej. Spróbujemy też znaleźć jego główne wady i zalety.

SSL - a co to takiego?

SSL VPN to jedna z metod zapewnienia zdalnego dostępu do zasobów, operująca w warstwie czwartej (transportowej) stosu OSI. Rezyduje więc o warstwę wyżej niż IPSec, który pracuje w warstwie trzeciej (sieci). SSL jako taki jest dość starym protokołem. Został wprowadzony przez firmę Netscape w celu zabezpieczenia komunikacji pomiędzy aplikacjami typu klient-serwer poprzez łącza potencjalnie niebezpieczne. Od czasu powstania, czyli od roku 1994, zasady jego działania nie zmieniły się zasadniczo i obecnie funkcjonuje w wersji 3.1 (SSLv3.1).

SSL w codziennych zastosowaniach zabezpiecza komunikację przede wszystkim webową opartą na protokole http, który sam z siebie nie zapewnia żadnych mechanizmów bezpieczeństwa. Podstawowe zadania, jakie zostały postawione protokołowi SSL, to zapewnienie poufności komunikacji, integralności przesyłanych informacji oraz uwierzytelnienie obu stron połączenia (a w szczególności serwera). Tak się składa, że podobne funkcje wyznaczono również podczas budowania wirtualnych sieci prywatnych, co powoduje, że wykorzystanie SSL-a w VPN-ach jest naturalne i oczywiste.

SSL, jak już wspomnieliśmy, pracuje w warstwie transportowej, co pozwala mu na enkapsulację informacji płynących w warstwach wyższych - w tym aplikacyjnej. SSL zatem nadaje się nie tylko do zabezpieczania ruchu webowego, ale również niemal wszelkiej komunikacji realizowanej w warstwie 7 (np. FTP, SMTP czy POP3). Jak zatem wygląda komunikacja wykorzystująca protokół SSL? Zanim zostanie zestawiony bezpieczny kanał komunikacji za pomocą SSL-a, strony połączenia muszą "dogadać się" co do jego parametrów - coś jak 3-way handshake w TCP (z tym że tutaj proces jest nieco bardziej skomplikowany).

Zdalny dostęp z przeglądarki

SSL Handshake - fazy zestawiania komunikacji

Podczas negocjowania tunelu SSL wymagane jest uwierzytelnienie obydwu stron połączenia względem siebie. Zazwyczaj do tego celu stosuje się mechanizmy kryptografii asymetrycznej. Zarówno klient, jak i serwer wymieniają pomiędzy sobą klucze publiczne, co z kolei pozwala na szyfrowanie komunikatów przekazywanych podczas uzgadniania parametrów tunelu. Najszerzej wykorzystywanym algorytmem kryptograficznym w tej fazie komunikacji jest RSA (od nazwisk panów: Rivest, Shamir, Adleman). Powszechnie algorytm ten uważa się za zupełnie bezpieczny (dopiero wynalezienie komputera kwantowego mogłoby spowodować powstanie realnego zagrożenia). Kiedy uda się już wynegocjować określone parametry i połączenie zostanie ustanowione, dalsza komunikacja szyfrowana jest symetrycznie.

Kilka lat po pojawieniu się SSL, w roku 1999 u jego boku wyrósł nowocześniejszy brat - TLS 1.0 (Transport Layer Security), obecnie występujący w wersji 1.1. Oferuje on bardziej zaawansowane mechanizmy bezpieczeństwa niż SSL. Najważniejsze z różnic to zastąpienie algorytmu haszującego MAC poprzez HMAC, zwiększenie ilości alertów, wprowadzenie wymogu wspierania algorytmów DSS/DH. Te różnice (i kilka mniej krytycznych) powodują, że SSL i TLS nie są niestety ze sobą kompatybilne. Nie ma jednak powodu do załamywania rąk. Większość rozwiązań określanych mianem SSL VPN wspiera zarówno protokół TLS jak i SSLv3.

Wiemy już na czym w skrócie polega działanie SSL-a. A co daje skorzystanie z jego dobrodziejstwa w przypadku wirtualnych sieci prywatnych?

SSL VPN umożliwia zestawianie tuneli VPN zarówno typu site-to-site, jak i client-to-site. I tu pojawia się jedno z częściej spotykanych nieporozumień. Potocznie SSL VPN utożsamiany jest z dostępem klienckim, co nie jest prawdą. Sztandarowym przykładem rozwiązania typu open source, które pozwala zestawiać tunele site-to-site w oparciu o SSL, jest OpenVPN (www.openvpn.net). Dostęp typu client-to-site z wykorzystaniem technologii SSL VPN określa się często mianem tzw. clientless VPN, ponieważ nie wymaga on instalacji i konfiguracji klienta na stacji roboczej. Nie jest to do końca prawdą, ponieważ realizacja niektórych funkcji wymaga pobrania kontrolki ActiveX lub apletu Javy. Za przykład rozwiązania typu clientless VPN może posłużyć również open source'owy SSL-Explorer (www.3sp.com). Stąd też stawianie znaku równości pomiędzy SSL VPN i clientless VPN nie jest uprawnione. Technologia jak widać jest podobna, ale sposób wykorzystania inny.

Patryk Królikowski

***

Pełna treść artykułu została zamieszczona w czerwcowym numerze miesięcznika NetWorld. (06'07)

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200