Привет, Хабр! Меня зовут Максим Теплых, эксперт по тестированию на проникновение в ИТ-компании Innostage. В этой статье я хочу рассмотреть тему, которая с годами становится все более актуальной — тестирование систем, использующих ГОСТ TLS. Кратко расскажу о самой технологии, а также покажу подходы и наработки, которые применяем на практике. 

Заранее приношу извинения за объемное и несколько затянутое введение. Хотя изложение начинается не с динозавров и не с истории древней Руси, тему все же необходимо раскрыть с некоторой предыстории.

Введение

За годы практики нам приходилось сталкиваться с большим разнообразием технологий: одни были нишевые, другие популярными, но с нотками экзотики. Сегодня я расскажу о довольно привычной вещи, с которой многие встречаются ежедневно, но зачастую не замечают.

В 2015 году появился отечественный стандарт ГОСТ Р 34.12-2015, и мир узнал ещё одно необычное название для серьёзной технологии — «Кузнечик». За этим названием скрывался симметричный блочный алгоритм шифрования, который уже в 2018 году стал частью национального стандарта шифрования в России ГОСТ 34.12-2018.

Имя это стало чуть более известно из-за новостей о новых требованиях для оборудования сетей 5G. Для тех, кто читает это название впервые или просто хочет познакомиться с алгоритмом поближе, рекомендую две хорошие статьи: Статья про Кузнечик простыми словами и более подробная статья.

Итак, зачем понадобился новый алгоритм? Это часть усилий по достижению технологического суверенитета и важный этап в развитии другой отечественной технологии, о которой и пойдёт речь.

Эта технология — ГОСТ TLS. Она непростая и комплексная. По сути, это набор отечественных криптографических решений, используемых при реализации протокола TLS.

Протокол TLS (Transport Layer Security) представляет собой один из наиболее широко используемых механизмов для установления защищенного канала связи. Он основан на SSL (Secure Sockets Layer) версии 3.0 и за время развития сильно изменился. Сейчас актуальна версия TLS 1.3, хотя TLS 1.2 остаётся наиболее распространённой.

Как понятно из описания, это технология для защиты данных, передаваемых по каналам связи. Распространенность и привычность протокола TLS мало кого удивит, он есть буквально повсюду. Например, вы читаете эту статью через HTTPS, который также использует TLS. Но что насчёт его отечественной версии?

Отчасти могу понять скептицизм некоторых наших соотечественников в вопросах наших технологий, однако именно ГОСТ TLS стал той темной лошадкой, которая получила распространение и доказала свою жизнеспособность. Пусть это не всегда заметно, но системы, использующие ГОСТ TLS, есть практически у каждого из нас. Государственные сайты поддерживают работу через ГОСТ TLS. Ваше мобильное приложение Госуслуг или налоговой, большую часть трафика шифрует с помощью того самого Кузнечика. Множество систем КИИ, да и просто критичных для бизнеса работает только с использованием ГОСТ TLS, который стал привычным и незаметным для большинства пользователей.

Но в чем тогда ценность статьи, если я так хвалю эту технологию? Для обычного пользователя ГОСТ TLS стал незаметной частью жизни, а вот для разработки и тестирования он часто оказывается серьёзной проблемой.

Проблемы индейцев

Для обычных пользователей таких систем и сайтов проблем особых нет. Весь heavy lifting на себя берут приложения с решениями для работы с ГОСТ TLS или этим занимается браузер. Для тестировщиков и разработчиков этого совершенно недостаточно. 

Например, в задачах анализа защищённости и пентеста нам нужно нечто большее, чем просто браузер с поддержкой ГОСТа. Разработчикам, в свою очередь, приходится искать способы, как встроить в существующую инфраструктуру новые компоненты, которые могут работать с ГОСТ.

Есть ли такие решения на рынке? Ответ неутешительный: готовых инструментов для отладки нет, есть только заготовки.

Существующие технические решения

Работать без госта

Самый простой вариант для проведения любых тестирований — просить доступ к стендам, где не используется ГОСТ TLS. Решение простое, но зачастую неприменимое.

В моей практике были случаи, когда удавалось договориться с заказчиком и получить доступ к тестируемой системе в обход ГОСТ TLS. Но чаще всего никто не хочет разворачивать дополнительный стенд или клонировать боевую систему — это дорого.

Отсюда вопрос: как работать с ГОСТ TLS при тестировании?

Работа через существующие инструменты

Много лет назад стало понятно: готовых инструментов нет, необходимо использовать то, что есть.

А что же есть? 

Браузеры с поддержкой ГОСТ TLS. Они построены на базе Chromium, и в них можно поставить нужные плагины, превратив их в подобие BurpSuite.

Раньше были браузеры с нативной поддержкой ГОСТа. Сейчас они либо устарели, либо используют msspi (через сторонний криптопровайдер). Например, https://github.com/deemru/Chromium-Gost  — это Chromium с msspi, который работает с криптопровайдером Крипто ПРО CSP. Яндекс бразуер также умеет работать с msspi из коробки.

Решение рабочее, но неудобное. Возможности BurSuite и ZAP нельзя полноценно реализовать через браузерные плагины. Есть инструменты и утилиты, которые невозможно пропустить через браузер. 

Хочется перебрать файлы по словарю? Не получится, надо придумывать другой способ.

Существующий пласт проблем

В поисках решений мы провели анализ, почему существующие инструменты не работают с ГОСТ TLS.

Проблемы средств отладки для работы с ГОСТом

В «красной» части ИБ для тестирования веб-приложений уже много лет используют два инструмента:

• OWASP ZAP

• Burp Suite

Но нас интересовал конкретный вопрос: почему ни один из них не работает с ГОСТом? Изучив вопрос поближе, мы разбили проблему на две части: криптография и сертификаты.

Поддержка криптографии

Снова возвращаемся к «Кузнечику» и «Стрибогу»: первый — алгоритм шифрования, второй — алгоритм хэширования. Сначала казалось, что инструменты, созданные за пределами России, просто не поддерживают эти алгоритмы и придётся всё переписывать.

Реальность оказалась несколько интереснее.

ZAP использует OpenSSL и его модули, а Burp Suite — библиотеку Bouncy Castle. И в обоих случаях поддержка ГОСТ-алгоритмов есть:

• Bouncy Castle — поддерживает ГОСТ «из коробки»

• OpenSSL — поддержку можно добавить через модули или получить вместе с КриптоПРО CSP

Получается, поддержка криптографии есть. Тогда почему всё равно не работает?

Поддержка сертификатов

Все подобные инструменты реализуют атаку MITM, точнее технику ssl-split.

В чем же суть? Браузер открывает сайт через HTTP-прокси, в роли которого выступает ZAP или Burp. Инструмент устанавливает соединение с сайтом, получает его сертификат и генерирует самоподписанную копию. Благодаря этому он может расшифровывать HTTPS-трафик: принимает данные от браузера, обрабатывает их и отправляет на сервер.

Где возникает проблема? Всё работает до момента генерации самоподписанного сертификата. Даже если инструмент умеет устанавливать соединение с использованием ГОСТ TLS, он не может корректно обработать сертификат, полученный от сервера. Сертификаты ГОСТ внешне похожи на обычные TLS-сертификаты, но отличаются содержимым. Поля, их идентификаторы и значения хоть и поддерживаются библиотеками, но полноценной работы с ними в этих инструментах нет. Ни Burp Suite, ни ZAP не умеют преобразовывать ГОСТ-сертификаты в привычный формат RSA/ECC. Разработчики просто не закладывали такой сценарий.

Ниже приведены примеры различий между OID и значениями полей в сертификатах:

Изобретение костылей

Базовая задача

Из полученных знаний получили два варианта действий:

• Переписывать куски ZAP/BurpSuite

• Отдать работу с ГОСТом другому инструменту

Мы выбрали второй вариант.

Что он предполагает:

• ZAP/BurpSuite переводятся в конфигурацию, которая реализует логику ssl-strip. То есть получает шифрованный трафик, расшифровывает и передает дальше.

• Мы работаем с расшифрованными данными: смотрим, меняем.

• ZAP/BurpSuite отправляет незашифрованные данные в другой инструмент.

• Другой инструмент производит взаимодействие с оригинальным сайтом с помощью ГОСТ TLS и передает данные.

Схема вполне логичная и позволяет просто сбросить с ZAP/BurpSuite задачу, которую они не могут выполнить.

Если представить все в виде схемы, то выглядит это так:

Преимущество данной схемы в том, что мы можем пропускать через новый инструмент все что захотим (fuff, dirb, sqlmap, iisns). А при достаточных мощностях можно использовать один инструмент для нескольких специалистов одновременно, это немного упростит жизнь тому, кто это будет настраивать.

Для реализации такой схемы у нас целых четыре варианта костылей.

Вариант нулевой

Самый простой, быстрый и бесплатный.

В комплекте поставки КриптоПро CSP есть утилита stunnel с поддержкой ГОСТ TLS. С помощью нее можно создать тоннель до нужного нам сайта, и все шифрование она возьмет на себя. Ссылка на сайт криптопро: https://cryptopro.ru/products/other/stunnel

Пример конфигурации такой конструкции (stunnel.conf):

pid=/var/opt/cprocsp/tmp/stunnel_cli.pid

output=/var/opt/cprocsp/tmp/stunnel_cli.log

socket = l:TCP_NODELAY=1

socket = r:TCP_NODELAY=1

debug = 7



[https]

client = yes

accept=127.0.0.1:1500

connect = gost.site.ru:443

verify=0

Запуск нашей конфигурации:

/opt/cprocsp/sbin/amd64/stunnel_thread stunnel.conf

После запуска нужный сайт становится доступен на localhost на порту 1500. Подключение к нему происходит через обычный http без шифрования. 

Не забываем прописать себе новый адрес сайта в hosts

Плюсы: решение работает, есть поддержка авторизации по сертификатам.

Минусы: для каждого сайта нужна отдельная настройка. Не подходит для работы с мобильными приложениями (к этой проблеме вернёмся позже).

Вариант первый

Вариант с минимальными затратами на разработку или покупку. На нём мы в итоге и остановились.

Этот подход основан на том, что nginx в unix дистрибутивах вполне спокойно пользуется криптографией из openssl. При этом никаких специальных патчей или сложных настроек не требуется.

Разбираемся с openssl

Здесь есть маленькая загвоздка, после версии 1.1.0 openssl перестал поддерживать ГОСТ криптографию. Но это поправимо. На просторах open-source существует репозиторий https://github.com/gost-engine/engine, в нем лежит имплементация отечественной криптографии для openssl. Можно взять и собрать нужный модуль с криптографией для своих потребностей. 

Собрав библиотеку, переместите ее в /usr/local/ssl/lib/engines-3/ и пропишите ее в конфигурацию для openssl.

openssl_conf=openssl_def

[openssl_def]



engines = engine_section

[engine_section]



gost = gost_section

[gost_section]



engine_id = gost

dynamic_path = /usr/local/ssl/lib/engines-3/gost.so

default_algorithms = ALL

CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet

Если собирать модуль из исходников вам не хочется, то существует и другой способ: https://github.com/rnixik/docker-openssl-gost

В этом репозитории представлены примеры docker-контейнеров и их build-файлов. Внутри контейнеров находятся готовые сборки OpenSSL, nginx и curl. Подробное описание реализации приведено в отдельной статье.

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

Если собираете свой образ путем копирования библиотек из готового примера, то не забудьте их активировать.

echo "/usr/local/ssl/lib" >> /etc/ld.so.conf.d/ssl.conf && ldconfig

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

Настраиваем nginx

Разобравшись с openssl, переходим к части с nignx.

Есть два пути:

• устанавливаем его после того, как собрали все для openssl

• пересобираем, если установили до сборки.

Конфигурация nginx для наших целей — простой reverse-proxy, но с некоторыми нюансами:

server {

    listen  8081;

    server_name _;

    large_client_header_buffers 16 32k;

    resolver 127.0.0.11;



location / {

    proxy_pass https://$host;

    proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

    proxy_ssl_ciphers GOST2012-GOST8912-GOST8912:HIGH:MEDIUM;

    proxy_buffering off;

    proxy_buffer_size 128k;

    proxy_busy_buffers_size 256k;

    proxy_buffers 64 32k;

    }

}

Безусловно главная часть в данной конфигурации — это настройка поддерживаемых алгоритмов шифрования. За это отвечают две строки:

proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

proxy_ssl_ciphers GOST2012-GOST8912-GOST8912:HIGH:MEDIUM

Включенные старые версии TLS, можно убрать, но мы оставили их на случай разных сценариев. Поддержку TLSv1.3 для работы с ГОСТ TLS добавить не удалось, они так и не смогли подружиться.

В качестве приятных бонусов этой конфигурации: она позволяет работать не только с 443 портом на целевом ресурсе. Заголовок Host корректно обрабатывается даже при указании порта после адреса. Условно говоря, при поступлении запроса с заголовком: 

Host: gost.site.ru:8443

Данная конфигурация будет использовать:

proxy_pass https://$host

Что будет равноценно:

proxy_pass https://gost.site.ru:8443

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

Блок с указанием резолвера ситуативный и зависит от вашей конфигурации.

Приведённый конфиг корректно работает только для HTTP/1.1 и ниже. Причина проста: хотя HTTP/2 формально не требует TLS, большинство браузеров и клиентов используют его только с шифрованием.

Если нужно добавить поддержку http2, меняем конфиг:

server {

    listen  8081 ssl http2;

     server_name _;

     ssl_certificate      /certs/def.crt;

     ssl_certificate_key  /certs/def.key;

     large_client_header_buffers 16 32k;

     resolver 127.0.0.11;

 location / {

      proxy_pass https://$host;

      proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

      proxy_ssl_ciphers GOST2012-GOST8912-GOST8912:HIGH:MEDIUM;

      proxy_buffering off;

      proxy_buffer_size 128k;

      proxy_busy_buffers_size 256k;

      proxy_buffers 64 32k;

      }

}

Плюсы метода очевидны: его не нужно перенастраивать под каждый сайт. Работа через BurpSuite идет так, будто проблема с ГОСТ TLS отсутствует. 

Минусы: из-за особенностей конструкции, для перебора vhosts придется переделывать конфигурацию.

Вариант второй

Вариант похож на первый, но требует затрат. В составе продукта КриптоПРО CSP есть компонент с поддержкой msspi (тот самый механизм, который используется в браузерах для работы с ГОСТ TLS).

Веб-серверы nginx и Apache могут работать с msspi, но для этого требуется изменение их кода. У КриптоПРО есть готовые решения:

• Для nignx есть бинарный патч

• Для apache есть кастомный модуль mod_ssl

Ознакомиться можно по ссылке.

Недостатки этого подхода в том, что он требует довольно большие лицензии Крипто ПРО CSP, а использование бинарных патчей ограничивает возможность обновления веб-серверов.

Преимущества: поддержка TLSv1.3 работает, и такое решение может пройти сертификацию.

С точки зрения конфигурации серверов для наших задач отличий от первого варианта нет.

Вариант третий

Последний вариант — разработка собственного инструмента. 

Тем, кто отважится отправиться в это занимательное путешествие, мы дадим несколько ссылок на полезные материалы:

• статья о разработке с использованием ГОСТ TLS

• https://github.com/deemru/msspi — репозиторий с msspi

• https://github.com/deemru/go‑msspi — реализация msspi для go. У go своя криптография под капотом, потому заставить работать его с ГОСТ та еще задачка, но решение уже существует

• https://www.bouncycastle.org/ — здесь есть криптография на любой вкус и языки. И ГОСТ там тоже есть.

Мы, в свою очередь, на такое путешествие не отважились, но возможность реализации видна (да и просится на самом деле).

Интеграция инструментов с выбранными решениями

С вариантами реализации мы закончили, переходим к настройке BurpSuite/ZAP.

Работа с stunnel

Если выбрали вариант работы через stunnel, то никаких серьезных настроек не потребуется. Необходимо лишь направить трафик на порт stunnel через инструмент. Просто заранее проверьте в настройках прокси браузера и системы, чтобы адрес stunnel не стоял в исключениях (часто в исключениях прокси стоят "серые" сети, и по умолчанию отключено проксирование для localhost).

Работа через nginx/apache

При использовании nginx/apache настройка сложнее. BurpSuite и ZAP для этой схемы должны работать в режиме ssl-strip.

Для BurpSuite можно настроить еще один listener со специальной конфигурацией:

Такая конфигурация потребует включения https на стороне reverse-прокси, т.к. она не работает как ssl-strip. Опция Convert HTTPS links to HTTP во вкладке настроек прокси работает нестабильно и не всегда подходит. Также возможны проблемы с обработкой заголовка Host: в какой-то момент эта конфигурация перестала добавлять в конец адреса используемый порт, что нарушает работу с любыми портами в reverse-прокси.

Для решения можно использовать бесплатное расширение для BurpSuite — Target Redirector. Она может пересылать исходящие запросы на нужный адрес на основе простых правил, выполнять ssl-strip и переписывать заголовок Host в корректном формате.

Пример конфигурации расширения:

Здесь все логично и понятно:

• Редирект запросов к любым сайтам

• Работающих через https

• Пересылка на адрес 127.0.0.1, порт 8081

• Пересылка в виде http (plaintext), по сути, выполнение ssl-strip

• Заголовок Host выставляется как в оригинальном запросе, но с указанием порта

Такое расширение с приведённой конфигурацией позволяет использовать все преимущества reverse-прокси.

Если возникают ошибки с протоколом http2, отключите опцию выбора http2 по умолчанию в настройках Network -> HTTP -> HTTP2. Если http2 необходим, воспользуйтесь приведенным примером конфигурации для nginx и в настройках Target Redirector выставьте опцию redirect as https.

Настройка ZAP для этой схемы требует дополнительной реализации. Вероятно, потребуется создать расширение с функциональностью, аналогичной Target Redirector, либо использовать готовые решения для этой задачи, если они доступны.

Работа с мобильными приложениями

С настройкой инструментов для работы с сайтами за ГОСТ TLS мы разобрались. Но нам необходимо учитывать и мобильные приложения.

Все могло бы быть просто и красиво, привычные настройки, привычные действия, известные всем скрипты для frida. Но… Мобильные приложения, которые могут работать с ГОСТ TLS, имеют под капотом кастомные http-клиенты. Это могут быть решения, написанные вокруг продуктов от КриптоПРО, а могут быть и самописные реализации (с использованием того же bouncycastle). В зависимости от реализации, такие клиенты могут работать как со всеми шифрами (ГОСТ/неГОСТ), так и только с конкретным типом (только ГОСТ). Отсюда возникает новая проблема: как заставить работать ГОСТовые клиенты и при этом видеть их трафик?

Ответ нашелся довольно быстро. У нас уже есть веб-сервер с поддержкой ГОСТ TLS, осталось только соорудить такую конструкцию, которая принимает соединения с шифрованием ГОСТ и передает уже plaintext запросы в наш открытый BurpSuite, а оттуда уже в ранее созданную конструкцию.

Общий вид такой схемы:

Настройка nginx

Пример конфигурации для нашего nginx сервера:

server {

                resolver 127.0.0.11;

                listen       8082 ssl;

                server_name  _;

                ssl_certificate      /certs/gost.crt;

                ssl_certificate_key  /certs/gost.key;

                ssl_certificate      /certs/def.crt;

               ssl_certificate_key  /certs/def.key;

               ssl_ciphers GOST2001-GOST89-GOST89:HIGH:MEDIUM;

               ssl_protocols   TLSv1 TLSv1.1 TLSv1.2;

               ssl_prefer_server_ciphers  on;



               location / {

                         proxy_pass http://host.docker.internal:8083;

                         proxy_set_header Host $host;

                }

}

Это еще одна reverse-proxy. В этом случае он пересылает уже расшифрованный траффик в BurpSuite.

За это отвечает этот блок конфигурации:

location / {

             proxy_pass http://host.docker.internal:8083;

             proxy_set_header Host $host;

}

В конфигурации указано два варианта сертификатов. Nginx поддерживает использование разных сертификатов и ключей для разных алгоритмов шифрования. В нашем случае это сертификат для ГОСТ TLS и сертификат для стандартного TLS. Это позволяет использовать одну прокси для всех вариантов http-клиентов (поскольку у нас есть поддержка всех вариантов шифрования).

В разделе ssl_ciphers указываем поддержку ГОСТ - GOST2001-GOST89-GOST89:HIGH:MEDIUM

Настройка BurpSuite

Представленная на схеме карусель запросов внутри BurpSuite реализуется с помощью двух новых litener'а и одного правила для TLS-passthru.

Первый listener:

• Порт 8084 на адресе доступном для мобильного приложения

• Request handling — переадресация на адрес 127.0.0.1:8082, Invisible proxy включено

Второй listener:

• Порт 8083 на localhost

• Request handling — Invisible proxy включить

Правило для TLS -passthru (в разделе Proxy):

• адрес 127.0.0.1 порт 8082

Настройки для Target Redirector немного изменяются, правила редиректа переключаются с redirect only https на redirect both.

Проверить работоспособность можно с помощью curl с поддержкой ГОСТ TLS. Обратите внимание, в качестве прокси используется новый созданный listener на порту 8084.

curl -k https://gost.cryptopro.ru/ -x "http://host.docker.internal:8084" -vvv --ciphers GOST2012-GOST8912-GOST8912

Настройка мобильного приложения

Для тестируемого мобильного приложения необходимо указать http-proxy <адрес_BurpSuite>:8084. Некоторые http-клиенты на Andorid игнорируют системные настройки. В этих случаях можно использовать следующие варианты.

С помощью iptables перенаправить нужный порт в нашу прокси:

iptables -t nat -A OUTPUT -p tcp --dport 443 -j DNAT --to-destination <адрес_BurpSuite>:8084

iptables -t nat -A POSTROUTING -p tcp --dport 443 -j MASQUERADE

Или ставим на телефон ProxyDroid и настраиваем прокси через него:

Pinnig'а сертификаты и отключения их проверки зависят от конкретного приложения. Если у вас есть опыт тестирования мобильных приложений, то требуется разобрать apk, найти нужную функцию и написать хук-скрипт для frida.

Преимущества решений, построенных вокруг openssl

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

Например, при написании автоматизации на python можно использовать библиотеки urlib3 и requests для реализации http клиента с поддержкой ГОСТ TLS.

Небольшой hello world:

import requests

import urllib3

urllib3.disable_warnings()

requests.packages.urllib3.util.ssl_.DEFAULT_CIPHERS += ':GOST2012-GOST8912-GOST8912'



response = requests.get("https://gost.cryptopro.ru/",verify=False)

print(response.text)

Или другой вариант: собрать curl, после установки модуля для openssl. В этом случае он будет корректно работать с ГОСТ TLS.

Вместо вывода

ГОСТ TLS все чаще встречается в наших проектах, и для работы с ним регулярно приходится искать обходные решения. При этом крупные вендоры, занимающиеся отечественной криптографии, не предлагают базовых рекомендаций и подходящих решений для отладки. Вопрос, как будет развиваться ситуация с появлением отечественных стандартов 5G, также использующих ГОСТ, остается открытым.

Надеемся, что приведённые в статье подходы будут полезны в вашей работе. Они не универсальны, но все описанные выше методы проверены в реальных проектах.