Jak działa TLS w sieci i co widzi administrator na poziomie routera i firewall

Podstawy TLS w sieci – co tak naprawdę jest szyfrowane

Rola TLS w komunikacji sieciowej

Transport Layer Security (TLS) to standardowy mechanizm zapewniania poufności i integralności danych przesyłanych w sieci. Działa nad warstwą transportową (najczęściej TCP) i nie zastępuje IP ani TCP, ale owija ich ładunek w szyfrowaną „tubę”. Z punktu widzenia administratora routera czy firewalla, TLS zmienia przede wszystkim to, co da się odczytać z pakietu bez łamania szyfrowania.

W praktyce TLS odpowiada za:

• poufność – treść żądań i odpowiedzi (np. HTTP) staje się nieczytelna dla pośredników,
• integralność – utrudnia modyfikację danych „w locie” bez wykrycia,
• uwierzytelnienie serwera – klient może zweryfikować, że łączy się z właściwym serwerem (certyfikat),
• opcjonalne uwierzytelnienie klienta – np. logowanie certyfikatem po stronie użytkownika.

Na poziomie sieciowym nie zmienia się fakt, że mamy pakiety IP, nad nimi TCP, a nad TCP – jakiś protokół aplikacyjny. Różnica polega na tym, że zamiast czystego HTTP widoczna jest sesja TLS, a HTTP ukrywa się wewnątrz niej. Na firewallu typu stateful widać więc połączenia TCP do portu 443, 993, 465, 8443 itp., ale bez możliwości odczytania treści żądań HTTP(S) i odpowiedzi, jeśli nie stosuje się przechwytywania TLS.

Protokół TLS na osi czasu – od nawiązania do zamknięcia

Typowa sesja TLS składa się z kilku etapów. Administrator, który patrzy na ruch z poziomu routera lub firewalla, widzi głównie sekwencję pakietów TCP i wymianę wiadomości TLS w formie zaszyfrowanego strumienia bajtów. Jednak niektóre elementy handshake’u nadal są czytelne.

W dużym uproszczeniu przebieg wygląda tak (dla HTTP/1.1 lub HTTP/2 over TLS):

1. Klient wykonuje TCP three-way handshake (SYN, SYN/ACK, ACK).
2. Klient wysyła ClientHello – początek protokołu TLS.
3. Serwer odpowiada ServerHello i przesyła swój certyfikat.
4. Następuje uzgodnienie kluczy (współcześnie zwykle ECDHE/DHE).
5. Tworzony jest wspólny klucz sesyjny symetryczny.
6. Od tego momentu zawartość aplikacyjna jest szyfrowana.
7. Po zakończeniu sesji TLS następuje zamknięcie połączenia TCP (FIN/ACK).

W zależności od wersji TLS (1.0–1.3) szczegóły handshake’u się różnią: w TLS 1.3 skrócono go i przesunięto więcej elementów w stronę szyfrowaną. Dla administratora oznacza to mniej jawnych informacji dostępnych do klasycznej inspekcji.

Co szyfruje TLS, a co pozostaje w jawnym tekście

TLS nie szyfruje całego pakietu IP. Zabezpiecza tylko dane przesyłane między warstwą transportową a aplikacyjną. Z perspektywy urządzeń sieciowych można to podsumować następująco:

Samo szyfrowanie nie ukrywa informacji o kierunku, czasie i rozmiarach pakietów. Dlatego administrator nadal może analizować metadane ruchu: kto, dokąd, kiedy i jak intensywnie się łączy. Treść zapytania HTTP (np. adres URL z parametrami GET, nagłówki, ciało POST) jest jednak zaszyfrowana i bez dodatkowych mechanizmów nie da się jej podejrzeć ani zmodyfikować na standardowym firewallu.

Struktura pakietu w ruchu TLS – co widać bez łamania szyfrowania

Warstwa IP i TCP – niezmiennie widoczna

Dla każdego połączenia TLS wykorzystywany jest standardowy stos protokołów: IP + TCP. Te warstwy nie są zmieniane przez TLS, dlatego wszystkie urządzenia pośredniczące nadal widzą:

• adres źródłowy i docelowy IP,
• port źródłowy i docelowy TCP,
• flagi TCP (SYN, ACK, FIN, RST),
• rozmiar pakietów,
• czas ich przesyłania (możliwość analizy opóźnień, jittera),
• liczbę sesji z danego hosta do konkretnego IP/portu.

Z punktu widzenia routingu IP ważne jest, że szyfrowanie nie przeszkadza w normalnym przekazywaniu pakietów między routerami. Router nie musi rozumieć TLS, wystarczy, że zna adresy IP i potrafi przekazać pakiet do kolejnego hopu.

Warstwa TLS – handshake i szyfrowane rekordy

TLS definiuje własny format wiadomości (tzw. rekordy). Rekord TLS zawiera nagłówek z informacją o typie wiadomości (np. handshake, alert, dane aplikacyjne) oraz zaszyfrowany ładunek. Administrator może zobaczyć nagłówki rekordów (typ i długość), ale bez klucza sesyjnego nie odczyta treści.

Podczas handshake’u (przed pełnym zaszyfrowaniem) część informacji jest przesyłana w jawnym tekście. Należą do nich m.in.:

• lista wspieranych wersji TLS po stronie klienta,
• lista proponowanych szyfrów i algorytmów,
• rozszerzenia TLS, w tym istotne SNI (Server Name Indication),
• informacje o długości klucza, krzywe eliptyczne itp.

Po zakończeniu handshake’u większość dalszej komunikacji odbywa się już jako dane aplikacyjne TLS – zaszyfrowane, widoczne tylko jako ciąg bajtów o określonej długości. Jednak sam fakt, że w danym momencie przesyłane są dane (duży upload, burst pakietów) pozostaje widoczny w warstwie transportowej.

SNI, certyfikaty i inne widoczne metadane TLS

Rozszerzenie SNI (Server Name Indication) jest szczególnie ważne z perspektywy administratora. To pole w wiadomości ClientHello, w którym klient podaje nazwę hosta, z którym chce się połączyć (np. www.przyklad.pl). Dzięki temu na jednym adresie IP można hostować wiele certyfikatów. SNI jest przesyłane w jawnym tekście (w TLS < 1.3 oraz w standardowych konfiguracjach TLS 1.3 bez ESNI/ECH), więc firewall może:

• tworzyć reguły oparte o nazwę domeny (filtrowanie DNS-agnostyczne),
• kategoryzować ruch do poszczególnych serwisów mimo wspólnego IP,
• logować docelowe domeny użytkowników bez rozwiązywania DNS po stronie firewalla.

Certyfikat serwera również jest przesyłany w trakcie handshake’u w części nieszyfrowanej (dla TLS do wersji 1.2). Firewall, który potrafi parsować TLS, może więc:

• odczytać CN / Subject oraz rozszerzenia Subject Alternative Name,
• zweryfikować, kto wydał certyfikat (CA),
• sprawdzić datę ważności i użyte algorytmy kryptograficzne.

Nowsze mechanizmy jak Encrypted ClientHello (ECH) dążą do ukrycia SNI i innych danych handshake’u, ale ich zastosowanie jest jeszcze ograniczone. Gdy ECH stanie się powszechny, firewall bez przechwytywania TLS będzie widział znacznie mniej kontekstu przy analizie ruchu HTTPS.

Co widzi router – perspektywa warstwy 3 i 4

Router jako ślepy pośrednik dla TLS

Klasyczny router pracuje na poziomie warstwy sieciowej (L3) i, w bardziej zaawansowanych funkcjach, częściowo na warstwie transportowej (L4). Nie interpretuje protokołów z warstwy aplikacji ani TLS. Jego rola to przekazać pakiet IP we właściwe miejsce na podstawie tablicy routingu i ewentualnych polityk QoS.

Router widzi więc:

• kto (adres IP źródłowy) komunikuje się z kim (adres IP docelowy),
• po jakim protokole transportowym (TCP/UDP) i na jakie porty,
• ile ruchu generuje dane połączenie (liczba bajtów, PPS),
• jak wygląda ścieżka (trasa) do danego celu (routing, MPLS, VPN itd.).

Z perspektywy TLS router nie robi różnicy między HTTP a HTTPS. Dla niego to po prostu strumień TCP na dany port. Jedyna zmiana może dotyczyć polityk QoS lub limitów – administrator może zdefiniować, że ruch na port 443 ma określony priorytet lub ograniczenie przepustowości.

Metadane ruchu dostępne na routerze

Mimo że router nie widzi zawartości TLS, metadane ruchu pozwalają na dość szczegółową analizę zachowania hostów. Przy użyciu NetFlow/IPFIX lub mirrorowania portów do systemu NTA (Network Traffic Analysis) da się np.:

• identyfikować hosty generujące duże ilości szyfrowanego ruchu do jednego IP (podejrzenie tunelu lub exfiltracji),
• wykrywać skanowanie portów pod przykrywką TLS (np. SYN scan na port 443 do wielu IP),
• analizować czas trwania sesji TLS i częstotliwość nawiązywania połączeń (np. malware łączące się co kilka sekund do C2).

Na podstawie wzorców ruchu, nawet bez dostępu do treści, można wykonać profilowanie zachowań. Dla przykładu: użytkownik przeglądający strony WWW generuje zwykle krótkie, wielokrotne sesje TLS do wielu domen, z przewagą transferu w kierunku downstream. Inaczej wygląda stacja robocza nagle wysyłająca duże ilości danych do jednego, nietypowego hosta w internecie – to sygnał, który na routerze jest zauważalny.

Ograniczenia i możliwości zarządzania ruchem TLS na routerze

Router bez inspekcji TLS nie potrafi:

• zidentyfikować konkretnej aplikacji działającej wewnątrz TLS (np. czy to web, czy VPN w HTTPS),
• blokować konkretnych URL-i, zasobów czy słów kluczowych,
• analizować zawartości pod kątem złośliwych plików lub skryptów.

Może natomiast:

• ograniczać przepustowość na podstawie adresów IP, podsieci, portów,
• rozdzielać ruch według tras (policy-based routing) – np. cały ruch na port 443 przez określone łącze,
• wdrażać ACL-e na poziomie IP/port, blokując określone docelowe sieci/serwery TLS,
• monitorować poziomy wykorzystania łącza i alarmować o anomaliach.

Niektóre bardziej zaawansowane routery (lub routery z funkcjami NGFW) mogą klasyfikować aplikacje po sygnaturach ruchu (DPI – Deep Packet Inspection), ale w przypadku TLS ich skuteczność mocno spada, jeśli nie stosuje się przechwytywania SSL/TLS.

Co widzi firewall – od prostego stateful do NGFW

Firewall stateful bez inspekcji TLS

Klasyczny firewall stateful kontroluje:

• czy ruch pasuje do zdefiniowanej polityki (IP, port, protokół),
• czy pakiety należą do prawidłowo zestawionej sesji TCP (stan połączenia),
• czy nie dochodzi do naruszeń typu nielegalne flagi, nieprawidłowe numery sekwencji.

Z punktu widzenia takiego firewalla różnica między HTTP a HTTPS sprowadza się do innego portu docelowego (80 vs 443). W logach może więc rejestrować:

• źródło i cel ruchu (IP, port),
• czas rozpoczęcia i zakończenia sesji,
• liczbę przesłanych bajtów (TX/RX),
• akcję polityki (ALLOW/DENY).

Bez SSL inspection firewall nie będzie w stanie:

• blokować konkretnych kategorii stron (np. social media) po treści,
• rozpoznawać ataków webowych (SQLi, XSS) zaszytych w HTTPS,
• skanować plików pobieranych przez użytkownika.

NGFW i inspekcja TLS – przechwytywanie i terminacja

Nowoczesne zapory nowej generacji (NGFW, UTM) oferują funkcję SSL/TLS inspection. W praktyce oznacza to, że firewall przestaje być wyłącznie przekaźnikiem pakietów, a staje się pośrednikiem w sesji TLS – terminując ją po stronie klienta i nawiązuje osobne, szyfrowane połączenie do serwera.

Schemat jest następujący:

• klient zestawia TLS nie z oryginalnym serwerem, ale z adresem IP firewalla,
• firewall prezentuje klientowi własny certyfikat, wystawiony przez lokalne CA zaufane w systemach użytkowników,
• firewall deszyfruje ruch, analizuje go (AV, IPS, filtrowanie treści, DLP itd.),
• następnie szyfruje ruch ponownie i przesyła go dalej do właściwego serwera jako drugi, niezależny tunel TLS.

Z punktu widzenia routerów w środku sieci to nadal zwykła sesja TLS klient–serwer. Z perspektywy klienta – TLS zakończony na firewallu. Administrator firewalla, który ma dostęp do kluczy i certyfikatów używanych przez urządzenie, widzi natomiast pełną treść sesji aplikacyjnej.

Co firewall z inspekcją TLS faktycznie widzi

Po włączeniu przechwytywania TLS firewall przestaje być ograniczony wyłącznie do metadanych. Może:

• odczytywać pełne żądania HTTP(S), w tym URL, Header i treść Body,
• analizować przesyłane pliki (download i upload) pod kątem malware,
• egzekwować polityki DLP – np. blokować wysyłkę numerów PESEL czy dokumentów zawierających frazy kluczowe,
• identyfikować i kategoryzować aplikacje „ukryte” w HTTPS (np. komunikatory, proxy webowe, nieautoryzowane chmury),
• stosować klasyczne reguły WAF-owe (SQLi, XSS, command injection) także dla ruchu HTTPS.

W logach takiego urządzenia pojawiają się wpisy na poziomie:

• „użytkownik X pobrał plik report.docx z https://domena.pl/download”,
• „zablokowano POST do https://api.serwis.com/login z powodu podejrzenia SQLi”.

Dopiero przy takim poziomie wglądu administrator widzi rzeczywiste usługi i treści, a nie tylko „strumień TLS na port 443”.

Ograniczenia, wyjątki i problemy z przechwytywaniem TLS

Inspekcja TLS nie jest jednak magicznym narzędziem „widzącym wszystko” i ma szereg ograniczeń technicznych oraz organizacyjnych. W praktyce zwykle konfiguruje się:

• białe listy domen, dla których inspekcja jest wyłączona (np. serwisy bankowe, systemy medyczne),
• wyjątki dla aplikacji, które nie radzą sobie z MITM (część klientów VPN, niektóre aplikacje mobilne),
• różne poziomy inspekcji dla grup użytkowników – np. pełna inspekcja dla stacji roboczych, ograniczona lub brak dla serwerów.

Pojawiają się też kwestie techniczne:

• aplikacje pinujące certyfikat (certificate pinning) odrzucą połączenie, jeśli zobaczą certyfikat firewalla zamiast oryginalnego,
• protokół HTTP/2 i nowsze mechanizmy TLS (np. ECH) zwiększają złożoność inspekcji,
• wydajność – pełne deszyfrowanie i ponowne szyfrowanie wymaga sporej mocy obliczeniowej, zwłaszcza przy dużym wolumenie ruchu.

W sieciach korporacyjnych częstym kompromisem jest model „inspect by default, bypass dla wrażliwych serwisów”, oparty o kategorie URL, grupy domen oraz zaufane aplikacje biznesowe.

Konsekwencje dla prywatności użytkowników

Z punktu widzenia użytkownika inspekcja TLS oznacza, że administrator ma możliwość:

• czytania pełnej treści odwiedzanych stron (nie tylko adresów),
• przeglądania wgrywanych plików, załączników e-mail, treści formularzy,
• budowania bardzo dokładnego profilu aktywności w internecie.

W środowisku firmowym często formalizuje się to w regulaminach korzystania z sieci, politykach bezpieczeństwa i komunikatach przy logowaniu – tak, aby użytkownik był świadomy, że ruch HTTPS może być analizowany. W sieci domowej czy publicznej taki mechanizm pojawia się bardzo rzadko ze względu na brak centralnego zarządzania certyfikatami oraz kwestie etyczno-prawne.

Z technicznego punktu widzenia TLS wciąż spełnia swoją rolę – chroni dane w drodze między firewallami, w internecie. Jednak granica „zasięgu” szyfrowania przesuwa się z punktu końcowego (przeglądarka ↔ serwer) na komponent pośredni (przeglądarka ↔ firewall ↔ serwer).

Tunelowanie, VPN-y i TLS jako „opakowanie” innych protokołów

VPN w HTTPS (SSL VPN, DTLS, WireGuard over TLS)

Coraz częściej TLS staje się nie tylko mechanizmem szyfrującym HTTP, ale też transportem dla innych protokołów. Przykłady:

• SSL VPN – ruch użytkownika (warstwa IP) jest kapsułkowany w strumień TLS po porcie 443,
• OpenVPN w trybie TCP/443 lub UDP/443 (często z dodatkowymi warstwami maskującymi),
• rozwiązania typu „WireGuard over TLS” udające zwykły HTTPS, aby przechodzić przez ścisłe firewalle.

Dla routera taki tunel wygląda jak zwykła, długotrwała sesja TLS do pojedynczego IP. Dla klasycznego firewalla bez inspekcji – jak stałe połączenie HTTPS z jednym serwerem, z dużą ilością danych w obie strony. Administrator widzi:

• adresy IP końców tunelu,
• port 443 (lub inny skonfigurowany),
• objętość i charakterystykę ruchu (ciągły strumień zamiast typowych, krótkich sesji WWW).

Treść tunelu – czyli faktyczne pakiety IP innych sieci, protokoły RDP, SMB, SSH itp. – jest całkowicie niewidoczna bez przerwania lub zablokowania samego tunelu.

Jak rozpoznać tunel TLS na poziomie metadanych

W praktyce analityk sieciowy może po samych metadanych podejrzewać, że za ruchem TLS kryje się VPN lub inne tunelowanie. Typowe sygnały:

• bardzo długie sesje TLS (wiele godzin lub dni) do jednego hosta,
• przez większość czasu dwukierunkowy transfer o względnie stałej przepływności,
• brak typowego dla przeglądania internetu wzorca: krótka sesja – przerwa – kolejna sesja do innej domeny.

Do tego dochodzą sygnatury heurystyczne (np. charakterystyka rozmiaru pakietów, częstotliwość keepalive’ów) wykorzystywane przez systemy NTA/NDR. Jednak bez inspekcji TLS lub bez współpracy z endpointami nadal pozostaje to tylko analiza zachowania, a nie pełny wgląd w treść.

Jak TLS utrudnia klasyczny monitoring i IPS

Tradycyjne IPS a ruch szyfrowany

Klasyczne systemy IPS/IDS opierały się na inspekcji pakietów aplikacyjnych w formie nieszyfrowanej. Po wprowadzeniu powszechnego HTTPS:

• większość sygnatur ataków webowych stała się bezużyteczna bez deszyfracji,
• nie da się już prostym wyrażeniem regularnym wyszukać podejrzanego patternu w payloadzie,
• analiza protokołów takich jak HTTP, SMTP czy POP3 na brzegu sieci przestała być możliwa bez dodatkowych mechanizmów.

Odpowiedzią jest:

• integracja IPS z SSL inspection na firewallu lub dedykowanym proxy,
• przeniesienie części funkcji IPS na endpointy (EDR/XDR z inspekcją lokalną),
• wykorzystanie analityki behawioralnej zamiast wyłącznie sygnatur.

Tam, gdzie pełna inspekcja nie jest możliwa (ze względów prawnych lub wydajnościowych), pozostaje obserwacja anomalii na poziomie L3/L4 i logów systemowych.

Analiza opartej na metadanych i ML

Coraz więcej narzędzi bezpieczeństwa próbuje wykrywać zagrożenia wyłącznie na podstawie metadanych:

• czas trwania sesji, rozkład kierunków ruchu, liczba połączeń w czasie,
• historia komunikacji danego hosta (czy to typowy partner biznesowy, czy nowy, nieznany adres),
• informacje z DNS (domeny jednorazowe, świeżo zarejestrowane, domeny generowane algorytmicznie).

Model może np. zauważyć, że stacja księgowości nagle wysyła duży, ciągły strumień zaszyfrowanego ruchu do hosta w nietypowym kraju, choć dotąd łączyła się tylko z kilkoma znanymi serwisami bankowymi i CRM. To sygnał ostrzegawczy, mimo że treść TLS pozostaje zaszyfrowana.

TLS a widoczność w narzędziach sieciowych

NetFlow, IPFIX, sFlow i dane eksportowane z routerów/firewalli

Standardowe protokoły telemetryczne – NetFlow, IPFIX, sFlow – nie wchodzą w treść TLS. Dostarczają natomiast bogaty zestaw metadanych na poziomie przepływów:

• adresy IP źródłowe i docelowe, porty, protokół,
• czas rozpoczęcia i zakończenia przepływu, ilość bajtów i pakietów,
• flag TCP, informacje o retransmisjach (pośrednio – jakości łącza).

Niektóre implementacje rozszerzają to o:

• pole Application ID – wynik klasyfikacji aplikacji przez DPI (jeśli jest dostępne),
• dodatkowe etykiety – np. rozpoznaną domenę SNI, jeśli urządzenie potrafi odczytać ClientHello.

W praktyce system NTA/NDR otrzymuje więc informację: „host A prowadzi od godziny X do godziny Y sesję TLS do domeny przyklad.com, przeniesiono N bajtów, szczytowa przepustowość Mbit/s”, ale treść pozostaje tajemnicą.

Mirroring portów, SPAN, TAP i analiza offline

Często stosuje się też mirrorowanie ruchu (SPAN na przełączniku, TAP optyczny) do dedykowanych sensorów. Dla ruchu TLS taki sensor może:

• analizować strukturę pakietów, czas, rozmiary,
• parsować niezaszyfrowane części handshake’u, w tym SNI, wersje TLS, listę szyfrów,
• budować statystyki i wykrywać anomalie na bazie metadata-only.

Jeśli sensor nie ma dostępu do kluczy serwera (np. kluczy prywatnych certyfikatów), nie odszyfruje danych. Wyjątkiem są specyficzne środowiska, gdzie klucze są przekazywane np. do systemu monitoringu w centrum danych – wtedy, dla serwisów własnych, analiza pełnej treści jest możliwa bez przechwytywania po stronie klienta.

Specyfika TLS 1.3 a widoczność ruchu

Zmiany w handshake’u i ukrywanie większej części negocjacji

TLS 1.3 wprowadził szereg zmian, które dodatkowo ograniczają informacje dostępne dla pośredników:

• skrócony handshake (często 1-RTT lub nawet 0-RTT),
• większość parametrów negocjacji szyfrów przesyłana w formie zaszyfrowanej,
• brak wsparcia dla wielu starszych, „wygodnych do podglądu”, ale niebezpiecznych szyfrów.

W praktyce firewall lub sensor widzi:

• w jawnym tekście – ClientHello (z SNI, jeśli nie użyto ECH),
• częściowo – ServerHello i minimalne informacje potrzebne do zestawienia sesji,
• resztę – już jako szyfrowany strumień, łącznie z większością mechanizmów rozszerzeń TLS.

Dla administratorów oznacza to mniejszą widoczność „kto jakie szyfry próbuje wymusić” czy jakie rozszerzenia są używane – chyba że inspekcja TLS zostanie włączona.

Encrypted ClientHello (ECH) i dalsze ukrywanie metadanych

Mechanizm Encrypted ClientHello (ECH) ma na celu ukrycie szczegółów ClientHello, w tym SNI, przed urządzeniami pośredniczącymi. Scenariusz:

• klient pobiera z DNS dodatkową informację (tzw. ECHConfig) zawierającą klucz publiczny serwera frontowego,
• prawdziwe SNI i pozostałe dane ClientHello są szyfrowane tym kluczem,
• pośrednik widzi jedynie zewnętrzne, „fałszywe” SNI lub jego brak.

Kiedy ECH stanie się powszechny:

• klasyczne filtrowanie domen po SNI na firewallu przestanie działać,
• kategoryzacja ruchu po nazwie hosta stanie się znacznie trudniejsza bez współpracy z DNS resolverem lub endpointami,

Konsekwencje ECH dla polityk bezpieczeństwa w sieci firmowej

Gdy SNI przestaje być wiarygodnym wskaźnikiem docelowej usługi, wiele przyzwyczajeń administratorów traci sens. Dotychczasowe podejście: „pozwalamy ruch do <wybrane_domeny>, resztę blokujemy lub rejestrujemy” przestaje działać w oparciu wyłącznie o dane z warstwy TLS. Zostają inne dźwignie:

• kontrola dostępu na poziomie DNS (własny resolver, filtrowanie domen, DNS-over-HTTPS terminowany wewnątrz),
• silniejsze proxy HTTP(S) z obowiązkową konfiguracją w przeglądarkach lub erzacją przez PAC/transparent proxy,
• polityka „wszystko wychodzi przez określone egressy” (np. pojedynczy zestaw NAT-ów lub bram), a nie bezpośrednio do internetu.

W wielu organizacjach wymusza to przemyślenie architektury: od „płaskiego” wyjścia na zewnątrz z prostym firewallem do modelu, w którym większość sesji TLS kończy się na kontrolowanych punktach (proxy, bramy SASE, CASB), a dopiero potem wychodzi dalej.

Co faktycznie widzi administrator na routerze i firewallu TLS-heavy

Poziom routera L3 – spojrzenie czysto transportowe

Na klasycznym routerze L3 (brak DPI, brak inspekcji TLS) administrator ma przede wszystkim obraz ruchu z perspektywy IP i TCP/UDP. Dla sesji TLS sprowadza się to do:

• adresu IP źródłowego i docelowego,
• portu (zwykle 443, ale równie dobrze 8443, 9443, czy całkowicie niestandardowego),
• objętości danych i czasu trwania połączenia,
• podstawowych statystyk – retransmisje, RTT, ewentualne problemy z MTU.

Jeśli ruch jest routowany „w ciemno” (bez dodatkowego tagowania QoS czy policy-based routing), z punktu widzenia routera sesja TLS nie różni się od dowolnego innego TCP (poza rozkładem długości pakietów). Dlatego to właśnie na routerach zbiera się dane NetFlow/IPFIX, a analizę zachowania zostawia systemom NTA/NDR.

Poziom firewalla L4 – klasyfikacja po porcie i IP

Najprostsza forma firewalla aplikacyjnego dla ruchu TLS to nadal filtr L4 z kilkoma dodatkami. Reguły typu:

• „pozwól ruch TCP/443 z sieci biurowej do internetu”,
• „zabroń ruchu TLS z serwerów w DMZ do internetu, z wyjątkiem aktualizacji systemowych”

nie korzystają z treści TLS. Dają jednak pewną kontrolę: które segmenty mogą nawiązywać sesje szyfrowane i dokąd. W wielu incydentach to już wystarcza, by powstrzymać malware przed „telefonem do domu” – jeżeli ruch wychodzący z serwerów jest bardzo mocno ograniczony.

Problemy zaczynają się, gdy:

• użytkownicy mogą uruchamiać własne aplikacje tunelujące (np. własny klient VPN przez port 443),
• firmowe serwery muszą komunikować się z wieloma zewnętrznymi API (mikrousługi, SaaS, integracje),
• ruch HTTPS staje się głównym kanałem wszystkiego – od weba po backup.

Sama informacja „TCP/443 do internetu” przestaje mieć dużą wartość kontrolną. Na takim firewallu widać gdzie host się łączy i ile danych przesyła, ale nie co dokładnie robi.

Firewall z TLS inspection – widoczność aplikacyjna

Urządzenia NGFW z funkcją TLS inspection (MITM) mają już wgląd w treść ruchu, ale tylko w określonych warunkach:

• muszą wystawić własny certyfikat MITM, któremu ufają endpointy (zwykle przez instalację w magazynie zaufanych CA),
• nie zadziałają dla protokołów korzystających z certificate pinning (np. niektóre aplikacje mobilne, klienty bankowe, niektóre komunikatory),
• muszą obsłużyć wydajnościowo terminowanie i ponowne zestawianie tysięcy sesji TLS równocześnie.

Z punktu widzenia administratora zyskuje się wtedy:

• pełną widoczność HTTP(S) – URL-e, nagłówki, metody, kody odpowiedzi,
• możliwość stosowania IPS/AV/DLP wewnątrz strumienia,
• granularne polityki: np. „pozwól na <chmura_X>, ale zablokuj upload plików > X MB do niezatwierdzonych serwisów”.

Z drugiej strony:

• rosną koszty sprzętowe (akceleracja kryptograficzna, pamięć, licencje),
• dochodzi ryzyko prawne i prywatności (wgląd w treść prywatnej poczty, bankowość, zdrowie),
• pojawiają się luki – ruch, którego nie można terminować (np. z pinningiem), staje się blind spotem.



Segmentacja i projektowanie sieci pod „wszechobecny TLS”

Podział na strefy o różnym poziomie inspekcji

W praktycznych wdrożeniach rzadko stosuje się jeden, uniwersalny model inspekcji TLS. Częściej sieć dzieli się na strefy:

• strefa użytkowników – głębsza inspekcja weba, filtracja treści, kategoryzacja URL, DLP,
• strefa serwerów – ograniczone wyjście TLS, silne reguły L4/L7, pełny wgląd w ruch przychodzący,
• strefy specjalne (R&D, OT, laboratoria) – często minimalne „grzebanie” w ruchu ze względów zgodności lub stabilności, zamiast tego mocna kontrola dokąd w ogóle mogą się łączyć.

Każda z tych stref może mieć inny poziom:

• terminowania TLS (czy firewall/proxy rozplątuje szyfrowanie, czy przepuszcza end-to-end),
• rejestrowania metadanych (pełne logi URL vs. wyłącznie logi przepływów),
• analityki behawioralnej (NDR tylko dla serwerów, prostszy monitoring dla stacji roboczych itd.).

Dobrze zaprojektowana segmentacja potrafi zredukować liczbę miejsc, w których trzeba prowadzić ciężką inspekcję TLS – i tym samym uprościć polityki oraz sprzęt.

Przykładowy przepływ: użytkownik → proxy → internet

Typowy scenariusz w firmie, która chce mieć kontrolę nad HTTPS, ale nie chce „podsłuchiwać” wszystkiego w ciemno:

1. Przeglądarka jest skonfigurowana do korzystania z proxy HTTPS (ręcznie, GPO, MDM lub PAC).
2. Ruch TLS jest ustanawiany najpierw do proxy (TLS klient ↔ proxy), z certyfikatem własnym organizacji.
3. Proxy na podstawie polityki decyduje:
   • dla serwisów „wrażliwych” (np. bankowość) – tuneluje do docelowego hosta bez inspekcji (CONNECT, brak MITM),
   • dla reszty – terminowanie i ponowne zestawienie TLS do zewnętrznego serwera, z pełną inspekcją HTTP.
4. Firewall na wyjściu widzi głównie ruch proxy ↔ internet, a nie bezpośrednie połączenia stacji roboczych.

Administrator na poziomie proxy widzi wtedy: docelowe domeny, URL-e, typy plików, użytkowników (po SSO). Na poziomie routera/firewalla brzegowego – ruch pomiędzy proxy a światem, z metadanymi TLS (SNI, certyfikaty) tam, gdzie inspekcja nie jest stosowana.

TLS a narzędzia typu SIEM, EDR i NDR

Łączenie metadanych sieciowych z logami z hostów

W środowisku, gdzie większość ruchu jest szyfrowana, pojedyncze źródło danych przestaje wystarczać. Żeby zbudować pełniejszy obraz, łączy się:

• logi z firewalli/NGFW (kto, dokąd, kiedy, jakim protokołem),
• metryki z routerów i NetFlow/IPFIX (objętość, czas trwania, liczba sesji),
• telemetrię z EDR/XDR (jaki proces na hoście nawiązał połączenie, z jakim URI, z jakimi parametrami),
• alarmy z NDR (anomalie w zachowaniu sesji TLS, możliwe tunelowanie, C2).

Dopiero zestawiając:

• „host 10.10.5.23 utrzymuje od 3 godzin stałe połączenie TLS do 198.51.100.10, przepływ łącza ~ stały”
• z informacją „proces <nieznany.exe> na tej stacji używa biblioteki TLS spoza systemu i otworzył to połączenie chwilę po uruchomieniu pliku z maila”

SOC może wyciągnąć sensowny wniosek. Sam NetFlow nie odpowie, czy to backup, czy wyciek danych, a sam EDR nie powie, jaka jest charakterystyka ruchu w sieci szkieletowej.

Rola NDR w świecie TLS 1.3

Systemy NDR (Network Detection & Response) coraz częściej bazują wyłącznie na metadanych, czasem wzbogaconych o fragmenty handshake’u TLS. Typowe elementy wykorzystywane przez takie narzędzia:

• fingerprinty TLS (JA3/JA4) dla klienta i serwera – charakterystyczne kombinacje szyfrów, rozszerzeń i wersji,
• wzorce czasowe – okresowość połączeń, bursty ruchu, nietypowe godziny aktywności,
• nietypowe długości pakietów i kierunki transferu (np. dominujący upload w godzinach nocnych).

Dzięki fingerprintom TLS można wykryć np. malware korzystające z niestandardowych stosów TLS (inna lista szyfrów, dziwne rozszerzenia), nawet jeśli łączy się z pozornie „zaufanym” hostem (np. popularną chmurą). To podejście przypomina sygnatury w klasycznym IPS, ale funkcjonuje na poziomie negocjacji szyfrowania, nie treści.

Przykładowe scenariusze z punktu widzenia administratora

Scenariusz 1: Nieautoryzowany VPN przez TLS

Objawy w logach:

• stacja robocza z sieci biurowej ustanawia jedną, bardzo długą sesję TCP/443 do pojedynczego IP w chmurze,
• ilość danych rośnie w obie strony, nawet gdy użytkownik deklaruje „nic nie robię”,
• firewall klasyfikuje ruch jako „HTTPS”, bez dodatkowych informacji aplikacyjnych.

Na routerze/NetFlow:

• widać nietypowy wolumen ruchu z tego hosta w porównaniu z innymi stacjami o podobnym profilu,
• sesja jest praktycznie non-stop, bez typowego patternu stron WWW.

Jeśli organizacja nie stosuje TLS inspection ani NDR, możliwości reakcji to głównie:

• blokada po IP docelowym (reaktywna – po identyfikacji),
• wprowadzenie reguł: „z sieci <X> ruch HTTPS tylko do listy zatwierdzonych destynacji/proxy”,
• ewentualnie sandboxing hosta (EDR) w celu sprawdzenia, co uruchomił użytkownik.

Scenariusz 2: Atak na serwer www z TLS 1.3

Serwer HTTP(S) wystawiony za firewallem terminującym TLS 1.3. Co widzą poszczególne warstwy?

• Firewall bez inspekcji TLS:
  • wzrost liczby połączeń TCP/443 do IP serwera,
  • czasem nietypowo dużo przerwanych handshake’ów lub błędów TCP,
  • brak wglądu w same żądania HTTP (np. SQLi, XSS).
• Firewall z TLS inspection lub reverse proxy:
  • pełne logi HTTP: ścieżki, parametry, nagłówki,
  • możliwość zastosowania reguł WAF (np. blokada charakterystycznych patternów ataków),
  • ewentualne korelacje: ten sam fingerprint TLS / adres źródłowy atakuje różne ścieżki aplikacji.
• Router szkieletowy:
  • tylko skok wolumenu ruchu do adresu serwera,
  • ewentualne objawy DDoS (wysycenie łącza, wzrost CPU, kolejki w interfejsach).

Bez inspekcji TLS analiza takiego incydentu na brzegu sieci sprowadza się do „jest DDoS lub skan, ale nie wiemy, jakiego typu ataki webowe idą w środku”. Dokładniejszy obraz wymaga logów z samej aplikacji lub z reverse proxy.

Kierunki rozwoju: większe szyfrowanie, większa zależność od endpointów

Coraz mniej informacji w sieci, coraz więcej na końcówkach

Wraz ze wzrostem użycia TLS 1.3, ECH, DoH/DoT i rozwiązań typu QUIC/HTTP/3, warstwa sieciowa traci kolejne elementy, które kiedyś były jawne:

• treść HTTP,

Najczęściej zadawane pytania (FAQ)

Co dokładnie szyfruje TLS, a co nadal widzi router lub firewall?

TLS szyfruje dane pomiędzy warstwą transportową (np. TCP) a aplikacyjną. Oznacza to, że treść protokołów takich jak HTTP, SMTP czy IMAP (adresy URL, nagłówki, parametry, treść formularzy, ciało e‑maili) jest niewidoczna dla urządzeń pośredniczących, o ile nie stosuje się przechwytywania TLS.

Router lub firewall nadal widzą:

• adresy IP źródłowe i docelowe,
• porty TCP/UDP (np. 443 dla HTTPS),
• nagłówki IP i TCP (flagi, numery sekwencji, rozmiary pakietów),
• czas i częstotliwość połączeń oraz ilość przesyłanych danych.

Szyfrowana jest natomiast sama zawartość protokołu aplikacyjnego oraz większość komunikacji po zakończeniu handshake’u TLS.

Co administrator może zobaczyć w ruchu HTTPS bez łamania TLS?

Bez terminacji lub przechwytywania TLS administrator może analizować przede wszystkim metadane: kto (IP źródłowe) łączy się z kim (IP docelowe), na jaki port, jak długo trwa sesja i jak duży jest transfer. Widoczne są też ogólne informacje o strukturze rekordów TLS, takie jak ich typ i długość, ale nie zaszyfrowana treść.

Dodatkowo, w trakcie handshake’u TLS (szczególnie w wersjach do 1.2) często można odczytać:

• nazwę hosta w polu SNI (Server Name Indication),
• prezentowany przez serwer certyfikat (CN, SAN, wystawca, okres ważności),
• proponowane przez klienta wersje TLS i zestawy szyfrów.

Sama zawartość żądań i odpowiedzi HTTP(S) pozostaje niewidoczna.

Co to jest SNI i dlaczego firewall może na jego podstawie filtrować ruch?

SNI (Server Name Indication) to rozszerzenie TLS, w którym klient podczas handshake’u przesyła nazwę hosta, z którym chce się połączyć (np. www.przyklad.pl). Dzięki temu serwer może dobrać właściwy certyfikat, nawet gdy wiele domen współdzieli ten sam adres IP.

Ponieważ SNI jest zazwyczaj przesyłane w jawnym tekście, firewall potrafiący analizować TLS może:

• tworzyć reguły filtrujące w oparciu o nazwę domeny (np. blokada wybranych serwisów),
• kategoryzować i logować ruch per domena, mimo wspólnego IP,
• wdrażać polityki bezpieczeństwa bez konieczności „łamania” szyfrowania.

Wyjątkiem są scenariusze z ECH (Encrypted ClientHello), gdzie SNI jest również szyfrowane.

Czym różni się widoczność ruchu w TLS 1.2 i TLS 1.3 dla administratora?

W TLS 1.2 większa część handshake’u jest przesyłana w sposób czytelny, co pozwala firewallom łatwiej odczytać m.in. certyfikat serwera, wersje protokołu i część parametrów kryptograficznych. Administrator ma więc więcej jawnych danych do klasycznej inspekcji.

TLS 1.3 skraca i upraszcza handshake, a więcej informacji przenosi do części szyfrowanej. Efektem jest mniejsza ilość metadanych dostępnych „w prosty sposób” dla urządzeń pośrednich. Nadal zwykle widoczne jest SNI, ale wiele innych szczegółów procedury uzgadniania kluczy staje się niewidocznych bez aktywnej terminacji TLS.

Czy router musi „rozumieć” TLS, żeby poprawnie routować ruch HTTPS?

Router nie musi rozumieć TLS ani analizować warstwy aplikacyjnej, aby przekazywać ruch HTTPS. Operuje on głównie na warstwie sieciowej (IP) i transportowej (TCP/UDP), bazując na adresach IP, portach i własnej tablicy routingu.

Z punktu widzenia routera sesja HTTPS to zwykłe połączenie TCP na określony port (np. 443). TLS jest dla niego tylko zaszyfrowanym ładunkiem, który nie ma wpływu na podstawowe działanie routingu, QoS czy mechanizmów typu MPLS/VPN.

Co musi zrobić administrator, żeby „zajrzeć” do zaszyfrowanego ruchu TLS?

Aby zobaczyć treść żądań i odpowiedzi wewnątrz TLS, administrator musi zastosować mechanizmy przechwytywania lub terminacji TLS, nazywane często SSL inspection lub TLS offloading. Polega to na tym, że ruch jest zestawiany w dwóch sesjach: klient–firewall i firewall–serwer, a firewall działa jako pośrednik posiadający dostęp do odszyfrowanej treści.

Wymaga to:

• zainstalowania i zaufania do certyfikatu wystawionego przez urządzenie pośredniczące (np. na stacjach roboczych w firmie),
• odpowiedniej mocy obliczeniowej i konfiguracji polityk prywatności,
• świadomości użytkowników i zgodności z przepisami (np. RODO) w przypadku inspekcji treści.

Bez takich rozwiązań standardowy router lub firewall nie ma możliwości podglądu ani modyfikacji samej treści szyfrowanego ruchu.

Co warto zapamiętać

• TLS szyfruje warstwę aplikacyjną (np. HTTP), ale nie zmienia warstw IP i TCP – routery i firewalle nadal widzą adresy IP, porty, flagi TCP i mogą normalnie routować ruch.
• Dla administratora standardowy ruch HTTPS to po prostu połączenia TCP (najczęściej na port 443) z zaszyfrowaną treścią – bez przechwytywania TLS nie da się podejrzeć adresów URL, nagłówków ani treści żądań i odpowiedzi.
• Podczas handshake’u TLS część informacji jest jawna: wersje TLS, listy szyfrów, parametry kryptograficzne i rozszerzenia (w tym SNI), co pozwala na podstawową analizę i klasyfikację ruchu.
• Po ustanowieniu klucza sesyjnego cała komunikacja aplikacyjna jest szyfrowana i widoczna jedynie jako strumień rekordów TLS o określonej długości, bez dostępu do faktycznej zawartości.
• Samo szyfrowanie nie ukrywa metadanych: administrator widzi kto, dokąd, kiedy i jak intensywnie się łączy (częstotliwość, rozmiary pakietów, czas trwania sesji), co umożliwia analizę zachowań, ale nie treści.
• W nowszej wersji TLS 1.3 więcej elementów handshake’u jest zaszyfrowanych, więc urządzenia pośredniczące mają mniej jawnych danych do klasycznej inspekcji w porównaniu z wcześniejszymi wersjami.
• Rozszerzenie SNI w ClientHello ujawnia nazwę hosta, z którym łączy się klient, co bywa kluczowe dla polityk bezpieczeństwa, filtrowania i diagnostyki ruchu szyfrowanego.

Warte uwagi:

• 

  Warstwy modelu OSI: Zrozumieć sieci od podstaw

• 

  Jak działa oprogramowanie typu firewall?

• 

  Jak działa firewall i czy warto mieć go włączonego?

• 

  Czym różni się firewall sprzętowy od programowego?

• 

  TCP/IP vs UDP – kiedy co stosować?

• 

  Jak wygląda praca administratora sieci?