Łańcuch zaufania. CC BY-SA 4.0
Inspekcja ruchu SSL (deszyfrowanie SSL/TLS, analiza SSL lub DPI) staje się coraz bardziej gorącym tematem dyskusji w sektorze korporacyjnym. Idea deszyfrowania ruchu wydaje się zaprzeczać samej koncepcji kryptografii. Fakt jest jednak faktem: coraz więcej firm korzysta z technologii DPI, tłumacząc to koniecznością sprawdzania treści pod kątem złośliwego oprogramowania, wycieków danych itp.
Cóż, jeśli przyjmiemy, że taką technologię trzeba wdrożyć, to powinniśmy przynajmniej rozważyć sposoby, aby zrobić to w sposób możliwie najbezpieczniejszy i najlepiej zarządzany. Przynajmniej nie polegaj na tych certyfikatach, które daje Ci np. dostawca systemu DPI.
Jest jeden aspekt wdrożenia, o którym nie wszyscy wiedzą. Tak naprawdę wiele osób jest naprawdę zaskoczonych, gdy o tym usłyszą. Jest to prywatny urząd certyfikacji (CA). Generuje certyfikaty w celu odszyfrowania i ponownego zaszyfrowania ruchu.
Zamiast polegać na certyfikatach z podpisem własnym lub certyfikatach z urządzeń DPI, możesz skorzystać z dedykowanego urzędu certyfikacji od zewnętrznego urzędu certyfikacji, takiego jak GlobalSign. Ale najpierw zróbmy mały przegląd samego problemu.
Co to jest inspekcja SSL i dlaczego się ją stosuje?
Coraz więcej publicznych witryn internetowych przechodzi na protokół HTTPS. Na przykład według na początku września 2019 r. udział ruchu szyfrowanego w Rosji osiągnął 83%.
Niestety, szyfrowanie ruchu jest coraz częściej wykorzystywane przez atakujących, zwłaszcza że Let's Encrypt w sposób zautomatyzowany dystrybuuje tysiące bezpłatnych certyfikatów SSL. Tym samym HTTPS jest używany wszędzie – a kłódka w pasku adresu przeglądarki przestała być niezawodnym wskaźnikiem bezpieczeństwa.
Z tych stanowisk promują swoje produkty producenci rozwiązań DPI. Są osadzone pomiędzy użytkownikami końcowymi (tj. Twoimi pracownikami przeglądającymi sieć) a Internetem i odfiltrowują złośliwy ruch. Obecnie na rynku dostępnych jest wiele takich produktów, ale procesy są zasadniczo takie same. Ruch HTTPS przechodzi przez urządzenie inspekcyjne, gdzie jest odszyfrowywany i sprawdzany pod kątem złośliwego oprogramowania.
Po zakończeniu weryfikacji urządzenie tworzy nową sesję SSL z klientem końcowym w celu odszyfrowania i ponownego zaszyfrowania treści.
Jak działa proces deszyfrowania/ponownego szyfrowania
Aby urządzenie do kontroli SSL mogło odszyfrować i ponownie zaszyfrować pakiety przed wysłaniem ich do użytkowników końcowych, musi mieć możliwość wystawiania certyfikatów SSL w locie. Oznacza to, że musi mieć zainstalowany certyfikat CA.
Dla firmy (lub kogokolwiek pośrodku) ważne jest, aby przeglądarki ufały tym certyfikatom SSL (tzn. nie powodowały wyświetlania przerażających komunikatów ostrzegawczych, takich jak ten poniżej). Dlatego łańcuch CA (lub hierarchia) musi znajdować się w magazynie zaufanych certyfikatów przeglądarki. Ponieważ te certyfikaty nie są wydawane przez publicznie zaufane urzędy certyfikacji, należy ręcznie rozesłać hierarchię urzędów certyfikacji do wszystkich klientów końcowych.
Komunikat ostrzegawczy dotyczący certyfikatu z podpisem własnym w przeglądarce Chrome. Źródło:
Na komputerach z systemem Windows można korzystać z usługi Active Directory i zasad grupy, ale w przypadku urządzeń mobilnych procedura jest bardziej skomplikowana.
Sytuacja staje się jeszcze bardziej skomplikowana, jeśli w środowisku korporacyjnym potrzebna jest obsługa innych certyfikatów głównych, na przykład firmy Microsoft lub opartych na OpenSSL. Do tego ochrona i zarządzanie kluczami prywatnymi, tak aby żaden z kluczy nie wygasł niespodziewanie.
Najlepsza opcja: prywatny, dedykowany certyfikat główny z zewnętrznego urzędu certyfikacji
Jeśli zarządzanie wieloma certyfikatami głównymi lub certyfikatami z podpisem własnym nie jest atrakcyjne, istnieje inna opcja: poleganie na zewnętrznym urzędzie certyfikacji. W takim przypadku certyfikaty wydawane są od prywatny urząd certyfikacji połączony łańcuchem zaufania z dedykowanym, prywatnym głównym urzędem certyfikacji utworzonym specjalnie dla firmy.
Uproszczona architektura dedykowanych certyfikatów głównych klienta
Ta konfiguracja eliminuje niektóre problemy wspomniane wcześniej: przynajmniej zmniejsza liczbę korzeni, którymi należy zarządzać. Tutaj możesz użyć tylko jednego prywatnego urzędu głównego do wszystkich wewnętrznych potrzeb PKI, z dowolną liczbą pośrednich urzędów certyfikacji. Na przykład powyższy diagram przedstawia wielopoziomową hierarchię, w której jeden z pośrednich urzędów certyfikacji jest używany do weryfikacji/deszyfrowania SSL, a drugi do komputerów wewnętrznych (laptopów, serwerów, komputerów stacjonarnych itp.).
W tym projekcie nie ma potrzeby hostowania urzędu certyfikacji na wszystkich klientach, ponieważ urząd certyfikacji najwyższego poziomu jest hostowany przez GlobalSign, który rozwiązuje problemy związane z ochroną kluczy prywatnych i ich wygaśnięciem.
Kolejną zaletą tego podejścia jest możliwość odwołania uprawnień inspekcji SSL z dowolnego powodu. Zamiast tego tworzony jest po prostu nowy, który jest powiązany z Twoim oryginalnym prywatnym katalogiem głównym i możesz z niego natychmiast korzystać.
Pomimo wszystkich kontrowersji, przedsiębiorstwa coraz częściej wdrażają kontrolę ruchu SSL w ramach swojej wewnętrznej lub prywatnej infrastruktury PKI. Inne zastosowania prywatnej infrastruktury PKI obejmują wydawanie certyfikatów do uwierzytelniania urządzenia lub użytkownika, SSL dla serwerów wewnętrznych i różne konfiguracje, które nie są dozwolone w publicznych zaufanych certyfikatach zgodnie z wymaganiami forum CA/Browser.
Przeglądarki kontratakują
Należy zauważyć, że twórcy przeglądarek starają się przeciwdziałać temu trendowi i chronić użytkowników końcowych przed MiTM. Na przykład kilka dni temu Mozilla Włącz domyślnie protokół DoH (DNS-over-HTTPS) w jednej z kolejnych wersji przeglądarki Firefox. Protokół DoH ukrywa zapytania DNS przed systemem DPI, co utrudnia kontrolę SSL.
O podobnych planach 10 września 2019 r Google dla przeglądarki Chrome.
W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. , Proszę.
Czy uważasz, że firma ma prawo kontrolować ruch SSL swoich pracowników?
-
Tak, za ich zgodą
-
Nie, proszenie o taką zgodę jest nielegalne i/lub nieetyczne
Głosowało 122 użytkowników. 15 użytkowników wstrzymało się od głosu.
Źródło: www.habr.com