14 подписчиков
Влияние дешифрации TLS на производительность NGFW (почему SSL-инспекции убивают производительность, и как это проверить)
По данным телеметрии глобальных провайдеров (Cloudflare обрабатывает более 63 млн HTTPS-запросов в секунду), доля зашифрованного трафика превышает 90%. Это создает критическую нагрузку на NGFW, выполняющие функции инспекции (DPI). Устройство становится Man-in-the-Middle: расшифровать поток, проверить его на угрозы, зашифровать заново.
Исследования NSS Labs [MOU1.1][Ю1.2]показывают, что включение полной SSL-инспекции приводит к падению пропускной способности на 50–80% по сравнению с plaintext. На практике устройство с заявленной производительностью 10 Гбит/с может обрабатывать менее 2 Гбит/с зашифрованного трафика при включенных функциях Threat Prevention. Но пропускная способность – это не самое болезненное место.
Connection Rate оказывается критичнее. TLS-хендшейк требует значительных ресурсов CPU для криптографических операций: модульное возведение в степень, обмен ключами, генерация сессионных ключей. Стандартные тесты часто замеряют только постоянную пропускную способность, игнорируя скачки новых соединений. По тем же исследованиям NSS Labs, connection rate падает на 92% при включенной SSL-инспекции. Это означает, что даже при низком проценте утилизации канала фаервол может отказать в обслуживании новым сессиям, что может быть очень болезненным для приложений с частыми переподключениями.
Ситуация усложняется появлением новых классов трафика. С ростом AI/ML и обработки больших данных в датацентрах появилась категория, называемая elephant flows – долгоживущие сессии с огромным объемом данных (синхронизация баз, передача градиентов при обучении нейросетей). Проблема в том, что elephant flow может монополизировать буферы NGFW и коммутаторов. Когда буфер заполнен пакетами одного большого потока, пакеты других, чувствительных к задержке потоков (VoIP, игровые сессии, транзакции БД) просто отбрасываются. Традиционная балансировка часто неэффективна: хеширование отправляет весь elephant flow по одному пути, создавая локальную перегрузку. Результат – непредсказуемые задержки и деградация приложений.
Все эти проблемы невозможно обнаружить на основе вендорских даташитов. Потому что даташиты измеряют один параметр в изолированных условиях, а реальная сеть – это комбинация одновременных проблем.
Как это проверить? Тестирование должно включать смешанные сценарии: одновременное присутствие elephant flows, волны новых TLS-соединений и обычного трафика. Только так вы увидите, как реально будет работать ваше оборудование, когда на него давит именно ваш профиль трафика, а не синтетический поток. Потому что дефект в буферизации или QoS-обработке может быть скрыт, пока вы не создадите условия, в которых он проявляется.
Подписывайтесь на наш канал в ТГ, где мы регулярно публикуем материалы про нагрузочное и функциональное тестирование ИТ/ИБ решений и инфраструктуры.
2 минуты
Сегодня