TLS Inspection – jak działa inspekcja szyfrowanego ruchu HTTPS

TLS Inspection to mechanizm bezpieczeństwa pozwalający urządzeniu pośredniczącemu, np. firewallowi, analizować treść ruchu szyfrowanego przez TLS.

Ma to ogromne znaczenie, ponieważ większość współczesnego ruchu internetowego korzysta z HTTPS. Bez inspekcji firewall może widzieć:

IP źródłowe
IP docelowe
Port 443

ale niekoniecznie zobaczy, co znajduje się wewnątrz szyfrowanej komunikacji.

Dlaczego TLS Inspection jest potrzebne?

Bez inspekcji:

                 HTTPS
Client ===================== Server
        encrypted traffic

Firewall może wiedzieć:

192.168.10.25
      |
      | TCP/443
      v
203.0.113.50

ale zawartość jest zaszyfrowana.

Jeżeli złośliwe oprogramowanie wykorzystuje HTTPS do komunikacji z C2:

Malware
   |
   | encrypted HTTPS
   v
C2 Server

klasyczny firewall może mieć ograniczone możliwości wykrycia zawartości tej komunikacji.

Jak działa TLS Inspection?

Firewall staje się pośrednikiem TLS.

Schemat:

Client
   |
   | TLS
   v
Firewall
   |
   | TLS
   v
Internet Server

W praktyce firewall tworzy dwie sesje TLS:

Client
   |
TLS session #1
   |
Firewall
   |
TLS session #2
   |
Server

Firewall może więc odszyfrować ruch, przeanalizować go i ponownie zaszyfrować.

Kluczowa idea – TLS Proxy

Bez inspekcji:

Client ================= Server
          TLS

Z inspekcją:

Client ======> Firewall ======> Server
          TLS       TLS

Firewall musi zatem zachowywać się jak TLS proxy.

Co firewall może wtedy zobaczyć?

Po odszyfrowaniu ruchu możliwa jest analiza między innymi:

• URL,
• HTTP headers,
• metod HTTP,
• treści żądania,
• treści odpowiedzi,
• pobieranych plików,
• malware,
• exploitów,
• podejrzanych domen.

Przykład:

GET /download/malware.exe

IPS może teraz przeanalizować zawartość żądania lub odpowiedzi.

TLS Inspection a HTTPS

Normalnie:

HTTPS
  |
  v
Encrypted
  |
  v
Firewall
  |
  v
Server

Firewall nie ma dostępu do pełnej treści.

Po TLS Inspection:

HTTPS
  |
  v
Decrypt
  |
  v
Security Inspection
  |
  +--> Allow
  |
  +--> Block
  |
  v
Re-encrypt

Certyfikat CA

To jeden z najważniejszych elementów TLS Inspection.

Urządzenia użytkowników muszą ufać certyfikatowi CA używanemu przez firewall.

Przykładowo:

Enterprise Root CA
        |
        v
     Firewall
        |
        v
Client trusts CA

Firewall może generować certyfikaty dla odwiedzanych domen.

Co widzi użytkownik?

Użytkownik odwiedza:

https://example.com

Bez TLS Inspection:

Certificate:
example.com

Z TLS Inspection może zobaczyć certyfikat wystawiony przez firmowy CA dla:

example.com

a firewall utrzymuje osobne połączenie TLS z prawdziwym serwerem.

Dlaczego urządzenia muszą ufać CA?

Jeżeli komputer nie ufa CA:

Client
   |
   v
Firewall
   |
Fake / untrusted certificate
   |
   X
Certificate warning

Użytkownik zobaczy błąd certyfikatu.

Dlatego w środowisku firmowym certyfikat CA jest zwykle dystrybuowany centralnie przez:

• Active Directory / Group Policy,
• MDM,
• system zarządzania urządzeniami.

TLS Inspection a prywatność

To bardzo ważny aspekt.

TLS Inspection oznacza, że organizacja może potencjalnie zobaczyć treść szyfrowanej komunikacji użytkowników.

Dlatego wdrożenie powinno być zgodne z:

• polityką bezpieczeństwa,
• zasadami prywatności,
• obowiązującymi przepisami,
• zasadami minimalizacji danych.

Nie powinno się po prostu odszyfrowywać całego ruchu bez określenia zakresu i celu.

Nie wszystko powinno być inspekcjonowane

Typowo tworzy się wyjątki.

Przykład:

TLS Inspection
      |
      +---- Banking      BYPASS
      |
      +---- Healthcare   BYPASS
      |
      +---- Personal     BYPASS
      |
      +---- Corporate    INSPECT

Zakres zależy od polityki organizacji.

TLS Inspection i Certificate Pinning

Jednym z problemów może być certificate pinning.

Aplikacja może oczekiwać konkretnego certyfikatu lub klucza.

Schemat:

Application
     |
Expected Certificate
     |
     X
Firewall-generated Certificate

Aplikacja może wtedy odrzucić połączenie.

Dotyczy to szczególnie niektórych aplikacji mobilnych i specjalistycznego oprogramowania.

TLS 1.3

TLS 1.3 zwiększył bezpieczeństwo i prywatność protokołu, ale nie oznacza to automatycznie, że TLS Inspection jest niemożliwe.

Firewall musi jednak prawidłowo obsługiwać współczesny TLS.

Schemat:

Client
  |
TLS 1.3
  |
Firewall
  |
TLS 1.3
  |
Server

Firewall nadal może pełnić rolę pośrednika TLS, o ile rozwiązanie i konfiguracja to wspierają.

TLS Inspection a HTTP/2

Współczesny HTTPS często wykorzystuje HTTP/2.

Dlatego system inspekcji powinien prawidłowo obsługiwać:

• HTTP/2,
• TLS 1.2,
• TLS 1.3,
• nowe mechanizmy HTTP.

TLS Inspection a QUIC / HTTP/3

To jeszcze ciekawszy przypadek.

HTTP/3 wykorzystuje QUIC, który działa nad UDP.

HTTP/1.1 → TCP
HTTP/2   → TCP
HTTP/3   → QUIC / UDP

Dlatego klasyczna inspekcja TLS dla TCP/443 nie wystarczy.

W środowisku firmowym trzeba uwzględnić:

TCP/443
+
UDP/443

Jeżeli organizacja nie ma odpowiedniej obsługi QUIC, może stosować polityki ograniczające lub kontrolujące HTTP/3, aby wymusić ruch przez ścieżkę, którą potrafi inspekcjonować.

TLS Inspection + IDS/IPS

To bardzo ważne w kontekście poprzednich tematów.

Bez TLS Inspection:

HTTPS
   |
   v
Suricata
   |
Encrypted Content

Możliwości analizy treści są ograniczone.

Po TLS Inspection:

HTTPS
   |
   v
TLS Inspection
   |
Decrypted Traffic
   |
   v
Suricata
   |
   +---- ALERT
   |
   +---- DROP

Dzięki temu IDS/IPS może analizować większą część ruchu aplikacyjnego.

TLS Inspection + Zeek

Podobnie można zwiększyć widoczność dla Network Security Monitoring.

Client
  |
HTTPS
  |
TLS Inspection
  |
Decrypted Traffic
  |
Zeek
  |
Logs

Zeek może wtedy uzyskać znacznie więcej informacji niż w przypadku obserwacji wyłącznie zaszyfrowanego ruchu.

TLS Inspection + DLP

Inspekcja TLS może również współpracować z Data Loss Prevention.

Przykład:

Employee
   |
HTTPS Upload
   |
TLS Inspection
   |
DLP
   |
Sensitive Data?
   |
   +---- YES → BLOCK
   |
   +---- NO → ALLOW

Możliwe jest wykrywanie prób wysłania określonych danych poza organizację.

TLS Inspection + Malware Detection

Przykład:

User
 |
HTTPS
 |
Firewall
 |
Decrypt
 |
Antimalware / IPS
 |
Malicious File
 |
DROP

Bez odszyfrowania firewall może mieć znacznie mniej informacji.

TLS Inspection + OPNsense

W środowiskach opartych na OPNsense można budować architekturę:

                    INTERNET
                       |
                       v
                   OPNsense
                       |
                TLS Inspection
                       |
             +---------+---------+
             |                   |
          Suricata              DNS
             |
             v
            LAN

Dokładne możliwości zależą jednak od zastosowanych komponentów i wersji systemu.

TLS Inspection + pfSense

Podobnie w środowiskach pfSense można wykorzystać rozwiązania proxy/firewall umożliwiające kontrolę szyfrowanego ruchu.

Architektura:

Client
   |
   v
pfSense / Proxy
   |
TLS Inspection
   |
IPS / Filtering
   |
Internet

TLS Inspection w przedsiębiorstwie

Przykładowa architektura:

                         INTERNET
                            |
                            v
                       Edge Firewall
                            |
                            v
                      TLS Inspection
                            |
              +-------------+-------------+
              |             |             |
             IPS           DLP          AV
              |             |             |
              +-------------+-------------+
                            |
                         Network
                            |
              +-------------+-------------+
              |             |             |
            Users         Servers        DMZ

To może zapewnić znacznie większą kontrolę nad ruchem.

Największe zalety TLS Inspection

1. Widoczność HTTPS

Możliwość analizy treści szyfrowanego ruchu.

2. Lepsze IDS/IPS

Suricata/Snort mogą analizować więcej danych.

3. Malware detection

Możliwość kontroli pobieranych treści.

4. DLP

Możliwość wykrywania przesyłania poufnych danych.

5. Web filtering

Możliwość dokładniejszego filtrowania ruchu.

Wady TLS Inspection

Nie jest to rozwiązanie bez kosztów.

Wydajność

Firewall musi:

Decrypt
↓
Inspect
↓
Encrypt

To wymaga CPU i pamięci.

Złożoność

Dochodzi:

• CA,
• certyfikaty,
• dystrybucja zaufania,
• wyjątki,
• troubleshooting.

Kompatybilność

Niektóre aplikacje mogą nie działać z TLS proxy.

Prywatność

Organizacja uzyskuje dostęp do potencjalnie wrażliwego ruchu.

Najczęstsze błędy

❌ inspekcja całego Internetu bez wyjątków

❌ brak zarządzania CA

❌ brak polityki prywatności

❌ brak obsługi urządzeń mobilnych

❌ ignorowanie HTTP/3/QUIC

❌ brak monitorowania wydajności

❌ brak procedury dla aplikacji korzystających z certificate pinning

❌ wdrożenie od razu w trybie blokowania

Dobra strategia wdrożenia

Podobnie jak w przypadku IPS warto działać etapami:

Planowanie
    ↓
CA
    ↓
Testowa grupa urządzeń
    ↓
TLS Inspection
    ↓
Monitoring
    ↓
Wyjątki
    ↓
IDS / DLP / Malware Detection
    ↓
Selective Blocking
    ↓
Produkcja

Najpierw warto wdrożyć inspekcję na niewielkiej grupie urządzeń, sprawdzić kompatybilność i dopiero rozszerzać zakres.

TLS Inspection a Zero Trust

TLS Inspection może być jednym z elementów architektury Zero Trust:

User
 |
Device Identity
 |
TLS Inspection
 |
Policy
 |
Application
 |
Access

Nie zastępuje jednak Zero Trust. Jest tylko jednym z mechanizmów kontroli ruchu.

TLS Inspection – najważniejsza rzecz

Trzeba zapamiętać jeden prosty schemat:

Bez inspekcji:

Client =================== Server
             TLS

Firewall widzi głównie metadane połączenia.

Z inspekcją:

Client ======> Firewall ======> Server
          TLS       TLS

Firewall może odszyfrować ruch, przeanalizować go i ponownie zaszyfrować.

Podsumowanie

TLS Inspection pozwala przełamać problem „ślepego punktu”, jakim dla wielu systemów bezpieczeństwa jest szyfrowany HTTPS.

W połączeniu z wcześniejszymi elementami:

                    INTERNET
                       |
                    Firewall
                       |
                 TLS Inspection
                       |
              +--------+--------+
              |        |        |
           Suricata   Zeek      DLP
              |        |        |
              +--------+--------+
                       |
                      SIEM
                       |
                      SOC

otrzymujemy znacznie większą widoczność ruchu.

Najważniejsze jest jednak zachowanie równowagi między bezpieczeństwem, wydajnością, kompatybilnością i prywatnością. TLS Inspection powinno być wdrażane jako świadomie zaprojektowana polityka bezpieczeństwa, a nie jako proste „odszyfruj wszystko”.

Polecane wpisy

Diagnostyka sieci LAN i WAN: Wybór odpowiedniego programu

Diagnostyka sieci LAN i WAN: Wybór odpowiedniego programu Istnieje wiele programów, które mogą pomóc w diagnozowaniu problemów z siecią LAN Czytaj dalej

Routing między sieciami lokalnymi – przykład

Routing między sieciami lokalnymi - przykład Wstęp W tym artykule przedstawimy przykład konfiguracji routingu między dwoma sieciami lokalnymi. Sieci lokalne Czytaj dalej