Споры вокруг TLS-инспекции обычно сводятся к двум позициям. Одни говорят: без расшифрования NGFW почти ничего не видит. Другие отвечают: включите расшифрование везде — получите проблемы с приложениями, сертификатами и производительностью.
💱 На практике вопрос интереснее: не включена ли инспекция, а какую долю трафика, подлежащего инспекции, межсетевой экран действительно проверяет?
Без расшифрования NGFW не становится слепым. Продолжают работать правила по зонам, адресам, GeoIP и сервисам, блокировка известных вредоносных доменов, часть IPS-сигнатур по сетевым признакам. Используются и доступные данные TLS-рукопожатия: например, PT NGFW при отключенном расшифровании может определять URL-категорию по SNI из ClientHello. Но эта остаточная видимость сокращается на уровне самих протоколов.
В TLS 1.3 большая часть рукопожатия уже зашифрована, включая сертификат сервера. А в марте 2026 года опубликован RFC 9849 — стандарт Encrypted Client Hello, который позволяет скрывать в том числе SNI. Например, Firefox использует ECH там, где серверная и DNS-инфраструктура его поддерживают.
То есть подход «не расшифровываем, но домен все равно увидим» перестает быть универсальным. При этом полезная нагрузка HTTPS без расшифрования остается недоступной. Межсетевой экран может видеть соединение с
download.example.com, но не знает, что передается внутри: документ, архив или вредоносный файл. Проверки, которым нужна полезная нагрузка, — например, анализ передаваемых файлов и часть IPS-сигнатур прикладного уровня, — эту видимость теряют.📎 С другой стороны, включить TLS-инспекцию одной галочкой и считать задачу решенной тоже нельзя.
Часть трафика приходится исключать намеренно, например из-за особенностей приложений или закрепления сертификата. Где-то расшифрование невозможно из-за технических ограничений. Клиентские устройства должны доверять корневому сертификату, которым NGFW подписывает сертификаты при расшифровании. Сам процесс требует вычислительных ресурсов.
Поэтому реальная картина — это всегда три категории трафика: этот расшифровываем, этот намеренно исключили, этот не смогли расшифровать.
Первые две задаются правилами, третья видна только по факту — из журнала.
И здесь появляется показатель полезнее, чем «включено/выключено»: покрытие TLS-инспекцией.
Из самой настройки политики не видно, какая доля HTTPS-трафика действительно расшифровывается, какие приложения чаще всего оказываются вне инспекции и где срабатывают исключения.
В PT NGFW техническая база для такого контроля уже есть. Правила расшифрования позволяют задавать как инспекцию, так и явные исключения. В журнале трафика фиксируется признак
decrypted, а отдельный журнал расшифрования показывает сработавшее правило, версию TLS, ошибки и этап, на котором не состоялось TLS-рукопожатие.Следующий логичный шаг — относиться к TLS-инспекции как к измеримому механизму защиты: считать долю реально расшифрованного трафика, причины пропуска и основные слепые зоны. Такой отчет о покрытии — естественное развитие наблюдаемости NGFW.
Поэтому вопрос «стоит ли выключать TLS-инспекцию?» кажется нам не совсем правильным.
Полезнее другой: какой трафик мы не расшифровываем — намеренно или из-за технических ограничений — и где эти слепые зоны создают наибольший риск?
Потому что наличие TLS-инспекции в спецификации NGFW еще ничего не говорит о том, сколько зашифрованного трафика устройство действительно видит 🫡
💬 Чат для общения | Попробовать тест-драйв