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

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline SovereignSun1989  
#1 Оставлено : 17 мая 2022 г. 9:36:54(UTC)
SovereignSun1989

Статус: Новичок

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

Здравствуйте,

Подскажите, необходимо из Java сервиса сделать TLS SSL соединение с другим сервисом (интеграция с компанией).

  • Что лучше использовать Java CSP или JCP и как в этом случае работать с PFX ключом? Можно ли из Java CSP просто из keystore забрать и создать безопасное подключение?
  • Нужно ли помещать сертификат в контейнер и как в такой случае в CSP создать контейнер из сертификата PFX?
  • Как сертификат подключить к HTTPS и как к нему в таком случае обращаться?

И в дополнение вопрос:

Какие различия между CryptoPro Java CSP и CryptoPro JCP?

Отредактировано пользователем 17 мая 2022 г. 9:56:10(UTC)  | Причина: Не указана

Offline two_oceans  
#2 Оставлено : 17 мая 2022 г. 11:54:57(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Добрый день.
Вопрос лучше задать в разделе, посвященном Java, там ответят быстрее и точнее. Там также много информации по вопросу.
Не хочу вводить в заблуждение неверными деталями, очень кратко про различия: один из криптопровайдеров самостоятельный со своей лицензией, а другой скорее надстройка над "обычным" КриптоПро CSP. Соответственно, надстройка может не работать в изолированном контейнере. Также только один из них поддерживает pfx в качестве хранилища ключей/сертификатов.

С другой стороны, контейнеры в формате КриптоПро подойдут замечательно. Важно помнить, что КриптоПро принципиально не выдаст программе настоящий закрытый ключ, вместо него в качестве "закрытого ключа" в классе PrivateKey фигурирует временный дескриптор. Проще будет понять по аналогии с раздевалкой - пальто (pfx или контейнер) сдали (установили) в гардероб (хранилище), получили номерок (либо алиас при установке, либо потом по алиасу дескриптор). Когда нужно подписать или еще как пользоваться ключом - показываете "номерок", криптопровайдер делает операцию с тем "пальто" (pfx или контейнером), для которого номерок. Сохранить номерок в качестве закрытого ключа бессмысленно, как только дескриптор закрыт будет ошибка (номерком не оденешься). Проталкнуть настоящий закрытый ключ (пальто) вместо номерка тоже не выйдет. Это также значит прикладная программа не сможет произвольно конвертировать pfx в контейнер и обратно, конвертация идет утилитами из комплекта криптопровайдера КриптоПро CSP.

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

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

Отредактировано пользователем 17 мая 2022 г. 11:56:40(UTC)  | Причина: Не указана

Offline SovereignSun1989  
#3 Оставлено : 18 мая 2022 г. 17:07:51(UTC)
SovereignSun1989

Статус: Новичок

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

Задача поставлена так:

Защита канала связи сертифицированным каналообразующим оборудованием или программными средствами по протоколу TLS (v.1.0 RFC 2246) с использованием криптографических алгоритмов ГОСТ в режиме односторонней аутентификации.

Вот что может быть этим сказано?
Offline two_oceans  
#4 Оставлено : 18 мая 2022 г. 20:45:22(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Автор: SovereignSun1989 Перейти к цитате
Задача поставлена так:
Защита канала связи сертифицированным каналообразующим оборудованием или программными средствами по протоколу TLS (v.1.0 RFC 2246) с использованием криптографических алгоритмов ГОСТ в режиме односторонней аутентификации.
Вот что может быть этим сказано?
Явно списано из какого-то нормативного документа, к которым еще и словарики терминов прилагаются. Ну ясно, как минимум, что у сервера будет сертификат гост и что они не сильно идут в ногу со временем раз еще 1.0 (и это лишний источник головной боли если они отклоняют 1.1 и 1.2). От Вас сертификат получается не требуют (иначе была бы двусторонняя аутентификация), просто при установке соединения в список поддерживаемых с Вашей стороны шифросьютов должен попасть гост. Так что Вы зря уже собрались работать с ключами.

Что до остального: вопрос в основном с какого места начинается канал связи и сертифицированность средств. Например, при использовании криптошлюза (стуннел) соединение как раз может быть защищено "программными средствами по протоколу TLS с использованием криптографических алгоритмов ГОСТ в режиме односторонней аутентификации". TLS 1.0 обычно проблем не вызывает, могут быть особенности если потребуется прям совсем отключить версии TLS новее. Если расположить стуннел на том же сервере, где Ваш сервис и слушать стуннелом 127.0.0.1, то "пролезть в канал" смогут только программы из этого же сервера.

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

При собственной реализации соединения промежутка конечно нет, но хоть и на основе КриптоПро, вопросы сертификации окончательно не снимаются (классы Джава в той или иной степени допускают изменение - если что-то нельзя поменять прямо, то дубликат кода с небольшими изменениями создать возможно).

Со стуннелом тоже была проблема о сертифицированности под Windows, однако было сообщение что одна из версий стуннела включена в сертифицированную версию КриптоПро CSP на Windows. Под *nix такое было и раньше, но там сейчас может требоваться отдельная лицензия. Другими словами, при использовании именно этих версий (а не просто какого-то стуннел, скачанного из интернета) требование "сертифицированности" также формально удовлетворено. Если склонитесь к этому подходу, стоит написать какую-то бумажку, что решение удовлетворяет требованиям задачи при использовании конкретной версии того и конкретной версии этого, может даже указать хэш-суммы файлов.

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

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