Почти весь сетевой трафик сегодня зашифрован. Внутри зашифрованного трафика может пройти вредоносный код, также через него утекают файлы из сети и работают системы управления бот-сетями, проводятся обновления ПО и идут сообщения мессенджеров, социальных сетей, передаются файлы между хранилищами. Самая большая часть трафика представлена TLS-соединениями. Чтобы проверить передаваемый внутри TLS контент, его требуется сначала расшифровать, а затем проверить имеющимися у вас автоматизированными инструментами проверки, например антивирусом или DLP. Этот процесс инспекции трафика и называют TLS-инспекцией или, чаще, SSL-инспекцией. Ниже мы разберемся, в чем разница между SSL и TLS.
С удивлением обнаруживаю, что для коллег из мира ИТ два разных слова: «инспекция» и «расшифрование» — означают одно и то же. На самом деле это два разных по сложности действия. Чтобы четче представлять их отличия, приведу картинку:
Нужно различать эти два термина: SSL-инспекция включает SSL-расшифрование + анализ расшифрованного контента различными модулями инспекции. Если мы просто выполняем SSL-расшифрование и больше ничего не делаем с трафиком, это вообще странное мероприятие. Как если бы мы приходили в поликлинику и сразу же выходили из нее, без медосмотра.
Этим непониманием пользуются производители в своих маркетинговых брошюрах, чтобы показать, как быстро они пропускают трафик… без инспекции. Наверняка вы даже не представляете, как часто вам показывают лишь скорость SSL-расшифрования, очень быстро пропуская трафик через свою «поликлинику» без реального осмотра. Скорость работы SSL-расшифрования без инспекции — бессмысленный параметр. В реальности вам важно знать, как быстро ваша «поликлиника» будет пропускать через себя потоки трафика, если «осмотр пациентов» все-таки проводить, а не выпускать их без проверки.
SSL и TLS
SSL-протокол был придуман компанией Netscape, для того чтобы доказать браузеру, что веб-сервер — это тот самый веб-сервер, к которому мы хотели подключиться. То есть он изначально был придуман для установления доверия между браузером и веб-сервером. TLS-протокол стал развитием SSL и был переименован, чтобы показать открытый характер стандарта, — в общем, он теперь используется не только для HTTPS. В сети вы увидите также протоколы SMTPS, POP3S, IMAPS, FTPS и т.д.
Вторая задача SSL/TLS — обеспечение конфиденциальности: весь трафик между клиентом и сервером зашифрован. Чаще всего для этого используется симметричный протокол AES с ключами 128 или 256 бит.
Внутри протокола TLS используется несколько технологий из мира криптографии, которые рекомендуется знать. Это алгоритмы контроля целостности, шифрования данных, аутентификации сервера и, иногда, клиента, алгоритмы обмена ключами, цифровая подпись. Для понимания работы SSL/TLS нужно знать основы PKI, представлять различия в типах сертификатов, понимать, что такое Certification Authority и другие вещи. Но это все лежит за рамками данной статьи. Исхожу из предположения, что мои читатели в этом уже разбираются. Чаще всего в литературе используется термин SSL-инспекция, даже если инспектируется TLS, поэтому в данной статье будем следовать данному тренду. На самом деле уже весь трафик — это TLS. SSL-протокол устарел, его редко встретишь в сетевом трафике.
Криптографические вычисления нагружают процессор
Самое главное, что нужно понимать: любой криптографический алгоритм требует интенсивных вычислений, а это нагружает и процессор клиента TLS, и процессор сервера TLS, поскольку происходит обмен сеансовыми ключами по алгоритму Диффи–Хеллмана или RSA, выполняется проверка электронных подписей по DSA или ECDSA, идет шифрование AES на обеих сторонах. Асимметричное шифрование более затратно для процессоров, чем симметричное.
Приведу пример набора шифров для TLS.
Для примера: типовой веб-сервер в состоянии обслужить 3000 TLS-запросов в секунду. Если пользователей у сервиса больше, уже требуется ферма из веб-серверов.
Чтобы хоть как-то разгрузить сервера, придумали использовать одинаковые ключи для нескольких TLS-сессий. И это тоже нужно учитывать, тестируя производительность TLS, ведь в этом случае нагрузка снимается — ключи не надо генерировать на каждую сессию. В настройках тестового устройства IXIA, например, это настраивается в параметрах session reuse.
Также сильной подмогой веб-серверам стало использование HTTP/2, где по одному TLS-соединению передаются все файлы в специальных потоках. Больше половины веба — уже на HTTP/2, часть — уже на HTTP/3.
SSL-расшифрование
Если вы посмотрите свой трафик на периметре сети, то обнаружите, что 80–90% — это TLS 1.2 и 1.3. Статистику использования версий протоколов SSL и TLS ведет сайт https://www.ssllabs.com/ssl-pulse . Приведу пример статистики на февраль 2022 г.
Практически все приложения перешли на защищенный обмен: Zoom, Webex, Telegram, WhatsApp, Skype, мессенджеры, социальные сети, электронная почта, файлообменники, записные книжки, интернет-банки, бизнес-приложения, обновления продуктов, вебинары и т.д. Для того чтобы посмотреть, что внутри, придумали процесс расшифрования TLS.
Английское слово Decrypt на русский язык можно перевести и как расшифрование, и как дешифрование. Русская школа криптографии вносит разный смысл в эти два термина. Расшифрование — это процесс перевода закрытого текста в открытый, когда мы знаем ключ шифрования. И это тот самый процесс, о котором мы сегодня говорим.
Дешифрование — это процесс перевода закрытого текста в открытый, когда мы не знаем ключ шифрования. По сути, это криптоанализ. И обычные люди этим не занимаются.
Проблемой для работы SSL-расшифрования является то, что мы не знаем закрытого ключа сервера и должны как-то вклиниться. Например, это dropbox.com, и у нас нет его закрытого ключа. А мы хотим проверить, не скачивает ли наш сотрудник оттуда вирус или не выкладывает ли он туда Word-документ со списком всех контактов компании. Как сделать так, чтобы мы занимались не дешифрованием, а все-таки расшифрованием?
Для этого между клиентом ставится SSL-прокси. Это делается прозрачно, т.е. это не надо явно прописывать в сети. Прокси работает прозрачно и занимается подменой сертификата сервера. В нашем примере наш SSL-прокси отправляет клиенту не сертификат dropbox.com, а собственный сертификат, говорящий о том, что он якобы dropbox.com, хотя это наше устройство, на котором работает SSL-прокси. И вот тут возникает проблема доверия. Клиент будет проверять подпись сертификата, и нужно, чтобы он этой подписи доверял.
Первое условие для работы SSL-расшифрования
Вам нужно всем клиентам SSL/TLS установить в список доверенных сертификат центра сертификации (CA), на котором подписаны сертификаты вашего SSL-прокси. Этот сертификат нужно как-то распространить всем клиентам — это первая задача, которую нужно сделать, когда вы включаете SSL-расшифрование. Не везде это можно сделать, не все приложения согласятся это поддержать. К тому же есть шанс, что приложение работает так, что проверяет еще и сертификат клиента. А вот подменить клиентский сертификат так, чтобы не нарушить цепочку доверия, уже не получится, поэтому в этом случае выполнить расшифрование не получится.
Половина HTTPS-трафика будет в исключениях
Практический опыт показывает, что половину трафика HTTPS нельзя расшифровать.
Причин для этого несколько:
приложение не доверяет сертификату SSL, который подставляет прокси-сервер в режиме MITM;
приложение использует SSL-Pinning — перестанет работать;
трафик идет только через SPAN (TAP) порт (возможен только режим Inbound SSL Decrypt без PFS);
закрытый ключ защищаемого сервера нельзя поместить в NGFW по политике безопасности;
внутри SSL может ходить не только HTTP, но и собственные приложения компании, SMTP, FTP и др.;
использование PFS (использование алгоритма Диффи–Хелмана) позволяет расшифровать только через MITM;
используются редкие протоколы, например ChaCha20 (Salsa20), x25519 Elliptical curve;
в 10–100 раз снижается скорость сети при анализе раскрытого трафика IPS, антивирусом, DLP, URL.
SSL-инспекция
Сотрудники отдела информационной безопасности используют SSL-расшифрование, для того чтобы проанализировать контент, находящийся внутри зашифрованного трафика. Чаще всего расшифровывают HTTPS и HTTP/2.
Вместе с SSL-раcшифрованием работает движок URL-фильтрации, который помещает определенные категории URL в список исключений, например адреса интернет-банков, медицинских сайтов, порталов государственных организации.
Также инспекция подразумевает включение движков антивируса, «песочницы», IPS, DLP, анализа типа файлов.
Поскольку внутри TLS-трафика может быть не только HTTP/1.1 и HTTP/2, требуется включать контроль приложений. Внутри может быть DNS, SMTP, POP3, IMAP и другие протоколы.
Итак, формула проста: SSL-инспекция — это SSL-расшифрование + анализ приложений + анализ атак + анализ типов файлов + анализ сигнатур антивируса + анализ сигнатур IPS + DLP. У некоторых производителей может быть другой функционал, например проверка индикаторов Threat Intelligence, Machine Learning и др.
Поскольку все эти операции весьма затратны для процессора и памяти вычислительного устройства, заказчику нужно заранее знать, хватит ли конкретной модели для анализа всего трафика нужными ему модулями, который есть в его сети.
Включаем критическое мышление
Некоторые производители публикуют скорость SSL-расшифрования, но называют его SSL-инспекцией. Что самое удивительное, этого не замечает никто. Давайте посмотрим, как это бывает, на конкретных примерах.
Fortinet
Самый активный производитель, который использует скорость SSL как свое конкурентное преимущество — это Fortinet. Посмотрим в его datasheet. Возьмем модель 1800F. Мы видим строку SSL Inspection Throughput, в которой указано 12 Гбит/с. Правда ли это SSL-инспекция?
Выключены:
– контроль приложений;
– URL-фильтрация;
– антивирус;
– «песочница»;
– фильтрация типов файлов;
– DLP;
– проверка сертификата CRL;
– проверка сертификата OCSP;
– журналирование.
И возникает вопрос, а какая будет производительность, если нужные нам функции инспекции SSL все-таки включить?
Если подойти к анализу данных производителя критично, возникает вопрос к модулю IPS: а какой трафик ему дали анализировать? Ведь нагрузка на IPS разная, если подавать jpg, exe, html, javascript или просто нули. Это в datasheet не указано, но мы знаем, что производительность будет разная у IPS, если подавать различные атаки, файлы и приложения внутри SSL.
Очень серьезной нагрузкой на устройство будет журналирование. Ведь на скорости 12 Гбит/с нужно, чтобы устройство справлялось с записью журналов по всей найденной в трафике информации. Что будет, если включить полное журналирование? По сути, мы покупаем устройство защиты, чтобы оно показывало нам ситуацию с безопасностью в сети — для этого и сделаны журналы безопасности и журналы трафика. Анализировать трафик и не записывать информацию о результатах анализа — очень странное упражнение. Атака могла пройти, но никаких следов в журналах не осталось. А смысл? Зачем тогда знать производительность устройства с выключенным журналированием? И в данном тесте нам показывают скорость с выключенным журналированием.
Кроме того, задержку по времени создают такие важные операции, как проверка, что сертификат SSL отозван. Обычно это выглядит как запросы по протоколу OCSP, а также поиск по внутренней базе отозванных сертификатов. К тому же задержку вызывает проверка самого сертификата на валидность. Все эти функции, как мне известно, выключаются, для того чтобы показать скорость в datasheet как можно выше. В реальной сети, естественно, это будет включено, и скорость устройства серьезно упадет. По моему опыту пропускную способность для SSL-расшифрования в datasheet у Fortinet нужно делить на 10–20. Но для вашей сети это покажет только тест.
Fortinet не указывает размер HTTPS транзакции
Важным параметром при измерении пропускной способности является размер транзакции. Странно, что этот важный параметр для HTTPS не указан, хотя в соседней строке с производительностью движка контроля приложений указано, что подаются тестовые 64Кб файлы по HTTP. Увеличив размер HTTPS транзакции, мы можем резко увеличивать пропускную способность в 10 раз, что было неоднократно показано в тестах NSS Labs (сейчас это компания Cyber Ratings https://www.cyberratings.org/ ) и NetSecOpen ( https://www.netsecopen.org/ ).
А может лучше измерять CPS?
Вообще, я считаю, что измерять производительность TLS в пропускной способности в числе байт неверно. Ведь самая большая нагрузка на процессор и память приходится именно в момент установления соединения и в момент обмена и генерации ключей шифрования, а не на сам процесс передачи зашифрованых AES байт данных.
Поэтому более правильно оценивать число новых соединений в секунду, которое обычно указывается словосочетанием Connection Per Second (CPS). И реально в сетях это тот самый параметр, в который упираются все NGFW, особенно в финансовой индустрии, где много коротких SSL-соединений.
Если вы посмотрите в этот же datasheet, вы обнаружите, что, даже включив SSL Decrypt + IPS, это устройство 1800F снизило CPS с 750 000 до 9500 (в 78 раз). А что будет, если включить еще антивирус, контроль приложений, блокировку файлов, DLP и т.д.?
Еще одна важная особенность устройств Fortinet — несколько режимов работы. По умолчанию Fortinet показывает все измерения в flow mode и на стандартных портах. На самом деле в вашей сети, скорее всего, устройство будет работать в более безопасном режиме, который называется proxy mode, или в режиме NGFW policy mode, когда вы можете писать правила по приложениям L7 и URL-категориям. Однако информации по производительности в этих режимах у Fortinet публично нет, запрашивайте ее у производителя. Как известно, в proxy mode в зависимости от модели производительность снижается в 2–3 раза. Также снизится производительность, если включить контроль TLS не только на стандартных портах, но и на любом порту протокола TCP.
Cisco
Другой производитель, который публикует пропускную способность SSL, — компания Cisco.
Cisco с ходу заявляет, что они тестируют именно скорость SSL-расшифрования — вообще никакой модуль анализа не включается. Скорость SSL-инспекции у этого производителя тоже неизвестна. В datasheet ( https://www.cisco.com/c/en/us/products/collateral/security/firepower-4100-series/datasheet-c78-742474.html ) указываются все параметры для TLS, в отличие от datasheet Fortinet. Заметьте, что в сноске также написано, что расшифровывается только 50% от передаваемого трафика.
Если посмотреть презентацию ( https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2020/pdf/BRKSEC-2494.pdf ),
на слайде 47 подробно рассказано, как проходит тестирование SSL-расшифрования.
Здесь четко указывается версия TLS 1.2, длина RSA-ключа — 2048 бит, длина ключа AES — 256 бит, а также алгоритм хеширования SHA. Интересно вам должно быть почему расшифровывается лишь 50% от всего генерируемого трафика. Иначе говоря, если в datasheet указано 10 Гбит/с, это означает, что 5 Гбит/с — это просто HTTP, а 5 Гбит/с — это именно расшифрованный и зашифрованный обратно HTTPS. Я думаю, что это связано с тем, что в корпоративных сетях действительно получается расшифровать только 50% трафика SSL. И вполне логично тестировать производительность только 50% от всего трафика. Мало того, тот TLS трафик, который мы не расшифровали еще и выключает трату ресурсов процессора на другие движки, поскольку мы не можем проверить зашифрованный трафик антивирусом, песочницей и IPS.
Скрывать размер транзакции — общий тренд
Размер транзакции HTTPS и HTTP из их презентации мне тоже непонятен. SSL Record size 1460 — ну очень странно написано. Поскольку это размер фрейма, а не SSL-транзакции. Я попросил коллег прислать более подробный datasheet Cisco, и в нем указаны размеры транзакций для других тестовых режимов, но не для SSL-расшифрования.
Обозначение 1024B это транзакции, где передают 250Кб HTML файл, и 450B — это 11Кб транзакция.
Но нигде для TLS размер транзакции не указан. Причем он не указан даже в более продвинутой презентации с Cisco Live. Спрашивайте компанию Cisco про размер транзакции и про производительность SSL-инспекции, если включить требуемые вам движки анализа контента.
И самое интересное мы видим в презентации: они переиспользуют старые ключи TLS в нескольких сессиях. Обычно каждая сессия TLS идет со своими ключами, внутри работает алгоритм Диффи–Хеллмана для генерации сессионного ключа. Но настройка session reuse позволяет использовать старые ключи для нескольких новых сессий. Такая настройка есть в любом генераторе трафика, например в IXIA. Эта фишка позволяет показать более высокую производительность, поскольку разгружает процессор, ведь ему не надо создавать новый ключ для каждой сессии.
Также можно задаться вопросом: а что передается внутри SSL — http- или SMTP-приложения, какие именно файлы. Но в данном тесте вся безопасность выключена, поэтому тип файла не повлияет на производительность именно в этом тесте. Если вы включите IPS или антивирус, тип передаваемого файла тоже нужно учитывать.
А что другие производители
У других производителей найти в datasheet такой параметр, как SSL-расшифрование, а тем более SSL-инспекцию, не получилось. Я связываю это с тем, что реально SSL-расшифрование очень многоплановая проверка и указывать какой-то один результат, все равно, что ткнуть пальцем в небо.
Вывод
Итак, публикует ли кто-то из производителей производительность SSL-инспекции? К сожалению, нет. Всегда нужно требовать пилот и тестирование на своем трафике либо на трафике HTTPS c нужным вам размером транзакции. Для примера: чаще всего тестируют производительность на транзакциях, внутри которых передают 64Кб файлы HTML.
Мы посмотрели выше, что, хотя у Fortinet и Cisco данные вроде бы указаны, они не несут никакого практического смысла — мы не знаем какая реально будет скорость устройства, если инспекцию контента все-таки включить. А нам нужна производительность именно SSL-инспекции, а не SSL-расшифрования. На своем личном опыте тестирования различных производителей я видел, что производительность может упасть даже в 100 раз при включении всех модулей анализа. Нужно ли вам устройство, которое позволяет анализировать лишь одно новое SSL-соединение в секунду антивирусом, URL, DLP и IPS?
Вывод простой: если вам нужна SSL-инспекция, тестируйте этот функционал перед покупкой со всеми включенными модулями защиты, причем тестируйте именно на вашем трафике, а не на каком-то искусственном. Либо вы можете воспользоваться сервисом NGFW в облаке или SASE, где вы не задумываетесь о вопросах производительности вообще.
