Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline scherepanov  
#1 Оставлено : 14 августа 2017 г. 21:41:38(UTC)
scherepanov

Статус: Участник

Группы: Участники
Зарегистрирован: 11.08.2015(UTC)
Сообщений: 19
Российская Федерация
Откуда: Екатеринбург

Сказал(а) «Спасибо»: 4 раз
Добрый день!

В нашей системе используем для работы с ЭП на стороне сервера библиотеку CAdES из реализации Крипто ПРО JCP (версия 2.0, Java 8).

При проверке ЭП произошла следующая ситуация.

Для одного из сертификатов в цепочке первая точка распространения CRL в списке медленно обрабатывала запросы. Т.е. физически узел был доступен, но сервер висел. Другие 4 точки распростанения CRL, указанные в сертификате, по утверждению УЦ, обрабатывали запросы в штатном режиме.
При этом метод проверки ЭП зависал в ожидании ответа и не пытался использовать другие адреса по списку.

В итоге в логе приложения наблюдался следующий стек-трейс:

Код:

авг 14, 2017 12:20:08 PM ru.CryptoPro.reprov.certpath.URICertStore engineGetCRLs
WARNING: Exception fetching CRL:
java.security.cert.CRLException: Empty input
        at sun.security.provider.X509Factory.engineGenerateCRL(X509Factory.java:395)
        at java.security.cert.CertificateFactory.generateCRL(CertificateFactory.java:497)
        at ru.CryptoPro.reprov.certpath.URICertStore.engineGetCRLs(Unknown Source)
        at java.security.cert.CertStore.getCRLs(CertStore.java:181)
        at ru.CryptoPro.reprov.certpath.DistributionPointFetcher.a(Unknown Source)
        at ru.CryptoPro.reprov.certpath.DistributionPointFetcher.a(Unknown Source)
        at ru.CryptoPro.reprov.certpath.DistributionPointFetcher.a(Unknown Source)
        at ru.CryptoPro.reprov.certpath.CrlRevocationChecker.a(Unknown Source)
        at ru.CryptoPro.reprov.certpath.CrlRevocationChecker.a(Unknown Source)
        at ru.CryptoPro.reprov.certpath.CrlRevocationChecker.check(Unknown Source)
        at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125)
        at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:219)
        at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:140)
        at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:79)
        at java.security.cert.CertPathValidator.validate(CertPathValidator.java:292)
        at ru.CryptoPro.reprov.CPCertPathValidator.engineValidate(Unknown Source)
        at java.security.cert.CertPathValidator.validate(CertPathValidator.java:292)
        at ru.CryptoPro.CAdES.b.d.a.a(Unknown Source)
        at ru.CryptoPro.CAdES.b.d.a.a(Unknown Source)
        at ru.CryptoPro.CAdES.CAdESSigner.a(Unknown Source)
        at ru.CryptoPro.CAdES.CAdESSignature.a(Unknown Source)
        at ru.CryptoPro.CAdES.CAdESSignature.verify(Unknown Source)
...



Возможно, метод получения CRL в итоге отваливался по таймауту, но оценить его значение по логу не представляется возможным.

Далее, по утверждению УЦ, они устранили проблему с зависшим сервером. Но ошибка в нашем приложении осталась до перезапуска JVM.

Вопрос 1: Хотелось бы понять, как штатно должен вести себя JCP в описанной ситуации, задается ли какой-то таймаут для соединения с сервером CRL и можно ли им управлять?

Вопрос 2: То, что потребовался перезапуск JVM для восстановления работоспособности приложения - это следствие зависания соединения в ожидании ответа или результат кэширования данных предыдущих запросов (если все-таки таймаут есть), и можно ли этого избежать в будущем?
Offline basid  
#2 Оставлено : 15 августа 2017 г. 6:06:19(UTC)
basid

Статус: Активный участник

Группы: Участники
Зарегистрирован: 21.11.2010(UTC)
Сообщений: 1,037

Сказал(а) «Спасибо»: 7 раз
Поблагодарили: 140 раз в 126 постах
Автор: scherepanov Перейти к цитате
Вопрос 1: Хотелось бы понять, как штатно должен вести себя JCP в описанной ситуации, задается ли какой-то таймаут для соединения с сервером CRL и можно ли им управлять?
ЖТЯИ.00091-01 33 01. КриптоПро JCP. Руководство программиста. Общая часть
...
Для того, чтобы ограничить время подключения к хосту и чтения данных при
скачивании CRL по точкам CRLDP в сертификате, можно указать таймауты подключения
и чтения в секундах:
-Dcom.sun.security.crl.timeout=xxx // по умолчанию — 15 сек
-Dru.CryptoPro.crl.read_timeout=xxx // по умолчанию — 10 сек

P.S. Уж сколько раз твердили миру, что дока - рулез ...
thanks 1 пользователь поблагодарил basid за этот пост.
scherepanov оставлено 15.08.2017(UTC)
Offline scherepanov  
#3 Оставлено : 15 августа 2017 г. 13:13:41(UTC)
scherepanov

Статус: Участник

Группы: Участники
Зарегистрирован: 11.08.2015(UTC)
Сообщений: 19
Российская Федерация
Откуда: Екатеринбург

Сказал(а) «Спасибо»: 4 раз
Автор: basid Перейти к цитате

Для того, чтобы ограничить время подключения к хосту и чтения данных при
скачивании CRL по точкам CRLDP в сертификате, можно указать таймауты подключения
и чтения в секундах:
-Dcom.sun.security.crl.timeout=xxx // по умолчанию — 15 сек
-Dru.CryptoPro.crl.read_timeout=xxx // по умолчанию — 10 сек


Спасибо! Но если данные параметры явно не выставлены, то судя по документации применяются по умолчанию 15 сек и 10 сек, а не бесконечные. Значения по умолчанию нас устраивают. НО проблема у нас была в том, что висело не секунды, а несколько дней. Предположили, что таймауты были бесконечными, поэтому решили уточнить.
Offline Евгений Афанасьев  
#4 Оставлено : 15 августа 2017 г. 13:18:29(UTC)
Евгений Афанасьев

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 06.12.2008(UTC)
Сообщений: 3,910
Российская Федерация
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 685 раз в 646 постах
ru.CryptoPro.crl.read_timeout добавлен относительно недавно.
Offline scherepanov  
#5 Оставлено : 15 августа 2017 г. 16:12:46(UTC)
scherepanov

Статус: Участник

Группы: Участники
Зарегистрирован: 11.08.2015(UTC)
Сообщений: 19
Российская Федерация
Откуда: Екатеринбург

Сказал(а) «Спасибо»: 4 раз
Автор: afev Перейти к цитате
ru.CryptoPro.crl.read_timeout добавлен относительно недавно.


А можете подсказать с какой точно версии JCP данный параметр добавлен?
Offline Евгений Афанасьев  
#6 Оставлено : 15 августа 2017 г. 16:23:51(UTC)
Евгений Афанасьев

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 06.12.2008(UTC)
Сообщений: 3,910
Российская Федерация
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 685 раз в 646 постах
2016-09-28 КриптоПро JCP 2.0.38999
* jcp: добавлена возможность указать таймаут чтения CRL в JCPRevCheck (JCP-688)
thanks 1 пользователь поблагодарил Евгений Афанасьев за этот пост.
scherepanov оставлено 15.08.2017(UTC)
Offline scherepanov  
#7 Оставлено : 15 августа 2017 г. 20:06:16(UTC)
scherepanov

Статус: Участник

Группы: Участники
Зарегистрирован: 11.08.2015(UTC)
Сообщений: 19
Российская Федерация
Откуда: Екатеринбург

Сказал(а) «Спасибо»: 4 раз
Автор: scherepanov Перейти к цитате

Вопрос 2: То, что потребовался перезапуск JVM для восстановления работоспособности приложения - это следствие зависания соединения в ожидании ответа или результат кэширования данных предыдущих запросов (если все-таки таймаут есть), и можно ли этого избежать в будущем?


А можете еще по этому вопросу дать комментарии, пожалуйста?
Offline Евгений Афанасьев  
#8 Оставлено : 16 августа 2017 г. 9:36:58(UTC)
Евгений Афанасьев

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 06.12.2008(UTC)
Сообщений: 3,910
Российская Федерация
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 685 раз в 646 постах
Сложно сказать, с таким не сталкивались, возможно, "следствие зависания соединения в ожидании ответа".
Offline basid  
#9 Оставлено : 16 августа 2017 г. 10:20:03(UTC)
basid

Статус: Активный участник

Группы: Участники
Зарегистрирован: 21.11.2010(UTC)
Сообщений: 1,037

Сказал(а) «Спасибо»: 7 раз
Поблагодарили: 140 раз в 126 постах
Автор: scherepanov Перейти к цитате
судя по документации применяются по умолчанию 15 сек и 10 сек, а не бесконечные. Значения по умолчанию нас устраивают. НО проблема у нас была в том, что висело не секунды, а несколько дней.
Это уже другая проблема.
Приложение установило TCP-соединение с сервером и отправило HTTP-запрос. Сервер запрос принял, вероятно, отправил заголовки ответа и начал передавать данные, но завис. Если нет контроля "минимальной скорости передачи", то "висеть в ожидании данных" можно о-о-чень долго.
У HTTP-сервера такой контроль должен быть, но "сервер завис". Есть ли такой контроль на стороне клиента - неизвестно.
"По-моему так" (ц) Винни-Пух (голосом Евгения Леонова).

Отредактировано пользователем 16 августа 2017 г. 10:20:54(UTC)  | Причина: Не указана

Offline scherepanov  
#10 Оставлено : 16 августа 2017 г. 13:07:04(UTC)
scherepanov

Статус: Участник

Группы: Участники
Зарегистрирован: 11.08.2015(UTC)
Сообщений: 19
Российская Федерация
Откуда: Екатеринбург

Сказал(а) «Спасибо»: 4 раз
Автор: afev Перейти к цитате
Сложно сказать, с таким не сталкивались, возможно, "следствие зависания соединения в ожидании ответа".


Версия КриптоПро JCP на сервере у нас 2.0.38674, в которой получается НЕТ второго параметра (таймаута чтения данных -Dru.CryptoPro.crl.read_timeout)...
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.