Как мы тестируем TLS и HTTPS: handshake в секунду при включенной инспекции

В даташите файрвола или балансировщика есть строка «TLS throughput». Сноска, если она есть, говорит: TLS 1.2, RSA 2048, один шифр, объекты 64 КБ, инспекция выключена. Ваши пользователи приносят TLS 1.3, ECDSA, страницы по 20 КБ и 50 запросов за визит, а политика безопасности требует включенной инспекции. Две цифры отличаются от 3 до 5 раз. Мы измеряем вторую.

Стенд

DUT – все, что терминирует, проксирует или инспектирует TLS: NGFW, балансировщик, WAF, reverse proxy, VPN-концентратор. Генератор эмулирует клиентов с одной стороны и серверы с другой, с настоящими стеками TLS, настоящими сертификатами и прикладным трафиком внутри: страницы HTTP/1.1 и HTTP/2, вызовы API, видео, любой ваш микс. Порты от 1G до 100G, нагрузка L4-7 от 200 Гбит/с и выше, когда под тестом кластер.

Инспекция настраивается так, как вы ее эксплуатируете: ваша политика расшифровки, ваш сертификат, категории, которые вы исключаете. Тест с выключенной инспекцией – это тест другого продукта.

Что проверяем

• Handshake в секунду: полные handshake и resumption, TLS 1.2 и 1.3, сертификаты RSA и ECDSA, с наращиванием до первой ошибки
• Одновременные сессии: 100 000, 1M и больше открытых TLS-сессий с медленным трафиком внутри, память на сессию и наращивание до первого отказа в соединении
• Throughput на cipher suite: AES-GCM, ChaCha20, разрешенные у вас длины ключей, с размерами объектов вашего трафика вместо 64 КБ
• Инспекция включена: те же 3 измерения с активными расшифровкой, IPS и application control; это и есть цифра, которую вы получите на практике
• Сертификаты: цепочки из 3 и 4 звеньев, проверки OCSP и CRL, просроченные и отозванные сертификаты и что устройство с ними делает, клиентские сертификаты там, где они используются
• Граничные случаи протокола: обработка SNI и ESNI, ALPN, session ticket, 0-RTT в TLS 1.3, renegotiation, большие handshake с множеством расширений
• Latency: время до первого байта с инспекцией и без, по перцентилям
• HA и прогон: failover с 1M открытых сессий, затем 24 часа на 80% измеренной скорости handshake

Методика по пунктам для устройств безопасности следует RFC 9411, профиль трафика берется из вашего собственного.

Что обычно ломается

Цифра с инспекцией. NGFW с 10 Гбит/с в даташите дает 9 с выключенным TLS и 2,5 с включенными расшифровкой, IPS и application control, то есть в той конфигурации, за которую заказчик заплатил. Третью конфигурацию до покупки никто не тестировал.

Второй случай: handshake на ECDSA. В устройстве стоит чип offload для RSA, а ECDSA считается программно, поэтому 20 000 handshake в секунду превращаются в 3000 в день, когда сертификат перевыпускают с другим типом ключа. Нашли заменой одного сертификата на стенде.

Третье: одновременные сессии. 2M в даташите измерены на сессиях, которые ничего не несут. Со страницами по 20 КБ внутри память на сессию растет, и устройство отказывает новым соединениям на 600 000. Для сайзинга годится только цифра с трафиком внутри.

Что в отчете

Handshake, сессии и throughput таблицами по версии протокола, шифру и типу сертификата, каждая в 2 колонках: инспекция выключена и включена. Latency по перцентилям. Проверки сертификатов списком pass и fail. Ресурсы за прогон, конфигурация устройства и профиль трафика. Вендору хватит, чтобы повторить каждую строку, а вы получаете цифру для сайзинга, на которую можно опираться в планировании.

С чего начать

Пришлите нам модель устройства, прошивку, которую планируете запускать, и топологию, в которой оно будет стоять. Мы ответим тест-планом: пункты проверки, схема стенда и сроки. План бесплатный, отчет остается у вас, его можно показать вендору. Напишите нам или посмотрите, что еще умеет стенд.