Отличие SSL инспекции от SSL расшифрования

Дата: 20.11.2021. Автор: Денис Батранков. Категории: Блоги экспертов по информационной безопасности
Отличие SSL инспекции от SSL расшифрования

Иногда ко мне на встречи приходят заказчики, которые впечатлены тестами NSS Labs или просто datasheet поставщиков, которые им показали как быстро они расшифровывают SSL в своем устройстве класса все-в-одном. Причем глаза заказчиков горят, потому что они на каком-то основании думают, что это SSL расшифрование это SSL инспекция. 

В словах расшифрование и инспекция как минимум разные буквы. Так же как и в словах decryption и inspection. Почему же люди считают, что это одно и тоже? Давайте разберемся.

SSL инспекция работает в режиме proxy

Для начала приведу схему как идет поток ваших данных внутри NGFW к разным модулям. Внутри устройства SSL Decrypt используется два раза. Сначала, чтобы установить соединение и подтвердить доверие между клиентом и NGFW. И второй раз, чтобы установить соединение и установить доверие между NGFW и сервером. То есть любой NGFW выполняет расшифрование как прозрачный SSL proxy. Существуют на рынке и обычные прокси, которые тоже расшифровывают SSL, но они это делают только для HTTPS трафика. А NGFW расширяет функциональность и SSL Decrypt работает обычно для любого трафика на основе TLS.

Если возникло непонимание чем отличается SSL и TLS, то еще одна картинка ниже. Далее по тексту буду использовать слово SSL как более часто употребляемое, хотя конечно технически у вас в сети уже давно TLS 1.2 и TLS 1.3. TLS 1.1 и ранее уже не рекомендуется использовать в своей сети, как небезопасные версии.               

SSL инспекция в вашей сети

Зачем нужно расшифрование HTTPS, POP3S, IMAPS, SMTPS, FTPS и в принципе любого протокола, который сегодня основан на TLS 1.2 и TLS 1.3, но по-старинке мы используем название SSL. Для того, чтобы после расшифрования анализировать открытый трафик вашими средствами безопасности. В NGFW встроены такие модули безопасности как URL категоризация, cистема предотвращения атак (IPS), антивирус, песочница,  блокировка файлов по типам, DLP, Threat Intelligence, Machine Learning, DNS Security. Если трафик зашифрован, то очевидно, что эти системы работают неполноценно. Поэтому NGFW сегодня выполняет функцию SSL расшифрования. И вот SSL расшифрование + включенные модули безопасности — является SSL инспекцией.

Иногда функцию SSL расшифрования выполняет внешний балансировщик, например F5, A10, Radware, то да, это верно, они занимаются только SSL Decrypt.
А если функция расшифрования выполняется одновременно на NGFW и одновременно в нем включены модули защиты, то тогда, это SSL Inspection.

И вот эта путаница приводит к неверному выбору модели устройства. Дело в том, что разница в производительности одного и того же устройства с включенным функционалом threat protection и с выключенным — в 10 раз. Даже распознавание приложений убивает иногда устройство, что уж тут говорить про антивирус, с его миллионами сигнатур.

Причем производительность вычислительного устройств зависит от алгоритмов шифрования и обмена ключами: RSA, ECDHE, AES, DES, и от длины ключей 2 Кб или 1 Кб, 56 байт или 256 байт.  А еще производительность SSL/TLS зависит от того обращаемся ли мы к базе CRL для проверки не был ли сертификат отозван, часто это протокол OCSP. А еще производительность зависит от такого параметра как session reuse, это когда новое SSL соединение использует старый ключ от прошлого SSL соединения, что экономит процессорное время.

Внутри SSL может быть любое приложение. Даже веб трафик сегодня идет по QUIC, HTTPS и по HTTP/2 — это разные протоколы, там по-разному надо анализировать трафик и файлы в нем. Что уж говорить про такие протоколы на базе SSL как SMTPS, где файлы еще надо из BASE64 выковыривать.

URL категоризация 

Зачем нужна URL категоризация во время SSL инспекции? Потому что часть URL вы не имеете права расшифровывать даже банально по законодательству: личные страницы банков, медицинские карты, госуслуги. GDPR и закон о персональных данных не дремлют. И также вы будете исключать из расшифрования множество сайтов, который против расшифрования в принципе: все системы обновления, например, Microsoft Update не разрешит себя расшифровать, все вебинары, например, Zoom и Webex не разрешат себя расшифровать.. и в общем-то 50% трафика вы не сможете расшифровать в своей сети, потому что SSL pinning и проверка клиентских сертификатов не дремлют тоже. Также как и другие нюансы.

Вывод

Резюмируя: если вам говорят, что производитель очень быстрый на SSL Inspection, то, опыт показывает, что он точно выключил всю безопасность и измерил производительность с SSL Decrypt только. Причем это не какая-то вероятность, а именно 100% ситуация. Потому что всегда, когда ко мне приходили люди и счастливо говорили ой какой он быстрый то я показывал пальцем в документ этого же поставщика, где черным по белому написано: мы выключили контроль приложений, URL фильтрацию, анализ файлов любым способом, антивирус, песочницу и измерили скорость. Ну, молодцы. Только зачем сбивать с толку людей, что это скорость SSL инспекции?

И кстати, самый важный параметр для Вас не SSL throughput, а SSL new transaction per second. Смотрите в него. Ведь самое долгое в TLS — установить соединение и проверить доверие, а не передать трафик. Также как, самое долгое в поездке за границу — получить визу. Это тема отдельной статьи.
Попросите предоставить вам производительность именно с всеми включенными функциями анализа. Ведь запускать вхолостую SSL Decrypt вы не будете — вы явно будуте анализировать трафик после расшифрования. В противном случае вы покупаете устройство греть трафик в ЦОД.

Если посмотреть тесты NSS labs — там обычно измеряется только скорость с HTTPS Decrypt c включенным IPS. Это явно не весь функционал NGFW. Также я видел еще результаты публичных тестов, что когда тестируют SSL трафик, но расшифровывают только 50% а 50% просто пропускают и считают сколько пропустили. Также интересные результаты показывает NetSecOpen, где была включить попытка все модули. Но некоторые их результаты не бьются с реальными тестами, в которых участвовал я сам, поэтому к NetSecOpen надо отнестись внимательно, но осторожно. Ведь в тестах участвует две стороны: тот кто настраивает тестовый стенд и тот кто настраивает устройство. И у тех и у других сотни настроек, которые можно включить и включить. А какие были включены и выключены — там не описаны.
 


Источник — персональный блог Батранкова Дениса «Реальная безопасность».

Денис Батранков

Об авторе Денис Батранков

Советник по безопасности корпоративных сетей.
Читать все записи автора Денис Батранков

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *