LINUX.ORG.RU
Форум — Admin  

GOST Engine не работает на OpenSSL 1.1.1k (Centos Stream 8)

 ,


1

4

Добрый день!

Есть 2 сервера, на обоих нужен openssl с поддержкой ГОСТ. Используемый мануал: https://sysos.ru/?p=589

  1. Ubuntu 18.04 Использую уже установленный openssl из репозитория (openssl 1.1.1). Успешно собираю gost-engine.

openssl engine выдает:

(rdrand) Intel RDRAND engine
(dynamic) Dynamic engine loading support (gost) Reference implementation of GOST engine

openssl ciphers|tr ':' '\n'|grep GOST выдает:
GOST2012-GOST8912-GOST8912 GOST2001-GOST89-GOST89

Все успешно. Серт по url читается успешно

  1. Centos Stream 8
    Использую уже установленный openssl из репозитория (openssl 1.1.1k)
    Успешно собираю gost-engine.
    openssl engine выдает:
    (dynamic) Dynamic engine loading support
    (gost) Reference implementation of GOST engine
    openssl ciphers|tr ':' '\n'|grep GOST выдает пустоту.
    Не работает =\ Серт по url не выдается.

Подскажите пожалуйста в чем может быть загвоздка?

Ответ на: комментарий от t184256

https://www.thegeekdiary.com/how-to-disable-fips-mode-on-centos-rhel-7/

это? ТС может попробовать.

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

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

это? ТС может попробовать.

Этот гайд подразумевает RHEL-7 и заранее включенный FIPS mode.

Выключать FIPS mode, кстати, смысла никакого нет, так как это нарушает compliance, а на поржать FIPS mode не включают.

смотрел этот ключ в рпм,

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

он там отменял сборку всего, что можно.

ТСу от этого всего все равно ни холодно, ни жарко, потому что все вопросы надо адресовать к его поставщикам gost engine.

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 2)

Интереса ради собрал в центос8, работает.

openssl ciphers | tr ":" "\n" | grep GOST 
GOST2012-GOST8912-GOST8912
GOST2001-GOST89-GOST89

там в конфиге все запрещено

/etc/pki/openssl.cnf

# Load default TLS policy configuration
#openssl_conf = default_modules
#[ default_modules ]
#ssl_conf = ssl_module
#[ ssl_module ]
#system_default = crypto_policy
#[ crypto_policy ]
#.include /etc/crypto-policies/back-ends/opensslcnf.config

openssl_conf = openssl_def

[openssl_def]
engines = engine_section

[engine_section]
gost = gost_section

[gost_section]
engine_id = gost
dynamic_path = /usr/lib64/engines-1.1/gost.so
default_algorithms = ALL
CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet

и в полисях

/etc/crypto-policies/back-ends/openssl.config

@SECLEVEL=1:aGOST:aGOST01:kGOST:GOST94:GOST89MAC:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8

Подробнее тут: https://redos.red-soft.ru/base/manual/safe-redos/gost-in-openssl/

Не могу не ругнуться в сторону редсофта. Хороший док сделали, без него хрен бы разобрался. Но конфиги без перевода строк, это провал…

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

Затем необходимо явно указать Cipher Strings в файле конфигурации /etc/crypto-policies/back-ends/openssl.config:

Хороший док сделали

Да просто очешуенный док, прямо в генерируемые файлы писать, они сами-то это пробовали? При следующем же обновлении crypto-policies это затрет скриптлетом. Я уже даже и не спрашиваю зачем это туда писать, когда остальная конфигурация маков и шифров openssl идет через denylisting по принципу «все, что не запрещено, разрешено».

t184256 ★★★★★
()
Ответ на: комментарий от t184256

во первых это не файл а ссылка. дистрибутивный файл находится в /usr/share

во вторых суть выше. вот где фигня вся

#openssl_conf = default_modules
#[ default_modules ]
#ssl_conf = ssl_module
#[ ssl_module ]
#system_default = crypto_policy
#[ crypto_policy ]
#.include /etc/crypto-policies/back-ends/opensslcnf.config

И нигде больше я этого не увидел…

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

во первых это не файл а ссылка. дистрибутивный файл находится в /usr/share

Ты прости меня, конечно, но я — мэйнтейнер crypto-policies, и я тебе авторитетно заявляю, что ссылкой в /usr/share оно будет только при условии не-custom policies и отсутствии модификаций через local.d впридачу.

во вторых суть выше. вот где фигня вся

воистину фигня какая-то, но самой сути мысли не улавливаю.

t184256 ★★★★★
()
Ответ на: комментарий от AVL2

Вот, справки ради, openssl.config и opensslcnf.config, которые будут при применении GOST subpolicy поверх текущего DEFAULT на федоре. Сам я никогда этого не пробовал, честно признаюсь, но если это по какой-то причине не работает, я бы предложил перед или вместо безудержной самодеятельности в /etc/pki/openssl.cnf слать багрепорты и/или патчи.

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от t184256

Ты прости меня, конечно, но я — мэйнтейнер crypto-policies, и я тебе авторитетно заявляю, что ссылкой в /usr/share оно будет только при условии не-custom policies и отсутствии модификаций через local.d впридачу.

-rw-r--r-- 1 root root 180 дек  1 01:09 openssl.config
lrwxrwxrwx 1 root root  46 сен 15 11:00 openssl.config.bak -> /usr/share/crypto-policies/DEFAULT/openssl.txt
[root@rhome-msk ~]# rpm -qf /etc/crypto-policies/back-ends/openssl.config
crypto-policies-20211116-1.gitae470d6.el8.noarch

openssl.config.bak ’жто переименованный оригинальный истрибутивный файл openssl.config. Как видишь, это ссылка на /usr/share/crypto-policies/DEFAULT/openssl.txt

В centos8 вот так. Не я это делал.

Далее, проверим необходимость.

Сразу оговорюсь, при любом значении полиси, енгайн гостов грузится:


openssl version -a
OpenSSL 1.1.1k  FIPS 25 Mar 2021
built on: Wed Aug 31 14:57:14 2022 UTC
platform: linux-x86_64
...
engines:  rdrand dynamic gost

А вот кипхеров с оригинальной политикой нет:

ln -s  openssl.config.orig  openssl.config
# openssl ciphers | tr ":" "\n" | grep GOST

А вот с исправленой политикой они есть:

#ln -s openssl.config.new openssl.config
# openssl ciphers | tr ":" "\n" | grep GOST
GOST2012-GOST8912-GOST8912
GOST2001-GOST89-GOST89

Но ты прав, если удалить политику вовсе, то они тоже будут присутствовать.

Однако я прогнал через дифф все три вариата и вариант с отсутвтсием политики показлся мне излишне измененным. Между двумя наборами политик изменения товлько в двух гостовых кипхерх а при отсутствии политики удаляюстся и добавляются какое то ненормальное кличество оных.

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

diff -u  orig.log wo.log 
--- orig.log	2022-12-01 04:12:01.032516096 +0300
+++ wo.log	2022-12-01 04:11:25.123880027 +0300
@@ -3,52 +3,60 @@
 TLS_AES_128_GCM_SHA256
 ECDHE-ECDSA-AES256-GCM-SHA384
 ECDHE-RSA-AES256-GCM-SHA384
+DHE-RSA-AES256-GCM-SHA384
 ECDHE-ECDSA-CHACHA20-POLY1305
 ECDHE-RSA-CHACHA20-POLY1305
-ECDHE-ECDSA-AES256-CCM
+DHE-RSA-CHACHA20-POLY1305
 ECDHE-ECDSA-AES128-GCM-SHA256
 ECDHE-RSA-AES128-GCM-SHA256
-ECDHE-ECDSA-AES128-CCM
+DHE-RSA-AES128-GCM-SHA256
+ECDHE-ECDSA-AES256-SHA384
+ECDHE-RSA-AES256-SHA384
+DHE-RSA-AES256-SHA256
 ECDHE-ECDSA-AES128-SHA256
 ECDHE-RSA-AES128-SHA256
+DHE-RSA-AES128-SHA256
 ECDHE-ECDSA-AES256-SHA
 ECDHE-RSA-AES256-SHA
+DHE-RSA-AES256-SHA
 ECDHE-ECDSA-AES128-SHA
 ECDHE-RSA-AES128-SHA
+DHE-RSA-AES128-SHA
+RSA-PSK-AES256-GCM-SHA384
+DHE-PSK-AES256-GCM-SHA384
+RSA-PSK-CHACHA20-POLY1305
+DHE-PSK-CHACHA20-POLY1305
+ECDHE-PSK-CHACHA20-POLY1305
 AES256-GCM-SHA384
-AES256-CCM
+PSK-AES256-GCM-SHA384
+PSK-CHACHA20-POLY1305
+RSA-PSK-AES128-GCM-SHA256
+DHE-PSK-AES128-GCM-SHA256
 AES128-GCM-SHA256
-AES128-CCM
+PSK-AES128-GCM-SHA256
 AES256-SHA256
 AES128-SHA256
+ECDHE-PSK-AES256-CBC-SHA384
+ECDHE-PSK-AES256-CBC-SHA
+SRP-RSA-AES-256-CBC-SHA
+SRP-AES-256-CBC-SHA
+RSA-PSK-AES256-CBC-SHA384
+DHE-PSK-AES256-CBC-SHA384
+RSA-PSK-AES256-CBC-SHA
+DHE-PSK-AES256-CBC-SHA
+GOST2012-GOST8912-GOST8912
+GOST2001-GOST89-GOST89
 AES256-SHA
-AES128-SHA
-DHE-RSA-AES256-GCM-SHA384
-DHE-RSA-CHACHA20-POLY1305
-DHE-RSA-AES256-CCM
-DHE-RSA-AES128-GCM-SHA256
-DHE-RSA-AES128-CCM
-DHE-RSA-AES256-SHA256
-DHE-RSA-AES128-SHA256
-DHE-RSA-AES256-SHA
-DHE-RSA-AES128-SHA
-PSK-AES256-GCM-SHA384
-PSK-CHACHA20-POLY1305
-PSK-AES256-CCM
-PSK-AES128-GCM-SHA256
-PSK-AES128-CCM
+PSK-AES256-CBC-SHA384
 PSK-AES256-CBC-SHA
-PSK-AES128-CBC-SHA256
-PSK-AES128-CBC-SHA
-DHE-PSK-AES256-GCM-SHA384
-DHE-PSK-CHACHA20-POLY1305
-DHE-PSK-AES256-CCM
-DHE-PSK-AES128-GCM-SHA256
-DHE-PSK-AES128-CCM
-DHE-PSK-AES256-CBC-SHA
-DHE-PSK-AES128-CBC-SHA256
-DHE-PSK-AES128-CBC-SHA
-ECDHE-PSK-CHACHA20-POLY1305
-ECDHE-PSK-AES256-CBC-SHA
 ECDHE-PSK-AES128-CBC-SHA256
 ECDHE-PSK-AES128-CBC-SHA
+SRP-RSA-AES-128-CBC-SHA
+SRP-AES-128-CBC-SHA
+RSA-PSK-AES128-CBC-SHA256
+DHE-PSK-AES128-CBC-SHA256
+RSA-PSK-AES128-CBC-SHA
+DHE-PSK-AES128-CBC-SHA
+AES128-SHA
+PSK-AES128-CBC-SHA256
+PSK-AES128-CBC-SHA

Вот все отличия между двумя политиками. По моему, идеально.

[root@rhome-msk back-ends]# diff -u  orig.log new.log 
--- orig.log	2022-12-01 04:12:01.032516096 +0300
+++ new.log	2022-12-01 04:11:45.018921745 +0300
@@ -1,6 +1,8 @@
 TLS_AES_256_GCM_SHA384
 TLS_CHACHA20_POLY1305_SHA256
 TLS_AES_128_GCM_SHA256
+GOST2012-GOST8912-GOST8912
+GOST2001-GOST89-GOST89
 ECDHE-ECDSA-AES256-GCM-SHA384
 ECDHE-RSA-AES256-GCM-SHA384
 ECDHE-ECDSA-CHACHA20-POLY1305
AVL2 ★★★★★
()
Ответ на: комментарий от t184256

По поводу сути, я тут уже писал, что енгайн (движок) гостов подгружается при любой политике.

Но в целом ты прав, можно минимизировать изменения в оригинальном конфиге и использовать свой файл политик.

В начале файла /etc/pki/tls/openssl.cnf заменить:

#openssl_conf = default_modules
openssl_conf = openssl_def

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

В конец файла /etc/pki/tls/openssl.cnf добавить:

[openssl_def]
engines = engine_section

[engine_section]
gost = gost_section

[gost_section]
engine_id = gost
dynamic_path = /usr/lib64/engines-1.1/gost.so
#default_algorithms = ALL
#CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet
system_default = crypto_policy_gost

[ crypto_policy_gost ]
.include /etc/crypto-policies/back-ends/opensslcnf-gost.config

я закомментировал две строчки, но возможно они и нужны. Особенно набор параметров CRYPT_PARAMS.

И наконец, создать новый файл политик:

cat /etc/crypto-policies/back-ends/opensslcnf-gost.config 
@SECLEVEL=1:aGOST:aGOST01:kGOST:GOST94:GOST89MAC:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8

Таким образом, изменения в конфиге минимальны, вернуться к дефолтным можно изменив или раскоментарив единственную директиву

#openssl_conf = default_modules

И файл политик не перепишется дистрибутивным при обновлении.

Надеюсь, теперь ты доволен. ;)

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

ссылкой в /usr/share оно будет только при условии не-custom policies и отсутствии модификаций через local.d впридачу

Как видишь, это ссылка на /usr/share/crypto-policies/DEFAULT/openssl.txt

Ты прочел вообще, что я написал? Сделай update-crypto-policies --set DEFAULT:NO-CAMELLIA или выполни свое

cat > /etc/crypto-policies/local.d/openssl-gost.config <<EOF
openssl_conf = openssl_def
[engine_section]
gost = gost_section
... вся остальная твоя простыня ...
EOF
update-crypto-policies --set

и посмотри, какая это ссылка и куда.

И файл политик не перепишется дистрибутивным при обновлении.

Угу, и теперь я могу хоть уобновляться, изменения тебе не применятся.

Надеюсь, теперь ты доволен. ;)

Надеюсь клиенты твои довольны, что вместо чтения манов и применения штатных механизмов конфигурации ты креативишь какую-то дичь по живому. Нет чтобы скачать и применить GOST subpolicy или вариацию на ее тему, нет чтобы найти официальную документацию как вообще перестать использовать crypto-policies для openssl поддерживаемым способом, надо обязательно полезть куда попало и вписать туда что попало как попало. А то, что у них теперь апдейты больше не затрагивают конфигурацию и внезапно больше не запрещены какие-нибудь TLS 1.0 и RSA-ключи длиной 1024 бита, это ж тебе явно побоку.

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от t184256

Пафос понятен и даже отчасти оправдан, НО.

Это все вопросы к дистростроителям. И ответ прост, поддержки ГОСТ в дистрах просто нет. Даже в федоре. Ибо надпись недвусмыслена:

# Adds GOST algorithms.
# This is an example subpolicy, the algorithm names might differ in reality.

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

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

Вот казалось бы, была политика DEFAULT и мы делаем установку политики … DEFAULT.

update-crypto-policies --set DEFAULT

Что-то должно было измениться? Да вроде же нет?

Но нет, в /etc/crypto-policies/back-ends появилась ссылка на openssl.config

Упреждая вопросы, никаких файлов в local.d не добавлялось.

никаких ссылок на этот файл в конфигах openssl нет. Есть ссылка на мой файл, с гостами. Но эта явная ссылка идет нахуй, пока я не удалю этот новоприбывший конфиг openssl.config

Еще раз повторю, его не было и все работало! А политики применялись. А теперь есть и все настройки к черту. Предлагаешь это использовать?

На деле это выглядит так. Мы настраиваем сервер,уходим, а через неделю все летит к черту, причем абсолютно неявным образом…

AVL2 ★★★★★
()
Последнее исправление: AVL2 (всего исправлений: 1)
Ответ на: комментарий от psyapathy

Если эта, то нет, это просто демонстрация работы локальных политик.

GOST Engine не работает на OpenSSL 1.1.1k (Centos Stream 8) (комментарий)

Последний вариант, который вносит минимум изменений в конфиги состоит в следующем:

Все настройки энгайна кладем в отдельный файл.

# cat /etc/pki/tls/openssl-gost.conf 
openssl_conf = openssl_def

[openssl_def]
engines = engine_section

[engine_section]
gost = gost_section

[gost_section]
engine_id = gost
dynamic_path = /usr/lib64/engines-1.1/gost.so
default_algorithms = ALL
CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet

И включаем его в основной конфиг директивой .include

и комментарим блок старых настроек. По идее, достаточно закомментарить одну строчку

.include /etc/pki/tls/openssl-gost.conf
#openssl_conf = default_modules

но я комменталил всю цепочку блоков

#cat /etc/pki/tls/openssl.conf

...
.include /etc/pki/tls/openssl-gost.conf

#openssl_conf = default_modules
#[ default_modules ]
#ssl_conf = ssl_module
#[ ssl_module ]
#system_default = crypto_policy
#[ crypto_policy ]
#.include /etc/crypto-policies/back-ends/opensslcnf.config
...

Далее создаем политику

cat /etc/crypto-policies/back-ends/openssl.config 
@SECLEVEL=1:aGOST:aGOST01:kGOST:GOST94:GOST89MAC:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8

И ставим на нее бит неизменности

chattr +i  /etc/crypto-policies/back-ends/openssl.config

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

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

Спасибо большое за помощь и инструкцию! Теперь все работает!

Единственное так как chattr не сработал изначально из-за ссылки, я поставил +i на исходный файл

psyapathy
() автор топика
Admin