Decryption SSL/TLS Proxy

Protokół TLS (Transport Layer Security) jest następcą protokołu SSL (Secure Sockets Layer). Oba służą do szyfrowania ruchu w bezpiecznych połączeniach np. HTTPS. W momencie gdy chcielibyśmy dla takiego ruchu przeprowadzić bardziej szczegółowa inspekcję, czy nie narusza on zasad bezpieczeństwa naszej firmy, trzeba by go odszyfrować. Dzięki modułowi ASA CX jest to możliwe. W ustawieniach polis typu Decryption, jest możliwe ustawienie jaki ruch będzie deszyfrowany do szczegółowej inspekcji, a który przejdzie przez firewall nie sprawdzany. Jedyny ruch jaki jest deszyfrowany jest to ruch HTTPS. CX zachowuje się jak man-in-the-middle. Man-in-the-middle to atak polegający na przechwytywaniu naszego ruchu i analizowaniu go w taki sposób, że nam wydaje się, że nawiązaliśmy połączenie z naszą docelową stacją np. serwerem. CX najpierw deszyfruje cały ruch, sprawdza czy nie narusza żadnych reguł z grupy Access i jeżeli ruch jest puszczany dalej, zaszyfrowywuje go i wysyła dalej. Ruch powracający jest również poddawany takim samym procedurom. CX może wymusić deszyfrowanie ruchu na podstawie Web reputation. Jeżeli adres docelowy ruchu wpada w pule stron o niskiej reputacji zostanie deszyfrowany i poddany szczegółowej inspekcji. Jeżeli adres docelowy należy do strony o wysokiej reputacji zostanie przepuszczony bez deszyfrowania. Ruch, który nie jest deszyfrowany nie jest poddawany inspekcji przez CX. Ruch, nie podlegający deszyfrowaniu jest jedynie kontrolowany na podstawie adresu IP, serwisów (portów) czy uprawnień użytkownika. Zdeklarowane URL objects czy File filtering obiekty nie będą działać na taki ruch gdyż nie wiadomo co jest w środku.

Mechanizm deszyfrowania ruchu przez CX. W momencie nawiązywania połączenia przez użytkownika do serwera zewnętrznego, CX przechwytuje ruch i udaje użytkownika wysyłając własne Hello w celu nawiązania połączenia. Serwer odpowiada i wysyła swój certyfikat. CX sprawdza certyfikat i wymusza polityki deszyfrowania (jeżeli w tym momencie nie pojawi się żadna polisa wymuszające deszyfrowanie ruchu CX zakończy połączenie. Użytkownik ponownie nawiąże połączenie z serwerem. CX już będzie wiedział, że ten ruch ma pozostać zaszyfrowany i pozwoli na połączenie). Następnie powstaje nawiązanie połączenia pomiędzy CX i serwerem. CX następnie wysyła swój własny certyfikat do użytkownika, wynikiem czego jest nawiązanie połączenia. Użytkownik wysyła zaszyfrowane dane, po dotarciu do CX zostają deszyfrowane i poddane inspekcji. Jeżeli ruch jest zabroniony przez którąś z polis, zostanie odrzucony w tym momencie. Jeżeli zostanie puszczony CX prześle go do serwera.

Konfiguracja deszyfrowania SSL/TLS

1. Należy zainstalować licencję CX 3DES/AES (K9) do możliwości silnego szyfrowania. Licencja ta jest darmowa, jej brak może spowodować niemożliwość połączenia się z urządzeniami, które wymagają silnego szyfrowania.
2. Należy włączyć możliwość deszyfrowania i wybrać certyfikat CA, którym posługiwać się będzie CX do rozmowy z użytkownikiem.
a) wchodzimy Device -> Decryption
b) wybieramy Enable Decryption Policies: On
c) pojawią się nowe opcje certyfikatów możemy albo wygenerowac nowy albo zaimportować istniejący
d) zapisujemy

3. Ustanowienie Decryption polis, jak chcemy aby CX traktował ruch czy ma być poddawany deszyfrowaniu czy nie. Domyślnie jest ustawione, że żaden ruch nie jest deszyfrowany.
a) wchodzimy Polices -> Polices
b) wyszukujemy Decrption, najeżdżamy i dodajemy nową Add New Policy
4. Należy wprowadzić obejścia dla połączeń do zaufanych witryn, czy stron należących do takich kategorii jak Bankowość czy Finanse. Zakładamy z góry, że taki ruch jest bezpieczny. Należy też wprowadzić obejście dla ruchu niosącego z komunikatorów internetowych
a) w naszym przypadku zrobimy obejście dla sektora bankowego, jako pierwszy tworzymy obiekt URL filtering wyrzucający kategorie Finnance

b) następnie tworzymy polise w której zawieramy nasz obiekt bankowy, cały ruch będzie deszyfrowany poza tym, który wpada w kategorie Finnance