Szybki rozwój protokołów transportowych i kryptograficznych spowodował powstanie konfliktu między prywatnością danych użytkowników a wymogami operacyjnymi w zakresie bezpieczeństwa sieci korporacyjnych (choć moim zdaniem wykorzystywanie serwera DNS swojego operatora jest lepsze z punkty widzenia prywatności). Chociaż nowoczesne rozwiązania zapewniają bezpieczeństwo metadanych i zmniejszają opóźnienia w nawiązywaniu połączeń, to jednocześnie uniemożliwiają one działanie tradycyjnych mechanizmów bezpieczeństwa.
Ewolucja warstw transportowej i kryptograficznej
Zabezpieczanie ruchu internetowego przeszło od oddzielnych, sekwencyjnych procedur nawiązywania połączeń w warstwie TCP do zintegrowanych, wysoce zoptymalizowanych architektur działających w protokole UDP. Aby zrozumieć wyzwania, jakie stwarza to dla deszyfrowania ruchu sieciowego w urządzeniach typu NGFW(Next Generation Firewall), należy porównać mechanikę starszych procedur nawiązywania połączeń w protokole TCP (Transmission Control Protocol) w połączeniu z protokołem TLS (Transport Layer Security) z nowoczesnymi frameworkami opartymi na protokole UDP (User Datagram Protocol), takimi jak QUIC (Quick UDP Internet Connections) i DTLS (Datagram Transport Layer Security).
Starsze protokoły TCP z mechanizmem TLS 1.2
Nawiązanie bezpiecznej sesji w ramach starszej architektury TCP i TLS 1.2 jest procesem sekwencyjnym wymagającym wielu cykli wymiany danych.
- Nawiązywanie połączenia TCP (1-RTT): Klient wysyła pakiet TCP SYN, serwer odpowiada pakietem SYN-ACK, a klient finalizuje połączenie pakietem ACK. Ta faza jest całkowicie niezaszyfrowana.
- Faza uzgadniania TLS 1.2 (2-RTT):
• ClientHello: Klient inicjuje ustalenia kluczy kryptograficznych, wysyłając komunikat ClientHello zawierający listę obsługiwanych zestawów szyfrów (obsługujących RSA, DSA lub ECDSA), metod kompresji oraz rozszerzeń, takich jak Server Name Indication (SNI).
• ServerHello: Serwer wyszukuje w pamięci podręcznej identyfikator sesji w celu wznowienia połączenia lub generuje nowy. Odpowiada komunikatem ServerHello, wskazującym wybrany zestaw szyfrów i wersję TLS, a następnie przesyła swój certyfikat X.509 zawierający klucz publiczny, opcjonalne parametry Diffie-Hellmana (jeśli wynegocjowano ECDHE/DHE) oraz komunikat ServerHelloDone.
• Wymiana kluczy i ustalenie klucza sesji: Klient weryfikuje łańcuch certyfikatów prowadzący do zaufanego urzędu certyfikacji. Następnie generuje losowy klucz pre-master, szyfruje go przy użyciu klucza publicznego serwera (jeśli wykorzystywany jest RSA) i przesyła go za pomocą komunikatu ClientKeyExchange. W przypadku wykorzystania zestawów DH ten etap obejmuje również przesłanie publicznych parametrów Diffie-Hellmana. Obie strony obliczają sekret główny przy użyciu wspólnych liczb losowych i klucza pre-master, tworząc ostatecznie symetryczne klucze sesji.
• Zakończenie uzgadniania połączenia: Klient wysyła sygnał „ChangeCipherSpec” oraz komunikat „Finished”. Serwer odpowiada analogicznie, wysyłając własne komunikaty „ChangeCipherSpec” i „Finished”, po czym rozpoczyna się przesyłanie danych aplikacji.
Ponieważ uzgadnianie połączenia w protokole TLS 1.2 odbywa się w postaci tekstu jawnego, osoby obserwujące ruch sieciowy mogą z łatwością uzyskać certyfikaty serwera, wynegocjowane rozszerzenia oraz parametry SNI.
Nowe podejście – protokół TCP z wykorzystaniem TLS 1.3
Standard TLS 1.3, określony w RFC 8446, optymalizuje cykl połączenia poprzez skrócenie procesu nawiązywania połączenia do jednej rundy (1-RTT) oraz wprowadzenie wymogu Perfect Forward Secrecy (PFS). Całkowicie eliminuje on obsługę wymiany kluczy RSA oraz wymiany kluczy Diffie-Hellmana.
• ClientHello z częścią klucza: Klient inicjuje negocjacje, wysyłając komunikat ClientHello zawierający listę obsługiwanych zestawów szyfrów (takich jak TLS_CHACHA20_POLY1305_SHA256) oraz metod wymiany kluczy. Co istotne, klient odgaduje protokół uzgadniania klucza serwera (zazwyczaj X25519) i dołącza swoją część klucza publicznego bezpośrednio do komunikatu początkowego, eliminując w ten sposób jedną rundę wymiany.
• Szyfrowany proces nawiązywania połączenia przez serwer: Serwer przetwarza część klucza publicznego klienta, generuje własną część klucza i oblicza sekret główny. Następnie wysyła komunikat ServerHello zawierający wybraną część klucza, po którym natychmiast następują zaszyfrowane komunikaty: zaszyfrowane rozszerzenia serwera, zaszyfrowany certyfikat serwera oraz komunikat ServerFinished.
• Zakończenie uzgadniania: Klient weryfikuje zaszyfrowany certyfikat, oblicza wspólną część klucza symetrycznego i odpowiada komunikatem ClientFinished.
Architektura ta gwarantuje, że wszystkie dane przesyłane po komunikacie „ServerHello” są szyfrowane. W rezultacie certyfikat serwera jest całkowicie chroniony przed pasywną analizą na poziomie warstwy sieciowej. W przypadku wznowionych sesji protokół TLS 1.3 obsługuje tryb Zero Round-Trip Time (0-RTT) poprzez wykorzystanie kluczy Pre-shared Key (PSK) pochodzących z poprzednich połączeń. Chociaż tryb 0-RTT minimalizuje opóźnienia, wiąże się on z zagrożeniami dla bezpieczeństwa: nie zapewnia pełnej poufności przekazywania (jeśli klucze sesji zostaną ujawnione, przechwycone dane 0-RTT mogą zostać odszyfrowane) i nie gwarantuje natywnie ochrony przed atakami typu replay.
Zunifikowana architektura QUIC i HTTP/3
QUIC to nowoczesny protokół transportowy zaprojektowany do działania w oparciu o protokół UDP, a nie TCP. Łączy on nawiązywanie połączenia transportowego oraz negocjację kryptograficzną w jeden, ujednolicony proces uzgadniania połączenia (handshake) trwający 1 RTT. W ramach protokołu QUIC komunikaty uzgadniania TLS 1.3 nie są przesyłane jako oddzielne warstwy; zamiast tego są one osadzone bezpośrednio w ramkach QUIC CRYPTO. To ujednolicone podejście pozwala na jednoczesne negocjowanie parametrów kryptograficznych i parametrów transportowych (takich jak identyfikatory połączeń i limity kontroli przepływu). Ponadto QUIC rozwiązuje problem blokowania typu Head-of-Line (HOL) występujący w protokole TCP poprzez wykorzystanie natywnego multipleksowania na poziomie strumieni. W protokole TCP utrata pojedynczego pakietu powoduje wstrzymanie całej transmisji do momentu ponownego przesłania pakietu. QUIC obsługuje strumienie danych niezależnie. Jeśli pakiet w strumieniu A zostanie utracony, strumień A samodzielnie zarządza jego retransmisją, podczas gdy strumień B kontynuuje transmisję danych bez zakłóceń.
Datagram TLS (DTLS)
W przypadku aplikacji UDP innych niż QUIC, wymagających szyfrowania, standardem jest protokół Datagram Transport Layer Security (DTLS). Protokół DTLS został zaprojektowany jako seria modyfikacji standardowego protokołu TLS w celu radzenia sobie z utratą pakietów, ich powielaniem i zmianą kolejności, które są nieodłącznymi cechami bezstanowych sprotokołów transportowych. DTLS 1.0 został zaprojektowany jako rozszerzenie protokołu TLS 1.1, DTLS 1.2 odpowiadał protokołowi TLS 1.2, a DTLS 1.3 (RFC 9147) funkcjonuje jako rozszerzenie protokołu TLS 1.3. DTLS 1.3 zapewnia gwarancje bezpieczeństwa kryptograficznego równoważne z protokołem TLS 1.3, z wyjątkiem ochrony kolejności przesyłanych pakietów i zapobiegania powtórnemu odtworzeniu.
Podczas wczesnych testowych wdrożeń TLS 1.3 operatorzy sieci napotykali powszechne przerwy/problemy w połączeniach, ponieważ istniejące urządzenia sieciowe takie jak NGFW i serwery proxy uległy „skostnieniu”(ossification) wokół formatu TLS 1.2. Jeśli urządzenia te napotykały nowy format uzgadniania połączenia lub nieoczekiwane parametry wersji, blokowały połączenie. Aby złagodzić ten efekt , TLS 1.3 naśladuje „odcisk sieciowy” protokołu TLS 1.2. W polu wersji starszej (legacy version) pakietu ClientHello klient podaje wersję 0x0303 (odpowiadającą TLS 1.2). Rzeczywista negocjacja protokołu TLS 1.3 odbywa się w ramach nowego rozszerzenia: supported_versions. Taka konstrukcja zapewnia kompatybilność ze starszymi urządzeniami sieciowymi, umożliwiając jednocześnie punktom końcowym nawiązywanie bezpiecznych połączeń TLS 1.3.
Mechanika i podstawy kryptograficzne Encrypted Client Hello (ECH)
Chociaż protokół TLS 1.3 szyfruje certyfikat serwera, nadal ujawnia żądaną nazwę domeny docelowej w postaci tekstu jawnego w rozszerzeniu Server Name Indication (SNI) komunikatu ClientHello. Ta luka jest wykorzystywana przez operatorów sieci, zapory sieciowe oraz państwa stosujące cenzurę do monitorowania, rejestrowania i blokowania połączeń z określonymi domenami. Protokół Encrypted Client Hello (ECH), znormalizowany w RFC 9849, eliminuje ten wyciek metadanych poprzez szyfrowanie całego początkowego uzgodnienia połączenia.
Ewolucja od ESNI do ECH
Pierwszym standardem opracowanym w celu ochrony metadanych domeny był Encrypted SNI (ESNI). ESNI izolował i szyfrował wyłącznie rozszerzenie SNI. Jednak późniejsza analiza sieci wykazała, że inne elementy w postaci jawnego tekstu w ramach ClientHello – takie jak rozszerzenie Application-Layer Protocol Negotiation (ALPN) oraz lista obsługiwanych zestawów szyfrów – mogą być skorelowane w celu zidentyfikowania domeny docelowej. Aby rozwiązać ten problem, ECH zastąpił ESNI, szyfrując całą strukturę ClientHello.
Architektura Dual ClientHello
ECH dzieli początkowy proces nawiązywania połączenia na dwuwarstwową strukturę komunikatów w ramach jednej transakcji:
• ClientHelloInner: Jest to autentyczny, prywatny komunikat ClientHello. Zawiera on prawdziwe, wrażliwe parametry połączenia, w tym rzeczywistą docelową domenę źródłową (prawdziwy SNI) oraz żądane protokoły ALPN. Jest on w całości zaszyfrowany.
• ClientHelloOuter: Jest to otwarta, pozorna „koperta” widoczna dla urządzeń sieciowych. Zawiera ona parametry niewrażliwe oraz publiczny, „fikcyjny” identyfikator SNI wskazujący na serwer front-endowy (zazwyczaj sieć CDN lub publiczny serwer reverse-proxy). ClientHelloOuter zawiera rozszerzenie encrypted_client_hello, które przenosi zaszyfrowany tekst szyfrowy ClientHelloInner.
Aby zaszyfrować komunikat ClientHelloInner przed nawiązaniem sesji z kluczem symetrycznym z serwerem, protokół ECH wykorzystuje hybrydowe szyfrowanie kluczem publicznym (HPKE, RFC 9180).
Proces kryptograficzny ECH: 1. Zapytanie DNS -> Wyodrębnienie listy ECHConfigList 2. Obliczenie pary kluczy DH (sk_ecdh, pk_ecdh) 3. Wykonanie funkcji HPKE.Encap(PK_ech, pk_ecdh) -> Wyprowadzenie klucza szyfrującego (enc) i wspólnego sekretu (shared_secret) 4. Przetworzenie wspólnego sekretu (shared_secret) przez HKDF -> Wyprowadzenie symetrycznych kluczy AEAD 5. Szyfrowanie ClientHelloInner -> Wstawienie do rozszerzenia ClientHelloOuter
Aby zaszyfrować procedurę nawiązywania połączenia, klient musi najpierw pobrać klucz publiczny serwera przeznaczony dla klientów (PK_ech) z rekordów DNS domeny typu Service Binding (SVCB, typ 64) lub HTTPS (typ 65). Klucz ten jest zakodowany w alternatywnym parametrze punktu końcowego o nazwie „ech”, sformatowanym jako lista ECHConfigList zakodowana w Base64. Po przeanalizowaniu listy ECHConfigList klient wybiera parę kluczy Diffie-Hellmana na krzywej eliptycznej: sk_ecdh i pk_ecdh. Następnie przeprowadza enkapsulację HPKE przy użyciu pobranego klucza publicznego.
Korzystając z wygenerowanego shared_secret, klient uruchamia opartą na HMAC funkcję generowania klucza typu „Extract-and-Expand” (HKDF) w celu wygenerowania symetrycznych kluczy i wartości „nonc” szyfrowania uwierzytelnionego z danymi powiązanymi (AEAD). Klient serializuje pakiet ClientHelloInner i szyfruje go przy użyciu secret_1 oraz secret_2, przekazując elementy pakietu ClientHelloOuter jako dane powiązane, aby zapobiec atakom typu „wytnij i wklej”. Ta zawartość jest umieszczana w rozszerzeniu encrypted_client_hello pakietu ClientHelloOuter i wysyłana do serwera. Gdy serwer obsługujący klienta odbiera pakiet, wykorzystuje swój klucz prywatny sk_ech do odszyfrowania. Jeśli odszyfrowanie się powiedzie, serwer kończy uzgodnienie, wykorzystując parametry określone w ClientHelloInner. Jeśli odszyfrowanie nie powiedzie się lub zostanie odrzucone, serwer kończy uzgodnienie, wykorzystując fałszywy ClientHelloOuter, umożliwiając klientowi bezpieczne pobranie zaktualizowanej listy ECHConfigList i ponowne podjęcie próby nawiązania połączenia.
Integracja przeglądarki i zależności DNS over HTTPS (DoH)
Przeglądarki internetowe, takie jak Firefox (która domyślnie włączył funkcję ECH począwszy od wersji 119), wiążą aktywację funkcji ECH bezpośrednio z wykorzystaniem protokołów Secure DNS. Aby bezpiecznie pobrać listę ECHConfigList, przeglądarka musi korzystać z protokołu DNS over HTTPS (DoH) lub DNS over TLS (DoT). Jeśli protokół DoH jest wyłączony lub jeśli przeglądarka wykryje ograniczenia wynikające np. z polityki firmowej, oprogramowanie zabezpieczające lub serwer proxy w środowisku korporacyjnym, automatycznie wyłącza funkcję ECH. Takie rozwiązanie zapobiega naruszaniu przez funkcję ECH kontroli administracyjnych w środowiskach zarządzanych, jednocześnie chroniąc prywatność użytkowników w sieciach, którym nie można ufać.
Ścieżka migracji do kryptografii kwantowej (PQC)
Obecne implementacje protokołu ECH wykorzystują klasyczną kryptografię opartą na krzywych eliptycznych (taką jak X25519) do uzgadniania kluczy w ramach HPKE, co sprawia, że są one podatne na ataki przyszłych komputerów kwantowych (podejście harvest now decrypt later). Aby rozwiązać ten problem, organizacja IETF planuje przejście na kryptografię postkwantową (PQC). Jednak migracja ECH do postkwantowego HPKE wiąże się z wyzwaniami dotyczącymi wydajności. Klucze publiczne i teksty zaszyfrowane są znacznie większe niż klasyczne klucze oparte na krzywych eliptycznych. Jeśli nie zostanie to starannie zoptymalizowane, przejście z ECH na algorytmy takie jak ML-KEM (Kyber) może podwoić rozmiar komunikatu ClientHello. Ten wzrost może spowodować fragmentację pakietów i utratę pakietów na poziomie IP, co sprawia, że efektywne projektowanie postkwantowego ECH jest kluczowym obszarem bieżących badań.
Mechanizmy deszyfrowania ruchu na zaporze sieciowej i przechwytywanie handshake
Ponieważ protokoły TLS 1.3 i ECH szyfrują metadane związane z nawiązywaniem połączenia, korporacyjne zapory sieciowe nie mogą już polegać na pasywnym, „out-of-band” monitorowaniu ruchu w celu jego kontroli. Aby wymuszać polityki bezpieczeństwa, NGFW muszą być na ścieżce ruchu sieciowego i pełnić rolę aktywnych serwerów proxy typu „man-in-the-middle” (MITM).
Dylemat związany z inspekcją TLS 1.3
W protokole TLS 1.2 zapory sieciowe mogły analizować certyfikat serwera w postaci jawnego tekstu w celu ustalenia domeny docelowej. W protokole TLS 1.3 certyfikat serwera jest zaszyfrowany. Jedynym atrybutem w postaci zwykłego tekstu dostępnym w treści komunikatu jest SNI zawarty w komunikacie ClientHello klienta. Opieranie się wyłącznie na SNI przy podejmowaniu decyzji dotyczących deszyfrowania wiąże się z dwoma głównymi zagrożeniami:
• Sfałszowanie SNI: złośliwy atakujący może wstawić zaufaną domenę (taką jak microsoft.com) do pola SNI w postaci jawnego tekstu podczas nawiązywania zaszyfrowanego połączenia ze złośliwym serwerem (C2), omijając w ten sposób reguły zapory sieciowej.
• Niezgodność z przepisami dotyczącymi prywatności: Ramy prawne (takie jak HIPAA lub RODO) wymagają, aby wrażliwe transakcje finansowe, medyczne i rządowe omijały proces deszyfrowania ruchu. Jeśli zapora sieciowa nie może zweryfikować rzeczywistego certyfikatu serwera przed podjęciem decyzji o kontroli ruchu, naraża się na ryzyko odszyfrowania wrażliwych danych użytkowników lub umożliwienia złośliwemu ruchowi ominięcia zabezpieczeń.
Rozwiązanie „Sidecar”
Aby zweryfikować tożsamość serwera przed podjęciem decyzji o odszyfrowaniu lub pominięciu połączenia TLS 1.3, zapory sieciowe wykorzystują technikę typu „sidecar”.
- Przechwycenie i wstrzymanie: Gdy klient wysyła pakiet TLS 1.3 ClientHello, zapora przechwytuje ten pakiet i wyodrębnia identyfikator SNI. Zapora wstrzymuje proces uzgadniania połączenia z klientem.
- Weryfikacja w pamięci podręcznej: Zapora przeszukuje lokalną pamięć podręczną certyfikatów serwerów, wykorzystując docelowy adres IP oraz wyodrębniony identyfikator SNI. Jeśli zostanie znaleziony pasujący certyfikat, zapora natychmiast ocenia swoją politykę.
- Badanie out-of-band: Jeśli certyfikat nie znajduje się w pamięci podręcznej, zapora wstrzymuje proces uzgadniania połączenia z klientem i inicjuje oddzielne, out-of-band połączenie TLS 1.2 („probe”) z serwerem docelowym.
- Wyodrębnianie certyfikatu: Ponieważ sonda „probe” negocjuje protokół TLS 1.2, serwer docelowy odpowiada, przesyłając swój certyfikat w postaci jawnego tekstu. Zapora sieciowa wyodrębnia alternatywną nazwę podmiotu (SAN) oraz dane wydawcy, kończy połączenie sondy „probe” i zapisuje certyfikat w pamięci podręcznej.
- Działanie zgodne z polityką: Zapora porównuje zweryfikowany certyfikat z własnymi zasadami deszyfrowania. Jeśli polityka nakazuje „Ominięcie”, zapora wznawia pierwotny, niezmodyfikowany proces nawiązywania połączenia TLS 1.3. Jeśli polityka nakazuje „Deszyfrowanie”, zapora zastępuje klucz klienta własnymi parametrami kryptograficznymi i inicjuje połączenie jako aktywny serwer proxy typu MITM.
W Firewall Cisco Firepower sposób wyzwalania „probe” typu „sidecar” zależy od konfiguracji priorytetów między polityką kontroli dostępu (ACP) a polityką dekrypcji ruchu.
Modyfikacja pakietu ClientHello w NGFW jako MITM
Gdy zapora sieciowa podejmuje decyzję o odszyfrowaniu połączenia, przerywa sesję TLS klienta i nawiązuje oddzielną sesję TLS z serwerem docelowym. W celu optymalizacji bezpieczeństwa i kompatybilności zapora modyfikuje kilka pól w oryginalnym komunikacie ClientHello klienta przed przekazaniem go do serwera:
• Metody kompresji: Zapora usuwa element compression_methods. Skompresowane sesje TLS nie mogą zostać odszyfrowane ani sprawdzone przez mechanizmy bezpieczeństwa firewall.
• Zestawy szyfrów: Zapora sieciowa usuwa nieobsługiwane zestawy szyfrów z listy cipher_suites. Zapobiega to negocjowaniu przez klienta i serwer algorytmu szyfrowania, którego zapora sieciowa nie jest w stanie odszyfrować.
• Identyfikatory sesji: Zapora sieciowa usuwa identyfikatory sesji oraz rozszerzenia SessionTicket, które nie pasują do jej lokalnej pamięci podręcznej. Wymusza to przeprowadzenie pełnego uzgadniania połączenia i zapobiega wznowieniu sesji poza pasmem.
• Krzywe eliptyczne: Nieobsługiwane krzywe są usuwane z rozszerzenia Supported Groups. Jeśli nie pozostaną żadne obsługiwane krzywe, rozszerzenie jest usuwane, a powiązane zestawy szyfrów są eliminowane.
• Rozszerzenia ALPN: Nieobsługiwane elementy negocjacji protokołu, takie jak parametry HTTP/2 lub HTTP/3 na urządzeniach, które ich nie obsługują, są usuwane z listy ALPN, aby wymusić powrót do standardowego protokołu HTTP/1.1.
• Identyfikatory kanałów i NPN: Rozszerzenia Next Protocol Negotiation (NPN) oraz TLS Channel ID są usuwane, aby zapobiec tworzeniu niestandardowych kanałów weryfikacyjnych między klientem a serwerem.
Implementacje klasy enterprise, strategie mitygacji i różnice między dostawcami
Zespoły bezpieczeństwa sieci w firmach muszą wdrażać strategie dostosowane do konkretnych dostawców w celu zarządzania nowoczesnymi protokołami szyfrowanymi.
Palo Alto Networks (PAN-OS 11.0 / Strata)
Zapory nowej generacji (NGFW) firmy Palo Alto Networks oraz rozwiązanie Prisma Access obsługują deszyfrowanie TLS 1.3 w trybach Forward Proxy i Inbound Inspection. Zarządzanie nowoczesnymi funkcjami szyfrowania wymaga jednak zastosowania określonych metod konfiguracji:
Dostosowanie ruchu aplikacji mobilnych
Firma Palo Alto Networks zaleca skonfigurowanie profili deszyfrowania w taki sposób, aby ograniczyć maksymalną negocjowaną wersję TLS do TLS 1.2 dla reguł dla aplikacji mobilnych. Ponieważ protokół TLS 1.3 szyfruje certyfikat serwera, zapora sieciowa nie może odczytać atrybutów certyfikatu w trybie inline w celu dynamicznego stosowania wyłączeń deszyfrowania. Wiele aplikacji mobilnych wykorzystuje mechanizm przypisywania certyfikatów (certificate pinning), co powoduje zerwanie połączeń w przypadku wykrycia ponownie podpisanego certyfikatu zapory sieciowej. Ograniczenie tych sesji do protokołu TLS 1.2 pozwala zaporze odczytać certyfikat w postaci jawnego tekstu i zastosować reguły „Brak deszyfrowania” przed wystąpieniem błędu weryfikacji.
Zabezpieczenia DNS w protokole DoH
Aby uniemożliwić użytkownikom i złośliwemu oprogramowaniu wykorzystywanie protokołu DNS over HTTPS (DoH) do omijania firmowych zabezpieczeń DNS, system PAN-OS 11.0 może deszyfrować ruch DoH. Zapora sieciowa odszyfrowuje żądania DNS wysyłanych do serwerów rozpoznających DoH, wyodrębnia żądane domeny i stosuje profile bezpieczeństwa. Nieautoryzowany ruch DoH jest identyfikowany za pomocą identyfikatora aplikacji dns-over-https i blokowany przy użyciu kategorii adresów URL „encrypted-dns”.
Strategia ograniczania QUIC
Zapory sieciowe Palo Alto Networks mogą analizować i kontrolować ruch QUIC, ale nie są w stanie go odszyfrować. Zezwolenie na ruch QUIC przez protokół UDP pozwala na ominięcie mechanizmów bezpieczeństwa, blokowania plików oraz filtrowania adresów URL, co może spowodować, że złośliwe pakiety przedostaną się do sieci niezauważone. Aby temu zapobiec, firma Palo Alto Networks zaleca globalne blokowanie protokołu QUIC:
• Utwórz regułę polityki bezpieczeństwa skonfigurowaną tak, aby blokowała identyfikator aplikacji (App-ID) QUIC.
• Utwórz regułę polityki bezpieczeństwa opartą na portach, aby zablokować porty UDP 80 i 443.
• Wykorzystaj obiekty GPO lub zasady MDM, aby administracyjnie wyłączyć protokół QUIC w zarządzanych przeglądarkach.
Zablokowanie protokołu QUIC zmusza aplikacje do przejścia na standardowy protokół TLS 1.3 oparty na TCP, który zapora sieciowa może odszyfrować i sprawdzić. Alternatywnie organizacje mogą wdrożyć przeglądarkę Prisma Access Browser, która integruje się z Enterprise DLP i WildFire w celu sprawdzania ruchu internetowego bezpośrednio na urządzeniu końcowym bez obciążenia związanego z odszyfrowywaniem ruchu na urządzeniu sieciowym.
Blokowanie ECH
Aby zachować skuteczność filtrowania adresów URL i identyfikacji aplikacji, firma Palo Alto Networks zaleca blokowanie ECH. W ramach profilu „Advanced DNS Security” administratorzy powinni zablokować rekordy typu 64 (SVCB), typu 65 (HTTPS) oraz typu 255 (ANY). Zapobiega to pobieraniu przez klientów listy ECHConfigList i zmusza ich do powrotu do standardowego ClientHello w postaci jawnego tekstu.
Fortinet (FortiOS 8.0.0)
Zapory sieciowe FortiGate wykorzystują specjalistyczne procesory ASIC NP7 i NP8 w celu odciążenia procesora od obliczeń związanych z generowaniem kluczy symetrycznych i asymetrycznych podczas deszyfrowania TLS 1.3, zapobiegając w ten sposób przeciążeniu procesora przy dużym obciążeniu.
Polityka ograniczania ECH
System FortiOS 8.0.0 oferuje różne strategie ograniczania ECH w zależności od aktywnego profilu inspekcji SSL/SSH:
• Tryb głębokiej inspekcji: Urządzenie FortiGate działa jako pełny serwer proxy i automatycznie usuwa rozszerzenie „encrypted_client_hello” z komunikatu ClientHello. Wymusza to na przeglądarce klienta powrót do standardowego połączenia TLS 1.3, ujawniając SNI w postaci zwykłego tekstu.
• Tryb inspekcji certyfikatów: Ponieważ inspekcja certyfikatów nie polega na robieniu proxy, zapora sieciowa nie może modyfikować uzgadniania połączenia klienta w trybie inline. W tym trybie administratorzy mogą blokować połączenia ECH na warstwie sieciowej lub usuwać klucze ECH na warstwie DNS.
# Metoda 1: Konfiguracja profilu SSL w celu blokowania handshake ECH, wymuszenie powrotu do tekstu jawnego
config firewall ssl-ssh-profile
edit "custom_cert_inspection"
config https
set status certificate-inspection
set encrypted-client-hello block
end
next
end
# Metoda 2: Konfiguracja profilu filtrowania DNS w celu usunięcia parametrów ECH z odpowiedzi DNS
config dnsfilter profile
edit "strict_dns_filter"
set strip-ech enable
next
endJeśli klient spróbuje skorzystać z protokołu ECH w pierwszej konfiguracji, zapora sieciowa zablokuje początkową wymianę danych, co spowoduje, że przeglądarka przejdzie na protokół ClientHello w postaci jawnego tekstu. W drugiej konfiguracji filtr DNS usuwa parametr „ech SvcParam” z przychodzących rekordów DNS. Pozbawiona klucza publicznego przeglądarka nie może zaszyfrować komunikatu ClientHello i domyślnie przechodzi na standardowy protokół TLS 1.3.
CheckPoint
Check Point Quantum R82 wprowadza natywną architekturę zaprojektowaną do bezpośredniej kontroli nowoczesnych protokołów szyfrowanych.
Dekrypcja HTTP/3 over QUIC
Podczas gdy starsze wersje wymagały blokowania protokołu QUIC, Check Point R82 posiada natywny silnik analizujący protokół HTTP/3 over QUIC. Zamiast wymuszać przełączenie na protokół TCP, firewall R82 Quantum mogą natywnie odszyfrowywać, analizować i izolować w środowisku sandbox ruchu HTTP/3 over QUIC. Wykorzystują one wieloprocesową architekturę HyperFlow w celu przyspieszenia przepływów typu „elephant” w protokole QUIC i zapobiegania wąskim gardłom.
Polityki bezpieczeństwa HTTPS dla ruchu wychodzącego i przychodzącego
W wersji R82 polityki kontroli HTTPS zostały podzielone na niezależne polityki ruchu dla ruchu wychodzącego i przychodzącego, zarządzane bezpośrednio w SmartConsole. Check Point R82 obsługuje wiele urzędów certyfikacji (CA) dla ruchu wychodzącego, co pozwala administratorom konfigurować odrębne urzędy certyfikacji (CA) dla różnych firewalli lub domen administracyjnych (w poprzednich wersjach obsługiwany był tylko jeden globalny urząd certyfikacji).
Innowacje w zakresie inspekcji HTTPS w SmartConsole
• Tryb uczenia się: Model R82 obsługuje stopniowy, dwutygodniowy tryb uczenia się.
W tej fazie brama inspekcyjna analizuje niewielki, kontrolowany odsetek ruchu, tworzy profil zachowań sieciowych, prognozuje wpływ pełnego odszyfrowania na obciążenie procesora oraz identyfikuje potencjalne problemy z łącznością przed wdrożeniem na pełną skalę.
• Tryb awarii po stronie klienta: Ten silnik oparty na sztucznej inteligencji wykrywa awarie połączeń spowodowane przypisaniem certyfikatów po stronie klienta. Po wykryciu awarii firewall automatycznie oznacza domenę docelową jako taką, którą należy ominąć podczas przyszłych prób.
• Wykrywanie punktów końcowych: firewall automatycznie identyfikuje i rejestruje urządzenia końcowe, na których nie zainstalowano certyfikatu CA, pomagając administratorom zidentyfikować luki we wdrożeniu.
• Ominięcie przy dużym obciążeniu: Gdy firewall odnotowuje wysokie obciążenie procesora, może tymczasowo ominąć niekrytyczne połączenia TLS w celu utrzymania dostępności sieci.
Wyzwania architektoniczne
Połączenie protokołów TLS 1.3, ECH, QUIC oraz szyfrowanego DNS stanowi znaczącą zmianę w zakresie bezpieczeństwa sieci. Tradycyjne modele bezpieczeństwa oparte na zabezpieczeniu perymetra sieci stoją przed poważnymi wyzwaniami technicznymi i operacyjnymi.
Prywatność a bezpieczeństwo
Wdrożenie protokołów ECH i DoH stanowi znaczącą zmianę w zakresie ochrony prywatności użytkowników, zwłaszcza w sieciach publicznych lub w regionach objętych nadzorem państwowym. Dzięki szyfrowaniu metadanych związanych z nawiązywaniem połączenia protokoły te uniemożliwiają biernym obserwatorom sieci tworzenie profili zachowań użytkowników. Choć dla zwykłych użytkowników rodzi się pytanie, któremu dostawcy usług DNS ufają bardziej? Swojemu operatorowi czy usługodawcy DoH.
Jednak te same mechanizmy stwarzają poważne zagrożenia w obrębie sieci firmowych. Złośliwe serwery typu „command-and-control” (C2) mogą wykorzystywać protokół ECH do ukrywania swoich domen docelowych za publicznym identyfikatorem SNI dużych sieci CDN. Technika ta, znana jako „domain fronting”, sprawia, że tradycyjne bazy danych reputacji sieci, listy filtrowania adresów URL oraz listy blokowanych domen stają się całkowicie nieskuteczne.
Wnioski i rekomendacje dla sieci firmowych
- Kontrola DNS i zapobieganie atakom ECH
Firmy muszą zapewnić kontrolę nad ścieżką wyszukiwania DNS, ponieważ stanowi ona punkt wyjścia dla ECH.
• Wymuszanie lokalizacji DNS: Skonfiguruj zasady zapory sieciowej tak, aby ruch DNS (port UDP/TCP 53) był dopuszczany wyłącznie do autoryzowanych, zarządzanych wewnętrznie korporacyjnych serwerów DNS lub zatwierdzonych bezpiecznych DNS. Zablokuj wszystkie wychodzące zapytania DNS kierowane do publicznych rekurencyjnych serwerów DNS.
• Identyfikacja i deszyfrowanie DoH: Wprowadź polityki blokujące nieautoryzowany ruch DNS-over-HTTPS (DoH) przy użyciu klasyfikacji App-ID. Deszyfruj autoryzowany ruch DoH w celu sprawdzenia i egzekwowania korporacyjnych zasad DNS.
• Usuwanie metadanych ECH: Włącz usuwanie metadanych ECH na serwerze DNS lub w profilu filtru DNS zapory sieciowej. Skonfiguruj silnik DNS tak, aby usuwał rekordy zasobów typu 64 (SVCB) i typu 65 (HTTPS) zawierające parametry ECH. - Handshake
Aby zachować możliwość odszyfrowywania, zapora sieciowa musi obsłużyć ruch tak, aby można poddać go inspekcji.
• Wymuś przełączenie QUIC: O ile organizacja nie wdrożyła nowoczesnych zapór sieciowych obsługujących natywną inspekcję QUIC (takich jak Check Point Quantum R82), należy wprowadzić globalną blokadę portów UDP 80 i 443. Zmusza to przeglądarki do korzystania z protokołu TLS 1.3 opartego na TCP, który może być przetwarzany przez proxy bezpośrednio na zaporze sieciowej.
• Aktywuj modyfikację uzgadniania połączenia: W profilu deszyfrowania TLS skonfiguruj usuwanie ECH w celu wyeliminowania rozszerzeń ECH z niezaszyfrowanych komunikatów ClientHello, uniemożliwiając klientom negocjowanie bezpiecznych uzgodnień połączeń z sieciami CDN. - Stopniowe wdrażanie dekrypcji
Źle zaplanowane wdrożenie dekrypcji ruchu może zakłócić procesy krytyczne dla działalności firmy.
• Wykorzystaj tryby uczenia się i oceny: wdrażaj konfiguracje dekrypcji w trybie uczenia się przez co najmniej dwa tygodnie. Skorzystaj z narzędzi diagnostycznych zapory sieciowej, aby zidentyfikować aplikacje przypisane do certyfikatów i wygenerować automatyczne reguły obejścia przed przejściem do trybu blokowania.
• Opracuj ustrukturyzowane zasady obejścia: Zawsze umieszczaj reguły obejścia zgodne z przepisami i wymogami dotyczącymi prywatności (np. dane medyczne, bankowość, usługi rządowe) na samym szczycie bazy reguł deszyfrowania. Wykorzystaj sonde „probe” typu „sidecar”, aby zapewnić, że decyzje dotyczące obejścia opierają się na zweryfikowanych certyfikatach serwerów, a nie na potencjalnie sfałszowanych parametrach SNI.
• Zbuduj zaufanie do infrastruktury PKI: Upewnij się, że certyfikat głównego urzędu certyfikacji (Root CA) zapory, który został ponownie podpisany, jest wstępnie zainstalowany w lokalnych magazynach certyfikatów wszystkich zarządzanych punktów końcowych za pośrednictwem MDM lub Active Directory, aby zapobiec wyświetlaniu ostrzeżeń bezpieczeństwa użytkownikom.
Na koniec jedna, nadrzędna zasada: nie ma głupich pytań. A nawet jeśli jakieś pytanie jest rzeczywiście głupie, to jeszcze większą głupotą jest go nie zadać i tkwić w tejże głupocie. Uderzajcie do nas mailowo lub wbijajcie na naszego Discorda. Zapraszamy.