Przejdz do tresci
Avanet

Wprowadzenie inspekcji TLS w Sophos Firewall

Znaczna część dzisiejszego ruchu internetowego jest zaszyfrowana. Bez inspekcji TLS firewall często widzi tylko docelowy adres IP, SNI, informacje o certyfikacie i metadane, ale nie rzeczywistą zawartość połączenia.

To stanowi problem bezpieczeństwa: wiele funkcji ochronnych nie może sprawdzać zaszyfrowanego ładunku lub robi to w bardzo ograniczonym zakresie. Skanowanie złośliwego oprogramowania, ochrona sieciowa, analiza zero-day, skanowanie treści i części wykrywania aplikacji lub zagrożeń stają się naprawdę skuteczne dopiero wtedy, gdy firewall może odszyfrować, sprawdzić, a następnie ponownie zaszyfrować ruch TLS. Również IPS i NDR korzystają z większej widoczności w postaci tekstu jawnego. Bez deszyfracji wiele sygnałów ogranicza się do metadanych, certyfikatów, adresów IP, domen lub informacji o protokołach.

Jednak inspekcja TLS nie jest funkcją, którą należy aktywować bez przygotowania dla wszystkich użytkowników. Może zakłócać działanie aplikacji, dotykać kwestii prywatności i obciążać firewall. Dlatego inspekcję TLS należy wprowadzać planowo, stopniowo i z jasną strategią wyjątków.

Orientacja

Najpierw należy wybrać metodę ochrony lub konfiguracji pasującą do rzeczywistego przypadku. Dzięki temu unika się zbyt szerokich reguł i podwójnego troubleshooting.

Licencja i wymagania

Do inspekcji TLS i sensownej analizy odszyfrowanego ruchu potrzebne są odpowiednie licencje ochronne.

Najważniejsze są:

  • Web Protection: Zawiera Web Security, Web Control, Application Control i Web Malware Protection.
  • Network Protection: Zawiera m.in. IPS, Security Heartbeat i inne funkcje ochrony sieci.
  • Zero-Day Protection: Jest ważna, gdy pliki lub pobierane dane mają być dodatkowo analizowane za pomocą uczenia maszynowego lub sandboxingu.

Web Protection jest zawarte w pakiecie licencyjnym Standard Protection. Xstream Protection i Epic Protection również zawierają Web Protection i inne moduły ochronne. Aby zrozumieć pakiety, zobacz Jakie są pakiety Sophos Firewall?; dla licencji podstawowej, statusu wsparcia i subskrypcji zobacz Zrozumienie licencji podstawowej Sophos Firewall.

Przed wdrożeniem należy sprawdzić:

  • Zainstalowana jest aktualna wersja oprogramowania Sophos Firewall.
  • Web Protection jest licencjonowane.
  • Certyfikat CA firewalla jest rozprowadzony na klientach.
  • Zdefiniowana jest grupa testowa lub sieć testowa.
  • Wycofanie jest udokumentowane.
  • Proces wyjątków jest ustalony.
  • Logowanie jest aktywowane.

Jeśli certyfikat CA nie został jeszcze rozprowadzony, pomocny będzie artykuł Instalacja certyfikatu CA Sophos Firewall dla skanowania HTTPS.

⚠️ Inspekcja TLS może zakłócać działanie aplikacji, które używają przypinania certyfikatów lub przeprowadzają własne kontrole certyfikatów. Wdrożenie powinno zawsze zaczynać się od grupy testowej, a nie bezpośrednio od wszystkich użytkowników.

DPI czy Web Proxy?

Sophos Firewall może realizować deszyfrację HTTPS w dwóch trybach:

  • Tryb DPI: Reguła firewalla używa silnika DPI. Reguły inspekcji SSL/TLS w Rules and policies > SSL/TLS inspection rules decydują, co jest odszyfrowywane.
  • Tryb Web Proxy: Reguła firewalla używa Web Proxy. Deszyfracja HTTPS jest wtedy kontrolowana przez ustawienia Web Proxy i polityki sieciowe.

W nowoczesnych konfiguracjach często używa się trybu DPI. Ważna jest przy tym reguła firewalla:

  1. Otwórz Rules and policies > Firewall rules.
  2. Edytuj odpowiednią regułę LAN-to-WAN.
  3. Otwórz Security features > Web filtering.
  4. Aktywuj odpowiednią politykę sieciową.
  5. Aktywuj Scan HTTP and decrypted HTTPS.
  6. Pozostaw wyłączoną opcję Use web proxy instead of DPI engine, jeśli mają działać reguły inspekcji SSL/TLS.

Jeśli opcja Use web proxy instead of DPI engine jest aktywna, ruch sieciowy przechodzi przez Web Proxy. Wtedy dla HTTP/HTTPS obowiązują inne ustawienia deszyfracji niż w przypadku reguł inspekcji SSL/TLS opartych na DPI. Przed wdrożeniem należy więc jasno określić, czy środowisko używa Web Proxy czy DPI, aby później nie szukać wyjątków w niewłaściwym miejscu.

Jaki ruch należy odszyfrować?

Nie należy ślepo odszyfrowywać wszystkiego. Dobra inspekcja TLS zaczyna się od jasnych celów.

Sensowne pierwsze cele:

  • LAN > WAN: klasyczny ruch sieciowy użytkowników do internetu.
  • Wi-Fi > WAN: zarządzane urządzenia w firmowej sieci Wi-Fi.
  • VPN > WAN: użytkownicy zdalnego dostępu, jeśli ich ruch internetowy przechodzi przez firewall.
  • LAN > DMZ: wewnętrzne dostępy do własnych serwerów, jeśli tam jest pożądana kontrola bezpieczeństwa i certyfikaty są poprawnie rozprowadzone.

Z ostrożnością należy traktować:

  • Bankowość, zdrowie, urzędy i portale o wysokiej wrażliwości.
  • Menedżery haseł i dostawców tożsamości.
  • Usługi aktualizacji systemu operacyjnego i producentów.
  • Aplikacje mobilne i urządzenia z Androidem.
  • Aplikacje z przypinaniem certyfikatów.
  • Usługi głosowe, wideo i współpracy, jeśli stają się niestabilne przez deszyfrację.

Dla publikacji serwerów z internetu do DMZ inspekcja TLS nie jest automatycznie najlepszym rozwiązaniem. W przypadku serwerów WWW często bardziej sensowne jest użycie Ochrony serwera WWW / WAF lub odwrotnego proxy.

QUIC i polityka sieciowa

Jeśli ruch sieciowy mimo inspekcji TLS nie jest sprawdzany zgodnie z oczekiwaniami, należy również sprawdzić QUIC lub HTTP/3. Wiele przeglądarek może nawiązywać połączenia HTTPS przez UDP 443. W zależności od projektu reguł i polityki sieciowej ruch ten może nie przechodzić przez oczekiwany klasyczny ścieżkę HTTPS przez TCP 443.

W regułach internetowych dla klientów należy świadomie sprawdzić:

  • Czy aktywna jest odpowiednia polityka sieciowa?
  • Czy w rzeczywiście dopasowanej regule firewalla aktywna jest opcja Block QUIC protocol?
  • Czy Scan HTTP and decrypted HTTPS jest ustawione zgodnie z strategią deszyfracji?
  • Czy reguła używa DPI czy Web Proxy?
  • Czy w Log Viewer widać spójnie UDP 443, TCP 443, zdarzenia polityki sieciowej i zdarzenia inspekcji SSL/TLS?

Procedura blokowania QUIC znajduje się w Sophos Firewall - Blokowanie protokołu QUIC i HTTP/3. Dla samej polityki sieciowej zobacz Tworzenie polityki ochrony sieciowej Sophos Firewall.

Planowanie rollout

TLS Inspection należy wdrażać etapami, aby wyjątki, certyfikaty klientów i zgłoszenia supportowe były łatwe do opanowania.

Strategia wdrożenia

Sprawdzonym podejściem jest podejście etapowe:

  1. Rozprowadzenie certyfikatu CA.
  2. Przygotowanie polityki sieciowej i reguły firewalla.
  3. Wybór profilu deszyfracji.
  4. Definicja małej grupy testowej.
  5. Aktywacja reguły inspekcji SSL/TLS tylko dla tej grupy.
  6. Obserwacja Centrum sterowania i Log Viewer.
  7. Analiza błędów i dokumentacja wyjątków.
  8. Stopniowe rozszerzanie na inne grupy użytkowników.

Dzięki temu można wcześnie zidentyfikować, które aplikacje sprawiają problemy, bez wpływu na całą operację.

Planowanie faz wdrożenia

Wdrożenie inspekcji TLS powinno być planowane w fazach. Dzięki temu pozostaje ono kontrolowane i można oddzielić problemy techniczne od problemów z akceptacją lub aplikacjami.

  • Przygotowanie: Certyfikat CA, polityka sieciowa, reguła firewalla i grupa testowa są gotowe. Rozprowadzenie CA, licencja, logowanie, wycofanie
  • Pilot: kilka zarządzanych klientów testuje codzienną pracę. Log Viewer, widżet na pulpicie, opinie użytkowników
  • Rozszerzenie: włączenie kolejnych grup użytkowników lub sieci. Dokumentacja wyjątków, obserwacja wydajności
  • Operacja: Inspekcja TLS jest regularnie sprawdzana. Przegląd wyjątków, raporty, błędy i nowe aplikacje

Ważne jest, aby każda faza miała jasny punkt przerwania. Jeśli aplikacja krytyczna dla biznesu przestaje działać w fazie pilotażowej, nie należy od razu ustawiać szerokiego globalnego wyjątku. Lepsza jest dokładna analiza: która domena, który klient, która reguła, który profil deszyfracji i jaki błąd w Log Viewer są dotknięte?

Ustalenie pilota, właściciela i procesu wyjątków

Przed pierwszym wdrożeniem produkcyjnym powinno być jasne, kto zarządza grupą testową, kto zatwierdza wyjątki i jak zgłaszane są błędy. Inspekcja TLS szybko generuje nieuporządkowane wyjątki: pojedyncze domeny są gorączkowo ustawiane na Don't decrypt, bez późniejszego wyjaśnienia, dlaczego wyjątek istnieje.

Dla operacji powinny być udokumentowane następujące punkty:

  • Grupa pilotażowa, dotknięte sieci i okres.
  • Właściciel polityki sieciowej, profilu deszyfracji i reguł inspekcji SSL/TLS.
  • Proces dla nowych wyjątków z powodem, biletem i datą przeglądu.
  • Kryteria, kiedy aplikacja jest wyłączona, a kiedy najpierw sprawdzana jest przyczyna.
  • Miejsce, w którym zbierane są Log Viewer, widżet na pulpicie i opinie użytkowników.
  • Wycofanie, jeśli aplikacje krytyczne dla biznesu są zakłócane.

Szczególnie ważne jest rozróżnienie między wyjątkiem technicznym a trwałą decyzją bezpieczeństwa. Tymczasowy wyjątek może być sensowny, aby usługa znów działała. Jednak ten wyjątek powinien być później ponownie oceniony, gdy przyczyna, ryzyko i alternatywa są jasne.

Test rollbacku przed wdrożeniem

Rollback nie powinien być wymyślany dopiero w czasie awarii. Przed pilotem musi być jasne, jak wycofać TLS Inspection dla grupy testowej bez pomieszania innych reguł, Web Policies lub wyjątków.

Praktyczna kontrola rollbacku:

  • Usunąć grupę testową: sprawdzić, czy SSL/TLS Inspection Rule nie dopasowuje już klienta pilotażowego.
  • Dezaktywować regułę: skontrolować, czy ruch wraca na oczekiwaną ścieżkę bez decryption.
  • Przetestować wyjątek: ukierunkowana reguła Don't decrypt musi stać powyżej ogólnej reguły Decrypt i być widoczna w Log Viewer.
  • Zachować Web Policy: rollback deszyfracji nie może przypadkowo usunąć web filtering, malware scanning ani loggingu.
  • Udokumentować dowód: zapisać klienta testowego, domenę docelową, nazwę reguły, zdarzenie logu i czas.

Ta próba jest szczególnie ważna, gdy kilku administratorów pracuje nad Web Policies, regułami firewalla i SSL/TLS Inspection Rules. Czysty rollback wycofuje tylko dotknięty scope i nie oślepia całego łańcucha Web Protection.

Konfiguracja

Konfiguracja powinna być precyzyjna, testowalna i łatwa do późniejszego przeglądu.

Zrozumienie profili deszyfracji

Profil deszyfracji określa, jak rygorystycznie firewall traktuje połączenia TLS. Profile można znaleźć w Profiles > Decryption profiles.

Profil deszyfracji odpowiada między innymi na te pytania:

  • Co się dzieje w przypadku nieprawidłowych lub niewiarygodnych certyfikatów?
  • Czy starsze wersje TLS są blokowane?
  • Czy niebezpieczne zestawy szyfrów są blokowane?
  • Co się dzieje w przypadku kompresji SSL?
  • Co się dzieje w przypadku nierozpoznanych zestawów szyfrów?
  • Co się dzieje, gdy firewall nie może odszyfrować połączenia?
  • Która CA jest używana do ponownego podpisania?

Dla pierwszego wdrożenia sensowny jest bardziej kompatybilny profil, na przykład Maximum compatibility lub własny konserwatywny profil. Dla produkcyjnych reguł bezpieczeństwa można później użyć bardziej rygorystycznego profilu, takiego jak Block insecure SSL.

Ważne: Profil deszyfracji jest wybierany bezpośrednio w regule inspekcji SSL/TLS. Profil może zastąpić globalne ustawienia inspekcji SSL/TLS dla tej reguły. Dlatego podczas rozwiązywania problemów należy zawsze sprawdzać konkretną regułę, a nie tylko globalne ustawienia.

Tworzenie reguły inspekcji SSL/TLS

Ścieżka menu to Rules and policies > SSL/TLS inspection rules.

Pierwsza reguła powinna być możliwie jak najbardziej precyzyjna:

  • Działanie: Decrypt
  • Profil deszyfracji: konserwatywny profil testowy
  • Strefy źródłowe: LAN lub sieć testowa
  • Sieci i urządzenia źródłowe: grupa testowa lub podsieć testowa
  • Strefy docelowe: zazwyczaj WAN
  • Sieci docelowe: początkowo Any
  • Usługi: na początek często Any, ponieważ SSL/TLS może być rozpoznawane również na innych portach TCP
  • Strony internetowe / Kategorie: opcjonalnie ograniczyć

Reguły inspekcji SSL/TLS mogą rozpoznawać połączenia TLS również poza klasycznym portem HTTPS. Reguły są przetwarzane od góry do dołu. Specyficzne wyjątki i reguły pilotażowe powinny być umieszczone powyżej ogólnych reguł deszyfracji, w przeciwnym razie później trudno będzie zrozumieć, dlaczego połączenie zostało odszyfrowane lub wyłączone.

Listy wyjątków

Nie każdy ruch TLS powinien być odszyfrowywany. Sophos używa do tego reguł wyjątków i list wyłączeń TLS.

Lokalna lista wyłączeń TLS

Lokalna lista wyłączeń TLS to lokalna lista wyjątków firewalla. Ta lista jest domyślnie pusta i może być wypełniana podczas rozwiązywania problemów w Centrum sterowania lub Log Viewer.

Można ją również edytować ręcznie:

Web > URL groups > Local TLS exclusion list

Ta lista jest przydatna dla domen, które sprawiają problemy w danym środowisku, na przykład z powodu przypinania certyfikatów lub specjalnych aplikacji klienckich.

Zarządzana lista wyłączeń TLS

Zarządzana lista wyłączeń TLS zawiera wyjątki utrzymywane przez Sophos dla znanych problematycznych usług. Ta lista jest aktualizowana przez aktualizacje oprogramowania.

Typowe przykłady to usługi, w których inspekcja TLS powoduje problemy lub jest technicznie nieuzasadniona.

Własne reguły wyjątków

Dodatkowo można tworzyć własne reguły inspekcji SSL/TLS z Action > Don’t decrypt. Powinny one znajdować się bezpośrednio pod domyślną regułą wyjątków i zawierać tylko ruch, który naprawdę nie powinien być odszyfrowywany.

Możliwe kryteria:

  • Kategorie sieciowe
  • Grupy URL
  • Użytkownicy i grupy
  • Sieci źródłowe i docelowe
  • Adresy IP
  • Usługi

Wyjątki powinny być dokumentowane: domena, powód, dotknięci użytkownicy, data i termin przeglądu.

Kontrola i analiza

Po aktywacji dashboard i Log Viewer pokazują, czy ruch jest faktycznie odszyfrowywany czy wyłączany.

Obserwacja widżetu na pulpicie

W Centrum sterowania znajduje się widżet dla inspekcji SSL/TLS. Ten widżet jest bardzo pomocny w monitorowaniu wdrożenia i błędów.

Pokazuje między innymi:

  • Procent odszyfrowanych sesji SSL/TLS.
  • Procent nieodszyfrowanych sesji SSL/TLS.
  • Inny ruch.
  • Błędy z ostatnich dni.
  • Najczęściej odwiedzane strony lub użytkownicy z problemami.
  • Szczyt deszyfracji i limit deszyfracji.
Sophos Firewall - Widżet inspekcji SSL/TLS z odszyfrowanym i nieodszyfrowanym ruchem
Sophos Firewall - Centrum sterowania > Widżet inspekcji SSL/TLS

Jeśli w widżecie pojawia się wiele błędów, nie należy od razu wyłączać całej inspekcji TLS. Lepiej jest, korzystając z opcji Fix errors, dokładnie sprawdzić dotknięte cele i w razie potrzeby stworzyć czyste wyjątki.

Analiza Log Viewer

W Log Viewer można wybrać filtr SSL/TLS inspection. Tam można zobaczyć, co się stało z poszczególnymi połączeniami.

Sophos Firewall - Log Viewer z wydarzeniami inspekcji SSL/TLS
Sophos Firewall - Log Viewer > Inspekcja SSL/TLS

Kolory pomagają w pierwszej ocenie:

  • Czerwony: Błąd. Połączenie nie mogło zostać poprawnie odszyfrowane lub przetworzone. Należy sprawdzić błędy certyfikatów, zestawy szyfrów, wersje TLS lub niekompatybilne aplikacje.
  • Zielony: Nie odszyfrowuj. Połączenie zostało świadomie nieodszyfrowane, na przykład z powodu reguły wyjątku lub listy wyłączeń TLS.
  • Niebieski: Odszyfruj. Połączenie zostało odszyfrowane i następnie ponownie zaszyfrowane.

W logu widać również profil deszyfracji, adres IP źródłowy, adres IP docelowy, użytkownika, kategorię i domenę docelową. Dzięki temu można sprawdzić, czy odpowiednia reguła została dopasowana i czy wyjątek rzeczywiście działa.

Testy

Po aktywacji inspekcji TLS należy sprawdzić:

  • Czy w przeglądarce używany jest certyfikat CA Sophos?
  • Czy działają ważne aplikacje biznesowe?
  • Czy w Log Viewer występują błędy TLS?
  • Czy zdarzenia związane z złośliwym oprogramowaniem lub polityką sieciową są poprawnie rozpoznawane?
  • Czy ruch w widżecie Centrum sterowania jest wyświetlany jako odszyfrowany?
  • Czy wydajność firewalla pozostaje w oczekiwanym zakresie?
  • Czy są skargi od użytkowników testowych?

Do rozwiązywania problemów szczególnie przydatne są Log Viewer, Policy Test, widok certyfikatów w przeglądarce, Packet Capture i widżet inspekcji SSL/TLS.

Troubleshooting i eksploatacja

Problemy z TLS Inspection zwykle rozwiązuje się przez jasne wyjątki, kontrolowany rollback i regularny przegląd.

Typowe błędy

  • Przeglądarka wyświetla ostrzeżenie o certyfikacie: Brak CA w magazynie zaufania lub używana jest niewłaściwa CA. Rozprowadzenie CA, łańcuch certyfikatów w przeglądarce, restart klienta
  • Log Viewer nie pokazuje zdarzeń inspekcji SSL/TLS: niewłaściwy tryb, brak odpowiedniej reguły lub silnik SSL/TLS nieaktywny. Reguła firewalla, DPI/Web Proxy, reguła inspekcji SSL/TLS
  • Ruch jest dozwolony, ale nie odszyfrowany: Reguła Don't decrypt, zarządzany wyjątek lub niewłaściwa kolejność reguł. Sprawdzenie reguł inspekcji SSL/TLS od góry do dołu
  • Filtr sieciowy nie działa zgodnie z oczekiwaniami: Brak polityki sieciowej, aktywny QUIC lub błędne zrozumienie Scan HTTP and decrypted HTTPS. Dopasowana reguła firewalla, QUIC, log polityki sieciowej
  • Pojedyncze aplikacje przerywają działanie: Przypinanie certyfikatów, stara wersja TLS, niekompatybilny zestaw szyfrów lub własna kontrola certyfikatów. Log Viewer, profil deszyfracji, celowy wyjątek
  • Wiele błędów w widżecie na pulpicie: zbyt szerokie wdrożenie lub nieodpowiedni profil deszyfracji. Zmniejszenie grupy pilotażowej, sortowanie błędów według domeny i kategorii
  • Wydajność spada po aktywacji: zbyt szeroki zakres, duże pobierania lub zbyt wiele jednoczesnych sesji. Zakres deszyfracji, obciążenie firewalla i sprawdzenie najważniejszych użytkowników
  • Wyjątek nie działa: Wyjątek znajduje się poniżej bardziej ogólnej reguły deszyfracji. Sprawdzenie kolejności reguł i dopasowanych kryteriów

W przypadku niejasnych sytuacji nie należy zmieniać kilku rzeczy jednocześnie. Lepiej jest przeprowadzić wąski test: jeden klient, jedna domena docelowa, jedna reguła firewalla, jeden profil deszyfracji i jeden jasny czas w Log Viewer.

Wycofanie

W przypadku wystąpienia zakłóceń powinno być możliwe jasne wycofanie:

  • Dezaktywacja reguły inspekcji SSL/TLS.
  • Usunięcie grupy testowej z reguły.
  • Złagodzenie profilu deszyfracji.
  • Dodanie wyjątku dla dotkniętej domeny lub aplikacji.
  • Przywrócenie reguły firewalla do Web Proxy, jeśli jest to świadomie pożądane.

Reguły inspekcji SSL/TLS i silnik SSL/TLS muszą być widocznie aktywne, aby Centrum sterowania i Log Viewer wyświetlały szczegóły. Jeśli inspekcja SSL/TLS jest wyłączana w celach rozwiązywania problemów, należy ją później ponownie aktywować i krótko udokumentować stan.

Zalecenia dotyczące operacji

Inspekcja TLS nie jest projektem na jedno kliknięcie. Prawidłowo wprowadzona dostarcza jednak znacznie większej widoczności i poprawia skuteczność ochrony sieciowej, skanowania złośliwego oprogramowania, IPS, NDR i funkcji zero-day.

Dla środowisk produkcyjnych zalecamy:

  • Najpierw LAN-to-WAN dla małej grupy testowej.

  • Rozprowadzenie certyfikatu CA w sposób poprawny.

  • Świadome wybranie trybu DPI/Web Proxy.

  • Nie zaczynanie zbyt agresywnie z profilami deszyfracji.

  • Codzienna obserwacja Log Viewer i widżetu na pulpicie.

  • Dokumentowanie wyjątków i regularne ich przeglądanie.

  • Rozszerzanie dopiero po pomyślnych testach.

  • Utrzymywać przetestowany rollback dla grupy pilotażowej i wyjątków.

FAQ

Czy inspekcję TLS należy natychmiast aktywować dla wszystkich użytkowników?

Nie. Inspekcja TLS powinna rozpocząć się od grupy testowej. Dopiero gdy rozprowadzenie CA, polityka sieciowa, profil deszyfracji, wyjątki, logi i aplikacje biznesowe zostaną sprawdzone, należy rozszerzyć zakres.

Dlaczego inspekcja TLS nie działa mimo zainstalowanego certyfikatu CA?

Certyfikat CA zapewnia tylko, że klienci ufają CA firewalla. Dodatkowo muszą pasować reguła firewalla, polityka sieciowa, reguła inspekcji SSL/TLS, profil deszyfracji i kolejność reguł.

Jaka jest różnica między trybem DPI a trybem Web Proxy?

W trybie DPI reguły inspekcji SSL/TLS działają dla ruchu reguły firewalla. W trybie Web Proxy ruch sieciowy przechodzi przez proxy, a deszyfracja jest kontrolowana inaczej. Dlatego należy świadomie sprawdzić tryb dotkniętej reguły firewalla.

Kiedy potrzebny jest wyjątek TLS?

Wyjątek jest sensowny, gdy aplikacja z powodu przypinania certyfikatów, własnej kontroli certyfikatów lub technicznej niekompatybilności nie może być poprawnie odszyfrowana. Wyjątek powinien być udokumentowany i później sprawdzony.

Czy QUIC musi być zablokowany dla inspekcji TLS?

W zarządzanych sieciach klienckich jest to zazwyczaj sensowne, jeśli filtrowanie sieciowe, skanowanie złośliwego oprogramowania lub inspekcja TLS mają działać niezawodnie. QUIC przez UDP 443 może inaczej ominąć oczekiwaną klasyczną ścieżkę HTTPS przez TCP 443.