Цепочка доверия. CC BY-SA 4.0 Yanpas

Инспекция трафика SSL (расшифровка SSL/TLS, анализ SSL или DPI) становится все более горячей темой обсуждения в корпоративном секторе. Идея расшифровки трафика вроде бы противоречит самой концепции криптографии. Однако факт есть факт: всё больше компаний используют технологии DPI, объясняя это необходимостью проверки контента на предмет зловредов, утечек данных и т. д.

Что ж, если принять за факт, что необходимо внедрять такую технологию, то следует хотя бы рассмотреть способы сделать это наиболее безопасным и хорошо управляемым способом. Хотя бы не полагаться на те сертификаты, например, которые вам даёт поставщик системы DPI.

Есть один аспект реализации, о котором не все знают. На самом деле многие действительно удивляются, когда слышат о нём. Это частный центр сертификации (ЦС). Он генерирует сертификаты для дешифровки и повторного шифрования трафика.

Вместо того, чтобы полагаться на самоподписанные сертификаты или сертификаты из устройств DPI, вы можете использовать выделенный ЦС от стороннего центра сертификации, такого как GlobalSign. Но сначала давайте сделаем небольшой обзор самой проблемы.

Что такое SSL-инспекция и почему она используется?

Все больше публичных веб-сайтов переходят на HTTPS. Например, по статистике Chrome, в начале сентября 2019 года доля зашифрованного трафика в России достигло 83%.



К сожалению, шифрованием трафика всё чаще пользуются и злоумышленники, тем более что Let's Encrypt тысячами раздаёт бесплатные SSL-сертификаты в автоматизированном режиме. Таким образом, HTTPS используется повсеместно — и замочек в адресной строке браузера перестал служить надёжным индикатором безопасности.

С этих позиций и продвигают свой продукт производители решений DPI. Они внедряются между конечными пользователями (т. е. вашими сотрудниками, просматривающими веб-страницы) и Интернетом, отфильтровывая вредоносный трафик. На сегодняшний день на рынке существует ряд таких продуктов, но процессы по сути одинаковые. Трафик HTTPS проходит через устройство проверки, где он расшифровывается и проверяется на наличие вредоносных программ.

После завершения проверки устройство создаёт с конечным клиентом новую SSL-сессию для расшифровки и повторного шифрования содержимого.

Как работает процесс расшифровки/повторного шифрования

Чтобы устройство SSL-инспекции расшифровало и повторно шифровало пакеты перед отправкой конечным пользователям, оно должно иметь возможность выдавать сертификаты SSL на лету. Это означает, что на нём должен быть установлен сертификат ЦС.

Для компании (или другого человека-в-середине) важно, чтобы эти SSL-сертификаты были доверенными в браузерах (т. е. не вызывали страшных предупреждающих сообщений, подобные приведённому ниже). Поэтому цепочка ЦС (или иерархия) должна быть в хранилище доверия браузера. Поскольку эти сертификаты не выдаются из общедоступных доверенных центров сертификации, необходимо вручную передать иерархии ЦС всем конечным клиентам.


Предупреждающее сообщение для самоподписанного сертификата в Chrome. Источник: BadSSL.com

На компьютерах с Windows можно задействовать Active Directory и групповые политики, но для мобильных устройств процедура сложнее.

Ситуация ещё больше усложняется, если нужно поддерживать в корпоративной среде и другие корневые сертификаты, например, от Microsoft, или на базе OpenSSL. Плюс защита секретных ключей и управление ими, чтобы какой-нибудь из ключей не истёк неожиданно.

Лучший вариант: частный, выделенный корневой сертификат от стороннего ЦС

Если управление несколькими корнями или самоподписанные сертификаты не привлекают, то есть и другой вариант: можно положиться на сторонний ЦС. В этом случае сертификаты выдаются из частного удостоверяющего центра, который связан в цепочке доверия с выделенным, частным корневым центром сертификации, созданным специально для компании.


Упрощённая архитектура для выделенных клиентских корневых сертификатов

Такая настройка устраняет некоторые из проблем, упомянутых ранее: хотя бы уменьшает количество корней, которыми нужно управлять. Здесь можно использовать только один частный корневой центр для всех внутренних потребностей PKI с любым количеством промежуточных центров сертификации. Например, на приведённой выше диаграмме показана многоуровневая иерархия, в которой один из промежуточных центров сертификации используется для проверки/расшифровки SSL, а другой — для внутренних компьютеров (ноутбуков, серверов, настольных компьютеров и т. д.).

В этой схеме не нужно размещать ЦС на всех клиентах, потому что ЦС верхнего уровня размещается у GlobalSign, что решает проблемы с защитой закрытого ключа и сроком действия.

Ещё одно преимущество этого подхода в возможности отзыва удостоверяющего центра SSL-инспекции по любой причине. Вместо него просто создаётся новый, который привязывается к вашему исходному частному корню, и можно использовать его немедленно.

Несмотря на все противоречия, предприятия всё чаще внедряют SSL-инспекцию трафика как часть внутренней или частной инфраструктуры PKI. Другие варианты использования частной PKI — выпуск сертификатов для аутентификации устройств или пользователей, SSL для внутренних серверов, а также разные конфигурации, которые не разрешены в общедоступных доверенных сертификатах в соответствии с требованиями CA/Browser Forum.

Браузеры сопротивляются

Нужно заметить, что разработчики браузеров пытаются противостоять этой тенденции и защитить конечных пользователей от MiTM. Например, несколько дней назад Mozilla приняла решение включить по умолчанию протокол DoH (DNS-over-HTTPS) в одну из следующих версий браузера в Firefox. Протокол DoH скрывает DNS-запросы от DPI-системы, затрудняя SSL-инспекцию.

Об аналогичных планах 10 сентября 2019 года объявила компания Google для браузера Chrome.