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


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

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

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

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

    Для начала вспомним, как работает 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 в моём случае):



    CBS 51,67
    Компания
    Поделиться публикацией
    Комментарии 22
    • +2
      Спасибо, подробно и доходчиво. А расскажите, пожалуйста, что-нибудь про производительность в режиме расшифровки SSL? Как показала практика, у некоторых вендоров с этим большая-большая беда — включая, скажем, отнюдь недешевые Checkpoint и Palo Alto.

      Причем конкретные цифры никто не публикует, в отличие, например, от производительности IPS. А между тем, без расшифровки SSL DPI-фичи на 443 порту толком работать просто не будут, и весь NGFW превращается в тыкву.
      • 0
        По производительности cisco тоже не даёт точных цифр. Объясняют тем, что цифры очень зависят от дополнительных включенных сервисов: используется ли IPS, файловые политики и AMP и т.д.
        В любом случае, вендор предупреждает, что не стоит использовать дешифрацию для всего подряд. Включайте дешифрацию только тогда, когда она действительно нужна.

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

        Ранее устройства-сенсоры SourceFIRE вообще не поддерживали дешифрацию. Для дешифрации нужно было покупать дополнительную железку — SSL Appliance. Это было связано именно с производительностью.

        Возможно нам удастся протестировать в каком-либо виде устройство Cisco на предмет производительности при дешифрации. Если получится, обязательно поделимся результатами.
      • +1
        Спасибо!
        Вопрос — как в браузере (Yandex, IE) запретить переход на сайт, чей сертификат подменен таким образом?
        • 0
          Рискну предположить, что никак. От подмены сертификата поможет техника Certificate pinning. Я кратко упоминал этот момент в тексте. Думаю, по вашего вопросу имеет смысл смотреть в этом направлении.
          • +1
            Локальный CA разве не перебивает эту политику, как сделано в Хроме?
            • 0
              Не совсем понял, что вы имеете в виду?
              • +2
                Chromium отключает HPKP для цепочек с приватными корневыми CA и они могут генерить сертификаты для любых сайтов, в том числе из захардкоженного списка.
                • 0
                  То есть HPKP тоже не спасёт от подмены сертификата?
                  • +3
                    Оно спасаёт от публичных CA (и частных с кросс-сертификацией от них), которые начинают дурить. А отключение проверки для приватных рекомендуется прямо в RFC.
                    • 0
                      Супер, спасибо за пояснения!
          • +2
            Спасибо огромное за оч толковую и емкую статью.
          • 0
            Битва меча и щита.
            Прокси научились подменять сертификаты.
            Браузеры научились проверять сертификаты (HPKP, привет).
            Ждем ответа от щита (прокси).

            Наверно, под давлением, производители браузеров HPKP сделают отключаемым, хотя бы в корпоративной среде. Либо прокси разрешат подключаться только через те браузеры, в которых HPKP отключен.
            • 0
              Отключение HPKP для приватных CA как раз обсуждали в коментах выше.
              • 0
                Прошу прощение если скажу глупость, но HPKP — это просто HTTP-заголовки в респонсах сервера. Если мы уж ломаем SSL на прокси, то что нам мешает там же подменить и заголовки? И браузер будет считать что вообще все хорошо…
                • 0
                  Теоретически, да, можно резать заголовок. Но у меня есть чёткое подозрение, что в большинстве случаев это банально не требуется. Локальный CA перебивает политику HPKP и на этом всё заканчивается. На практике при внедрении FirePOWER мы пробовали включать дешифрацию, проблем с HPKP не встречали.
                  • 0
                    Чего-то грустно… Certificate pinning — это насколько я понял просто встраивание сертификатов в приложении. Если «попросят» встраивать нужный сертификат, как условие распространения приложения на территории страны, то выходит защиты нет совсем? Все это не означает что надо что-то серьезное и глобальное делать с handshake и как-то менять алгоритм?
                    • +1
                      Certificate pinning — это

                      Привязка к хэшу текущего публичного ключа через специальный HTTP заголовок Public-Key-Pins или Strict-Transport-Security, чтобы браузер не открывал сайты при его изменении в течении max-age.
                      Плюс в Chrome и FF есть захардкоженный список публичных ключей для google.com и ещё некоторых сайтов, который обновляется вместе с браузером. При их подмене браузер шлёт уведомление разработчикам (если подменяет не приватный CA).
                      • 0
                        Про заголовок я писал выше — если уж делать серьезно, то заголовок вырезается сразу за подделкой сертификата.
                        >«При их подмене браузер шлёт уведомление разработчикам». Т.е. пользователь не в курсе?
                        • 0
                          если уж делать серьезно, то заголовок вырезается сразу за подделкой сертификата

                          Сложно и ненадёжно, проще заставить всех установить сертификат Ростелекома при подключении к Интернету.
                          Т.е. пользователь не в курсе?

                          Скорее всего в курсе, но лучше посмотреть в коде браузера.
                      • +1
                        Если «попросят» встраивать нужный сертификат, как условие распространения приложения на территории страны, то выходит защиты нет совсем?

                        В браузере он вряд ли появится, но могут заставить устанавливать при подключении к интернету.
                        Все это не означает что надо что-то серьезное и глобальное делать с handshake и как-то менять алгоритм?

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

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое