Расшифровка трафика на сетевом экране нужна для дальнейшей его обработки различными модулями и службами такими как AV, IPS, URL-Filtering, AppControl и т.п.  Такая обработка позволяет эффективно устранять угрозу до того, как она попадёт на конечное устройство.

Для корректной работы SSL расшифровки есть два важных требования:

-отключение Fast Forwarding;

-активная лицензия Content Security Group.

 

Fast forwarding.

Fast forwarding – это режим аппаратного ускорения обработки трафика, при котором пакеты передаются через специализированные чипы (NPU/ASIC), минуя глубокую программную обработку в CPU. Это технология обхода программной обработки для повышения производительности. Пакеты, соответствующие простым правилам, например, NAT, базовый ACL, маршрутизация между интерфейсами, не проходят полный анализ в ядре системы. Аппаратные ускорители не поддерживают DPI, IPS, Anti-Virus, VPN, сложную маршрутизацию, Multicast IGMP, сложный NAT. Для работы этих модулей нужна полная процессорная обработка с отключением Fast forwarding. Отключаем.

 

С лицензией всё понятно – покупаем, активируем.

 

Принцип работы расшифровки.

SSL-трафик это трафик, зашифрованный по протоколу SSL или TLS (Secure Sockets Layer/Transport Layer Security) с помощью сертификата.

SSL-сертификат – это X.509-сертификат, выданный и подписанный центром сертификации (CA), который содержит открытый ключ сервера и подтверждает его подлинность. Он используется в протоколе SSL/TLS для установления защищённого соединения и создания доверия между клиентом и сервером.

HTTPS (HyperText Transfer Protocol Secure) – это расширение протокола HTTP, при котором данные между клиентом и сервером передаются в зашифрованном виде с использованием протокола SSL/TLS. HTTPS = HTTP + SSL/TLS. Кроме HTTP шифрование часто используют в FTP, SMTP и некоторых других протоколах.

В настоящее время почти весь защищённый трафик в Интернете использует TLS 1.2 или TLS 1.3. Протоколы SSL 2.0 и 3.0 больше не используются из-за критических уязвимостей. Почему до сих пор говорят SSL-расшифровка или SSL-трафик, SSL Inspection, SSL Proxy, SSL VPN? Потому что это исторически укоренившийся термин, который упрощает понимание.

 

Обычный вариант доступа к сайту.

Клиент инициирует HTTPS-запрос к сайту в Интернете через браузер. Отправляет TCP SYN на порт 443(TCP Handshake).

Сайт (сервер) отправляет в ответ сертификат с открытым ключом.

Клиент проверяет сертификат на доверие и подлинность. Сравнивает со списком установленных в системе или в браузере доверенных корневых сертификатов. При нахождении совпадения сертификат считается действительным и устанавливается TLS-соединение

Клиент генерирует сеансовый ключ, шифрует его открытым ключом сервера и отправляет серверу.

Сервер расшифровывает этот ключ своим закрытым ключом.

Далее обе стороны используют один и тот же сеансовый ключ, чтобы шифровать весь трафик (симметричное шифрование).

 

Вариант с расшифровкой в USG.

Клиент инициирует HTTPS-запрос к сайту в Интернете через браузер.

USG перехватывает HTTPS-запрос клиента. Он не отправляет запрос напрямую на сервер, а подменяет сертификат и создаёт две отдельных сессии:

-между клиентом и USG (SSL-сессия 1);

-между USG и реальным сервером (SSL-сессия 2).

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

На основе оригинального сертификата, USG «на лету» генерирует копию, но подписанную своим «поддельным» CA-сертификатом. Этот сертификат подсовывается клиенту в процессе TLS Handshake.

Клиент должен доверять этому поддельному CA, иначе будет ошибка SSL в браузере – небезопасное соединение. На клиента нужно установить CA от USG.

В итоге клиент думает, что общается с сайтом, но на самом деле с USG. Сервер сайта не знает о вмешательстве, думает, что работает с клиентом. То есть USG отправляет запрос на сервер и получает ответ. USG шифрует ответ своим сертификатом и отправляет клиенту.

USG видит весь трафик в незашифрованном виде «посередине» двух сессий, поэтому такая ситуация называется Man-In-The-Middle (MITM), но не как вид атаки, а как легальный способ работы с трафиком.

Расшифрованный «в середине» соединения трафик анализируется на вирусы (AV), на фильтрацию URL, запрещённый контент, на утечки данных (DLP) и тп.

Понимая эту механику, переходим к настройке.

 

Сертификат.

Работы с сертификатами выполняются в локальном центре сертификации на USG (Objects >> Certificates). Здесь можно создавать сертификаты, импортировать, удалять, управлять ключевыми парами и тп.

SSL Decryption Certificate – в этом разделе создаётся CA-сертификат, который будет использоваться для подписи поддельных SSL-сертификатов сайтов «на лету» во время SSL Inspection. Сертификат содержит закрытый ключ и используется как корневой центр сертификации.

Создаем сертификат.

 

Certificate Name – название сертификата.

Identifier – Идентификаторы.

Common Name – общее имя (CN), будет отображаться в сертификате. Видимо клиенту при просмотре сертификата в браузере.

IP Address – IP-адрес, который будет включён в поле SAN (Subject Alternative Name) сертификата. Обычно указывается локальный IP-адрес USG, чтобы сертификаты, подменяемые устройством в HTTPS-сессиях, выглядели корректными при доступе к ресурсам по IP. Это важно, если клиентские устройства подключаются по IP-адресу, а не по доменному имени.

FQDN – полное доменное имя устройства, указываемое в CA-сертификате. Обычно используется для идентификации центра сертификации, но не влияет на работу подмены. USG при генерации подменных сертификатов автоматически подставляет нужный FQDN запрашиваемого сайта.

Email – контактный email (опционально, обычно не используется).

Country/Area – страна, указывается двухбуквенным кодом ISO. Влияет на поле C= в сертификате.

State/Province – штат/область (поле ST=).

Location – город или населённый пункт (L=).

Department – подразделение (OU=).

Organization – организация (название компании; O=).

Key Options – параметры ключа.

Key Type – тип криптографического алгоритма (обычно RSA).

Key Length – длина ключа (рекомендуется минимум 2048 бит; влияет на безопасность).

Нажимаем ОК для создания.

После создания к названию добавляется суффикс _builtinca.cer. Это автоматически сгенерированное расширенное имя файла, указывающее на то, что сертификат создан как локальный центр сертификации (CA), встроенный в USG.

Built-in CA (встроенный центр сертификации) – это локальный центр сертификации (CA), существующий на самом USG, который может самостоятельно выпускать и подписывать X.509-сертификаты, используемые для расшифровки SSL-трафика.

 

Через CLI сертификат создается, но в итоге отсутствует в разделе built-in-ca, непонятно это баг или фича, поэтому надежнее создавать через GUI.

Создаем entity с названием decription-ssl-pc360

pki – это раздел в CLI включающий набор инструментов для управления сертификатами, ключами и безопасной криптографией. pki расшифровывается как Public Key Infrastructure – инфраструктура открытых ключей. В pki входят центры сертификации (CA), сертификаты X.509, открытые и закрытые ключи, процедуры проверки подлинности.

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

 

Создаем RSA-ключевую пару с таким же названием (decription-ssl-pc360)

pki rsa built-in-ca decription-ssl-pc360 create

rsa – это команда для создания, просмотра и управления RSA-ключевыми парами на устройстве.

built-in-ca – ключевая пара будет для встроенного центра сертификации.

Ключевая пара включает:

Приватный ключ – остаётся на устройстве, используется для подписи.

Публичный ключ – включается в сертификат и распространяется.

 

Создаем сертификат с названием decription-ssl-pc360 и указываем какие использовать при создании entity и rsa-key-pair.

Huawei рекомендует (и документирует) создавать SSL Decryption CA через CLI – pki generate built-in-ca certificate .

Однако, чтобы сертификат отображался в GUI и мог быть использован в SSL расшифровке через GUI, его нужно либо создавать напрямую через GUI, либо после CLI-генерации импортировать в GUI как Trusted CA. info.support.huawei.com   support.huawei.com

Это не баг, а особенность архитектуры, где GUI и CLI используют разные хранилища.

 

Просмотр

 

Настраиваем доверие привязкой к app-proxy.

app-proxy – это подсистема в Huawei USG, отвечающая за прокси-приложения и особенно за функции SSL/TLS инспекции.

built-in-ca trust – означает, что мы настраиваем доверие к локальному встроенному CA (центру сертификации), чтобы USG мог использовать его для подписания сертификатов, которые он генерирует «на лету» при расшифровке SSL-трафика.

filename decription-ssl-pc360_builtinca.cer – указывает файл сертификата локального CA, которому доверяет подсистема app-proxy. Это тот самый CA-сертификат, который будет использоваться для подписывания поддельных SSL-сертификатов при инспекции.

SSL Policy.

Между сертификатом и политикой обнаружения работает политика SSL.

SSL Policy – это системная политика, в которой задаются параметры дешифровки: используемый сертификат, CA, путь к ключам, CRL и прочее. Она служит криптографическим профилем и может использоваться в политике дешифровки трафика, определяя, каким образом будет производиться MITM.

В данном случае эта политика не настраивалась, используется встроенная преднастройка с применением последнего активного CA-сертификата. Полноценное управление возможно только через CLI.

По смыслу pki generate built-in-ca certificate это и есть упрощённая, автоматическая конфигурация SSL Policy, которая подходит в большинстве типовых случаев для расшифровки HTTPS. Альтернатива – вручную настраивать SSL‑политику с загрузкой CA сертификата из вне.

​

Настройки далее выполняются в разделе Encrypted Traffic Detection – обнаружение зашифрованного трафика. Несмотря на название «Detection», в этом разделе настраивается не только детектирование, но и вся логика расшифровки (SSL Decryption).

 

Профиль обнаружения.

Detection Profile – это набор правил и настроек, определяющих условия и параметры предварительной обработки трафика при расшифровке SSL, в том числе, какие типы сертификатов и алгоритмов разрешены, как обрабатываются исключения, а также определяющий какие данные будут переданы дальше для анализа.

Подсказка сообщает что:

По умолчанию устройство использует встроенный CA-сертификат (built-in CA) для генерации поддельных серверных сертификатов при SSL-декрипции.

Если нужно использовать другой CA-сертификат, его можно сгенерировать или импортировать через меню Object > SSL Decryption Certificate.

Если клиентские устройства принимают только доверенные сертификаты, необходимо установить этот CA-сертификат в доверенные на клиенте или настроить SSL whitelist (исключения), чтобы не блокировать легитимный трафик.

В противном случае при расшифровке трафика без доверенного CA пользователи будут видеть ошибки безопасности, и некоторые сервисы могут перестать работать корректно.

Подробности можно найти в официальном руководстве администратора.

 

Mirroring Interface – интерфейс, на который можно зеркалировать (копировать) трафик для внешнего анализа или мониторинга. Если не выбран, значит зеркалирование не включено.

Untrusted Certificate (Ненадежный сертификат) – управляет поведением при обнаружении сертификатов, которые не доверены, не подписаны доверенным CA.

Unsupported Version (Неподдерживаемая версия протокола SSL/TLS) – определяет что делать, если клиент или сервер используют устаревшую или неподдерживаемую версию SSL/TLS.

Unsupported Algorithm (Неподдерживаемый алгоритм шифрования) – как поступать, если используется криптографический алгоритм, не поддерживаемый политикой или слишком слабый.

Non—matching SNI and SAN/CN (Несовпадение между SNI и SAN/CN сертификата):  SNI – имя сервера, которое клиент запрашивает; SAN/CN – имена в сертификате сервера. Если они не совпадают, это может означать подозрительную активность или конфигурационную ошибку.

Client Authentication (Аутентификация клиента) – управляет обработкой TLS-сессий, где требуется аутентификация клиента сертификатом (двухсторонний TLS).

Allow или Block.

В корпоративной сети в реальных условиях рекомендуется использовать Block для повышения безопасности. При начальных настройках и тестах логично использовать Allow.

Advanced Settings.

В расширенных настройках можно гибко управлять версиями шифрования.

Client Algorithm Version и Server Algorithm Version – в этих пунктах можно явно запретить использование SSL 3.0 и устаревших версий TLS.

TLS 1.2/1.3 – безопасны и рекомендуются для использования.

Отключение значит, что устройство откажется устанавливать или принимать SSL/TLS-сессии с использованием версии протокола SSL 3.0 при расшифровке трафика. Другими словами, USG не будет пытаться расшифровать трафик, если клиент или сервер предлагает только SSL 3.0.

Если сайт или клиент действительно работает только на SSL 3.0 (что сейчас практически не встречается, но теоретически возможно) USG не сможет выполнить SSL Decryption этого трафика, так как протокол запрещён в настройках. Трафик будет передаваться как есть (без расшифровки) – USG не вмешивается в шифрованный канал. В зависимости от настроек политики, возможно разрешение такого трафика, либо он может быть заблокирован, если политика строго запрещает трафик с устаревшими протоколами.

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

High, Medium, Low это условная классификация используемых криптографических алгоритмов и их параметров с точки зрения безопасности. Каждый уровень определяет, какие конкретно алгоритмы и длины ключей разрешены или запрещены.

High – включает только алгоритмы, признанные безопасными по современным стандартам. Отключает слабые и устаревшие. Используется для максимальной безопасности, корпоративные сети, финансовый сектор, где приоритет – защита данных. Пример алгоритмов: AES-256, SHA-2 (например, SHA-256), ECDHE с P-384 или выше, RSA с ключами >= 2048 бит

Medium – допускает использование алгоритмов средней крепости, обеспечивая широкую совместимость. Подходит для общего использования, где важна совместимость с большинством клиентов и серверов. Пример алгоритмов: AES-128, SHA-1/SHA-2, ECDHE с P-256, RSA с ключами >= 1024/2048 бит.

Low – разрешает даже устаревшие алгоритмы, которые часто считаются уязвимыми. Используется для совместимости с очень старыми системами, где безопасность не критична или невозможна. RC4, MD5, DES, 3DES, RSA с короткими ключами, устаревшие шифры.

​

Через CLI.

 

Политика обнаружения.

Detection Policy – это набор правил, который определяет, какой именно трафик и в каких условиях должен проходить процесс расшифровки SSL с применением конкретного Detection Profile.

 

Name – уникальное название политики: DETECTION-POLICY.

Description/Tag – описание и метка для группировки и пояснений.

Source Zone и Destination Zone – зоны, между которыми применяется политика, в данном случае от trust к untrust.

Source Address и Destination Address – IP-адреса источника и назначения.

User – пользователи, к которым применяется политика.

Service – сервисы, для которых включается расшифровка, в данном случае только https.

URL Category – категории URL, на которые политика распространяется.

Action – действие с трафиком:

Decrypt – расшифровывать трафик;

Do not decrypt – не расшифровывать;

Block – блокировать.

Detection Profile – профиль настроек, который задаёт конкретные параметры расшифровки SSL, применяемые в этой политике.

Не заполненные поля означают any (любой).

 

Настройка через CLI.

 

Просмотр статистики срабатываний в колонке Hits.

 

Политика безопасности.

SSL-дешифрация начинает работать только тогда, когда есть функционал, который эту расшифровку использует. Например, активируем антивирус в политике безопасности.

Политика настраивалась на этой странице.

Через CLI.

Использован default-профиль антивируса, присутствующий в USG изначально.

 

Проверка.

На ПК клиента в локальной сети в браузере Edge открываем любой сайт.

Появится сообщение о не безопасном подключении. При проверке сертификата видно, что его выдал сетевой экран.

Edge (как и Internet Explorer) напрямую использует доверенные корневые центры сертификации из Windows. Если USG-CA не добавлен в Trusted Root Certification Authorities ОС – Edge покажет предупреждение или ошибку. Это ожидаемо и корректно: браузер не доверяет подменному сертификату от USG, так как не знает этого CA.

 

Но браузер Chrome показывает оригинальный сертификат сайта и не выдает предупреждений. Это может происходить по разным причинам:

Некоторые сайты используют защиту от MITM, например HSTS preload – браузер обязан соединяться по HTTPS напрямую, и не примет подменный сертификат.

Certificate Transparency (CT) – механизм, который проверяет, был ли сертификат выдан честным CA и зарегистрирован.

В этих случаях Chrome не примет подмену от USG, даже если CA установлен в систему. Может обойти прокси напрямую, если возможно (например, при настройке QUIC, DNS-over-HTTPS и т.п.) или просто заблокирует соединение. Пока что не удалось найти путь, которым хром обходит расшифровку трафика.

 

Установим созданный ранее CA-сертификат на компьютер пользователя в локальной сети. Это можно сделать вручную или через доменные политики.

Добавим сертификат вручную.

Экспортируем сертификат из USG в формате CER.

 

Импортируем в ПК с Windows 10.

Переходим в менеджер сертификатов.

Win+R

 

Импортируем для пользователя или всего компьютера.

Подтверждаем.

 

В результате сайты начинают открываться без предупреждений, потому что сертификат находится в доверенном списке.

Просмотр статистики.

used: 1 говорит о том, что app-proxy активен и обрабатывает хотя бы одну сессию. То есть трафик действительно попадает под проксирование. Это необходимо для работы расшифровки.

 

Если на клиенте установлен антивирус с функцией проверки HTTPS, то он так же как USG перехватывает соединение до браузера и заменяет сертификат от USG на свой, подписанный Antivirus Root CA. Браузер клиента получает уже сертификат от Antivirus CA, а не от USG и не от настоящего сайта. Получается двойная HTTPS-дешифрация. Всё продолжает работать, если Antivirus CA доверен в системе.

Двойной MITM (USG + Antivirus) выглядит избыточно, и в практике часто стараются избежать этого дублирования, чтобы упростить цепочку обработки, повысить производительность и избежать конфликтов. Разработчики Huawei обычно рекомендуют делегировать MITM именно шлюзу, как централизованной точке. Оставить два уровня расшифровки на шлюзе и на клиенте допустимо, если они служат разным задачам.