🥇DPI (inspekcja SSL) jest sprzeczna z celem kryptografii, ale firmy ją wdrażają

Chain of Trust. CC BY-SA 4.0 Yanpas

Inspekcja ruchu SSL (deszyfrowanie SSL/TLS, analiza SSL lub DPI) staje się coraz bardziej gorącym tematem w sektorze korporacyjnym. Pomysł deszyfrowania ruchu wydaje się sprzeczny z samą koncepcją kryptografii. Jednak faktem jest, że coraz więcej firm korzysta z technologii DPI, tłumacząc to potrzebą weryfikacji treści pod kątem złośliwego oprogramowania, wycieków danych itp.

Cóż, jeśli przyjmiemy jako fakt, że taka technologia musi być wdrożona, warto przynajmniej rozważyć sposoby jej realizacji w możliwie najbezpieczniejszy i najlepiej zarządzany sposób. Przynajmniej nie powinno się polegać na certyfikatach, które na przykład dostarcza dostawca systemu DPI.

Jest jeden aspekt wdrożenia, o którym nie wszyscy wiedzą. W rzeczywistości wielu naprawdę jest zaskoczonych, gdy o tym słyszy. To prywatne centrum certyfikacji (CA). Generuje ono certyfikaty do deszyfrowania i ponownego szyfrowania ruchu.

Zamiast polegać na certyfikatach samopodpisanych lub certyfikatach z urządzeń DPI, można użyć dedykowanego CA od zewnętrznego centrum certyfikacji, takiego jak GlobalSign. Ale najpierw zróbmy krótkie wprowadzenie do samego problemu.

Czym jest inspekcja SSL i dlaczego jest stosowana?

Coraz więcej publicznych stron internetowych przechodzi na HTTPS. Na przykład, według statystyk Chrome, na początku września 2019 roku udział zaszyfrowanego ruchu w Rosji osiągnął 83%.

Niestety, szyfrowanie ruchu coraz częściej jest wykorzystywane przez przestępców, zwłaszcza że Let’s Encrypt rozdaje darmowe certyfikaty SSL masowo w sposób zautomatyzowany. Tak więc HTTPS jest używane wszędzie – a kłódka w pasku adresu przestała być wiarygodnym wskaźnikiem bezpieczeństwa.

Z tych perspektyw producenci rozwiązań DPI promują swoje produkty. Wdrażają się pomiędzy końcowymi użytkownikami (tj. twoimi pracownikami przeglądającymi strony internetowe) a internetem, filtrując złośliwy ruch. Obecnie na rynku istnieje szereg takich produktów, ale procesy są w zasadzie identyczne. Ruch HTTPS przechodzi przez urządzenie kontroli, gdzie jest deszyfrowany i sprawdzany pod kątem złośliwego oprogramowania.

Po zakończeniu weryfikacji urządzenie tworzy nową sesję SSL z końcowym klientem, aby odszyfrować i ponownie zaszyfrować treść.

Jak działa proces odszyfrowania/ponownego szyfrowania

Aby urządzenie SSL-inspekcji mogło odszyfrować i ponownie zaszyfrować pakiety przed wysłaniem do końcowych użytkowników, musi być w stanie wydawać certyfikaty SSL w locie. Oznacza to, że musi mieć zainstalowany certyfikat CA.

Dla firmy (lub innej osoby pośredniczącej) ważne jest, aby te certyfikaty SSL były zaufane w przeglądarkach (tj. nie wywoływały przerażających komunikatów ostrzegawczych, podobnych do przedstawionego poniżej). Dlatego łańcuch CA (lub hierarchia) musi znajdować się w magazynie zaufania przeglądarki. Ponieważ te certyfikaty nie są wydawane przez publiczne zaufane centra certyfikacji, konieczne jest ręczne przekazanie hierarchii CA wszystkim końcowym klientom.

Komunikat ostrzegawczy dla certyfikatu samopodpisanego w Chrome. Źródło: BadSSL.com

Na komputerach z systemem Windows można wykorzystać Active Directory i zasady grupowe, ale dla urządzeń mobilnych procedura jest bardziej złożona.

Sytuacja jeszcze bardziej komplikuje się, jeśli konieczne jest wsparcie dla innych certyfikatów głównych w środowisku korporacyjnym, na przykład od Microsoft lub opartych na OpenSSL. Dodatkowo ochrona kluczy prywatnych i ich zarządzanie, aby żaden z kluczy nie wygasł niespodziewanie.

Najlepsza opcja: prywatny, dedykowany certyfikat główny od zewnętrznego CA.

Jeśli zarządzanie kilkoma rootami lub certyfikaty samopodpisane nie są atrakcyjne, istnieje inna opcja: można polegać na zewnętrznym CA. W tym przypadku certyfikaty są wydawane z prywatnego centrum certyfikacji, które jest powiązane w łańcuchu zaufania z dedykowanym, prywatnym centrum certyfikacji, stworzonym specjalnie dla firmy.

Uproszczona architektura dla dedykowanych certyfikatów głównych klientów.

Taka konfiguracja eliminuje niektóre wcześniej wspomniane problemy: przynajmniej zmniejsza liczbę korzeni, którymi trzeba zarządzać. Można tutaj używać tylko jednego prywatnego centrum certyfikacji dla wszystkich wewnętrznych potrzeb PKI z dowolną liczbą pośrednich centrów certyfikacji. Na przykład, na powyższej ilustracji przedstawiona jest hierarchia wielowarstwowa, w której jedno z pośrednich centrów certyfikacji jest używane do weryfikacji/dekodowania SSL, a drugie — do komputerów wewnętrznych (laptopów, serwerów, komputerów stacjonarnych itp.).

W tym schemacie nie ma potrzeby umieszczania CA na wszystkich klientach, ponieważ CA najwyższego poziomu znajduje się u GlobalSign, co rozwiązuje problemy z ochroną klucza prywatnego i terminem ważności.

Kolejną zaletą tego podejścia jest możliwość unieważnienia certyfikatu SSL z jakiegokolwiek powodu. Zamiast tego po prostu tworzy się nowy, który związany jest z Twoim pierwotnym prywatnym korzeniem i można go używać natychmiast.

Pomimo wszystkich kontrowersji, przedsiębiorstwa coraz częściej wdrażają inspekcję SSL w ruchu jako część wewnętrznej lub prywatnej infrastruktury PKI. Inne zastosowania prywatnej PKI to wydawanie certyfikatów do uwierzytelniania urządzeń lub użytkowników, SSL dla wewnętrznych serwerów, a także różne konfiguracje, które nie są dozwolone w publicznych zaufanych certyfikatach zgodnie z wymogami CA/Browser Forum.

Przeglądarki się temu sprzeciwiają

Należy zauważyć, że deweloperzy przeglądarek starają się przeciwstawiać tej tendencji i chronić użytkowników końcowych przed MiTM. Na przykład, kilka dni temu Mozilla podjęła decyzję zaplanuje włączyć protokół DoH (DNS-over-HTTPS) domyślnie w jednej z przyszłych wersji przeglądarki Firefox. Protokół DoH ukrywa zapytania DNS przed systemami DPI, co utrudnia inspekcję SSL.

O podobnych planach 10 września 2019 roku ogłosiła firma Google dla przeglądarki Chrome.