Скучно о работе дешифрации NGFW

33c7629703cf4ac6b2f6760a417ce359.png

Если вы хотите окончательно испортить первое свидание — поговорите с девушкой о дешифрации. Да и в случае последующих — тоже не стОит.

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

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

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

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

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

5c71ebcc74dc4b6eb7194d28786dbf7f.png
Дамп установления 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»):

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

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

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

2c14ce6f2f284bdf9fd97b674761c09e.png
Формирование сеансового ключа при использовании 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 в адресной строке:

0650bed117564c46ae7b38800ef031fe.png
Chrome ругается на SHA-1

355c0aadfce54791b48b1fcb89aa6de5.png
Подробности

Чтобы избежать таких предупреждений центр сертификации должен использовать строгие алгоритмы формирования ХЭШ для подписи сертификатов — семейство 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-страниц. Пользователь сможет определить факт подмены сертификата, только если полезет в настройки.

4ca4c2ebfb344c66926748ddbc092c92.png
Цепочка сертификатов в Mozilla

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

83ab6799a3d64da5ba0d339b42099813.png
Поле 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.

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

На этом описание механизма дешифрации 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:

802e355fd60e4362b7f744fe749fa484.png

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

30d0a13c86474d83863bbd75ab0804af.png

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

1851c5800c204c7e9740cc756152e330.png

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

84dcd18658824f238ee4ea58c05adb8e.png

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

e9608edb61b84f4eae4a10d5f44aeea5.png

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

f6ecf13bf8154d0fa5fe8e55d96e8925.png

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

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

6e62cc1108c944a0be8312356ac7041a.png

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

afd1cff762554fbe9f94333826c0ec36.png

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

459331e9cf814432aa0218128f0e3e56.png
87e30f66d43249be81de7209d80aba7a.png

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

d83d50045f094c639f7d5a0a4fe421c2.png
c7e76f7b32ff410ba9462d694aa9d6cf.png

Комментарии (0)

© Habrahabr.ru