Mechanizm SSL PROXY jest jednym z najważniejszych modułów UTM-a za pomocą którego możemy w pełni kontrolować ruch webowy. Samo HTTP PROXY nie już dzisiaj wystarczające i bardzo łatwo obejść jego restrykcje. SSL PROXY w Netasq-u ma wiele opcji konfiguracyjnych pozwalających na dokładne dopasowanie sposobu działania funkcjonalności do własnych potrzeb i specyfiki instytucji.

Kanał transmisji zabezpieczony protokołem szyfrowanym SSL ma zapewnić poufność i integralność przesyłanych danych pomiędzy źródłem (serwerem) a odbiorcą (klientem).

 

SSL – schemat

Schemat działania (uwierzytelnienie serwera) protokołu wygląda następująco [źródło: Wikipedia] (jako K oznaczamy klienta, a jako S – serwer):

K → S Centello

Klient wysyła do serwera zgłoszenie zawierające m.in. obsługiwaną wersję protokołu SSL, dozwolone sposoby szyfrowania i kompresji danych oraz identyfikator sesji. Komunikat ten zawiera również liczbę losową używaną potem przy generowaniu kluczy.

K ← S ServerHello

Serwer odpowiada podobnym komunikatem w którym zwraca klientowi wybrane parametry połączenia: wersję protokołu SSL, rodzaj szyfrowania i kompresji, oraz podobną liczbę losową.

K ← S Certificate

Serwer wysyła swój certyfikat pozwalając klientowi na sprawdzenie swojej tożsamości (ten etap jest opcjonalny, ale w większości przypadków występuje)

K ← S ServerKeyExchange

Serwer wysyła informację o swoim kluczu publicznym. Rodzaj i długość tego klucza jest określony przez typ algorytmu przesłany w poprzednim komunikacie.

K ← S ServerHelloDone

Serwer zawiadamia, że klient może przejść do następnej fazy zestawiania połączenia.

K → S ClientKeyExchange

Klient wysyła serwerowi wstępny klucz sesji, zaszyfrowany za pomocą klucza publicznego serwera. Na podstawie ustalonych w poprzednich komunikatach dwóch liczb losowych (klienta i serwera) oraz ustalonego przez klienta wstępnego klucza sesji obie strony generują klucz sesji używany do faktycznej wymiany danych. Uwaga: wygenerowany klucz jest kluczem algorytmu symetrycznego (typowo DES)! Jest on jednak ustalony w sposób bezpieczny i znany jest tylko komunikującym się stronom.

K → S ChangeCipherSpec

Klient zawiadamia, że serwer może przełączyć się na komunikację szyfrowaną.

K → S Finished

… oraz że jest gotowy do odbierania danych zakodowanych.

K ← S ChangeCipherSpec

Serwer zawiadamia, że wykonał polecenie – od tej pory wysyłał będzie tylko zaszyfrowane informacje…

K ← S Finished

…i od razu wypróbowuje mechanizm – ten komunikat jest już wysyłany bezpiecznym kanałem.

Ponieważ transmisja jest zaszyfrowana nie ma możliwości bezpośredniego jej  kontroli przez IPS (ASQ). W NETASQ-u definicja SSL PROXY składa się z dwóch wpisów na zaporze. W pierwszej kolejności zaszyfrowane pakiety trafiają na „deszyfrator” (reguła numer 1). W zależności od definicji zawartych w filtrze SSL transmisja może zostać: zablokowana bez deszyfrowania, zdeszyfrowana i przekazana do modułów SSL PROXY i (opcjonalnie) HTTP PROXY, przepuszczona bez deszyfrowania.

(reguły możemy wstawić za pomocą kreatora: Kreator reguły SSL proxy)

Konfiguracja Filtra SSL opiera się o obiekty Klasyfikacji URL:

Należy pamiętać, że wpisy w grupach tworzymy w oparciu o nazwy CN występujące w certyfikatach witryn HTTPS a nie adresów URL jak to ma miejsce przy definiowaniu Klasyfikacji Własnej adresów URL.

Można stosować  klasyfikację producenta:

Kilka przykładowych ustawień Filtra SSL:

Pamiętajmy aby certyfikat CA podpisujący certyfikaty witryn dla SSL PROXY dodać do zaufanych certyfikatów na komputerze. W przeciwnym wypadku będziemy za każdym razem otrzymywać komunikat o nie zaufanym wystawcy certyfikatu.

Ponieważ Grupa URL o nawie social-ssl  ma być blokowana, otrzymujemy efekt:

Strona banku (Grupa URL: bank) ma zostać zdeszyfrowna, zatem NETASQ podstawia nam (klientowi) stronę zaszyfrowaną „fałszywym”  certyfikatem:

Natomiast, witryna www.omnikey.pl (Grupa URL: proxyssl_mybypass) ma zastać pominięta przez moduł deszyfracji:

Witryny Facebook-a i Omnikey „wypadają” z dalszego przetwarzania. Facebook został zablokowany a www.omnikey.pl przepuszczony bypassem. Witryna banku (z rozszyfrowaną treścią) zostaje natomiast przekierowana do kontroli przez IPS (ASQ) i ewentualnie przez moduł HTTP PROXY (możemy np. przeskanować ją modułem AV czy też przepuścić przez filtr URL).

Ponieważ SSL PROXY niejako uwiarygodnia serwer źródłowy SSL ważnym jest aby NETASQ kontrolował poprawność oryginalnego certyfikatu serwera źródłowego. IPS (ASQ) udostępnia szereg opcji za pomocą których jesteśmy w stanie wpływać na zachowanie SSL PROXY w zależności od „kondycji” certyfikatu.

Producent wraz z urządzeniem dostarcza dużą bazę powszechnie znanych zaufanych urządów certyfikacji, nie mniej jednak użytkownik może również wprowadzić dowolne inne CA którym urządzenie ma ufać (tzn. ufać certyfikatom podpisanym przez te CA). Dodawanie „własnych” CA odbywa się poprzez moduł PKI urządzenia.

Zobaczmy  jak zareaguje urządzenie jak wyłączymy zaufanie dla certyfikatów podpisanych przez VeriSign (np. certyfikat Multibanku jest podpisany przez VeriSign).

Druga reguła „tandemu reguł” SSL PROXY ma za zadanie kontrolę IPS i HTTP PROXY zdeszyfrowanego ruch a następnie zaszyfrowanie pakietów przez wewnętrzny HTTPS serwer i wysłanie pakietów do klienta. Do tej reguły możemy podpiąć zarówno HTTP URL Filter jak i kontrolę antywirusową, analogicznie jak ma to miejsce dla reguł ruchu HTTP.

Pokażę na przykładzie jak wygląda realizacja pełnego filtrowania HTTP/HTTPS:

Zadaniem jest zablokowanie dostępu do stron www.globessl.com (wybór tej witryny był spowodowany tylko tym, że jest ona dostępna zarówno dla HTTP jak i HTTPS). Na początku definiujemy własną grupę filtra URL, w przykładzie została ona nazwana GlobeSSL:

Konfigurujemy slot filtra URL numer 01:

Podłączmy slot 01 filtra URL pod regułę ruch http na zaporze:

Wywołanie strony http://www.globessl.com skończy się blokadą:

Nie mniej jednak przeglądanie tej witryny jest nadal możliwe po https:

Dodajemy filtrowanie URL na „drugiej” regule SSL PROXY:

Próbujemy ponownie otworzyć witrynę po https:

Administrator ma kontrolę nad „fałszywym” certyfikatem który jest podstawiany użytkownikowi w miejsce oryginalnego certyfikatu serwera HTTPS. Certyfikat ten jest generowany przez PKI urządzenia. Certyfikat dla witryny jest generowany w sytuacji gdy nie znajduje się w cache certyfikatów SSL PROXY i akcja na filtrze SSL jest ustalona na Decrypt. Przechowywanie wystawionych certyfikatów w cache znacznie poprawia czas dostępu do witryny przy powtórnym odwiedzeniu strony. Domyślnie w PKI urządzenia jest powołane CA które wydaje certyfikaty witryn dla serwera https obsługującego SSL PROXY, czyli CA o nazwie SSL proxy default authority :

Administrator może jednak powołać własne CA lub zaimportować certyfikaty zewnętrzne a następnie wskazać w konfiguracji SSL PROXY którego CA użyć w celu wystawiania certyfikatów dla witryn podlegających deszyfrowaniu:

Od tej chwili wystawca „fałszywego” certyfikatu SSL PROXY ulegnie zmianie:

Powyższy opis SSL PROXY powinien uzmysłowić jeszcze dobitniej jak ważne jest chronienie dostępu do samego urządzenia tzn. do jego systemu. Wystarczy z poziomu konsoli wydać polecenie tcpdump na interfejsie loopback (SSL PROXY słucha na porcie 8084/tcp interfejsu 127.0.0.2) aby przechwycić zdeszyfrowaną transmisję SSL:

Plik (tcpdump1.pcap) zaimportowany do programu WinShark daje nam możliwość obejrzenia w postaci jawnej całej treści (oczywiście łącznie z hasłami i nazwami użykowników) jaka była transmitowana przez https.