Pull to refresh

Comments 35

Не холивара ради, а образования для:
Гостовские сертификаты, кроме как на винде под IE, ещё где-нибудь поддерживаются?
Хм, а есть открытый (пускай и сторонний) плагин? Как-то немного нелогично в погоне за безопасностью ставить такие вот плагины…
UFO just landed and posted this here
Думаю маловероятно. ГОСТ ставят не для прикола, тут вся штука в слове 'сертификация', а на открытом откуда она появится? Кому не надо — тем и не надо :) используйте RSA-like и не парьте голову
Не задумываясь могу сказать, что браузеры использующие библиотеки openssl должны поддерживать ГОСТ сертификаты. А так же есть такой продукт как КриптоПРО Fox
>браузеры использующие библиотеки openssl
Опера?
Если нет, можете дать ссылку на такой браузер?

Опционально гост уже давно входит в состав openssl, а по-опыту — «вживую» я пользовал гостовское шифрование, вместе с выпиской и подписями сертификатов для организации vpn-тунелей (на том же openvpn — и под win и под фрёй и под прочими центосями :) ) — это обязательное условие при работе/передаче с персональных данных на территории РФ
А за границей сервер/концентратор с ГОСТ можно ставить?
Если этот сервер не будет участвовать в обработке/хранении или передаче персональных данных наших граждан, то никто не запрещает :)
А если как раз будет при трансграничной передаче?
Успокойтесь ;) У openssl нет сертификата ФСТЭК и ФСБ, так что хоть формально это и гост, но по бумагам это решение ничуть не лучше обычного https. Т.е. штрафануть вас могут в обоих случаях. Но если гост — ФСБшники могут закрыть глаза. Поможет только модель угроз/нарушителя где будет написано что ПДн общедоступные, например…
По поводу трансграничной передачи:
— делаете перевалочный сервак (если у вас, например, несколько отделений, где будет информация со всех отделений) на территории РФ, и шлите себе спокойно за границу.
Просто есть какое-то устойчивое мнение, что экспорт ГОСТ криптографии за границу запрещен, поэтому можно спокойно передавать ПДн трансгранично через обычный https (TLS), и этого в силу вышеупомянутого запрета достаточно.

Пытался найти обоснование — не нашел. Так и не понимаю до конца, можно ли передавать ПДн за границу через обычный https, если первичный ввод производится в БД в России, и данные никак не являются общедоступными.
Мое мнение:
есть 1119 пп и пункт 13г:
г) использование средств защиты информации, прошедших процедуру оценки соответствия
требованиям законодательства Российской Федерации в области обеспечения безопасности информации,
в случае, когда применение таких средств необходимо для нейтрализации актуальных угроз.

Т.е. если у вас актуальна угроза перехвата ПДн при передаче за границу, то вы сами себе злобные буратины и тогда привет сертифицированные СЗИ и СКЗИ в том числе. и повторюсь openssl вас в этом случае не спасет — бумажки нет.
Если угроза не актуальна (нет методики определения ущерба при разглашении, данные не очень критичные — типа ФИО и телефон и т.д. ) то речи о сертифицированных СЗИ не идет. таким образом и ФСБ требовать от вас госта не имеет права…
Может быть есть какие-то запреты за экспорт самой реализации ГОСТ за границу (как например в США во времена диффи и хелмана такое было) но тут я, увы, не подскажу…
Повторюсь, по возможности берите согласие что ПДн общедоступные… и не забудьте согласие на трансграничную передачу 3м лицам… и вы избавите себя от кучи бумажных проблем. Ну а защиту сделайте нормальными средствами и нормально :))) РЖД, ксттаи, так и поступает… ваши данные общедоступные… почему им можно а нам нет?
Вам могут сделать ата-та когда ФСБ придет вас проверять (если придет) и выяснит, что модель угроз написана некорректно. Но в этом случае у вас будет время на доработку и вы всегда можете поспорить — предъяви, например, некое экспертное заключение о том что эти угрозы признаны не актуальными, где экспертами может быть кто угодно…
Нет, в целом направление деятельности хорошее и правильное… реализация, как всегда, подкачала…
Использовать криптосредства можно, но в с соответствии указом президента России от 5 мая 2004 г. № 580 необходимо согласовать с ФСБ
Так вот как ключи теперь будут ФСБ передаваться) Понятненько
Поясните ход ваших мыслей, мистер Коломбо
А где в конфигах указан альтернативный сертификат от «китайских друзей»?
UFO just landed and posted this here
UFO just landed and posted this here
Постараюсь пояснить:
В строке директиве 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, который поддерживает браузер.

UFO just landed and posted this here
С тестовым стендом все в порядке, а вот ssllabs не смог закончить тестирование на 98% Assessment failed: Unsupported key algorithm: ECGOST3410
>Далее необходимо сконфигурировать OpenSSL для поддержки алгоритмов ГОСТ

правильно я понял, что вы использовали «чистый» OpenSSL, без отечественных модулей типа «КриптоПро CSP для nginx »?

Да. Но использование таких модулей возможно. Я уже протестировал работу с крипто про engine
А openssl из коробки, который в ubuntu 16.04 — openssl-1.0.2g-1ubuntu4.1, чем то не устроил? Чем вызвана необходимость сборки из исходников?
Да ничем, просто привычка свежие версии по на тестовом стенде всегда собирать из исходников. В статье я хотел осветить новые возможности появившиеся в связке nginx 1.11.0+openssl 1.0.2g, и я надеюсь, что статью не будут использовать как пошаговое руководство при пром. внедрении.

Если настроить системный OpenSSL на использование ГОСТовых алгоритмов, то глюки и странные сообщения об ошибках могут полезть из всех углов системы (я такое видел, хотя ничего страшного и не случилось), так что лучше системный OpenSSL не трогать.

Если настроить системный OpenSSL на использование ГОСТовых алгоритмов

как это настроить системный openssl на использование ГОСТовых алгоритмов? Я всегда думал, что алгоритмы, и поведение в целом, вы задаете в конкретной программе, которая использует openssl библиотеку. Например, postfix/nginx/apache/ssh и т.п. Т.е. вам никто не мешает в nginx отсавить возможность использовать sslv3, а в postfix запретить, конечно при условии что сама поддержка есть в openssl

Разве у openssl есть какой то глобальный конфигурационный файл, который влияет на работу всех программ, его использующих?

Да, есть. В Ubuntu находится по пути /etc/ssl/openssl.cnf и влияет на всю систему и все программы.

Этот файл конфигурирует утилиты командной строки, а не библиотеку.

Sign up to leave a comment.

Articles