Статус: Участник
Группы: Участники
Зарегистрирован: 17.08.2018(UTC) Сообщений: 14  Сказал(а) «Спасибо»: 2 раз
|
Добрый день! Имеется приложение, использующее СКЗИ КриптоПро JCP 2.0.39014 (сертифицированная версия) В процессе установления защищенного соединения с двухсторонней аутентификацией закрывается соединение с ошибкой " javax.net.ssl.SSLException: Received fatal alert: DECODE_ERROR" При включенных логах JTLS с уровнем ALL имеем запись: Split, RECV TLSv1 ALERT: fatal, description = DECODE_ERRORФакт, что при смене JCP на версию 2.0.39442 при идентичных настройках TLS соединение устанавливается успешно. В changelog'ах версий из темыИз-за чего может происходить такая проблема и как это исправить, не уходя от использования сертифицированной версии? SSL логи приложил  ssl.log (15kb) загружен 4 раз(а).P.S. дополнительно проверил, что с КриптоПро JCP/JTLS 2.0.39267 так же работает. в чем разница между версиями 2.0.39442 и 2.0.39267? может быть что-то донастроить надо на клиентской/серверной стороне? Отредактировано пользователем 13 ноября 2018 г. 14:55:26(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 4,005 Откуда: Крипто-Про Сказал(а) «Спасибо»: 21 раз
Поблагодарили: 715 раз в 675 постах
|
Добрый день. С подобным не сталкивались, кроме того, ошибка получена с сервера (recv alert, а не send alert). Что установлено на сервере, есть возможность увидеть какие-либо сообщения на нем, в его журналах (возможно, там будет описание ошибки)? Изменения по cpSSL описаны в changelog, возможно, что-то было изменено в Код:
* tls: рефакторинг, добавлена поддержка ГОСТ TLS v. 1.1, 1.2, удалены сайфер-сюиты SSL3_CK_GVO_KB2, SSL3_CK_GVO (JCP-386)
* tls: клиент по умолчанию шлет длину подписи в CertificateVerify (JCP-779)
В скором времени будет выложена новая сертифицированная версия. Пока можно взять последнюю с сайта. |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 17.08.2018(UTC) Сообщений: 14 Сказал(а) «Спасибо»: 2 раз
|
Евгений, спасибо за ответ TLS-сессия терминируется посредством nginx-сервера со следующими параметрами: Код:
# GROUP
# SERVER: MAIN
server {
listen 10.10.10.10:443 ssl default_server reuseport;
ssl_certificate /opt/waf/conf/ssl/5be42319eb5321719f7df890;
ssl_certificate_key /opt/waf/conf/ssl/5be4232ceb5321013c683789;
ssl_ciphers "HIGH:MEDIUM:GOST2001-GOST89-GOST89:GOST2012-GOST8912-GOST8912";
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_verify_client on;
ssl_client_certificate /opt/waf/conf/ssl/5be42320eb5321013c683786;
ssl_dhparam /opt/waf/conf/dhparam.pem;
ssl_verify_depth 3;
}
В качестве реализация алгоритмов используется OpenSSL c криптографическим движком gost, набор библиотек: Код:(gost) Reference implementation of GOST engine
[gost89, gost89-cnt, gost89-cnt-12, gost89-cbc, grasshopper-ecb, grasshopper-cbc, grasshopper-cfb, grasshopper-ofb, grasshopper-ctr, md_gost94, gost-mac, md_gost12_256, md_gost12_512, gost-mac-12, gost2001, gost-mac, gost2012_256, gost2012_512, gost-mac-12]
В общем виде ошибка подключения в логах со стороны сервера выглядит следующим образом: Код:2018/11/13 10:17:34 [crit] 3548#0: *1778188 SSL_do_handshake() failed (SSL: error:1417B109:SSL routines:tls_process_cert_verify:wrong signature size) while SSL handshaking, client: ***.**.***.**, server: **.***.***.**:10090
PS Хотелось бы узнать, если возможно, о примерных сроках, когда станет доступна новая сертифицированная версия? Так как вы советуете взять последнюю версию сайта, правильно ли я понимаю, что у новой версии так же как и у КриптоПро JCP/JTLS 2.0.40109-A будет поддержка только java 10 и выше?
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 17.08.2018(UTC) Сообщений: 14 Сказал(а) «Спасибо»: 2 раз
|
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 4,005 Откуда: Крипто-Про Сказал(а) «Спасибо»: 21 раз
Поблагодарили: 715 раз в 675 постах
|
Судя по сообщению сервера, это исправление JCP-779 (Какая версия csp? Был момент, когда изменения вносились и в csp, и в jcp). Сертифицированная сборка будет и 2.0 для java 7-8, и 2.0-A для java 10 и выше. Сроки - до конца года. Отредактировано пользователем 13 ноября 2018 г. 19:42:12(UTC)
| Причина: Не указана |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 17.08.2018(UTC) Сообщений: 14 Сказал(а) «Спасибо»: 2 раз
|
csp со стороны сервера не используется
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 4,005 Откуда: Крипто-Про Сказал(а) «Спасибо»: 21 раз
Поблагодарили: 715 раз в 675 постах
|
Версия ngnix, gost engine, openssl? |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 17.08.2018(UTC) Сообщений: 14 Сказал(а) «Спасибо»: 2 раз
|
Nginx 1.6 OpenSSL 1.1.0f 25 May 2017 О Gost engine есть следующая информация: Код:# openssl engine -vv
(rdrand) Intel RDRAND engine
(dynamic) Dynamic engine loading support
SO_PATH: Specifies the path to the new ENGINE shared library
NO_VCHECK: Specifies to continue even if version checking fails (boolean)
ID: Specifies an ENGINE id name for loading
LIST_ADD: Whether to add a loaded ENGINE to the internal list (0=no,1=yes,2=mandatory)
DIR_LOAD: Specifies whether to load from 'DIR_ADD' directories (0=no,1=yes,2=mandatory)
DIR_ADD: Adds a directory from which ENGINEs can be loaded
LOAD: Load up the ENGINE specified by other settings
(gost) Reference implementation of GOST engine
CRYPT_PARAMS: OID of default GOST 28147-89 parameters
PBE_PARAMS: Shortname of default digest alg for PBE
# openssl engine -c
(rdrand) Intel RDRAND engine
[RAND]
(dynamic) Dynamic engine loading support
(gost) Reference implementation of GOST engine
[gost89, gost89-cnt, gost89-cnt-12, gost89-cbc, grasshopper-ecb, grasshopper-cbc, grasshopper-cfb, grasshopper-ofb, grasshopper-ctr, md_gost94, gost-mac, md_gost12_256, md_gost12_512, gost-mac-12, gost2001, gost-mac, gost2012_256, gost2012_512, gost-mac-12]
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 4,005 Откуда: Крипто-Про Сказал(а) «Спасибо»: 21 раз
Поблагодарили: 715 раз в 675 постах
|
Если опираться на дату 25 May 2017, то исправление JCP-779 вошло в версию JCP 2.0.39267 28/06/2017, то есть позднее (и его нет в 2.0.39014 от 04/10/2016). |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 17.08.2018(UTC) Сообщений: 14 Сказал(а) «Спасибо»: 2 раз
|
Евгений, может я что-то не понял. Объясните, пожалуйста, как коррелирует версия openssl, которая датируется 25.05.17, с версией JCP, в которую вошло исправление JCP-779?
Openssl стоит со стороны сервера, с клиентской стороны - JCP. Мне казалось, что это два независимых продукта.
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
