Отличие 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 инспекция в вашей сети
Причем производительность вычислительного устройств зависит от алгоритмов шифрования и обмена ключами: RSA, ECDHE, AES, DES, и от длины ключей 2 Кб или 1 Кб, 56 байт или 256 байт. А еще производительность SSL/TLS зависит от того обращаемся ли мы к базе CRL для проверки не был ли сертификат отозван, часто это протокол OCSP. А еще производительность зависит от такого параметра как session reuse, это когда новое SSL соединение использует старый ключ от прошлого SSL соединения, что экономит процессорное время.
HTTPS Inspection — передовой опыт
В этой статье представлены некоторые рекомендации по развертыванию и использованию HTTPS Inspection для предотвращения распространенных проблем в конфигурации.
Обратите внимание: для извлечения пользы из последних обновлений в области безопасности, производительности и стабильности, Check Point всегда рекомендует обновить систему до самой последней версии (upgrade Security Gateway / upgrade Cluster / upgrade VSX / upgrade 600 appliance / upgrade 1100 appliance / upgrade Security Management Server / upgrade Multi-Domain Security Management Server / upgrade SmartConsole).
Благодаря использованию сертификатов, шлюз безопасности становится посредником между устройством пользователя и безопасным веб-сайтом. Все данные хранятся в личных журналах HTTPS Inspection. Только администраторы с доступом к HTTPS Inspection смогут увидеть все поля журнала.
HTTPS Inspection Rule Base представляет собой набор правил, определяющих, какого рода HTTPS трафик будет проверяться с помощью шлюза безопасности. Проверка осуществляется посредством всех программных блейдов (Software Blades), поддерживающих HTTPS Inspection, а именно:
Если запрос соответствует политикам безопасности, шлюз безопасности использует сертификат для внутреннего сервера, чтобы создать соединение HTTPS с внешним клиентом. Шлюз безопасности создает новое соединение HTTPS с внутренним сервером. Поскольку шлюз безопасности имеет защищенное соединение с внешним клиентом, он способен расшифровать HTTPS трафик. Расшифрованный трафик проверяется в соответствии с политиками.
Поток на Security Gateway:
Если запрос соответствует политикам безопасности, шлюз гарантирует, что сертификат на сервере (в интернете ) действителен. Шлюз безопасности создает новый сертификат и использует его для нового соединения HTTPS с сервером. Существуют два HTTPS соединения, первое — к внутреннему клиенту, второе – к серверу. Это позволяет расшифровывать и проверять пакеты в соответствии с политиками шлюза безопасности и другими базовыми правилами. Далее пакеты снова шифруются и перемещаются в место назначения.
Поток на Security Gateway:
2.Check Point на максимум. HTTPS-инспекция
В предыдущем уроке мы затронули проблему человеческого фактора в Информационной безопасности. В итоге мы сделали вывод, что не важно на сколько качественное и дорогое оборудование вы используете, т.к. все “упрется” в настройку, которая должна быть выполнена грамотно. В этом уроке мы рассмотрим https-инспекцию. Довольно многие недооценивают важность этой функции без которой немыслима современная защита сети. Но обо всем по порядку.
Защита веб-трафика
Практически все современные NGFW или UTM решения имеют функционал проверки веб-трафика. Это и категоризация сайтов и проверка скачиваемого контента и определение веб-приложений. Причем последний пункт (веб-приложения) очень важен, т.к. через один и тот же порт могут работать огромное кол-во сервисов. И если с проверкой HTTP-трафика практически у всех вендоров нет проблем, то HTTPS — настоящий вызов для современных средств защиты.
HTTPS
Думаю, что нет особого смысла рассказывать что такое HTTPS и на сколько он важен для организации безопасного Интернета. Благодаря HTTPS можно быть уверенным, что между клиентом (браузер) и сервером (web-server) невозможно перехватить или изменить передаваемую информацию. Согласно статистике за 2017 год, доля HTTPS-трафика превысила 50%.
Более того, современные браузеры (например google chrome) будут помечать http-сайты с формой авторизации как недоверенные, а google будет понижать их в поисковой выдаче. Все это спровоцирует еще более стремительное увеличение доли HTTPS-трафика.
Как было сказано ранее, HTTPS используется для защищенного общения между двумя узлами в сети Интернет. При этом HTTPS не является каким-то новым протоколом, в целом это обычный HTTP, просто для защиты трафика в качестве транспортного протокола используется SSL или TLS. Именно эти протоколы и отвечают за аутентификацию, шифрование и целостность трафика. Мы не будем подробно рассматривать работу этих протоколов, но всем кто интересуется очень рекомендую вот эту статью. В грубом приближении работа HTTPS выглядит следующим образом:
Т.е. клиент инициирует TLS-запрос к Web-серверу и получает TLS-ответ, а также видит цифровой сертификат, который естественно должен быть доверенным. Пример сертификата при обращении на сайт vk.com изображен выше. В нем содержатся параметры защищенного соединения и открытый ключ. Кроме того, браузер может “подсказать” какая именно версия TLS используется. Повторюсь, что это очень упрощенное описание работы TLS.
После успешного TLS Handshake, начинается передача данных в шифрованном виде. Казалось бы, что это очень хорошо (так оно и есть). Однако для “безопасника” в компании это настоящая головная боль. Поскольку он не “видит” этот трафик и не может проверять его содержимое ни антивирусом, ни системой предотвращения вторжений (IPS), ни DLP-системой, ничем… А это в свою очередь представляет собой очень серьезную уязвимость. Т.к. большинство сайтов переходят на HTTPS, то без HTTPS инспекции ваш интернет-шлюз не может проверять большую часть Web-трафика (т.к. он зашифрован). Кроме того, злоумышленники все чаще используют облачные файловые хранилища для распространения вирусов, которые также работают по HTTPS. Таким образом, каким бы качественным и дорогим не был ваш межсетевой экран (будь то UTM или NGFW решение), он будет пропускать абсолютно все вирусы и зловреды без включенной HTTPS инспекции. Даже пресловутый тестовый вирус EICAR, который детектится любым антивирусом, будет успешно проходить вашу защиту через HTTPS. Мы это обязательно рассмотрим на примере.
HTTPS-инспекция
Решить проблему безопасников призвана технология HTTPS-инспекции. Ее суть до безобразия проста. Фактически, устройство, которое организует HTTPS-инспекцию, совершает атаку типа man-in-the-middle. Выглядит это примерно следующим образом:
Т.е. Check Point перехватывает запрос пользователя, поднимает с ним HTTPS-соединение и уже от себя поднимает HTTPS-сессию с ресурсом, к которому обратился пользователь. В данном случае клиенту предъявляется сертификат, который выпустил сам Check Point. Само собой, что данный сертификат должен быть доверенным. Для этого в Check Point-е есть возможность импортировать сертификат от доверенного CA (subordinate certificate). При импортировании убедитесь, что сертификат имеет алгоритм подписи не ниже sha256, т.к. если он будет например sha1, то современные браузеры будут “ругаться” на такие сертификаты. Либо же вы можете сгенерировать самоподписанный сертификат, который затем необходимо сделать доверенным для всех компьютеров. Именно этот способ мы рассмотрим на примере.
Таким образом, оказавшись посередине между двумя шифрованными соединениям, Check Point получает возможность проверять трафик и все файлы, как с помощью антивируса, так и с помощью остальных блейдов (IPS, Threat Emulation и т.д.). Более подробно о HTTPS-инспекции Check Point вы можете почитать здесь.
Ограничения HTTPS-инспекции
Однако, не все так просто. Метод man-in-the-middle работает далеко не всегда. Есть случаи когда расшифровать https-трафик просто невозможно. Вот несколько примеров:
1) Используются отечественные криптоалгоритмы (ГОСТ) вместо стандартных SSL/TLS.
На данный момент ни одно иностранное решение не может обеспечивать корректную расшифровку подобного HTTPS-трафика (хотя и отечественных решений умеющих делать подобную https-инспекцию лично я не знаю). В качестве решения можно настроить исключения в HTTPS-инспекции для сайтов данной категории.
2) Используется Certificate Pinnig.
Т.е. приложение клиента заранее знает сертификат сервера, к которому он обращается. Обычно проверяется серийный номер сертификата. В этом случае приложение просто не будет смотреть в локальное хранилище доверенных сертификатов и при попытке подмены естественно будет возникать ошибка. Чаще всего данная проблема относится к толстым клиентам (такие как Skype, Telegram), которые используют SSL/TLS в качестве транспорта. Кроме того, буквально на днях обнаружил, что обновленная версия google chrome также начала использовать технологию certificate pinning для своих сервисов (youtube, google drive, gmail и так далее). Это делает невозможным использование https-инспекции. Компания Google активно заботится о безопасности пользователей, но значительно усложняет жизнь безопасникам. В этом случае есть два выхода:
3) Используется аутентификация не только сервера, но и клиента.
Это характерно для сайтов из категории финансовых услуг, когда для доступа к какому-нибудь банк-порталу клиент использует специальный ключ или токен. Естественно, что в данном случае устройство, которое осуществляет HTTPS-инспекцию просто не сможет организовать https-соединение с сервером, т.к. не обладает нужным ключем. Проблема решается только настройкой исключений в HTTPS-инспекции.
4) Используется отличный от SSL/TLS протокол.
В данном случае речь уже не о ГОСТ-шифровании, а об относительно новом протоколе от google — quic. Компания гугл начинает активно переводить свои сервисы именно на этот протокол. При этом на текущий момент невозможно обеспечить его расшифровку. Единственным решением в данном случае является блокировка протокола quic, после чего сервисы google начинают использовать стандартный SSL/TLS.
Настройка
Описать настройку в формате текста довольно трудоемко, поэтому мы сделали небольшое видео. В первой части рассказывается вышеописанная теория, а во второй части мы пробуем скачать вирус по HTTPS, а затем настроим HTTPS-инспекцию и сравниваем результат.
Вывод
Самое главное, что нужно вынести из этого урока — HTTPS-инспекция это ОБЯЗАТЕЛЬНЫЙ компонент современной защиты. Без этой функции в вашей сети огромная черная дыра с точки зрения безопасности. И это относится не только к Check Point-у, но и ко всем другим решениям. Обязательно протестируйте свою сеть подобным образом. Все что нужно, это какой-нибудь тестовый вирус и клиентская машина, желательно без антивируса, чтобы тот не смог заблокировать скачивание файла (для чистоты эксперимента).
На этом мы заканчиваем второй урок, спасибо за внимание!
Провести бесплатный аудит настроек безопасности Check Point можно здесь
What is SSL Inspection? How does it work?
Everything you need to know about SSL Inspection, sometimes known as HTTPS Interception
SSL Inspection or TLS/HTTPS Interception is a fascinating concept that divides opinion. Some regard SSL Inspection as an absurd idea, while some are rooting for it with conviction. There seems to be very little middle ground. It’s kind of like the never-ending “Pineapple on the Pizza” debate. Personally, I cannot stand the sight of Pineapple staring at me while lying comfortably on a slice of Pizza. But let’s not go there as we all know how it ends—err, doesn’t end.
Instead, let’s untangle the technique that is SSL inspection and see how it works.
What is SSL Inspection?
SSL/TLS Inspection or HTTPS Interception is the process of intercepting SSL/TLS encrypted internet communication between the client and server. Interception can be executed between the sender and the receiver and vice versa (receiver to sender)—it’s the same technique used in man-in-the-middle (MiTM) attacks, without the consent of both entities.
Now at first blush, it may seem that SSL Inspection undermines the purpose that HTTPS/SSL was created for. However, it’s not as simple as that.
We all know that SSL/TLS encryption helps us protect our sensitive information (such as passwords and credit card details). Every single bit of data is turned into an indecipherable format and thus it protects us from eavesdropping and data tampering.
However, it’s not all sunshine and rainbows.
Along with your legitimate information, malicious content could also be hidden in the encrypted traffic. And because it’s encrypted, it goes unnoticed by common security mechanisms meaning it could do the damage that it was intended to do. SSL-based malware attacks have become a common thing these days with HTTPS being utilized in around 37% of malware.
SSL Inspection is *intended to inspect* and filter out potentially dangerous content such as malware. This kind of inspection or interception is called Full SSL Inspection or Deep SSL Inspection. It allows you to do antivirus scanning, web filtering, email filtering, etc. Interception and inspection are done by an interception device sitting in the middle, often referred to as a ‘middlebox.’
How does SSL Inspection work?
To put it in simple terms, SSL Inspection or HTTPS Interception is a man-in-the-middle attack executed to filter out malicious content. SSL Inspection or TLS Interception, as we saw, is done by means of an interception device. This interceptor sits in between the client and server, with all the traffic passing through it.
When the connection is made over HTTPS, the inspector intercepts all traffic, decrypts it and scans it. First, the interceptor establishes an SSL connection with the web server. Here, it decrypts and examines the data. Once the scanning is done, it creates another SSL connection—this time with the client (browser). This way, the data gets to the client in an encrypted format—the way it was intended originally.
Here’s an overview of the SSL Inspection process of inbound traffic:
SSL Inspection works almost the same way for outbound traffic as well. Here’s a visualization courtesy of 01Net:
Poorly Executed SSL Inspection is Harming Security
In 2017, a study conducted by a large team of academics and professionals showed that SSL Inspection is doing more harm than good. This team included academics and professionals such as Zakir Durumeric, Zane Ma, Drew Springall, Elie Bursztein, Nick Sullivan (Head of Cryptography at Cloudflare), and Richard Barnes (Internet Security Research Group).
The team analyzed nearly 8 billion SSL/TLS handshakes, comparing data of the observed connections to determine when an interceptor was bridging the connection between the server and the client. They found that up to 10.9% of observed connections were intercepted.
This has enormous implications on the true privacy provided by those HTTPS connections. But the more significant problem is that some interception products are severely weakening HTTPS by using outdated cryptography and failure to implement essential features.
The study shows that 62% of traffic that traverses a network middlebox has reduced security and 58% of middlebox connections have severe vulnerabilities. They also investigated popular antivirus and corporate proxies, finding that nearly all of them reduce connection security and that many introduce vulnerabilities.
While there is a way to perform HTTPS inspection securely, and without much latency, poorly performed SSL interception is a problem.
Final Word
From the organizational security point of view, SSL Inspection looks good on the paper. And if implemented correctly, it could prevent a lot of damage. But as we saw, that doesn’t always happen.
A good part of the blame must go to the middlebox manufacturers for using outmoded or insecure SSL/TLS configurations. And then, of course, there’s always a risk in the form of the human element.
Right now, SSL inspection could potentially be doing more harm than good, that’s why over the coming months we’re going to delve into the practice and explore the best methods and practices for securely inspecting HTTPS traffic without sacrificing security or performance.
As always, feel free to leave any comments or questions below.
5 comments
Hey,
First, thanks for the text!
Second, I really don’t know exactly how the TSL protocol works, but if its so easy to intercept the traffic, read and analyse the msg.. why anyone else with acess to the network can’t do that for hacking?
Best Regards,
Alexandre
The middlebox needs to have valid certificates at both the client and server location. So any random MITM attacks are very hard.
it’s not that easy, the intercepting proxy must make sure that its own CA is used on the client side (some corporations do push that CA on the employees’ machines to enforce ‘security’)
Que tipo de certificado requiero comprar para hacer deep inspection?
No es necesario comprar un certificado para hacer deep inspection. Solamente necesita averiguar que el certificado (trusted root certificate authority) de su middlebox es en sus computadores/endpoints. Entonces cuando el middlebox hace un conexion con los computadores, los computadores ver que el certificado que el middlebox ha presentado es valido.
Leave a Reply Cancel reply
Author
Jay Thakkar
After graduating from university with an engineering degree, Jay found his true passion as a writer…specifically, a cybersecurity writer. He’s now a Hashed Out staff writer covering encryption, privacy, cybersecurity best practices, and related topics.
Инспектирование SSL
С помощью данного раздела администратор может настроить инспекцию данных, передаваемых по протоколу TLS/SSL, это в первую очередь HTTPS, а также почтовые протоколы SMTPS и POP3S. В UserGate используется известная технология man-in-the-middle (MITM), при которой контент расшифровывается на сервере, а затем анализируется.
Инспектирование SSL необходимо для корректной работы правил фильтрации контента и правил веб-безопасности. Дешифрование SMTPS иPOP3S необходимо для блокирования спама и вирусной проверки почтового трафика.
После дешифрования данные шифруются сертификатом, выписанным центром сертификации, указанным в разделе Сертификаты. Чтобы браузеры пользователя не выдавали предупреждение о подмене сертификата, необходимо добавить сертификат центра сертификации в доверенные корневые сертификаты. Более подробно это описано в разделе Приложение 1. Установка сертификата локального удостоверяющего центра .
Аналогично браузерам пользователя некоторые почтовые серверы и пользовательские почтовые программы не принимают почту, если сертификат был подменен. В этом случае необходимо произвести в почтовых программах настройки, отключающие проверку сертификатов, или добавить исключения для сертификата UserGate. Подробно о том, как это сделать, смотрите в документации на почтовое ПО.
Важно! Правила применяются сверху вниз в том порядке, в котором они указаны в консоли. Выполняется всегда только первое правило, для которого совпали условия, указанные в правиле. Это значит, что более специфические правила должны быть выше в списке, чем более общие правила. Используйте кнопки Выше/Ниже для изменения порядка применения правил.
Важно! Для срабатывания правила необходимо, чтобы совпали все условия, указанные в параметрах правила. Чекбокс Инвертировать в условии правила меняет действие условия на противоположное, что аналогично логическому действию отрицание.
Важно! Если не создано ни одного правила, то SSL не перехватывается и не дешифруются, соответственно, контент, передаваемый по SSL, не фильтруется.
Чтобы создать правило инспектирования SSL, необходимо нажать на кнопку Добавить в разделе Политики безопасности—>Инспектирование SSL и указать необходимые параметры.