Openssl error cannot load engine cryptocom



Openssl error cannot load engine cryptocom

FAQ МагПро КриптоПакет

Вопрос. Почему МагПро КриптоПакет базируется на OpenSSL 0.9.8e, когда уже существует 0.9.8g. Не приводит ли это к проблемам с безопасностью?

Ответ. В OpenSSL 0.9.8f было включено большое количество новой функциональности из разрабатываемой ветки 1.0.0. Выпуск security update 0.9.8g связан преимущественно с этой функциональностью. Мы предпочли не включать эту функциональность в МагПро КриптоПакет. Но все обновления безопасности, появившиеся с момента выпуска 0.9.8e, в частности CVE-2007-5135, интегрированы в КриптоПакет.

Вопрос. Подвержены ли Debian-пакеты МагПро КриптоПакет уязвимости CVE-2008-0166?

Ответ. Ни одна из когда-либо выпускавшихся версий МагПро КриптоПакет для Debian не подвержена этой уязвимости. Коммерческие версии МагПро КриптоПакет, использующие сертифицированные ДСЧ и отдельную программу генерации долговременных ключей вообще не затрагиваются этой уязвимостью. Ознакомительные версии МагПро КриптоПакет используют ДСЧ, встроенный в OpenSSL. Но они выпускаются на основе единой codebase для всех операционных систем, и далеко не все патчи, применяемые в конкретных дистрибутивах используются в библиотеках OpenSSL, входящих в МагПро КриптоПакет. В частности, патч, вызвавший данную уязвимость нами никогда не применялся.

Вопрос. Как создать сертификат сервера? С помощью команды openssl req?

Ответ. С помощью openssl req создается заявка на сертификат. Эту заявку необходимо отправить в удостоверяющий центр. Там заявка подписывается на ключах удостоверяющего центра. Полученный сертификат пересылается обратно заявителю.

Вопрос. Сертификат передается по открытому каналу связи?

Ответ. Сертификат удостоверяющего центра либо передается по надежному каналу (один раз при развертывании системы), либо передается по открытому каналу, а по надежному каналу (например, на бумаге, заверенной подписью и печатью удостоверяющего центра) передается его контрольная сумма (fingerprint). При установке корневого сертификата удостоверяющего центра его контрольная сумма сверяется с переданной на бумаге.

Целостность всех остальных сертификатов, выданных данным удостоверяющим центром, проверяется с помощью проверки электронной подписи удостоверяющего центра под этими сертификатами на корневом сертификате удостоверяющего центра. Эта функциональность встроена в библиотеку OpenSSL.

В качестве удостоверяющего центра в простейшем случае можно использовать команду openssl ca. Но это решение не сертифицировано как удостоверяющий центр.

Вопрос. Где можно посмотреть исходники простейшего клиент-серверного приложения, использующего OpenSSL API для ГОСТов?

Ответ. Например, исходники любого OpenSource-приложения, использующего OpenSSL (с учетом патчей, как правило, сводящихся к вызову OPENSSL_config(NULL)).

Исходники команд s_server и s_client, идущих в составе OpenSSL (эти команды и так читают файл конфигурации openssl).

Исходники тестов на SSL API, идущие в составе OpenSSL. См. также руководства программиста по продукту МагПро КриптоПакет.

Вопрос. Какие дополнительные меры необходимы для использования алгоритмов ГОСТ?

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

  • До вызова SSL_library_init был загружен модуль engine, реализующий алгоритмы ГОСТ. Если загрузка engine описана в конфигурационном файле OpenSSL (openssl.cnf), то достаточно загрузить этот файл вызовом OPENSSL_config(NULL) (с NULL оно загрузит конфигурационный файл по умолчанию).
  • В списке шифрсьютов, устанавливаемым вызовом SSL_CTX_set_cipher_list или SSL_set_cipher_list, должен присутствовать шифрсьют GOST2001-GOST89-GOST89.
  • Сертификат сервера и соотвествующий секретный ключ должны использовать алгоритм ГОСТ Р 34.10-2001.

Подробности описаны в файле README.gost, входящем в состав снапшота openssl-1.0.0.

Вопрос. При запуске приложения, работающего с МагПро КриптоПакет, происходит ошибка. Система сообщает:

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

Вопрос. Поступила информация, что в протоколе TLS обнаружена уязвимость. Что это за уязвимость и как можно ее избежать?

Этой уязвимости подвержен в первую очередь протокол HTTPS, в частности web-сервер Apache, поддерживаемый СКЗИ «МагПро КриптоПакет».

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

Читайте также:  Что такое http error 411

Уязвимость возникает в тех случаях, когда сервер позволяет клиенту выполнить следующую последовательность действий:

При обращении на сервер (на какую-то из страниц, находящихся на этом сервере) установить анонимное TLS-соединение;

затем, если при запросе другой страницы, находящейся на этом же сервере, требуется авторизация по сертификату, с помощью механизма renegotiation в TLS проапгрейдить установленное соединение до авторизованного по сертификату.

В этом случае права доступа, предоставленные на основании сертификата, применяются к данным, переданным клиентом до предъявления сертификата. Тогда атакующий, вклинившийся между клиентом и сервером, может передать на сервер какую-то свою команду, которая впоследствии будет невольно подтверждена ни о чем не подозревающим клиентом.

Таким образом, сервера, на которых при установлении TLS-соединения:

или вообще не производится аутентификация клиента;

или аутентификация производится по логину-паролю, а не по сертификату;

или аутентификация клиента по сертификату выполняется при любом TLS-соединении, т.е. без аутентификации клиента по сертификату TLS-соединение с данным сервером установить вообще невозможно,

полностью защищены от эффектов обнаруженной уязвимости.

Уязвимости подвержены только те сервера, на которые можно попасть автономно, а затем, уже установив автономное TLS-соединение с данным сервером, провести аутентификацию по сертификату. Т.е. сервера, на которых запрос на сертификат требуется не для любого TLS-соединения, а только для доступа к определенным страницам внутри сервера.

(Т.е в файле конфигурации Apache директива SSLVerifyClient require указана внутри блока Directory или Files.)

В настоящее время полного решения этой проблемы не найдено. Патч, предложенный в OpenSSL 0.9.8l, просто запрещает работу механизма renegotiation, что приводит к потере работоспособности для широкого спектра решений с использованием TLS.

Источник

OpenVPN Support Forum

Community Support Forum

OpenSSL error: cannot load engine ‘aesni’

OpenSSL error: cannot load engine ‘aesni’

Post by shakisha » Sat Mar 26, 2016 6:33 pm

I have got this error when setting in the server.conf the line

however the openssl command

openssl speed -evp aes-256-cbc

returns aes support. What can i do for fixing this error? Compiling from sources didn’t helped me.

Re: OpenSSL error: cannot load engine ‘aesni’

Post by Pippin » Sat Mar 26, 2016 7:23 pm

Is wrong command

Re: OpenSSL error: cannot load engine ‘aesni’

Post by shakisha » Sun Mar 27, 2016 12:17 am

Seems you cannot use it, ask Digital Ocean.

I’ve asked it, and they told me that yes, they support it.

Re: OpenSSL error: cannot load engine ‘aesni’

Post by Pippin » Sun Mar 27, 2016 10:50 am

Re: OpenSSL error: cannot load engine ‘aesni’

Post by ruxandy » Thu May 19, 2016 6:17 am

All the answers are wrong.
The OP is most lilely on OpenSSL 1.0.1 which does not have an AES-NI engine.
In OpenSSL 1.0.1, AES-NI support is integrated at EVP layer. More info here:
http://stackoverflow.com/questions/2893 . i-in-nginx

Bottom line, you don’t need to enable AES-NI in your OpenVPN config file. It will be used by default.

Источник

Настройка ГОСТ-TLS через КриптоПро

В протоколе https:// можно использовать криптографию ГОСТ (ГОСТ Р 34.10-2001, ГОСТ Р 34.10-94).

Для этого на Linux сервере есть 2 варианта реализации:

  • Opensource, добавленная в OpenSSL 1.0.* и входящая в комплект его поставки, и отделённая в https://github.com/gost-engine/engine, начиная с OpenSSL 1.1. Реализована компанией КриптоКом, НЕ сертифицирована.
  • Реализация через КриптоПро CSP и gost_capi. КриптоПро сертифицировано ФСБ, есть 3.9 и 4.0, 4.0 отличается дополнительным наличием поддержки чуть более нового стандарта ГОСТ Р 34.10-2012, однако для совместимости со старыми версиями КриптоПро (3.6, 3.9) и opensource реализацией его использовать не надо.

Содержание

Настройка OpenSource реализации (КриптоКом)

Самая простая в установке реализация ГОСТ — opensource. Установка сводится к 2 пунктам:

  1. Найти в комплекте поставки ИЛИ собрать engine «/usr/lib64/openssl/libgost.so»
  2. Включить её в конфигурации OpenSSL
Читайте также:  Unknown socket error java

Если ваша версия OpenSSL 1.0.x, ГОСТ может быть уже в комплекте поставки. Нужно найти директорию с engines OpenSSL (Debian: /usr/lib/x86_64-linux-gnu/openssl*/engines или /usr/lib/x86_64-linux-gnu/engines-1.1, RHEL: /usr/lib64/openssl/engines) и посмотреть, есть ли там файл с именем «libgost.so» или «libgost_engine.so». Если есть — можно переходить к редактированию конфигурации. Если нет — нужно скачать исходные коды вашего пакета OpenSSL и включить gost в его конфигурации сборки.

Если ваша версия OpenSSL 1.1.x, нужно склонировать репозиторий https://github.com/gost-engine/engine, установить пакеты cmake и libssl-dev (Debian) или openssl-devel (RHEL), зайти в склонированную директорию и выполнить команды

После чего взять libgost_engine.so из поддиректории bin клонированного репозитория и скопировать его в папку engines.

Далее отредактировать конфигурацию — добавить перед первой секцией INI-файла openssl.cnf следующий блок:

После этого всё ПО, использующее OpenSSL (в частности, nginx) сможет использовать ГОСТ в протоколе TLS.

Самоподписанный ГОСТ-сертификат можно сгенерировать так:

Чтобы сконвертировать ключевой контейнер КриптоПро в нормальный ASN.1/PEM формат, нужно использовать утилиту http://svn.yourcmc.ru/vitalif/trunk/scripts/cryptopro-key-to-openssl.c?view=co (источник: https://habrahabr.ru/post/275039/)

Установка КриптоПро на RHEL 7.2

Инструкция по установке КриптоПро CSP на сервер RHEL 7.2 в nginx.

Установка пакетов

  • Установить nginx >= 1.11 с официального сайта http://nginx.org/
  • Установить пакет redhat-lsb-core
  • Скачать дистрибутив КриптоПро CSP, например, 3.9
  • Установить пакеты КриптоПро: lsb-cprocsp-base, lsb-cprocsp-capilite-64, lsb-cprocsp-kc1-64, lsb-cprocsp-kc2-64, lsb-cprocsp-pkcs11-64, lsb-cprocsp-rdr-64, cprocsp-curl-64, cprocsp-cpopenssl-64, cprocsp-cpopenssl-base, cprocsp-cpopenssl-gost, опционально: lsb-cprocsp-devel, cprocsp-cpopenssl-devel
  • Убедиться, что сервис cryptsrv запущен (ps ax|grep cryptsrv), если нет — запустить (service cprocsp start), убедиться, что включён автозапуск (systemctl enable cprocsp)
  • Выполнить команду

Установка сертификата и ключа

Вначале устанавливаем закрытый ключ — для этого нужно взять директорию с ключами (см. #Формат ключа) и скопировать в /var/opt/cprocsp/keys/root/ под именем XXXXXXXX.000 (любое имя вида «8 латинских букв, точка, 3 цифры»). «Контейнер ключа/ключей» в терминологии КриптоПро — это и есть ключ.

Далее — установка сертификата.

Если сертификат НЕ в формате X.509/PEM, его нужно сконвертировать в этот формат.

В частности, один из наших тестовых сертификатов был получен в формате PEM (кусок текста в кодировке base64), но без заголовка — в этом случае нужно добавить заголовок, то есть в начало добавить строку ——BEGIN CERTIFICATE——, а в конец — строку ——END CERTIFICATE——.

Второй вариант — сертификат может быть в бинарном формате (X509/DER, расширение обычно *.cer) — тогда его надо сконвертировать в PEM командой Получив сертификат в формате PEM, нужно скопировать его в /etc/nginx/ssl-gost.pem и выполнить

КриптоПро должно предоставить выбор ключевого контейнера, в списке должен быть 1 элемент (ключ, скопированный на предыдущем шаге). Следует ввести цифру 1 и нажать Enter, таким образом выбрав единственный вариант. Если ключ защищён паролем, будет предложено ввести пароль.

Если ключ защищён паролем (если пароль запрашивался на предыдущем шаге), пароль нужно снять — командой

взять с прошлого шага из списка.

Проверить установку сертификата можно командой /opt/cprocsp/bin/amd64/certmgr -list. Должен быть выведен сертификат со строкой PrivateKey Link: Yes и указан ключевой контейнер — это будет означать, что сертификат установлен корректно.

Настройка nginx

Далее добавить в конфигурацию виртуального хоста nginx строки (то, что начинается с # — комментарии/пояснения, можно не добавлять):

Такая конфигурация говорит о том, что:

  • Для клиентов, поддерживающих ГОСТ — будет использоваться ГОСТ
  • Для остальных — будет использоваться RSA

Далее нужно перенаправить nginx на библиотеку OpenSSL, поставляемую с КриптоПро — для этого надо скопировать файл /usr/lib/systemd/system/nginx.service в /etc/systemd/system/nginx.service и отредактировать его, добавив в секцию [Service] строку

Кроме того, нужно выполнить команды:

После этого выполнить команду

Примечание: так получается сделать по той причине, что и в КриптоПро, и в RHEL 7.2 используется OpenSSL 1.0.x, то есть версии совместимы. При несовместимости версий нужно будет собирать nginx из исходных кодов, следующими командами:

Однако для RHEL/CentOS 7.2 этого можно не делать.

Читайте также:  Spring boot error message

Настройка SELinux и прав доступа

Далее, если на сервере не отключён SELinux (по умолчанию в RHEL 7.2 включён), нужно установить политику SELinux: http://svn.yourcmc.ru/vitalif/trunk/cryptopro-nginx-rhel7. Команды для установки:

После этого — перезапустить nginx: systemctl restart nginx.

Альтернативный путь (упрощённый): остановить nginx, если запущен ( systemctl stop nginx), установить пакет policycoreutils-python и далее повторять следующие 3 команды до тех пор, пока nginx не стартует:

Проверка работы

Для проверки нужно использовать openssl s_client на сервере.

Для проверки работы RSA: /usr/bin/openssl s_client -connect localhost:443 (с помощью системной OpenSSL без поддержки ГОСТ).

Для проверки работы ГОСТ: /opt/cprocsp/cp-openssl/bin/amd64/openssl s_client -connect localhost:443 (с помощью OpenSSL КриптоПро).

При условии нормальной работы TLS на экран в обоих случаях должен быть выведен сертификат сервера, детали соединения (Cipher — шифр, в первом случае вида …RSA…, во втором GOST2001-GOST89-GOST89), и openssl должен остаться включённым с приглашением ко вводу, то есть, при вводе «GET / » должен быть выведен HTTP ответ сервера, а следующую команду должно быть можно ввести только после отправки запроса (GET /) или нажатия Ctrl-C.

Если обе проверки удаются — соединение из клиентского браузера тоже будет работать.

Ошибки

В случае, если первый s_client (RSA) выводит строки «no peer certificate available» и «New, (NONE), Cipher is (NONE)» — следует проверить наличие в конфигурации nginx (/etc/nginx/nginx.conf, /etc/nginx/conf.d/*.conf) строк ssl_certificate и ssl_certificate_key с RSA-сертификатом и ключом.

В случае, если первый s_client (RSA) отрабатывает и выводит приглашение ко вводу, а второй (ГОСТ) выводит детали соединения и шифр GOST2001-GOST89-GOST89, но после этого сразу выходит в терминал — следует проверить права на файл /var/opt/cprocsp/tmp/openssl.log — владельцем файла должен быть пользователь nginx, а права должны стоять 644 (см. выше команду по смене владельца chown). Несмотря на то, что КриптоПро в инструкции по установке требует запускать nginx именно под пользователем root, наличия прав доступа к openssl.log должно быть достаточно для выполнения nginx под пользователем nginx.

Если права корректны, но ГОСТ s_client всё равно сразу выходит в терминал — следует поменять user nginx; на user root; в /etc/nginx/nginx.conf, перезапустить nginx и проверить s_client ещё раз.

Если и после этого ГОСТ s_client сразу выходит в терминал — можно проверить, прописана ли на сервере актуальная лицензия КриптоПро командой: /opt/cprocsp/sbin/amd64/cpconfig -license -view. Если лицензия невалидна, в выводе будет «the license is expired or not yet valid», а сервер тихо откажется работать. Также при этом в syslog/journalctl будут сообщения о невалидности лицензии от cryptsrv. Устанавливается лицензия командой /opt/cprocsp/sbin/amd64/cpconfig -license -set .

Некритичные ошибки

При запуске или перезапуске nginx возможны сообщения:

— данные ошибки некритичные, работе не мешают.

В журнале ошибок nginx /var/log/nginx/error.log возможно сообщение:

— это известное поведение библиотеки КриптоПро, работе не мешает.

При выполнении s_client в строке «Verify return code», в зависимости от сертификата, допустимы сообщения:

— эти ошибки некритичные, означают лишь то, что на сервере не установлены корневые сертификаты, которыми подписаны сертификаты TLS. Но для работы сервера установка корневых сертификатов необязательна.

Формат ключа

Формат ключа КриптоПро — не стандартный ASN1/PEM (-----BEGIN PRIVATE KEY----- . -----END PRIVATE KEY-----), а директория, содержащая файлы header.key, masks.key, masks2.key, name.key, primary.key, primary2.key.

Под Windows ключи хранятся аналогично, но в реестре, в ветке HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Crypto Pro\Settings\Users\ \Keys и в hex-кодировке. Для конвертации нужно выгрузить эту ветку в файл и подветки превратить в директории, а ключи с именами, аналогичными файлам выше — превратить в файлы путём перекодирования из hex в бинарный формат. Автоматически это можно сделать скриптом http://svn.yourcmc.ru/vitalif/trunk/scripts/convert-cryptopro.sh?view=co (скормив ему выгруженный файл *.reg)

Также под Windows есть поддержка экспорта сертификата и ключей в формат *.pfx. Но такие ключи потом невозможно импортировать в Linux-версию КриптоПро.

Источник

Оцените статью
toolgir.ru
Adblock
detector