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

Уведомление

Icon
Error

24 Страницы«<45678>»
Опции
К последнему сообщению К первому непрочитанному
Offline mstdoc  
#51 Оставлено : 21 декабря 2020 г. 15:42:51(UTC)
mstdoc

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

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

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 1 раз в 1 постах
Автор: Ситдиков Денис Перейти к цитате
Добрый день!
Нет, для cades это невозможно.

Как вариант, можно настроить OCSP службу: проверка по OCSP приоритетнее проверки по CRL.



Спасибо за ответ.
А можно более подробно, почему именно "невозможно" для cades?

Нельзя сделать вариант проверки типа "подпись была создана ключем именно этого сертификата, подпись валидна, но сам сертификат на отзыв не проверен"?

Проблема весьма актуальна, crl-серверы контрагентов лагают с завидной регулярностью.
Периодически эта же проблема возникает даже с crl минкомсвязи (http://reestr-pki.ru/cdp/guc_gost12.crl)
Offline Ситдиков Денис  
#52 Оставлено : 21 декабря 2020 г. 17:20:20(UTC)
Ситдиков Денис

Статус: Администратор

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

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 29 раз в 20 постах
>>Нельзя сделать вариант проверки типа "подпись была создана ключем именно этого сертификата, подпись валидна, но сам сертификат на отзыв не проверен"?
Значение подписи можно проверить с помощью объекта RawSignature. При этом, если подпись соответствует cades, то хэш считается не от данных, а от подписанных атрибутов. Вычислить это значение интерфейсом плагина не получится, можно воспользоваться низкоуровневым интерфейсом C.

При этом проверка значения подписи != проверка подписи в смысле требований законодательства.
Offline two_oceans  
#53 Оставлено : 22 декабря 2020 г. 11:08:47(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Вариант с OCSP замечателен, вот только не все УЦ их указывают в сертификате (плюс если не ошибаюсь, там может быть вопрос по сертификату самого ответчика). Склоняюсь к своеобразному "кэшированию" CRL на локальный сервер. Допустим на сутки или на час - как Вам кажется комфортнее. Далее устанавливать на компьютер или заворачивать запросы CRL на свой сервер, так будет гораздо "отзывчивее".

Вообще наверно Минкомсвязь можно и с большим интервалом проверять - отзывают лицензии УЦ не ежечасно. Также хотелось бы обратить на срок действия CRL - пока он не истек или не прошло хотя бы на 2/3 срока, формально Вы не обязаны скачивать новый.

Отредактировано пользователем 22 декабря 2020 г. 11:10:02(UTC)  | Причина: Не указана

Offline Ситдиков Денис  
#54 Оставлено : 22 декабря 2020 г. 12:09:27(UTC)
Ситдиков Денис

Статус: Администратор

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

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 29 раз в 20 постах
Да, вариант с собственным сервером тоже может подойти.

Цитата:
Вариант с OCSP замечателен, вот только не все УЦ их указывают в сертификате

Если адрес OCSP не указан в сертификате, его можно задать на проверяющей стороне.
Offline two_oceans  
#55 Оставлено : 22 декабря 2020 г. 12:41:40(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Автор: Ситдиков Денис Перейти к цитате
Если адрес OCSP не указан в сертификате, его можно задать на проверяющей стороне.
С этим я конечно не спорю, но хотел бы заметить, что ни один из УЦ, с которыми я встречался на работе, не указывает эти адреса утрированно говоря "крупными буквами на главной странице", то есть в перспективе это может обернуться обзвоном примерно 300 УЦ на предмет есть ли у них OCSP ответчик, не указанный в сертификате.

Отредактировано пользователем 22 декабря 2020 г. 12:42:13(UTC)  | Причина: Не указана

Offline Анатолий Беляев  
#56 Оставлено : 22 декабря 2020 г. 13:43:57(UTC)
Анатолий Беляев

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

Группы: Администраторы, Участники
Зарегистрирован: 24.11.2009(UTC)
Сообщений: 965
Откуда: Crypto-Pro

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 174 раз в 152 постах
Автор: two_oceans Перейти к цитате
Автор: Ситдиков Денис Перейти к цитате
Если адрес OCSP не указан в сертификате, его можно задать на проверяющей стороне.
С этим я конечно не спорю, но хотел бы заметить, что ни один из УЦ, с которыми я встречался на работе, не указывает эти адреса утрированно говоря "крупными буквами на главной странице", то есть в перспективе это может обернуться обзвоном примерно 300 УЦ на предмет есть ли у них OCSP ответчик, не указанный в сертификате.

Если OCSP реализован на стороне УЦ, то он обычно указан в сертификате. Службы которые отвечают на статусы сертификатов других УЦ, как правило, реализованы в самих площадках которые принимают "все квалифицированные" сертификаты. Тут есть вариант или интеллектуальный сервис которые следит за временем истечения CRL и отдельно их скачивает и обновляет или идти чуть дальше. Обновлять CRL все локально и построить на этом OCSP службу. Вопрос только в доверии этой OCSP службе, который, в рамках одной системы, вполне может быть решен.

Отредактировано пользователем 22 декабря 2020 г. 13:45:20(UTC)  | Причина: Не указана

Техническую поддержку оказываем тут.
Наша база знаний.
Наша страничка в Instagram.
thanks 1 пользователь поблагодарил Анатолий Беляев за этот пост.
two_oceans оставлено 23.12.2020(UTC)
Offline mstdoc  
#57 Оставлено : 22 декабря 2020 г. 14:50:30(UTC)
mstdoc

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

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

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 1 раз в 1 постах
У себя мы реализовали как раз вариант "кеширования" crl второй стороны и заворачивания всех запросов в сторону crl на свой собственный сервер.
НО.
Это очень большой костыль.
Это становится неудобно, когда количество "вторых сторон" увеличивается.
Сертификаты периодически обновляются, приходится следить за добавлением\удалением новых url crl.
Возникает очень много ручной работы, много мест в которых можно ошибиться.
Трудно настроить кеширование crl по расписанию, когда у какого-то УЦ nextupdate равен например сегодня 09:57, а в следующий раз 14:32.
Попадались случаи, когда nextupdate был около часа (не знаю насколько это соответствует стандартам, но прецеденты были)


Вообще ситуация довольно странная. Если взять в пример нашу ситуацию.
У нас больше 10 контрагентов.
Сертификаты у всех обновляются в разное время.
Количество запросов, которые требуют проверки подписи в пике достигает 100 в секунду.
При этом больше половины УЦ, которые выдавали сертификаты нашим контрагентам не имеют в составе сертификатов ссылки на ocsp.
Нет информации о ocsp и в сертификатах, выданных напрямую УЦ минкомсвязи
Понятно что для промежуточных сертификатов это менее актуально, но все же промежуточные сертификаты библиотека также проверяет на отзыв.

Как я указывал выше, сами url, по которым отдаются crl ОЧЕНЬ часто недоступны или отдаются с очень маленькой скоростью.
Очень часто глючат два из трех url crl минкомсвязи, со всеми вытекающими.
Все это в целом периодически вызывает образование просто диких очередей в проверке подписи и в такие моменты часть запросов просто отваливается по таймауту.
А имея все это в бизнес-процессах, критичных к времени обработки, получаем головную боль на ровном месте.
Мы фиксировали несколько случаев, когда в ситуации недоступности crl (отдавались просроченные) наши контрагенты отключали проверку подписи на своей стороне совсем (понятно что радикальный случай, но тем не менее случаи были).

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


Вопрос этот в целом касается не только данного расширения, но также и jcp и расширения для php.
Вопрос очень актуальный, сталкиваемся с ним постоянно не только мы, но почему-то в качестве решения только костыли...
Offline two_oceans  
#58 Оставлено : 23 декабря 2020 г. 13:39:40(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Да, все так.
По поводу добавления новых УЦ: если не ошибаюсь на e-trust.gosuslugi.ru есть выгрузка исчерпывающего списка с сертификатами и адресами. Можно ее разобрать и тогда не придется вручную добавлять адреса, боясь опечататься.

По разным интервалам УЦ: в принципе важно какой интервал Вам покажется безопасным. Списки отзыва по сути меняются при событии отзыва, а не по расписанию. Нет никакой гарантии, что следующий опубликованный через час список отзыва будет содержать хотя бы одно изменение и нет никакой гарантии, что изменение будет только одно. Поэтому на то расписание, которое предлагает УЦ можно просто начхать. Важно на какой риск в бизнес-процессах Вы готовы пойти. Чем больше интервал кэширования - тем больше риск, вот и все. Когда очередь большая можно интервал увеличивать.

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

У нас вот есть аккредитованный УЦ, который публикует списки отзыва раз в три месяца. Понятно что отзывы фактически происходят чаще, но те списки доступны только внутри сети, а в Интернете для сервиса проверки для МКС список меняется раз в три месяца. Замечательно, правда? Хоть каждые 10 минут можно проверять, но меняется вручную раз в 90 суток.

Еще вариант - вроде поднимали такую тему в связи с тем, что через 10 минут начинала тормозить проверка подписи - теоретически возможно неявно кэшировать результат проверки конкретного сертификата, то есть грубо говоря, запускать все подписи от одного клиента (контрагента) в отдельный поток, в котором уже будет "кэширован" в неких объектах КриптоПро результат от первой проверки сертификата клиента. Так повторная проверка будет без запроса списка отзыва. Тоже вроде можно было регулировать интервал до перепроверки списка, по умолчанию только 10-15 минут, но при большом потоке подписей одного клиента такой ход может очень даже снизить количество попыток скачивания CRL. Надо только разобраться какие объекты не уничтожать, а использовать повторно.

К сожалению, с веб-технологиями такое обычно не работает, так как веб-сервер периодически перезапускает рабочий процесс и это обычно чаще чем происходит повтор, но есть над чем подумать. При выполнении проверки внешней консольной программой очевидно тоже не работает, так как программа завершается после каждой проверке и освобождает объекты. Вот некая программа относительно постоянно висящая в памяти и разделяюшая подписи контрагентов по сертификатам в разные потоки (конкретный сертификат если уже был в каком-то потоке - то идет в него же, если сертификат попался первый раз - то создается новый поток) - хорошо бы подошла. Да, затратно по ресурсам, но плюс по скорости проверки. Для разумного баланса между ресурсами и скоростью, допустим, только раз в полчаса освобождать неиспользуемые потоки с "кэшированными" проверками конкретного сертификата (так как кэш уже истечет).
Offline mstdoc  
#59 Оставлено : 25 декабря 2020 г. 16:55:50(UTC)
mstdoc

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

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

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 1 раз в 1 постах
Автор: Ситдиков Денис Перейти к цитате
Да, вариант с собственным сервером тоже может подойти.

Цитата:
Вариант с OCSP замечателен, вот только не все УЦ их указывают в сертификате

Если адрес OCSP не указан в сертификате, его можно задать на проверяющей стороне.



Добрый день.

Просьба подсказать по нескольким вопросам.

1. Может ли данное расширение работать с ключами, на контейнеры которых установлен пароль?
2. Если нет, подскажите пожалуйста, методы в интерфейсе С, которые могут работать с такими запароленными контейнерами.
3. Как задать свой адрес ocsp-сервиса? Я правильно понимаю, что в таком случае проверка любой подписи, в сертификате которой не указан oscp, пойдет через этот "свой ocsp-сервис"?
4. Может ли так оказаться что после запроса в сторону своего ocsp-сервиса, продолжится проверка по crl спискам из сертификата подписи?
Offline bsoft  
#60 Оставлено : 28 декабря 2020 г. 7:43:53(UTC)
bsoft

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

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

Сказал(а) «Спасибо»: 11 раз
Добрый день!
Помогите разобраться с ошибкой. Пытаюсь подписать запрос для отправки в СМЭВ. При попытке подписать XML в режиме CADESCOM_XML_SIGNATURE_TYPE_TEMPLATE, получаю ошибку "An error was encountered while processing an XML digital signature"

Код:
import sys
sys.path.append(r'/path_to_pycades_so')
import pycades
from lxml import etree

store = pycades.Store()
store.Open(pycades.CADESCOM_CONTAINER_STORE, pycades.CAPICOM_MY_STORE, pycades.CAPICOM_STORE_OPEN_MAXIMUM_ALLOWED)
certs = store.Certificates
assert(certs.Count != 0), "Certificates with private key not found"

signer = pycades.Signer()
signer.Certificate = certs.Item(1)
signer.CheckCertificate = True

doc = etree.parse('test.txt', etree.XMLParser(encoding='ISO-8859-1', ns_clean=True, recover=True))

content_to_sign = etree.tostring(doc, pretty_print=False, encoding='unicode')

signedXML = pycades.SignedXML()
signedXML.Content = content_to_sign
#signedXML.SignatureType = pycades.CADESCOM_XML_SIGNATURE_TYPE_ENVELOPED | pycades.CADESCOM_XADES_BES
signedXML.SignatureType = pycades.CADESCOM_XML_SIGNATURE_TYPE_TEMPLATE | pycades.CADESCOM_XADES_BES
message = signedXML.Sign(signer)

print(message)


XML:

Код:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
                  xmlns:v2="http://history.smev.ru/v2/"
                  xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
                  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
	<soapenv:Header>
				<wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
			                          ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
			                          wsu:Id="CertId-0DA773FF46AF4146A6B28772356CBFC7">
			</wsse:BinarySecurityToken>
			<ds:Signature>
				<ds:SignedInfo>
					<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
					<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411"/>
					<ds:Reference URI="#BodyId-F6AC1DDCAC4D4FBF9078EEB332F502C4">
						<ds:Transforms>
							<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
						</ds:Transforms>
						<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr3411"/>
						<ds:DigestValue/>
					</ds:Reference>
				</ds:SignedInfo>
				<ds:SignatureValue>
				</ds:SignatureValue>
				<ds:KeyInfo>
					<wsse:SecurityTokenReference>
						<wsse:Reference URI="#CertId-0DA773FF46AF4146A6B28772356CBFC7"
						                ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
					</wsse:SecurityTokenReference>
				</ds:KeyInfo>
			</ds:Signature>
	</soapenv:Header>
	<soapenv:Body wsu:Id="BodyId-F6AC1DDCAC4D4FBF9078EEB332F502C4">
		<v2:newActionRequest>
			<v2:actionCode/>
			<v2:addAppId/>
			<v2:addAppIdCode/>
			<v2:addSocId/>
			<v2:addSocIdCode/>
			<v2:applicantId/>
			<v2:date/>
			<v2:empFio/>
			<v2:empId/>
			<v2:empJob/>
			<v2:finished/>
			<v2:fromIS/>
			<v2:innerId/>
			<v2:linkedAction/>
			<v2:name/>
			<v2:orgName/>
			<v2:ownerOrg/>
			<v2:rguId/>
			<v2:actionSoap>
				<v2:path/>
				<v2:length/>
				<v2:body/>
				<v2:name/>
			</v2:actionSoap>
			<v2:socId/>
			<v2:status/>
			<v2:statusDate/>
			<v2:toIS/>
			<v2:type/>
			<v2:uniqId/>
		</v2:newActionRequest>
	</soapenv:Body>
</soapenv:Envelope>
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
24 Страницы«<45678>»
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.