Comments 35
Гостовские сертификаты, кроме как на винде под IE, ещё где-нибудь поддерживаются?
По поводу трансграничной передачи:
— делаете перевалочный сервак (если у вас, например, несколько отделений, где будет информация со всех отделений) на территории РФ, и шлите себе спокойно за границу.
Пытался найти обоснование — не нашел. Так и не понимаю до конца, можно ли передавать ПДн за границу через обычный https, если первичный ввод производится в БД в России, и данные никак не являются общедоступными.
есть 1119 пп и пункт 13г:
г) использование средств защиты информации, прошедших процедуру оценки соответствия
требованиям законодательства Российской Федерации в области обеспечения безопасности информации,
в случае, когда применение таких средств необходимо для нейтрализации актуальных угроз.
Т.е. если у вас актуальна угроза перехвата ПДн при передаче за границу, то вы сами себе злобные буратины и тогда привет сертифицированные СЗИ и СКЗИ в том числе. и повторюсь openssl вас в этом случае не спасет — бумажки нет.
Если угроза не актуальна (нет методики определения ущерба при разглашении, данные не очень критичные — типа ФИО и телефон и т.д. ) то речи о сертифицированных СЗИ не идет. таким образом и ФСБ требовать от вас госта не имеет права…
Может быть есть какие-то запреты за экспорт самой реализации ГОСТ за границу (как например в США во времена диффи и хелмана такое было) но тут я, увы, не подскажу…
Повторюсь, по возможности берите согласие что ПДн общедоступные… и не забудьте согласие на трансграничную передачу 3м лицам… и вы избавите себя от кучи бумажных проблем. Ну а защиту сделайте нормальными средствами и нормально :))) РЖД, ксттаи, так и поступает… ваши данные общедоступные… почему им можно а нам нет?
Нет, в целом направление деятельности хорошее и правильное… реализация, как всегда, подкачала…
В строке директиве ssl_ciphers с лева на право перечисляются допустимые алгоритмы шифрования. В данном случае самым приоритетным (левым) указан алгоритм GOST2001-GOST89-GOST89, далее указаны алгоритмы HIGH — это ключевое слово указывает алгоритмы с длиной ключа более 128 бит, и MEDIUM — алгоритмы с длиной ключа 128 бит. Получается, что сначала NGINX предложит построить https соединение по ГОСТ, если отказались то RSA-like.
Ещё: при SSL-хэндшейке браузер отправляет серверу список алгоритмов шифрования, которые он поддерживает и браузер с сервером выбирают алгоритм, из пересечения этих списков. Тут в дело вступает директива ssl_prefer_server_ciphers on;
, которая и заставляет выбирать GOST2001-GOST89-GOST89, если браузер его поддерживает, поскольку в директиве ssl_ciphers
он стоит первым, т.е. имеет наивысший приоритет. Если браузер его не поддерживает, то выбирается первый алгоритм из списка HIGH
, который поддерживает браузер.
Кстати, а что про ваш сервер говорит SSL Test? Не падает ли случаем, какую оценку выдаёт, проверьте :-) https://www.ssllabs.com/ssltest/
правильно я понял, что вы использовали «чистый» OpenSSL, без отечественных модулей типа «КриптоПро CSP для nginx »?
Если настроить системный OpenSSL на использование ГОСТовых алгоритмов, то глюки и странные сообщения об ошибках могут полезть из всех углов системы (я такое видел, хотя ничего страшного и не случилось), так что лучше системный OpenSSL не трогать.
Если настроить системный OpenSSL на использование ГОСТовых алгоритмов
как это настроить системный openssl на использование ГОСТовых алгоритмов? Я всегда думал, что алгоритмы, и поведение в целом, вы задаете в конкретной программе, которая использует openssl библиотеку. Например, postfix/nginx/apache/ssh и т.п. Т.е. вам никто не мешает в nginx отсавить возможность использовать sslv3, а в postfix запретить, конечно при условии что сама поддержка есть в openssl
Разве у openssl есть какой то глобальный конфигурационный файл, который влияет на работу всех программ, его использующих?
Универсальный https c использованием ГОСТ сертификата