Главный инструмент видимости на седьмом уровне — расшифрование TLS. Механика известна: межсетевой экран подменяет сертификат сервера своим, разбирает содержимое, зашифровывает обратно и отдаёт дальше. Работало это долго и хорошо.
Сегодня работает частично, и это надо обсуждать вслух, а не обнаруживать на третьем месяце внедрения. Представьте, что вы вскрываете конверты на почте — аккуратно, по служебной необходимости. А отправители перешли на конверты, которые при вскрытии рвутся, или просто отказываются открываться кому-либо, кроме адресата.
Пять причин, по которым расшифровывается не всё подряд
Certificate pinning. Приложения закрепляют внутри себя допустимые сертификаты или открытые ключи — в Android это делается через SPKI-хеши. Подмена сертификата на периметре для них не инспекция, а атака: соединение разрывается.
Если приложение чужое и его настройками доверия вы не управляете, выход один — исключение. В своём приложении можно изменить конфигурацию доверия, а можно и просто запретить доступ. Решение зависит от того, чьё приложение, а не от самой техники закрепления.
Взаимная аутентификация. Здесь надо развести две вещи, которые часто смешивают.
Первое — почему mTLS мешает инспекции. Клиент доказывает свою подлинность закрытым ключом, которого у устройства в середине нет. Поэтому прозрачно встать в такое соединение нельзя — и так было задолго до любых изменений у удостоверяющих центров.
Второе — отдельная операционная задача. Публичные центры убирают из сертификатов назначение клиентской аутентификации: у Let's Encrypt обычный профиль лишился clientAuth в составе EKU 11 февраля 2026 года. Это часть общего движения: Chrome Root Program Policy v1.8 для конечных сертификатов ставит срок 15 марта 2027 года, а 15 июня 2026-го касается подчинённых центров, раскрываемых в CCADB.
Собственный удостоверяющий центр при этом не обязателен: нужны подходящие клиентские сертификаты и согласованное доверие, а выпускать их может и внешний поставщик. Своя инфраструктура — один из вариантов, обычно самый трудоёмкий.
Если выбран свой центр — это отдельный проект: выпуск, доставка и отзыв сертификатов для сервисов, API, контейнеров и устройств, сроки, списки отзыва, ротация корня. Плюс тихие отказы в унаследованных системах при миграции. Многие решают проще: трафик с взаимной аутентификацией уходит в обход инспекции.
Encrypted Client Hello. Сам TLS 1.3 активному вмешательству не мешает, если на клиенте стоит доверенный корневой сертификат: он закрыл пассивное прослушивание, а не инспекцию.
ECH шифрует внутреннее сообщение клиента с настоящим именем узла — RFC 9849. Внешнее сообщение и адрес назначения при этом видны, так что устройство не слепнет полностью: оно теряет истинное имя узла и все решения, которые на это имя опирались. А политика расшифрования обычно опирается именно на имя.
Меры у вендоров есть, и это разные меры: помешать клиенту получить параметры ECH через DNS либо отключить ECH при активной инспекции с доверенным центром. У FortiOS это strip-ech в DNS-профиле, у Cisco — фильтрация записей HTTPS и отключение при перехвате. Блокировать записи SVCB и HTTPS целиком и убрать только параметр ech — не одно и то же: первое задевает и другие параметры сервисов.
QUIC и HTTP/3. Распространённый ответ — закрыть UDP на 443-м порту и заставить браузеры откатиться на HTTP/2, где инспекция привычна. Возможная цена — рост задержек; возможная, а не обязательная, и проверяется замером.
Инспекция HTTP/3 поддерживается продуктами — например, FortiSASE описывает действия для трафика QUIC. Универсального отставания от HTTP/2 из этого не следует: требуйте отдельные измерения по обоим протоколам на своём профиле.
Постквантовый обмен ключами. В сети Cloudflare гибридные схемы стали большинством: половину трафика, инициированного людьми, перешагнули в последнюю неделю октября 2025 года, а к 7 апреля 2026-го доля превысила 65%. Это про обмен ключами в одной конкретной сети, а не про весь интернет и не про постквантовую аутентификацию.
Само по себе это инспекцию не отменяет: активный доверенный прокси работает и здесь, а поддержка описана в документации продуктов. Вопрос практический — совместимость конкретных алгоритмов, размер рукопожатия и измеренная нагрузка.
И отдельно — не техническое ограничение. Доступ к содержимому чужой переписки и обработка персональных данных требуют правового основания, и для части категорий трафика решение об инспекции принимается не инженером. Конкретную норму под свой случай смотрите с юристом: общая ссылка на 152-ФЗ сама по себе ни запрета, ни разрешения не даёт. Там, где основания нет, обход становится юридическим решением.
Как выглядит слепая зона
Чем это не лечится
Анализ зашифрованного трафика без расшифрования — по параметрам рукопожатия, размерам пакетов, отпечаткам клиента — работает и действительно ловит каналы управления, периодические обращения вредоноса и поведенческие аномалии. Но это дополнение к проверке содержимого, а не замена ей.
Но задачи у них разные: заметить аномалию в поведении потока и найти конкретный эксплойт внутри содержимого — не одно и то же, и вторую без содержимого не решить. Если вам предлагают такой анализ как замену расшифрованию, спрашивайте, какие угрозы и с какой полнотой он обнаружил в испытании на вашем трафике. Видимость складывается из сети и хоста вместе.
Что делать архитектору
Сначала измерить слепую зону. Какая доля HTTPS реально проходит проверку содержимого, а какая ушла в исключения. По моим ощущениям, до проверки содержимого доходит меньше половины — но это именно ощущение, а не замер, и переносить его на вашу сеть нельзя.
Считать надо у себя, и до счёта договориться о знаменателе: байты, запросы или сессии; за какой период; входит ли HTTP/3; учитываются ли удалённые устройства. И отделять проверку сертификата от расшифрования, а расшифрование — от собственно проверки содержимого. Пока это не посчитано, разговор о видимости беспредметен.
Расшифровывать избирательно. Зоны риска — неизвестные категории сайтов, недавно зарегистрированные домены, неопознанные назначения.
Исключения делаются не по принципу «это же госпортал» и не по вере в облако: основанием служит документированная несовместимость, правовое ограничение или оценка риска. У каждого исключения должен быть владелец и срок пересмотра, иначе список растёт и никогда не сокращается.
Переносить видимость на хост. Там, где сеть в тумане, камера ставится в точке, где данные ещё не зашифрованы, — на рабочей станции. Это не лозунг про EDR, а прямое следствие пяти причин выше.
Выносить инспекцию удалённых сотрудников в облако. Это снимает нагрузку с периметра, но не отменяет доверия на клиенте: для обычной инспекции TLS корневой сертификат на устройстве всё равно нужен — так это и описано у Cloudflare. Задача «не ставить свой сертификат на личное устройство» решается иначе: управляемым браузером или изоляцией без агента.
Учитывать учётную запись, результат аутентификации и состояние устройства. Когда содержимое канала недоступно, решение принимается по тому, кто и с чего пришёл. Прошедший строгую проверку доступ несёт меньший риск внутри закрытого канала — это и есть практический смысл ZTNA, а не маркетинговый.
Изоляция браузера расшифровать сессию не помогает, но выносит исполнение наружу: активный код страницы работает в удалённом браузере, а клиент получает её представление — не обязательно картинку, Cloudflare передаёт команды рисования. Это закрывает риск исполнения кода на рабочей станции. Контроль скачиваний, ввода данных и утечек остаётся отдельной задачей.
Что это меняет в требованиях к NGFW
Строка «поддерживает расшифрование TLS» в техническом задании ничего не решает. Значение имеют другие вопросы: производительность при включённом расшифровании на вашем профиле трафика; поведение при ECH и при QUIC с указанием версии и режима; удобство управления списками исключений, потому что жить вы будете именно в них; и что остаётся от защиты на трафике, который в исключения ушёл.
Полный список критериев с вопросами поставщику — на странице как выбрать NGFW, проверка на испытаниях — в программе пилота. Почему архитектура важнее списка функций — в статье об отличиях NGFW от UTM.