Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 14,211   Сказал «Спасибо»: 622 раз
Поблагодарили: 2399 раз в 1888 постах
|
pharaon написал:Андрей * написал:binGO написал:Ладно вопрос другой.
Сертификаты для SSL должны соответствовать (формально и\или по фактической структуре) формату X.509 ? Да. К чему этот вопрос? интересно, а будет время когда в хранилище доверенных корневых ОС и браузеров будет квалифицированный корневой минкомсвязи на госте. Такой как на снимке? или для TLS? Отредактировано пользователем 12 ноября 2012 г. 20:37:46(UTC)
| Причина: Не указана Вложение(я):  cert.zip (176kb) загружен 13 раз(а).У Вас нет прав для просмотра или загрузки вложений. Попробуйте зарегистрироваться. |
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 23.11.2010(UTC)
Сообщений: 162
Откуда: НН
Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 16 раз в 13 постах
|
Андрей * написал:pharaon написал:Андрей * написал:binGO написал:Ладно вопрос другой.
Сертификаты для SSL должны соответствовать (формально и\или по фактической структуре) формату X.509 ? Да. К чему этот вопрос? интересно, а будет время когда в хранилище доверенных корневых ОС и браузеров будет квалифицированный корневой минкомсвязи на госте. Такой как на снимке? или для TLS? Можно и его А уже через кроссы ДУЦ выпустили бы tls
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 18.06.2008(UTC)
Сообщений: 230
Откуда: Москва
Сказал(а) «Спасибо»: 2 раз
Поблагодарили: 40 раз в 28 постах
|
Просто для инфы, например, в Европе, инфраструктуры доступа (TLS/SSL) и инфраструктуры подписи (квалифицированные сертификаты) разведены в разные стороны и под каждую есть своя нормативка и свои регламенты. Наверное есть смысл в том чтобы использовать ключи по назначению, а не для всего попало куда всунуть можно. И это наверное было бы логичнее, поскольку требования к ключам шифрования и подписи разные, например, при шифровании правильнее делать депозит ключей чтобы безвозвратно не потерять зашифрованные данные, при подписи - эта процедура - лишняя дыра для компрометации.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 23.11.2010(UTC)
Сообщений: 162
Откуда: НН
Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 16 раз в 13 постах
|
Sergey M. Murugov написал:Просто для инфы, например, в Европе, инфраструктуры доступа (TLS/SSL) и инфраструктуры подписи (квалифицированные сертификаты) разведены в разные стороны и под каждую есть своя нормативка и свои регламенты. Наверное есть смысл в том чтобы использовать ключи по назначению, а не для всего попало куда всунуть можно. И это наверное было бы логичнее, поскольку требования к ключам шифрования и подписи разные, например, при шифровании правильнее делать депозит ключей чтобы безвозвратно не потерять зашифрованные данные, при подписи - эта процедура - лишняя дыра для компрометации. И что? один УЦ не может выпускать разные ВИДЫ сертификатов? Его то сертификат имеет все политики применения.
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 27.09.2010(UTC)
Сообщений: 19
Сказал(а) «Спасибо»: 1 раз
|
Возможно ошибаюсь в рассуждениях.... Но скажите, как посмотреть на чём реально происходит шифрование (при использовании CSP) при использовании SSL ? Первоначальное рукопожатие (обмен сертификатами, договорённость о протоколах и т.д.) это одно, но ведь дальнейшее шифрование проходит на сеансовых ключах? Т.е. стороны обменялись сертификатами с открытыми ключами, изданными по ГОСТ, всё хорошо, но дальше начинается согласование протокола шифрования для работы. Как можно посмотреть до какого криптопротокола они "договорились"? Отредактировано пользователем 5 января 2013 г. 11:55:53(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 14,211 Сказал «Спасибо»: 622 раз
Поблагодарили: 2399 раз в 1888 постах
|
Автор: binGO  Возможно ошибаюсь в рассуждениях.... Но скажите, как посмотреть на чём реально происходит шифрование (при использовании CSP) при использовании SSL ? Первоначальное рукопожатие (обмен сертификатами, договорённость о протоколах и т.д.) это одно, но ведь дальнейшее шифрование проходит на сеансовых ключах? Т.е. стороны обменялись сертификатами с открытыми ключами, изданными по ГОСТ, всё хорошо, но дальше начинается согласование протокола шифрования для работы. Как можно посмотреть до какого криптопротокола они "договорились"? До этого? p.s. Главная > Продукты > СКЗИ «КриптоПро CSP/TLS/JCP»\КриптоПро TLS не достаточно описания? Отредактировано пользователем 5 января 2013 г. 17:59:21(UTC)
| Причина: ссылки |
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 18.06.2008(UTC)
Сообщений: 230
Откуда: Москва
Сказал(а) «Спасибо»: 2 раз
Поблагодарили: 40 раз в 28 постах
|
1. В Европе квалифицированные сертификаты применимы ТОЛЬКО для подписи и при организации соединения не участвуют. Основание - правовые нормы, утверждённые профили и стандарты. Тут можно много писать ...
2. TLS на ГОСТ вполне работает и действительно всё работает по ГОСТ, более того вполне работают практически системы, построенные на провайдерах различных вендоров, мы к примеру вообще на PKCS#11 работаем и всём меж собой совместимо и именно с ГОСТ.
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 27.09.2010(UTC)
Сообщений: 19
Сказал(а) «Спасибо»: 1 раз
|
Автор: Андрей * До этого. Автор: Андрей * В данном случае вопрос не в полноте теории, а в возможности это увидеть на практике. Берём простой случай - односторонний SSL. На сервер ставим сертификат от КриптоПРО. На клиенте по идее кроме ПО (браузер), понимающего HTTPS ничего не надо. В браузере вбиваем HTTPS://.... Сервер отправляет клиенту свой сертификат (по идее это д.б. серт. от КриптоПРО) с открытым ключом, клиент формирует сеансовый ключ, зашифровывает его на полученном ОК сервера (ассимитричное шифрование), отправляет на сервер. Сервер расшифровывает (используя свой секретный ключ) полученный сеансовый ключ. На данном сеансовом ключе начинается потоковое шифрование данных в канале (симметричное шифрование). Криптоалгоритм, который будет использоваться для симметричного шифрования определяется предварительно на этапе handshake. Грубо говоря клиент направляет серверу информацию о поддерживаемых алгоритмах, из того что пересекается с перечнем алгоритмов поддерживаемых сервером выбирается самый strong. Как можно убедится, что выбран алгоритм на российской криптографии ?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы
Зарегистрирован: 12.12.2007(UTC) Сообщений: 6,462 Откуда: КРИПТО-ПРО Сказал «Спасибо»: 39 раз
Поблагодарили: 751 раз в 646 постах
|
В IE есть в меню Файл Свойства информация об алгоритме шифрования. |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 27.09.2010(UTC)
Сообщений: 19
Сказал(а) «Спасибо»: 1 раз
|
Автор: maxdm В IE есть в меню Файл Свойства информация об алгоритме шифрования. Можно поточнее. У меня IE9, в меню Сервис => Файл никакой информации нет. В Сервис => Свойства обозревателя также ничего не попадается.
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
