Главный инструмент «видимости» уровня приложений — SSL Inspection (или MITM — Man-in-the-Middle). Метод прост: межсетевой экран подменяет сертификат TLS(SSL) на свой, расшифровывает трафик, проверяет его и зашифровывает обратно.
Раньше это работало. Сегодня — это головная боль и часто бессмысленная затея. Представьте, что вы пытаетесь прочитать чужое письмо, аккуратно вскрывая конверт. Но теперь отправители используют специальные «умные» конверты, которые самоликвидируются или отказываются открываться, если видят, что их читает кто-то, кроме адресата.
Почему тотальное расшифрование больше не «серебряная пуля»
Многие эксперты продолжают настаивать на тотальном перехвате трафика (MITM). Технически расшифрование большинства веб-сессий всё еще возможно через корпоративные центры сертификации. Однако самые критичные зоны превращаются в «черные ящики».
Certificate Pinning и mTLS
Банковские приложения, популярные SaaS-решения и мобильный софт жёстко зашивают ожидаемый сертификат сервера. Любая попытка подмены сертификата NGFW приводит к немедленному разрыву соединения. В 2026 году таких приложений становится всё больше, и инженерам приходится выводить огромные объёмы трафика в списки исключений (Bypass). То же самое происходит при использовании обычного forward-прокси.
mTLS и «смерть» публичных клиентских сертификатов
В 2026 году ситуация с mutual TLS серьёзно усугубилась. Let’s Encrypt (с февраля), DigiCert, Sectigo и другие крупные публичные CA начали убирать из публичных TLS-сертификатов расширение Extended Key Usage — TLS Client Authentication.
Раньше один сертификат мог выполнять и роль сервера, и роль клиента. Теперь публичный сертификат может содержать только serverAuth. Для полноценного mTLS почти всегда требуется выпускать клиентские сертификаты из собственной private PKI.
На первый взгляд — ничего страшного, private PKI даже безопаснее. Но на практике это большая головная боль:
- Нужно развернуть и постоянно обслуживать внутренний удостоверяющий центр (или платить за managed-сервис).
- Приходится автоматизировать выпуск, доставку и отзыв тысяч клиентских сертификатов на микросервисы, API, контейнеры и устройства.
- Появляется новый слой операционной сложности: мониторинг срока жизни, CRL/OCSP, ротация корневого CA и т.д.
- При миграции часто возникают «тихие» сбои в legacy-системах.
В итоге то, что раньше решалось одним кликом через Let’s Encrypt, теперь требует полноценного проекта. Многие компании просто выводят весь mTLS-трафик в bypass.
TLS 1.3 + Encrypted Client Hello (ECH)
Сам по себе протокол TLS 1.3 не запрещает активное вмешательство, если на клиенте установлен доверенный сертификат. Он лишь закрыл пассивное прослушивание.Однако с массовым внедрением Encrypted Client Hello (ECH) в 2025–2026 годах шифруется даже начальное сообщение ClientHello, включая SNI. NGFW больше не видит, куда именно идёт соединение, и не может принять решение о дешифровке.
Palo Alto Networks рекомендует блокировать SVCB/HTTPS DNS-записи (типы 64 и 65), чтобы предотвратить появление ECH. Fortinet позволяет stripping ECH прямо в SSL/SSH-профилях или DNS-фильтре. Пока ECH используется не массово (реальная доля соединений — единицы процентов), но рост быстрый, особенно в связке с QUIC.
QUIC и HTTP/3
Трафик по протоколу QUIC (HTTP/3) значительно сложнее анализировать на лету. Многие организации до сих пор блокируют UDP-порт 443, заставляя браузеры откатываться на обычный HTTP/2 через TCP. Это позволяет провести инспекцию, но ценой заметного роста задержек и жалоб пользователей.
Современные NGFW уже умеют инспектировать QUIC напрямую: Fortinet (FortiOS 7.4+ / 7.6+) поддерживает deep inspection в flow- и proxy-режиме, Palo Alto и SASE-вендоры тоже значительно улучшили поддержку. Однако даже при этом производительность и стабильность ниже, чем при обычном TLS over TCP.
Post-Quantum Cryptography
Гибридные постквантовые схемы обмена ключами уже используются более чем в 50 % трафика на крупных CDN (по данным Cloudflare на конец 2025). В ближайшие годы это ещё сильнее усложнит традиционную инспекцию, особенно в сочетании с ECH.
Юридические и комплаенс риски расшифровки TLS
В России есть ФЗ-152, требования ФСТЭК и отраслевые регламенты, где расшифрование и изучение определённых категорий трафика может требовать дополнительных согласований или вообще быть запрещена. Тогда bypass становится не техническим, а юридическим решением.
Маркетинговые мифы против реальности
В маркетинговых в брошюрах предлагают заменить расшифрование анализом зашифрованного трафика (ETA) на базе нейросетей. Cсовременные ETA (Cisco, Palo Alto Encrypted Visibility Engine, ExtraHop и др.) уже довольно хорошо детектят C2, malware beaconing и аномалии по поведению handshake, packet sizes, JA3/JARM и т.д. Они не заменяют payload-инспекцию, но отлично дополняют в «слепых» зонах.
Взгляд инженера: Без данных с конечных точек (EDR/XDR) точность таких прогнозов остается низкой. Машинное обучение может заметить аномально тяжелый поток данных, но не заменит полноценную проверку содержимого на наличие эксплойтов. Видимость сегодня — это результат связки сети и хоста.
Новая архитектура: Как защищаться в условиях помех
Если сетевой уровень теряет прозрачность, нагрузку нужно перераспределять:
Удаленная изоляция браузера (RBI): Технология не помогает расшифровать сессию, но она выносит риск за пределы периметра. Подозрительные сайты открываются в облачной «песочнице» вендора, а пользователь видит лишь безопасную картинку. Это снимает необходимость лезть внутрь каждого шифрованного пакета.
Работа в самом браузере: Вы можете анализировать трафик в самом браузере, например, Яндекс Браузер позволяет проводить дополнительные проверки для отправляемого и передаваемого контента.
Избирательное расшифрование: Инспектируйте только зоны риска — неизвестные категории сайтов и свежезарегистрированные домены. Доверенные облака (M365, государственные порталы) лучше пускать в обход, чтобы не плодить ошибки в работе приложений.
Ставка на ZTNA: В мире закрытого трафика важнее знать «кто идет» и «с какого устройства», чем пытаться разобрать каждый байт. Если субъект уже прошел строгую проверку личности и здоровья системы, риск внутри шифрованного канала минимален.
Дорожная карта для инженера ИБ
Чтобы не оказаться владельцем дорогой, но бесполезной «железки», стоит сменить подход:
Аудит слепых зон: Замерьте, какой процент трафика уже идет в обход инспекции из-за исключений и жалоб пользователей. В типичной корпоративной сети 2026 года реально инспектируется 60–80 % HTTPS-трафика. Остальное уходит в bypass из-за pinning, mTLS, ECH, QUIC и юридических ограничений. Это подтверждается отраслевыми отчётами и опытом SASE-вендоров (Zscaler, Palo Alto Networks, Cloudflare).
Укрепление агентов на хостах: Раз на сети туман, нужно ставить «камеры» там, где данные еще не зашифрованы — на рабочие станции.
Гибридная видимость: Переносите проверку трафика удаленных сотрудников в облачные прокси (SASE/SSE). Это решает проблемы с сертификатами на личных устройствах и снимает нагрузку с локального железа.
Эпоха «всевидящего ока» закончилась. Наступает время умной архитектуры, где NGFW работает в тесной связке с защитой конечных точек, EDR и SASE.
Коллеги, а какой стратегии придерживаетесь вы? Мучаетесь с деградацией производительности при обработке QUIC или просто блокируете его? Пишите свои кейсы и модели NGFW в комментариях — разберем реальный опыт эксплуатации в 2026 году.
Больше прикладных материалов по сетевой безопасности и разборов новых протоколов — в канале
. «Топ Кибербезопасности Батранкова»