Дешифрация трафика

Дешифрация – нужна или нет?

Фильтрация по категориям URL, репутациям сайтов и Интернет-приложениям – это классическая функциональность NGFW.

Чтобы понять к какому сайту обращается клиент не обязательно расшифровывать весь трафик. Функциональность дешифрации, как таковая, необходима только для определенных действий: анализа трафика, контроля передачи файлов и мониторинга. В случае же фильтрации интернет-доступа по https, дешифрация не нужна, пусть это и не очевидно.

Вот как работает блокировка по URL-категории:

Создаем политику доступа на FMC, которая будет блокировать доступ к соц. сетям.

Пробуем доступ по-обычному http. Из соц. сетей нам подойдёт старая www.hi5.com.

Access Denied, политика работает. Смотрим на FMC в Analysis -> Connections -> Events. Вот наши заблокированные запросы:

Сдвигаем таблицу вправо, чтобы посмотреть URL:

Смотрим в Wireshark с фильтром по IP-адресу 67.221.174.31:

Видим: проходит TCP handshake, после клиент отправляет HTTP Get с URI «http://hi5.com». На HTTP Get он сразу получает ответ 403 Forbidden. Вот содержание:

Видно, что это как раз тот самый End User Notification (далее EUN), который мы видим в браузере. EUN отправляет vFTD в ответ на попытку пойти на запрещённый ресурс. Причём EUN отправляется с IP-адреса 67.221.174.31. То есть, фактически, vFTD вклинивается в TCP-сессию между клиентом и сервером и подкладывает свой ответ.

Ок, с чистым http всё понятно. Теперь пробуем зайти на https-сайт, например, vk.com. Дешифрация на vFTD не включена. Сможем ли заблокировать?

Оп, опять Access Denied. на FMC в Analysis -> Connections -> Events. Вот наши заблокированные запросы:

Сдвигаемся вправо:

Видим, что vk.com оказался не удачным примером. Оказывается, изначально сессия устанавливается по http (tcp порт 80, видно во втором столбце последней страницы). Поэтому блокировка происходит по тому же сценарию, что и в первом случае.

Перенаправление http на httpsКонечно, для vk.com мы могли бы просто написать в браузере «https://vk.com». Тогда сразу же попадаем на защищённую версию сайта. Но обычно никто так не делает — сайт самостоятельно перенаправляет на https.

Перенаправление

Wireshark для вконтактика 1

Видим, что сначала клиент устанавливает tcp-сессию на порт 80. В ответ на HTTP Get сервер отвечает HTTP 302 Found.

HTTP Get

Википедия подсказывает, что код HTTP 302 означает: «запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location». Видим, что в Location указано vk.com. Поэтому клиент сразу же устанавливает новую tcp-сессиию, но уже на порт 443.

Wireshark для вконтактика 2

Если вы еще не заснули — пробуем facebook.com:

Доступ заблокирован, но EUN не отобразился. Посмотрим на FMC:

Посмотрим в Wireshark:

Видим, что в отличие от vk, facebook сразу устанавливает сессию на порт 443.hstsFacebook использует механизм hsts. Если вкратце: сайты, поддерживающие hsts, после установления соединения с клиентом по https, говорят браузеру всегда использовать для последующих подключений https. То есть они для всех последующих сессий локально подставляют https:// вместо http:// в адресную строку.

Например, в google chrome можно посмотреть, для каких сайтов включён hsts. Для этого надо ввести в адресной строке chrome://net-internals/#hsts:

Проверка hsts в Chrome

По дампу трафика в Wireshark видим, что vFTD блокирует сессию к facebook после каждого сообщения SSL Client hello. Соответственно, в Client hello содержится достаточно информации для распознания URL и принятия решения о блокировке. Рассмотрим Client hello внимательнее:

Действительно, в поле Server Name Indication extension содержится информация, по которой можно определить запрашиваемый ресурс.

Что касается EUN, у FirePOWER есть некоторые ограничения при отображении уведомлений о блокировке для пользователей. Для не расшифрованного трафика EUN отображаться не будет.

Это логично, потому что FirePOWER подкладывает страничку EUN в установленную сессию (если она не расшифрована, сделать это нельзя).

Блокировка по интернет-приложениям:

Возможно стоит снова налить себе кофе. Осталось немного, но лучше перестраховаться.
Последнее, что решил проверить — будет ли работать фильтрация интернет-приложений внутри https. В частности, покомпонентная.

Создаем политику, которая будет блокировать Google Drive, Google Maps и Google Play:

Проверяем — выбранные приложения успешно заблокированы. Смотрим на FMC:

В Wireshark видно, что приложения блокируются по тому же сценарию, что и Facebook, то есть после каждого SSL Client Hello:

Блокировка Интернет-приложенийНа практике нужно проверять возможность блокировки для конкретных приложений. Нет гарантии, что настроенная политика будет срабатывать вне зависимости от дешифрации (включена она или выключена). Версии приложений постоянно меняются, а патчи для FirePOWER могут не успевать за ними.

Для распознавания некоторых приложений всё же требуется дешифрация. Их немного, они отмечены в настройках политик специальной иконкой с замком.

Приложения, требующие дешифрацию

Большинство из них связано с передачей файлов.

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

Для шифрованного трафика не работают сигнатуры IPS и файловые политики, включая Advanced Malware Protection (AMP). И это логично: чтобы искать вредоносов, трафик должен быть расшифрован. Тут стоит понимать, что глубокая инспекция не отработает именно для payload. Для той информации, которая передаётся в открытом виде (заголовки IP, TCP, сообщения SSL Handshake) сигнатуры работать будут.

С точки зрения IPS более интересна защита входящего трафика. Если, мы публикуем Web-сервер в Интернет и хотим защитить его с помощью IPS, то SSL-сессии будут инициироваться снаружи. Дешифровать их с подменой сертификата не имеет смысла: зачем менять один собственный сертификат на другой?

Для такой задачи на FirePOWER предусмотрена дешифрация с private key. То есть на FirePOWER заранее загружается сертификат публикуемого сервера и соответствующий private key. С помощью него будет осуществляться дешифрация сессии, запущенной снаружи. Данный вариант в рамках этого материала рассматривать не будем.

Последнее применение дешифрации – мониторинг трафика.

В итоге, для чего может потребоваться дешифрация трафика на FirePOWER:

1. Отображение EUN для заблокированных сайтов и Web-приложений;
2. Анализ трафика сигнатурами IPS;
3. Контроль передачи файлов, в том числе анализ файлов системой AMP;
4. Распознавание некоторых приложений;
5. Мониторинг.

Думаю, теперь понятно, зачем дешифровать SSL на NGFW (а также UTM, Web proxy) в принципе.

Как именно работает дешифрация с подменой сертификата.

Что нам для этого нужно?

Для начала вспомним, как работает SSL. Я кратко опишу основные моменты.

После установления TCP-сессии между клиентом и сервером происходит SSL Handshake. В его рамках обе стороны обмениваются сообщениями Client Hello и Server Hello.

Дамп установления SSL-соединения с vk.com

Client Hello описывает поддерживаемые параметры шифрования, Server Hello содержит выбранные из предложенных клиентом параметры. Обмен Client Hello и Server Hello можно использовать как индикатор установления SSL-сессии. При появлении этих сообщений устройство (vFTD в нашем случае) просматривает сконфигурированные политики дешифрации для принятия решения — нужно ли в дальнейшем дешифровать сессию или нет.

Если настроенные политики диктуют дешифровать трафик, устройство становится man-in-the-middle (MITM) и дешифрует передаваемые данные. При удачном запуске MITM мы имеем две установленные SSL-сессии.

Первая — между клиентом и дешифрующим устройством (vFTD). Вторая — между дешифрующим устройством и сервером. Зашифрованные данные приходят от клиента на vFTD.
Расшифровываются. Проверяются всевозможными политиками (доступа, IPS, файловыми, AMP и т.д.). Если дешифрованные данные от клиента проходят проверку, они снова шифруются и отправляются серверу. Если не проходят какую-либо проверку, данные либо просто блокируются (не отправляются в сторону сервера), либо сбрасывается сессия. Ответы от сервера обрабатываются аналогично.

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

Есть два наиболее распространённых в Интернете способа формирования общего сеансового ключа по открытым каналам связи: RSA и ECDH (Диффи-Хеллман). Процесс формирования сеансовых ключей показан на диаграммах ниже (взяты из материала «Анализ SSL/TLS трафика в Wireshark»):

Формирования сеансового ключа при использовании RSA

В случае RSA клиент генерирует предварительный секрет (pre-master secret). Шифрует его открытым ключом из сертификата сервера и передаёт его. Расшифровать предварительный секрет можно только с помощью закрытого ключа, который известен исключительно серверу.

Теперь у обеих сторон есть предварительный секрет. Они формируют главный секрет и далее общий сеансовый ключ.

Формирование сеансового ключа при использовании ECDH

В случае с ECDH пара ключей SSL-сертификата не используется для шифрования вообще. Клиент и сервер формируют пары случайных ключей Диффи-Хеллман — открытый и закрытый. Каждая сторона передаёт свой открытый ключ другой стороне в незашифрованном виде.

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

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

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

В случае с RSA, MITM-устройство сможет расшифровать предварительный секрет с помощью собственного закрытого ключа сертификата. Если используется ECDH, устройство сможет подписать свой открытый ключ Диффи-Хеллман таким образом, чтобы на стороне клиента подпись считалась валидной.

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

1. Поле subject сертификата содержало параметр Common Name со значением, равным тому, что введено в адресной строке браузера;
2. Сертификат был подписан доверенным центром сертификации.

Wildcard-сертификатыЭто сертификат, который заказывается на домен. В таком сертификате в поле subject параметр Common Name записывается со «звёздочкой», например, *.mysite.ru. Таким образом, на всех сервисах домена можно использовать единственный сертификат: ra.mysite.ru, owa.mysite.ru и т.п. Это может быть дешевле, чем заказывать отдельный сертификат на каждый сервис.

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

Безусловно, чтобы сертификат считался валидным на стороне клиента, должны выполняться и другие условия: он не должен быть отозван, просрочен и т.д. Но все эти условия учитываются на этапе подписи сертификата собственным центром сертификации.SHA-1Сейчас браузеры постепенно принуждают отказываться от использования SHA1RSA в качестве алгоритма цифровой подписи. Например, chrome будет выдавать красный перечёркнутый https в адресной строке:

Chrome ругается на SHA-1

Подробности

Чтобы избежать таких предупреждений центр сертификации должен использовать строгие алгоритмы формирования ХЭШ для подписи сертификатов — семейство SHA-2.

При использовании Certificate pinning, сертификат сервиса должен быть подписан строго определённым центром сертификации. Если это не так, доступ на ресурс блокируется даже в том случае, если сертификат подписан доверенным центром.

Соответственно, для ресурсов с certificate pinning дешифрация с подменой сертификата работать не будет.

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

На практике это реализуется следующим образом:

В компании должен существовать собственный центр сертификации, корневой сертификат которого помещён в доверенные на всех устройствах компании. Это необходимое условие.

На центре сертификации запрашивается новый сертификат по шаблону «подчинённый центр сертификации» (Subordinate certificate authority, далее SubCA). Особенность данного сертификата в том, что с помощью его закрытого ключа можно подписывать другие сертификаты (выставлен флаг CA в расширении «основные ограничения сертификата»).

Так как SubCA подписан доверенным корневым сертификатом, клиентские машины будут доверять как ему самому, так и любому сертификату, подписанному с его помощью. SubCA и соответствующий ему закрытый ключ устанавливается на устройство, которое должно стать MITM в SSL-сессии. Благодаря этому при каждой попытке клиента установить SSL-сессию с HTTPS-сервером наше устройство сможет:

1. Перехватывать сертификат сервера;
2. Создавать закрытый ключ;
3. Генерировать новый сертификат с такими же полями, как у подменяемого;
4. Подписывать созданный сертификат с помощью SubCA.

Если всё корректно настроить, пользовательский браузер не будет выдавать никаких предупреждений при открытии https-страниц. Пользователь сможет определить факт подмены сертификата, только если полезет в настройки.

Цепочка сертификатов в Mozilla

Если посмотреть поля конечного сертификата, увидим, что поле субъект содержит корректное значение Common Name.

Поле Common Name

Если сравнить реальный и подменённый сертификаты, увидим, что фактически они отличаются значениями открытых ключей и цифровыми подписями (в данном случае я пренебрегаю серийным номером, и т.п.).
Подменённый сертификат

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1482311739306634470 (0x14923aac5bc36ce6)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=RU, ST=Moscow, O=CBS, OU=Computers, CN=proxy.cbs.com.ru/emailAddress=uskov@cbs.ru
        Validity
            Not Before: Sep  4 21:17:41 2015 GMT
            Not After : Sep 16 11:56:55 2018 GMT
        Subject: OU=Domain Control Validated, CN=*.vk.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a1:09:76:bf:21:ce:9b:e7:e2:34:03:f0:74:02:
                    84:13:7f:2e:51:0b:e8:4a:11:e2:34:d8:3a:d9:39:
                    5b:ea:87:50:33:dc:64:5b:2e:f2:0d:33:36:47:3c:
                    0a:97:a7:ce:23:7d:d7:8f:76:85:17:42:f9:63:b6:
                    d1:91:ea:18:de:98:3c:e1:c5:5b:59:4a:d0:e5:e2:
                    b7:ce:e0:75:74:93:d9:35:b4:8b:85:70:4c:8e:c9:
                    e0:53:7c:2f:9f:4b:e1:48:f0:3f:a5:70:f7:4e:99:
                    f1:74:0b:2a:21:6a:9d:9f:20:f4:e5:fa:94:89:43:
                    61:82:0b:c1:98:7a:e3:7c:4e:cf:8b:6c:ad:6b:ce:
                    1b:0f:4d:e3:db:d4:47:5c:e8:77:aa:71:ea:62:8f:
                    17:c9:3b:a3:e2:29:ce:62:e2:31:71:a8:83:2a:41:
                    d9:6b:a7:b8:75:d0:07:fc:10:f1:6e:69:84:4b:b1:
                    11:f8:ae:20:94:44:0d:b0:7b:0f:d2:bd:b3:1d:1c:
                    7c:ae:f8:cf:37:e2:aa:4a:d2:de:24:60:50:06:f9:
                    c6:65:f0:9c:63:4f:53:eb:db:59:a4:93:14:b2:6f:
                    aa:b3:fb:50:ae:6e:e4:b9:3f:fa:69:b3:43:32:3f:
                    7a:4b:57:41:2d:7e:c8:41:00:f8:68:6a:43:53:83:
                    5c:c3
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Subject Alternative Name:
                DNS:*.vk.com, DNS:vk.com
            X509v3 Subject Key Identifier:
                18:91:5E:8A:5A:58:5D:AB:86:73:6D:C0:06:57:C2:6C:62:4E:5C:64
    Signature Algorithm: sha256WithRSAEncryption
         8d:bc:a8:ce:af:5d:39:fc:6a:ac:48:39:9a:7e:32:01:27:68:
         de:95:5c:4b:24:3a:51:5d:d2:90:e4:22:c1:55:5e:65:ea:4f:
         59:2c:76:b0:48:53:d8:6e:c6:e3:2a:cb:26:e6:40:e3:9a:36:
         4c:6b:29:52:1c:b5:83:c6:10:8e:cb:f8:6d:a9:ae:d7:71:1b:
         92:69:99:c0:1e:de:2f:02:82:17:d6:1d:52:35:65:f7:ca:a7:
         9c:fe:e6:1f:3b:a4:36:c2:4a:4e:e2:f2:7d:66:e1:c4:ea:e9:
         ca:d0:a9:76:fc:84:f1:55:e7:d8:04:45:04:9a:15:0d:23:c9:
         e1:0a:b0:9e:cb:3b:c0:86:d3:e4:23:3e:c5:8a:13:20:96:ac:
         6d:d8:79:ea:b9:83:b9:a7:fe:79:67:41:3d:7d:1f:22:eb:20:
         b9:6c:06:34:cb:fb:17:a7:b3:fc:5a:2c:a2:4f:86:0a:80:53:
         ea:f2:71:4a:36:80:a3:fb:2e:42:76:c6:f8:68:6c:78:f0:5c:
         5d:cd:c4:0a:05:29:a3:c5:a7:87:c4:87:af:5c:29:54:a1:8e:
         94:2f:72:89:54:c4:76:cb:0b:87:f9:29:a1:18:4e:55:97:e2:
         1f:86:2e:97:ca:15:40:6e:d4:29:25:eb:1c:5a:2e:b9:3d:e6:
         bb:5e:4d:18

А вот реальный сертификат

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 7817290772096849405 (0x6c7c988a18c595fd)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certs.godaddy.com/repository/, CN=Go Daddy Secure Certificate Authority - G2
        Validity
            Not Before: Sep  4 21:17:41 2015 GMT
            Not After : Sep 16 11:56:55 2018 GMT
        Subject: OU=Domain Control Validated, CN=*.vk.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:db:c0:ab:97:82:f1:70:06:3f:d9:9d:79:85:a8:
                    7c:11:d2:17:c5:9a:61:b1:72:06:d7:5e:21:7f:3d:
                    3b:c2:cd:dd:f4:d8:62:8a:7b:23:b7:cb:08:70:db:
                    bf:e8:85:f7:23:92:09:56:1c:bc:e4:f8:cd:81:01:
                    82:43:8d:37:b9:f1:6a:14:ac:68:fa:a4:ef:fd:5b:
                    99:ad:f1:df:04:00:1a:e2:8a:7e:80:6a:27:b3:60:
                    71:27:8d:dd:37:d2:df:2d:22:fe:f3:cb:cf:68:62:
                    65:d4:ff:88:47:6a:78:4d:bf:8f:8f:0d:06:47:3a:
                    b0:84:f0:a4:ea:9e:69:59:97:e5:03:a9:36:0e:93:
                    e6:2e:4e:d6:2a:bd:ea:bc:64:b8:9c:7d:a3:5e:c4:
                    ce:1c:74:82:4d:95:bc:00:a0:01:3e:d1:3f:2a:18:
                    7c:49:7c:af:6a:41:61:4b:99:1d:af:95:f4:77:c6:
                    e0:4e:60:aa:96:63:ee:68:96:63:33:fc:81:41:e5:
                    2c:15:0f:1d:39:f8:00:ac:05:13:f2:80:dd:96:00:
                    2d:42:4b:d5:c9:f7:26:08:67:68:f8:15:e4:25:43:
                    cd:e1:09:4c:5c:ab:15:23:d8:30:f1:89:b7:83:92:
                    fd:15:ad:b6:5b:e4:5c:b2:fa:7d:d1:b2:00:43:39:
                    d9:a3
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl.godaddy.com/gdig2s1-118.crl

            X509v3 Certificate Policies:
                Policy: 2.16.840.1.114413.1.7.23.1
                  CPS: http://certificates.godaddy.com/repository/

            Authority Information Access:
                OCSP - URI:http://ocsp.godaddy.com/
                CA Issuers - URI:http://certificates.godaddy.com/repository/gdig2.crt

            X509v3 Authority Key Identifier:
                keyid:40:C2:BD:27:8E:CC:34:83:30:A2:33:D7:FB:6C:B3:F0:B4:2C:80:CE

            X509v3 Subject Alternative Name:
                DNS:*.vk.com, DNS:vk.com
            X509v3 Subject Key Identifier:
                18:91:5E:8A:5A:58:5D:AB:86:73:6D:C0:06:57:C2:6C:62:4E:5C:64
    Signature Algorithm: sha256WithRSAEncryption
         80:61:fc:da:a9:f2:ea:f3:4a:70:4e:8a:39:3e:eb:9b:77:c2:
         c9:5d:da:30:20:7a:31:8f:19:f8:2f:b5:1b:4a:87:74:fb:99:
         59:78:0f:45:1b:9d:9d:76:29:5f:48:90:08:a5:f8:c8:2e:9f:
         55:ea:54:33:c1:a1:a3:7e:7f:8c:32:c5:a8:0f:9b:04:c7:d1:
         55:30:7e:09:87:03:7e:88:82:32:0a:cb:0c:66:f0:50:85:b2:
         e4:43:67:38:88:50:84:54:41:4b:bc:3e:b0:47:8f:71:46:e4:
         9a:cf:f1:a4:39:a9:4b:ca:63:44:c3:34:7d:7b:ca:de:6c:91:
         5b:15:09:06:b3:4c:56:6d:23:03:1b:dc:c5:d1:e5:a3:9f:d2:
         4d:be:d2:ff:62:4a:75:f7:4f:29:a4:7d:35:cf:33:06:83:6a:
         50:f6:25:ce:a7:59:ac:05:fe:74:7b:c7:89:06:f5:a8:2e:4e:
         d4:34:a1:e1:68:7b:66:8b:53:a8:41:ba:a7:50:72:49:94:e6:
         4a:ad:2d:26:95:a3:5d:ce:e3:8b:d9:6c:d2:1e:31:4b:28:ab:
         e2:33:c5:5e:3f:82:dd:e1:e8:36:a2:b5:08:d8:b3:2e:23:b4:
         9b:b4:e6:4a:ab:21:2d:6b:aa:5f:fd:56:31:dc:86:32:85:04:
         01:5a:b9:64

Последнее, что хотел отметить, vFTD для генерации любого подменённого сертификата использует одну и ту же пару ключей. Что собственно и логично: зачем тратить ресурсы и без того нагруженного шифрацией/дешифрацией устройства на генерацию новых пар ключей. Если открыть страничку ya.ru и просмотреть полученный сертификат, увидим, что открытый ключ будет таким же, как у подменённого сертификата для vk.com.

Подмененный и реальный сертификат

На этом описание механизма дешифрации SSL на NGFW завершаю. Приветствую всех бодрствующих, мы наконец сделали это! Это было мучительно, но зато вы теперь знаете об SSL чуточку больше. Стоило это того или нет – это уже на ваше усмотрение.

P.S.: И да, передаю поздравление от коллег (и присоединяюсь): всех с наступающим Новым Годом! Пусть в новом году у вас будет меньше багов, костылей и танцев с бубном!

P.P.S.: Для тех, кому интересно, как эта кухня настраивается на FirePOWER — вэлкам в подкат.Настройка дешифрации SSL на FMC v6.1.0.1Сперва подготавливаем SubCA. Генерируем пару ключей (открытый и закрытый). Подписываем сертификат на корпоративном центре сертификации по шаблону «подчинённый центр сертификации» (Subordinate certificate authority). Для этого можно воспользоваться утилитой openssl. Она доступна из командной строки FMC. Пример команд для генерации CSR:

openssl rand -out ./private/.rand 1024
openssl genrsa -out ./private/cakey.pem -aes256 -rand ./private/.rand 2048
openssl req -new -key ./private/cakey.pem -out subcareq.pem -config openssl.cnf -sha256

После того, как получаем подписанный сертификат, устанавливаем его на FMC. Переходим на вкладку Objects -> Object Management -> PKI -> Internal CAs и жмем Import CA:

Будет предложено загрузить сертификат и его закрытый ключ. Их мы получили ранее с помощью openssl и корпоративного CA. Задаем имя для новой CA и вводим пароль закрытого ключа (при необходимости):

Всё готово к созданию политики дешифрации. Идём в Policies -> SSL:

Нажимаем «New Policy», задаём имя политики, default action и, пишем свой Opus Magnum в описании:

Политики дешифрации в привычных табличках. Их поля описывают шаблон трафика, подлежащего дешифрации:

Нажимаем Add Rule и описываем шаблон трафика. В простейшем случае можно сделать правило без указания каких-либо параметров. В этом случае любой SSL-трафик будет дешифрован. В качестве действия выбираем «Decrypt – Resign». В поле после слова «with» выбираем загруженный на предыдущих шагах сертификат. Это и есть тот самый SubCA, которым мы будем подписывать подменённый сертификат.

Как видите на скриншоте, FMC даёт широчайшие возможности по описанию шаблона трафика для дешифрации. Трафик можно выбирать по пользователям, типу приложений, категории URL, по параметрам сертификата сервера (DN, Cert Status, Cipher Suite, Version) и т.д.

Например, скриншот вкладки Cert Status:

После настройки всех необходимых правил, нажимаем Save. Политика дешифрации готова. Но для того, чтобы она начала работать, её необходимо привязать к политике доступа. Идём в Policies -> Access Control:

Выбираем интересующую нас политику доступа и нажимаем на карандаш. В раскрывшейся вкладке нам нужно выбрать созданную на предыдущем шаге политику дешифрации:

Нажимаем Save. Не забываем выполнить deploy изменений на управляемое устройство (vFTD в моём случае):

Оригинал: https://habr.com/ru/company/cbs/blog/318326/