Опыт внедрения «Континент TLS VPN» в кластерной конфигурации
Введение
TLS – криптографический протокол, обеспечивающий защищенную передачу данных между узлами в сети интернет. С ним вы можете ознакомиться здесь или здесь.
Ключевые задачи TLS:
Задача
В нашем случае необходимо было обеспечить защищенный с помощью ГОСТ-шифрования доступ к веб-ресурсу.
Решение
Ниже представлена схема и описание компонентов.
Для решения данной задачи был выбран продукт компании «Код Безопасности» «Континент TLS VPN», соответствующий всем вышеперечисленным условиям.
Стоит отметить, что на момент проектирования это был единственный сертифицированный ПАК, осуществляющий шифрование по ГОСТ с использованием протокола TLS. В дальнейшем ожидается получение сертификата ПАК ViPNet TLS от «ИнфоТеКС».
Основные элементы системы:
Описание элементов
СКЗИ «Континент TLS VPN Клиент» — TLS-клиент представляет собой устанавливаемое на компьютере удаленного пользователя программное обеспечение, функционирующее совместно с TLS-сервером. TLS-клиент предназначен для реализации защищенного доступа удаленных пользователей к веб-ресурсам корпоративной сети по каналам связи общих сетей передачи данных.
NetScaler — это контроллер доставки приложений, обеспечивающий гибкую доставку сервисов для традиционных, контейнерных и микросервисных приложений из центра обработки данных или любого облака. Балансировщик на основе Citrix Netscaler раскидывает сессии HTTPS между кластерами серверов TLS. Ответы от WEB сервера также собирает балансировщик.
СКЗИ «Континент TLS VPN Сервер» — сервер предназначен для обеспечения защищенного доступа удаленных пользователей к защищаемым ресурсам.
Порядок настройки
Инициализация
Первая сложность возникла при запуске TLS-серверов. Появилось сообщение «No controller found». Совместно со специалистами компании «Код Безопасности» была выявлена довольно нестандартная проблема. Оказалось, ПАК отказался работать в ЦОДе с мониторами фирмы BenQ, а с любыми другими работал без проблем.
Первоначальная настройка несложная и состоит в основном из определения ip-адреса и шлюза, а также имени устройства. Плюс создание, экспорт/импорт мастер-ключа.
Заказчик в проекте использовал два сервера TLS. Оба сервера TLS должны работать в состоянии active-active.
На одном сервере создается мастер-ключ, на другие серверы он импортируется. Мастер-ключ (ключ кластера) предназначен для решения следующих задач:
Импорт сертификатов
Далее необходимо подключиться к серверу TLS по веб-морде, определить защищаемый ресурс и установить сертификаты для работы серверов (корневой сертификат УЦ, сертификат сервера, сертификат для удаленного управления сервером, сертификат администратора и CRL). Все эти сертификаты должны быть выданы одним УЦ. Для первого подключения по веб-морде нужно использовать КриптоПро CSP, а не «Код Безопасности CSP. При последующих сменах сертификатов, лучше сначала удалить корневой сертификат УЦ, а после менять другие сертификаты.
Из-за невозможности сразу сделать боевые сертификаты было принято решение проверить работоспособность кластера TLS серверов на сертификатах, сделанных на тестовом УЦ Криптопро.
На TLS-серверах есть возможность отключить аутентификацию пользователя. При этом защищенный канал будет создаваться при наличии клиента TLS и установленных сертификатов (корневого, сертификата сервера и CRL), т.е. личного сертификата для работы не требуется.
Проверка подключения
Изначально возникли проблемы с подключением по защищенному каналу к защищаемому ресурсу с помощью сертифицированной версии TLS-клиента от «Кода Безопасности». Получилось подключиться к защищаемому ресурсу с использованием TLS-клиента 2.0 от «Кода Безопасности», но данная версия пока находится на этапе сертификации. Проблема заключалась в неправильном редиректе на защищаемом ресурсе, который не проходил, потому что TLS-серверы не совсем корректно отрабатывали данное правило в релизной версии прошивки. Для решения проблемы необходимо было перепрошивать оба сервера TLS и поднимать сделанные бекапы.
Порядок перепрошивки следующий:
После проделанных операций заработал сертифицированный TLS-клиент от «Кода Безопасности», на работе которого в системе настаивал заказчик. Но вот в чем фокус, он не заработал в браузере Chrome, работа в котором была просто необходима заказчику, можно даже сказать, что все затачивалось под него. Был проведен еще ряд тестирований совместно с поддержкой «Кода Безопасности», и, как результат, заработало все на версии чуть более новой (1.2.1073), чем сертифицированная (1.2.1068).
Кстати, еще один из подводных камней при настройке любого клиента TLS от «Кода Безопасности» (кроме версии 2.0) – они не работают на виртуальных машинах. При тестировании часто использовались виртуальные машины, это еще немного усложнило процесс диагностики.
Выводы
В конце хотелось бы подытожить. Продукт несложный в настройке и разворачивании. Есть еще над чем работать разработчикам, это касается и сервера, и клиента. Но в целом продукт рабочий и работает в кластерной конфигурации. Система на текущий момент работает без сбоев и держит нагрузку. Надеемся, что наши набитые шишки помогут вам быстрее и эффективнее разворачивать «Континент TLS».
Код безопасности регистрация клиента tls
Континент TLS VPN клиент 2.0.1440 необходим для работы с сертификатом электронной подписи ГОСТ Р 34.10-2012. Континент TLS VPN клиент 1.0.920.0 не работает с сертификами ГОСТ 2012.
Данный дистрибутив скачан с сайта производителя и имеет ограничение в работе 14 дней. При регистрации Континента через интернет это ограничение снимается. Приобретать лицензию на СКЗИ «Континент TLS VPN Клиент» не надо. Клиенты казначейства также могут получить данное СКЗИ в местном казначействе.
Сертификаты сервера «Континент TLS VPN» (lk2012.budget.gov.ru и lk.budget.gov.ru)
Инструкция по установке Континент TLS VPN клиент 2.0.1440
Перед установкой Континента ТЛС версии 2 необходимо удалить предыдущую версию Континента (если конечно она была установлена) через Пуск > Панель управления > Программы > Программы и компоненты. Потом перезагрузить компьютер.
Скачанный дистрибутив необходимо разархивировать и запустить файл «Континент TLS-клиент.exe»
Далее в появившемся окне отмечаем чекбокс «Я принимаю условия лицензионного соглашения» и нажимаем кнопку «Установить».
После успешной установки предлагается перезагрузить компьютер — соглашаемся.
Далее необходимо зарегистрировать СКЗИ «Континент TLS VPN Клиент». При запуске незарегистрированной программы появится следующее окно.
Если в течение 14 дней не зарегистрировать программу, то по окончании демонстрационного периода работа программы будет приостановлена.
Если не зарегистрировались сразу, то форму регистрации ищите в Континент TLS Клиент на вкладке «Настройки» > раздел «Регистрация» > кнопка «Начать» под полем «Онлайн-регистрация».
В открывшемся окне заполняем поля: Фамилия, Отчество, Электронная почта, в поле Адрес сервера регистрации (если не было указано) пишем «registration.securitycode.ru», нажимаем «Готово».
После успешной регистрации всплывает окно. Ограничение демонстрационного периода (14 дней) снято.
Для регистрации Континент TLS Клиент работникам казначейства (компьютер находится в локальной сети казначейства) необходимо внести изменения (выделены красным) в файл PublicConfig.json.
<
«loggingConfig»: <
«fileLogMaxSize»: 3145728,
«fileLoggingDirectory»: «C:\\Users\\Public\\ContinentTLSClient\\»,
«fileLoggingEnabled»: true,
«sessionLogsEnabled»: false
>,
«serialNumber»: « test-50000 »
>
Настройка СКЗИ «Континент TLS VPN Клиент» для работы в Электронном бюджете
Запускаем Континент TLS VPN Клиент (через меню пуск или иконку на рабочем столе). В открывшемся окне нажимаем «Главная» > «Добавить» > «Ресурс».
В окне добавления ресурса прописываем следующее:
Нажимаем «Сохранить». В соединениях отобразиться «lk2012.budget.gov.ru» или/и «lk.budget.gov.ru».
Далее идем в раздел «Настройки» > «Основные». Ставим галочки в следующих чекбоксах:
Получаем страницу с такими настройками. Нажимаем «Сохранить».
Следующий этап — настройка прокси. Раздел «Настройки» > «Внешний прокси» ставим галку «Настраивать автоматически» и сохраняем.
Следующий этап — настройка сертификатов. Идем на вкладку «Управление сертификатами» > раздел «Серверные сертификаты» > «Импортировать».
Если у вас нет серверных сертификатов, то качаем…
Сертификат сервера «Континент TLS VPN» ГОСТ Р 34.10-2012
Сертификат сервера «Континент TLS VPN» ГОСТ Р 34.10-2001
В результате добавления сертификатов видим следующее. 
Далее проверяем вкладку пользовательские сертификаты. Если вашего сертификата там нет, то его необходимо установить через КриптоПро. Инструкция по установке личного сертификата в КриптоПро тут. Если сертификат установлен, то видим следующее.
Идем на вкладку «Управление сертификатами» > раздел «CDP» > кнопка «Скачать CRL». 
На панели задач внизу справа нажать правой кнопкой мыши на значок «Континент TLS Клиента» и выбрать пункт «Сброс соединений».
«Континент TLS-клиент» (версия 2.0.1440) выдает ошибку «Доступ к конфигурационно
davydkov пишет: Пока не удалось поставить TLS клиент на машинах на которых он уже был. На машине на которой не было до этого Кода Безопасности, встал нормально. Вопрос, что же надо вычищать, и сможет ли он совместно работать с КАП?
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Вложенный файл:
Вложенный файл:
Вложения:
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
porsche.911 пишет: А если обновить КриптоПро до 4.0 R4 (4.0.9963)? ну а вдруг, хотя это конечно на TLS никак не должно влиять.
И, если машина в домене, и работаете под пользователем, но устанавливаете все с правами администратора, включите UAC в позицию «по-умолчанию»
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
porsche.911 пишет: Возможно дело в наличии на этой машине других продуктов КБ? (Континент-АП, Код Безопасности CSP)
Вложения:
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
porsche.911 пишет: Возможно дело в наличии на этой машине других продуктов КБ? (Континент-АП, Код Безопасности CSP)
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
porsche.911 пишет: Возможно дело в наличии на этой машине других продуктов КБ? (Континент-АП, Код Безопасности CSP)
А можно поподробней о манипуляциях?
Или это большой большой секрет?
Секрета нет. КБ CSP 4.0.400(какая то) ниже сборка, которая была в куче с ПО КБ, почему то у меня не заработала. Обязательно запускать с правами администратора. В заголовке окна появится дополнение (Администратор). После этого копируем контейнер. У которого уже исчеpнет надпись (сторонний провайдер). Ставим сертификат в скопированный контейнер и радуемся.
Jinn кстати нормально работает и с 2001 и 2012 ГОСТом в крайней версии Мозиллы 67.0.1 =) Использование КБ CSP, если еще немного поковыряться, можно настроить и при наличии Крипто ПРО.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Инструкция при возникновении проблем подключения к АИС
Инструкция обновлена 19.05.2020.
Общая инструкция при возникновении проблем подключения к АИС с помощью TLS-клиента и ЭП:
Если предыдущие шаги не помогли, то найдите описание своей ошибки:
Способы решения перечисленных ошибок:
Данная ошибка возникает по разным причинам. Решение: выполните шаги 1-9 в начале данной инструкции.
Данная ошибка возникает по разным причинам. Решение: выполните шаги 1-9 в начале данной инструкции.
Данная ошибка возникает по разным причинам. Решение: выполните шаги 1-9 в начале данной инструкции.
Решение: Проверьте, что флешка с электронной подписью подключена к компьютеру. Необходимо установить все серверные сертификаты.
Решение: после получения новой электронной подписи (состоит из двух частей: сертификат и контейнер) необходимо установить сертификат в контейнер с помощью программы КриптоПро CSP. Флешка с контейнером электронной подписи обязательно должна быть подключена к компьютеру. Подробности в видео:
Решение: необходимо получить новую электронную подпись и/или удалить сертификат истекшей подписи из TLS-клиента, для этого:
Решение: необходимо установить корневые сертификаты по аналогии с ошибкой.
Решение: необходимо импортировать списки отзыва сертификатов по аналогии с ошибкой.
Решение: нарушен порядок установки программ либо произошел сбой.
Решение : нажмите «Да».
Решение: выполните действия по аналогии с предыдущей ошибкой.
Решение: в настройках TLS-Клиента уберите галочку «Самотестирование драйвера прозрачного проксирования»: 
Решение: выполните действия по аналогии с предыдущей ошибкой.
Решение: выполните действия по аналогии с предыдущей ошибкой.
Решение: выполните действия по аналогии с предыдущей ошибкой.
Решение: прописать адреса DNS (8.8.8.8 и 8.8.4.4). Подробности в видео:
Простая настройка взаимной проверки подлинности клиента и сервера с использованием TLS
Это руководство посвящено настройке защиты приложений с помощью TLS-аутентификации. При таком подходе возможность работы пользователей с приложением зависит от имеющихся у них сертификатов. То есть — разработчик может самостоятельно принимать решения о том, каким пользователям разрешено обращаться к приложению.
В учебном проекте, который будет здесь разобран, показаны основные настройки сервера и клиента. Их взаимодействие изначально осуществляется посредством HTTP. А это значит, что данные между ними передаются в незашифрованном виде. Наша задача заключается в том, чтобы обеспечить шифрование всего того, чем обмениваются клиент и сервер.
Мы рассмотрим следующие вопросы:
1. Запуск сервера
Для того чтобы организовать работу сервера — нам понадобится следующее:
В данном проекте содержится Maven-обёртка, поэтому запустить его можно и не устанавливая Maven. Тут будут приведены сведения и о стандартных командах, рассчитанных на mvn, и о командах, ориентированных на использование Maven-обёртки.
Если вы хотите запустить этот проект с использованием Java 8 — вы можете переключиться на более старую его версию с использованием нижеприведённой команды.
При работе с этой версией проекта рекомендовано следовать инструкциям, подготовленным специально для него. Найти их можно здесь.
Сервер можно привести в рабочее состояние, вызвав метод main класса App или выполнив следующую команду в корневой директории проекта:
Вот команда, рассчитанная на Maven-обёртку:
2. Отправка приветствия серверу (без шифрования)
Ответ должен выглядеть примерно так:
В клиенте реализован интеграционный тест, основанный на Cucumber. Его можно запустить, обратившись к классу ClientRunnerIT из IDE, или выполнив в корневой директории следующую команду:
При использовании Maven-обёртки это будет такая команда:
Тут имеется файл Hello.feature, который описывает шаги интеграционного теста. Этот файл можно найти в папке ресурсов теста клиентского проекта.
Есть и другой метод запуска и клиента, и сервера. Он представлен следующей командой, выполняемой в корневой директории проекта:
Вариант этой команды для Maven-обёртки выглядит так:
3. Включение HTTPS на сервере (односторонний TLS)
Речь идёт о следующих настройках:
Для того чтобы вышеописанные настройки вступили в силу — сервер надо перезапустить. Возможно, при этом вы увидите следующее исключение:
Причина его появления заключается в том, что серверу, для установки защищённого соединения с внешними сущностями, нужно хранилище ключей с сертификатом сервера. Сервер может предоставить более подробную информацию об этом в том случае, если воспользоваться следующими аргументами VM:
Для того решения этой проблемы нужно создать хранилище ключей, содержащее открытый и закрытый ключи для сервера. Открытый ключ будет передаваться пользователям. Так они смогут зашифровать данные, передаваемые серверу. Зашифрованные данные могут быть расшифрованы с использованием закрытого ключа сервера. Закрытый ключ сервера нельзя никому передавать, так как, имея этот ключ, злоумышленник может перехватить зашифрованные данные, которыми обмениваются клиент и сервер, и расшифровать их.
Создать хранилище ключей с открытым и закрытым ключами можно с помощью следующей команды:
Теперь нужно сообщить серверу о том, где именно находится хранилище ключей, и указать пароли. Сделаем это, отредактировав наш файл application.yml :
Замечательно! Только что мы настроили TLS-шифрование соединений между сервером и клиентом! Испытать сервер можно так:
Клиент можно запустить и прибегнув к классу ClientRunnerIT.
В результате можно будет увидеть следующее сообщение:
И приведём её к такому виду:
Попробуем снова запустить клиент. Это приведёт к выдаче такого сообщения:
Дело тут в том, что клиент собирается наладить обмен данными по HTTPS. Он, при выполнении процедуры рукопожатия, получает сертификат сервера, который он пока не может распознать. А это значит, что нам ещё нужно создать хранилище TrustStore. В таких хранилищах находятся доверенные сертификаты. Клиент сопоставляет то, что он получает в ходе процедуры рукопожатия, с тем, что есть в TrustStore. Если полученный им сертификат входит в список доверенных сертификатов — процедура продолжается. А прежде чем создавать TrustStore — нужно обзавестись сертификатом сервера.
Экспортировать сертификат сервера можно такой командой:
Теперь можно создать TrustStore для клиента и импортировать туда сертификат сервера такой командой:
TrustStore для клиента мы создали, но сам клиент пока об этом не знает. А это значит, что клиенту надо сообщить о том, что ему следует пользоваться TrustStore, указав адрес хранилища и пароль. Клиенту надо сообщить и о том, что включена аутентификация. Всё это делается путём приведения файла application.yml клиентского приложения к такому виду:
4. Аутентификация клиента (двусторонний TLS)
Приведём файл сервера application.yml к такому виду:
Если после этого запустить клиент, то он выдаст следующее сообщение об ошибке:
Это указывает на то, что клиент не обладает подходящим сертификатом. Точнее — у клиента пока вообще нет сертификата. Поэтому создадим сертификат следующей командой:
Нам ещё нужно создать TrustStore для сервера. Но, прежде чем создавать это хранилище, нужно иметь сертификат клиента. Экспортировать его можно так:
Теперь создадим TrustStore сервера, в котором будет сертификат клиента:
Мы создали для клиента дополнительное хранилище ключей, но клиент об этом не знает. Сообщим ему сведения об этом хранилище. Кроме того, клиенту нужно сообщить о том, что включена двусторонняя аутентификация.
Приведём файл application.yml клиента к такому виду:
Сервер тоже не знает о только что созданном для него TrustStore. Приведём его файл application.yml к такому виду:
Если снова запустить клиент — можно будет убедиться в том, что тест завершается успешно, и что клиент получает данные от сервера в защищённом виде.
Примите поздравления! Только что вы настроили двусторонний TLS!
5. Установление двустороннего TLS-соединения с использованием доверенного удостоверяющего центра
Есть и другой способ организации двусторонней аутентификации. Он основан на использовании доверенного удостоверяющего центра. У такого подхода есть сильные и слабые стороны.
1. Создание удостоверяющего центра
Обычно работают с уже существующими удостоверяющими центрами, которым, для подписи, нужно передавать сертификаты. Здесь же мы создадим собственный удостоверяющий центр и подпишем с его помощью сертификаты клиента и сервера. Для создания удостоверяющего центра воспользуемся такой командой:
Ещё можно воспользоваться существующим удостоверяющим центром.
2. Создание файла запроса на подпись сертификата
Вот её вариант для сервера:
Вот — эта команда для клиента:
Такой файл нужен удостоверяющему центру для подписи сертификата. Следующий шаг нашей работы заключается в подписании сертификата.
3. Подписание сертификата с помощью запроса на подпись сертификата
Вот соответствующая команда для клиента:
Вот команда для сервера:
4. Замена неподписанного сертификата подписанным
Экспортируем подписанный сертификат:
Выполним на клиенте следующие команды:
На сервере выполним такие команды:
5. Организация взаимодействия клиента и сервера, основанного исключительно на доверии к удостоверяющему центру
Теперь нужно настроить клиент и сервер так, чтобы они доверяли бы только удостоверяющему центру. Сделать это можно, импортировав сертификат удостоверяющего центра в хранилища TrustStore клиента и сервера.
Сделаем это, выполнив на клиенте следующую команду:
На сервере выполним такую команду:
В хранилищах TrustStore всё ещё хранятся собственные сертификаты клиента и сервера. Эти сертификаты нужно удалить.
Выполним на клиенте такую команду:
Вот — команда для сервера:
Если снова запустить клиент — можно видеть успешное прохождение теста. А это значит, что клиент и сервер успешно обмениваются данными, используя сертификаты, подписанные удостоверяющим центром.
6. Автоматизация различных подходов к аутентификации
Всё, о чём мы говорили выше, можно автоматизировать с помощью скриптов, которые находятся в папке script рассматриваемого нами проекта. Для запуска скриптов можете воспользоваться следующими командами:
Протестированные клиенты
Ниже приведён список протестированных клиентов. Настройки для HTTP-клиента, написанного на чистом Java, можно найти в классе ClientConfig. В директории service нашего проекта содержатся отдельные HTTP-клиенты, выполняющие демонстрационные запросы. Настройки HTTP-клиентов, основанных на Kotlin и Scala, включены в состав проекта в виде вложенных классов. Все примеры клиентов используют одну и ту же базовую конфигурацию SSL, созданную в классе SSLConfig.