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

Наша встреча с вами не первая, поэтому в этом тексте речь снова пойдет о дешифрации.
Да, я вновь расскажу об 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. Сертификат был подписан доверенным центром сертификации.

Безусловно, чтобы сертификат считался валидным на стороне клиента, должны выполняться и другие условия: он не должен быть отозван, просрочен и т.д. Но все эти условия учитываются на этапе подписи сертификата собственным центром сертификации.


При использовании 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

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



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


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

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

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



P.P.S.: Для тех, кому интересно, как эта кухня настраивается на FirePOWER — вэлкам в подкат.