CRM-система для УК и ТСЖ

Поддержка длинных строк

Будете спамить рекламой - будем нещадно банить)))
Сообщение
Автор
two_oceans
Бывалый
Сообщений: 438
Зарегистрирован: 30 сен 2016, 17:17
Благодарил (а): 386 раза
Поблагодарили: 351 раза

Поддержка длинных строк

#11 Сообщение two_oceans » 18 июл 2017, 08:06

Sergey Cheban писал(а):Источник цитатыВот не надо так делать. Надо - понимать, кто в каком формате данные получает и предоставляет, и переворачивать правильным образом.
Ну, потому и стоит смайлик, что "вредный совет". Про четко прописанные форматы и речи как бы нет, я не говорю, что после переворота и второй проверки подпись следует принять, но вывод ошибки "Похоже использован неверный endian, используйте big endian, определенный по стандарту" был бы более информативен для начинающих разбираться в теме (и копирующих примеры, не понимая их), чем просто "Плохая подпись".

Хотя, например, не понятно почему XMLDSIG, в котором почти все указывается параметрами (хотя для некоторых допустимое значение определено только одно! как для кодировки - Base64) не требует указывать big-endian явно в DigestValue и SignatureValue, а жестко определяет порядок байтов в базовом типе. Это бы тоже натолкнуло копирующих примеры (без чтения правильного, но мозгодробительного стандарта) на правильные мысли. Сетевой порядок байтов - это конечно хорошо, но фактически под win32 на intel x86-x64 программисты сталкиваются с ним главным образом при кодировании ip-адреса (и там он воспринимается скорее как "плагиат реализации IP протокола с линуха"). И наверно все, навскидку не припомню других широко распространенных применений.
А вот про "самописные" форматы, которыми славятся российские программы, вообще мрак.

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

Еще момент, который тоже хочется "перебрать" - возможность нахождения в контейнере 2 пар ключей: одна - типа AT_SIGNATURE, другая типа AT_KEYEXCHANGE. Формально первый тип предназначен для подписи, второй для согласования ключей. cryptoapi требует их указания и выдает ошибку, если такого типа в контейнере нет. КриптоПро их тоже различает и позволяет засунуть в один контейнер. Вот только: 1) могу ошибаться, но криптофункциям ГОСТ похоже все равно на тип ключа, подписывает ключом AT_KEYEXCHANGE без проблем; 2) пока не встречал контейнера КриптоПро c 2 ключами или контейнера с AT_SIGNATURE. Из объяснения (ссылка ниже) смутно понял, что AT_SIGNATURE имеет ряд ограничений использования в приложениях Майкрософт. С другой стороны, прописывать в программе AT_KEYEXCHANGE неправильно, вдруг встретится контейнер с AT_SIGNATURE. Пока указал AT_KEYEXCHANGE, но раздумываю может быть, помимо указания только одного типа, ввести ли для библиотеки значения вроде KEYEXCHANGE_FIRST и SIGNATURE_FIRST, позволяющие указывать предпочитаемый и при этом перебирать ключ второго типа, если предпочитаемый не нашелся. Коллеги, какие мысли на этот счет?
... US crypto exporting restrictions were only regarding strength of encryption keys but not signature keys. Microsoft was required to provide prove to the government that they never allow signature keys to be used for encryption purposes before they were allowed to ship Microsoft encryption modules with Windows. ... This all is explanation of why you get keyusage restrictions with Microsoft CSP, but not with thirdparty CSP.Ссылка
Похоже история тянется со времен, когда были ограничения экспортной криптографии в США и с российскими криптопровайдерами не связана.

Открываю сертификат через ASN.1 Editor, в нем есть ветка с ключом, для нее указан OID 1.2.643.2.2.19 (ГОСТ Р 34.10-2001, алгоритм подписи, открытый ключ), параметры: 1.2.643.2.2.36.0 (ГОСТ Р 34.10-2001, алгоритм подписи, параметры обмена по умолчанию), 1.2.643.2.2.30.1 (ГОСТ Р 34.11-94, хэш функция, параметры по умолчанию). Алгоритм хэша ГОСТ Р 34.11-94 (OID 1.2.643.2.2.9), в сертификате не виден. В целом алгоритм хэша/подписи ГОСТ Р 34.11-94/34.10-2001 имеет OID 1.2.643.2.2.3, указан в самом начале сертификата.
Как я понимаю, 1.2.643.2.2.36.0 - это как раз парамсет (в данном случае exA) и по слову "обмена" похоже цифра 36 помимо прочего как раз указывает, что это ключ обмена, то есть AT_KEYEXCHANGE. В примере настроек OpenSSL парамсет указан как A, по аналогии - это AT_SIGNATURE. Выходит если в программе жестко прописать AT_KEYEXCHANGE, то будет беда с ключами сгенерированными в OpenSSL? Попробовать считывать из сертификата парамсет и по нему определяться какой ключ?

Не разобрался еще вот с чем - получаю hcryptprov с пустым ключом и флагом VERIFY_CONTEXT и создаю хэш, запрашиваю CryptGetHashParam с кодом HP_OID (0xA) и получаю "1.2.643.2.2.30.1" и по параметрам хэша КриптоПро контрольные значения совпадают. Тут и тут утверждается, что если возвращает "1.2.643.2.2.30.1" то все вообще окей, а иначе надо устанавливать при проверке хэша/подписи то же значение параметров, что было при вычислении хэша/подписи. На форуме КриптоПро то же самое пишут.
Вопрос: а что указывать, если в сертификате окажется другое значение параметров хэша.. значение из сертификата только на проверку самого сертификата распространяется или на все операции с сертификатом? Ну в смысле вычисление хэша конечно идет без участия ключей и сертификата, но если хэш потом нужно подписать и приложить сертификат, то не будут ли параметры хэша для проверки считаны из сертификата? Значит их наверно нужно синхронизировать с сертификатом при вычислении подписи и проверке подписи. А что с другими хэшами в XMLDSIG - тоже согласовывать по сертификату? Итого: похоже все работают на параметрах по умолчанию и если их изменить вылезет масса недоработок в различном ПО, входящем в цепочку передачи данных.

Sergey Cheban
Стажер
Сообщений: 112
Зарегистрирован: 05 ноя 2016, 07:45
Благодарил (а): 55 раза
Поблагодарили: 60 раза

Поддержка длинных строк

#12 Сообщение Sergey Cheban » 18 июл 2017, 19:52

two_oceans писал(а):но вывод ошибки "Похоже использован неверный endian, используйте big endian, определенный по стандарту" был бы более информативен для начинающих разбираться в теме (и копирующих примеры, не понимая их), чем просто "Плохая подпись".

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

two_oceans писал(а):Хотя, например, не понятно почему XMLDSIG, в котором почти все указывается параметрами (хотя для некоторых допустимое значение определено только одно! как для кодировки - Base64) не требует указывать big-endian явно в DigestValue и SignatureValue, а жестко определяет порядок байтов в базовом типе.

Ну... Формат такой. Посмотрите на число 1234. Это и для нас тысяча двести тридцать четыре, и для евреев, которые пишут справа налево. Как-то обходимся без явного указания, в какую сторону число надо читать.

two_oceans писал(а):Сетевой порядок байтов - это конечно хорошо, но фактически под win32 на intel x86-x64 программисты сталкиваются с ним главным образом при кодировании ip-адреса (и там он воспринимается скорее как "плагиат реализации IP протокола с линуха"). И наверно все, навскидку не припомню других широко распространенных применений.

Навскидку - посмотрите на byte order mark, позволяющий отличить little-endian utf-16 от big-endian utf-16.
Но вообще byte order - это большой головняк. Представьте себе крупную компанию, в которой исторически используется big-endian железо, которое пишет данные на диски в своём родном формате. А теперь представьте, что руководство этой компании интересуется: "А не перейти ли нам с этого железа на обычные x86? Перекомпилировать исходники под другую платформу, и подключить к ней имеющиеся диски". И вот тут выясняется, что перекомпилировать мало, надо ещё везде расставить забытые при разработке ntohs и htons, чтобы работало.

two_oceans писал(а):Еще момент, который тоже хочется "перебрать" - возможность нахождения в контейнере 2 пар ключей: одна - типа AT_SIGNATURE, другая типа AT_KEYEXCHANGE. Формально первый тип предназначен для подписи, второй для согласования ключей.

Я не в теме, но гугл подсказал, что не совсем так:
http://cpdn.cryptopro.ru/content/csp40/ ... 017bf.html
AT_KEYEXCHANGE - "Предназначена для обмена сессионными ключами и ЭЦП", AT_SIGNATURE - "Предназначена для ЭЦП".


two_oceans писал(а):Тут и тут утверждается, что если возвращает "1.2.643.2.2.30.1" то все вообще окей, а иначе надо устанавливать при проверке хэша/подписи то же значение параметров, что было при вычислении хэша/подписи. На форуме КриптоПро то же самое пишут.
Вопрос: а что указывать, если в сертификате окажется другое значение параметров хэша.

Я опять же не в теме, но сдаётся мне, что правильно будет отказаться принимать такой сертификат от греха подальше: если мы будем принимать разные параметры криптоалгоритма, то злоумышленник сможет предложить нам наименее криптостойкие параметры.
Вообще, фраза "Сообщество российских разработчиков СКЗИ согласовало используемые в Интернет параметры ГОСТ Р 34.11-94, см. RFC 4357" (отсюда) вызывает у меня недоумение. Но - имеем что имеем.

И ещё: https://www.cryptopro.ru/news/2017/06/o ... lya-2017-g
Обращаем внимание, что в связи с требованиями ФСБ России, сопряженными с запретом использования ГОСТ Р 34.10-2001 для формирования подписи после 1 января 2019 года (источник), с 1 июля 2017 года в КриптоПро CSP версий 3.9 и 4.0, а также КриптоПро JCP 2.0 будут появляться предупреждения о необходимости скорого перехода на ГОСТ Р 34.10-2012 при формировании ключей ГОСТ Р 34.10-2001, а с 1 октября 2017 года – и при формировании подписи по ГОСТ Р 34.10-2001.

Я так понимаю, что "1.2.643.2.2.30.1" - это старый гост.

two_oceans
Бывалый
Сообщений: 438
Зарегистрирован: 30 сен 2016, 17:17
Благодарил (а): 386 раза
Поблагодарили: 351 раза

Поддержка длинных строк

#13 Сообщение two_oceans » 19 июл 2017, 06:49

Sergey Cheban писал(а):Источник цитаты У тех, кто думает о безопасности, свои профессиональные привычки. Они стараются не передавать ничего лишнего, потому что "всё, что вы скажете, может быть использовано против вас".
Логично, доходит до того, что вводят специальную задержку, чтобы по времени обработки нельзя было определить на каком этапе ошибка по уменьшению длительности. Но это - внутри одной операции проверки, я не понимаю, как добавление второй целой операции (то есть тоже выровненной по длительности), срабатывающей при неправильном ответе, может создать дополни-тельную угрозу. И тем более как ее может создать изменение ответа на один из 2^256 вариантов хэша. В принципе, понятно, что безопасность и комфорт не очень совместимые понятие.
Sergey Cheban писал(а):Источник цитатыНавскидку - посмотрите на byte order mark, позволяющий отличить little-endian utf-16 от big-endian utf-16.
В скомпилированных программах конечно utf-16 широко используется, но в веб (и соответственно БД для веб) большая часть Юникода - utf-8. И в utf-8 byte order mark скорее сродни чуме чем спасению - большинство программ (включая браузеры) впадают в различные баги, встретив byte order mark в середине файла, а некоторые и в начале. Поэтому концепт создания страницы из кусочков приводит к тому что надо из всех кусочков byte order mark убрать, указав кодировку другими средствами.
Sergey Cheban писал(а):Источник цитаты big-endian железо, которое пишет данные на диски в своём родном формате
Мысль уловил, головняк изрядный, хотя пример про железо наверно не очень удачный, так как данные пишут диски, но и читают тоже они. Те же самые big-endian жесткие диски подключенные к одной платформе и к другой платформе прочитают то же самое, другой вопрос, что драйвер, работающий с ними должен будет данные перевернуть перед передачей прикладным программам. В зависимости от разных факторов, часть данных возможно не придется преобразовывать в программе после этого, но преобразование других данных может еще больше запутаться. Кстати, и под x86 некоторые устройства (вроде бы даже USB, внезапно) работают в big-endian, но мы этого не замечаем, потому что драйверы справляются. С оптическими дисками наверно хуже, не знаю есть ли там byte order mark.
Sergey Cheban писал(а):Источник цитаты Я не в теме, но гугл подсказал, что не совсем так:
Спасибо за ссылку, почитаю. На функции генерации как-то не обратил внимание, тем более что это не "майкрософтовская" функция, а именно "криптопрошная", которую "майкрософтовская" вызывает внутри после нескольких промежуточных шагов.
Sergey Cheban писал(а):Источник цитаты Я опять же не в теме, но сдаётся мне, что правильно будет отказаться принимать такой сертификат от греха подальше: если мы будем принимать разные параметры криптоалгоритма, то злоумышленник сможет предложить нам наименее криптостойкие параметры.
Логично, но как-то неправильно. Российские УЦ не сообщают клиентам практически никакую техническую информацию о будущем сертификате. Пару недель назад добивался от сотрудников регионального отдела продаж одного из крупнейших УЦ - добился только что в выбранный сертификат для ЭП-ОВ не будет включена персональная информация и что в других ИС кроме СМЭВ он вроде бы не должен работать (как мне и надо). Внятно объяснить какие именно расширения сертификата и значения расширенного использования будут в сертификате они не могут, максимум назвать тарифный план и спросить у кого-то будет ли работать на определенной ИС. Меня три раза переспросили действительно ли я хочу чтобы не работало. Про параметры хэша, полагаю, они даже не слышали.

Итого, покупая сертификат и платя денежки, клиенты УЦ покупают "кота в мешке". Шанс, что кто-то намеренно поменяет параметры хэша в сертификате хоть и не нулевой, но и для рядового клиента не велик. Зато велик шанс, что кто-то не зная ничего получит сертификат с нестандартными параметрами хэша и если мы его отклоним - попадет на деньги, так как придется заказывать сертификат в другом УЦ (в том же УЦ выдадут с теми же параметрами скорее всего). Нехорошо как-то. УЦ молодцы, в заявке на изготовления сертификата включен пункт, что клиент соглашается, что УЦ не несет ответственность за невозможность использования сертификата в определенной ИС.
Sergey Cheban писал(а):Источник цитаты Я так понимаю, что "1.2.643.2.2.30.1" - это старый гост.
Не вдавался настолько в тему про новый ГОСТ, с текущим бы разобраться, но попадалась на глаза статья про будущий стандарт. Во-первых, разработчики стандартов всех уже запутали с 34.10 (вроде бы алгоритм шифрования?), 34.11 (алгоритм хэша) и 34.10/34.11 (алгоритм подписи, из которого умудряются тоже сократить до 34.10). Во-вторых, ГОСТ то может и новый, но в его рамках переопределены большинство алгоритмов из старого (названы "Магма", все те же с 1989 года) и добавлен новый "Кузнечик" (34.12-2015). Хэш тоже добавился новый "Стрибог" (34.11?-2012), с длиной 256 для "Магмы" и 512 для "Кузнечика". А еще режимы блочных шифров определили в 34.13-2015.
Путаница изрядная, ясно только, что с 2019 года нужно обновить криптопровайдер на поддерживающий новый хэш и видимо сгенерить новые ключи (с учетом что ключи как правило на год, ничего существенно нового - и там постоянно меняем). В итоге, надо будет сесть и хорошенько разобраться, что именно они понимают под схемой подписи 34.10-2001 (видимо ГОСТ Р 34.11-94/34.10-2001) и чем отличается от нового ГОСТ 2012 года. Судя по очередности принятия стандартов, исключительно хэшем. Пользователей OpenSSL полагаю тоже очень обрадует в 2019 году, если новый ГОСТ не будет там поддерживаться к тому времени (не изучал вопрос поддерживается ли сейчас). Кстати, не новый ли ГОСТ требует ГИС ЖКХ, когда ругается, что нет согласованного ФСБ алгоритма.

Про текущую поддержку новых ключей ничего утешительного сказать не могу - буквально вчера пытался установить сертификат с 2012 в алгоритме на компьютер, где криптопро 4.0 и континент-АП 3.7... вот я Вам скажу "засада" - открываю сертификат из оснастки сертификаты все нормально, открываю тот же сертификат с рабочего стола: "Произошла ошибка при проверке отношений сертификатов", "Сертификат содержит неверную подпись". Как я понял, континент теперь тоже содержит свой криптопровайдер и криптопро (выставленный "по умолчанию") не может проверить сертификат, выпущенный континентом. А из хранилища сертификатов, где проставлена ссылка на контейнер, открывается криптопровайдер континента и все нормально. Причем в криптопро основной алгоритм 2001 года (логично, что 2012 не понимает. попробовал переключить на 2012, но отличий не заметил), а континентовский криптопровайдер не виден в списке (значит тип не такой, как у криптопро, но реализует те же алгоритмы).
Еще смешнее - похоже они поставлены в комплекте, так как для прошлого континента требовался криптопро, а компьютер сертифицированный и удалить криптопро нельзя. Конечно континент работает, проблема не критична, но конфликт - нехороший признак.

Отправлено спустя 7 минуты 3 секунды:
Еще статья

Sergey Cheban
Стажер
Сообщений: 112
Зарегистрирован: 05 ноя 2016, 07:45
Благодарил (а): 55 раза
Поблагодарили: 60 раза

Поддержка длинных строк

#14 Сообщение Sergey Cheban » 19 июл 2017, 11:11

two_oceans писал(а):Мысль уловил, головняк изрядный, хотя пример про железо наверно не очень удачный, так как данные пишут диски, но и читают тоже они. Те же самые big-endian жесткие диски подключенные к одной платформе и к другой платформе прочитают то же самое, другой вопрос, что драйвер, работающий с ними должен будет данные перевернуть перед передачей прикладным программам.

Пример взят из жизни. Решать такие вещи на уровне драйвера нельзя: драйвер ведь не знает, что он читает, int или строку. Строку переворачивать нельзя, чтобы из abcdef не получилось badcfe. В результате руководство стоит перед выбором: то ли остаться на старом железе (а оно экзотическое, дорогое, не дружит с современными средствами разработки и пр.), то ли внимательно расставить ntohl/htons по всему коду (при этом кода много, цена ошибки велика, да ещё и производительность может пострадать).

two_oceans писал(а):Логично, но как-то неправильно. Российские УЦ не сообщают клиентам практически никакую техническую информацию о будущем сертификате. Пару недель назад добивался от сотрудников регионального отдела продаж одного из крупнейших УЦ - добился только что в выбранный сертификат для ЭП-ОВ не будет включена персональная информация и что в других ИС кроме СМЭВ он вроде бы не должен работать (как мне и надо). Внятно объяснить какие именно расширения сертификата и значения расширенного использования будут в сертификате они не могут, максимум назвать тарифный план и спросить у кого-то будет ли работать на определенной ИС. Меня три раза переспросили действительно ли я хочу чтобы не работало. Про параметры хэша, полагаю, они даже не слышали.

Увы.

two_oceans писал(а):Не вдавался настолько в тему про новый ГОСТ, с текущим бы разобраться,

Я тоже не в теме различий между ними, но подпись, сформированная по новому госту, может прийти от ГИС в самый неожиданный момент.

two_oceans писал(а):Путаница изрядная, ясно только, что с 2019 года нужно обновить криптопровайдер на поддерживающий новый хэш и видимо сгенерить новые ключи (с учетом что ключи как правило на год, ничего существенно нового - и там постоянно меняем).

Криптопровайдер надо обновлять уже сейчас (я так понимаю, что нужен криптопро 4.0). И готовиться к приёму подписи по новому госту - тоже сейчас, такая подпись в любой момент может прийти (примерно дату можно прикинуть, посмотрев на дату истечения сертификата ГИС). А ключи - да, должны в рабочем порядке обновиться, на это и дано время с 2013 до 2019 года.

two_oceans писал(а):Кстати, не новый ли ГОСТ требует ГИС ЖКХ, когда ругается, что нет согласованного ФСБ алгоритма.

Сейчас, по идее, старый гост пока должен работать (как на самом деле, не знаю). Я бы предположил, что ГИС требует хоть какой-нибудь ГОСТ, но именно ГОСТ, а не американские алгоритмы. По умолчанию ГОСТа нет ни в windows, ни в браузерах.

two_oceans
Бывалый
Сообщений: 438
Зарегистрирован: 30 сен 2016, 17:17
Благодарил (а): 386 раза
Поблагодарили: 351 раза

Поддержка длинных строк

#15 Сообщение two_oceans » 19 июл 2017, 13:22

Sergey Cheban писал(а):Источник цитаты int или строку.
В этом смысле да, драйвер скорее может порядок посылки по времени в протоколе устройства поменять (что и делается в USB).
Sergey Cheban писал(а):Источник цитаты внимательно расставить ntohl/htons по всему коду (при этом кода много, цена ошибки велика, да ещё и производительность может пострадать
Как мне кажется, если уже есть перекомпилированный рабочий код на другую платформу, то весь вопрос в разовом перевороте данных на диске (с учетом длины переворачиваемых частей). То есть выяснить местоположение и размер каждой части и перевернуть. Усложнять весь код из-за необходимости разовой операции как-то черезмерно рискованно. А при разовой операции, какая бы она не была долгая, про урон производительность речи не идет.
Sergey Cheban писал(а):Источник цитаты Криптопровайдер надо обновлять уже сейчас (я так понимаю, что нужен криптопро 4.0).
Ну готовиться-то конечно можно, вот только новая версия криптопровайдера это еще и новые константы во всех функциях, морока еще та. Судя по прошлым версиям, КриптоПро никак не может протащить одно название и значение константы в следующую версию. Конечно за год ничего не улучшится, но уже будет некий гайд от тех кто наткнулся на подводные камни.

Меня вот озаботило другое - я думал делать внутренний УЦ на ГОСТ-2001 и корневой сертификат до 2040 года бахнуть (подчиненный УЦ лет на 5 и сертификаты на ПК (машинные) года на 3). Но если ГОСТ-2001 придется менять через полтора года, то наверно надо сразу ГОСТ-2012 закладывать. Вот печаль-то.
Sergey Cheban писал(а):Источник цитаты Сейчас, по идее, старый гост пока должен работать (как на самом деле, не знаю). Я бы предположил, что ГИС требует хоть какой-нибудь ГОСТ, но именно ГОСТ, а не американские алгоритмы. По умолчанию ГОСТа нет ни в windows, ни в браузерах.
Все так, проблема в том, что все сделано по инструкции: установлен КриптоПро 3.6, cades plugin и настроены доверенные узлы в IE - сайт налоговой говорит ГОСТ-2001 есть, тестирует и переключается на него в HTTPS, при этом ГИС ЖКХ говорит "ГОСТа нет" в том же браузере. И соединение с помощью OpenSSL на сайт ГИС ЖКХ с шифросьютом гост-2001 тоже не проходит, выбирается американский алгоритм. Потому у меня и возникли подозрения, те кто говорил, что сообщение не выдает присылали скриншоты с Windows 8.1 или 10, на которых нужна новая версия КриптоПро (которая попутно поддерживает новые шифры).

Sergey Cheban
Стажер
Сообщений: 112
Зарегистрирован: 05 ноя 2016, 07:45
Благодарил (а): 55 раза
Поблагодарили: 60 раза

Поддержка длинных строк

#16 Сообщение Sergey Cheban » 19 июл 2017, 15:05

two_oceans писал(а):Как мне кажется, если уже есть перекомпилированный рабочий код на другую платформу, то весь вопрос в разовом перевороте данных на диске (с учетом длины переворачиваемых частей). То есть выяснить местоположение и размер каждой части и перевернуть. Усложнять весь код из-за необходимости разовой операции как-то черезмерно рискованно. А при разовой операции, какая бы она не была долгая, про урон производительность речи не идет.

Разовая переконвертация - скорее всего, не вариант.
- Это не ГИС и не Росреестр, которые могут себе позволить выключиться на пару месяцев, чтобы сменить форматы данных. Money never sleep.
- Данных много. Устройства, на которых они хранятся, подключены не к какой-то конкретной машине, а к сети.
- Заменить зоопарк машин, работающих с этими данными, за один приём не получится. И по техническим причинам (там десятки тонн компьютеров), и по организационным. Никто не будет рисковать, заменяя все компьютеры одновременно.
Сначала в сеть добавят одну little-endian машину и убедятся, что она _читает_ данные нормально. Потом вторую. Потом заведут какое-нибудь тестовое хранилище, в которое little-endian машины смогут писать, и проверят, что big-endian смогут это читать. Потом переведут в это хранилище какие-нибудь не очень важные данные и проверят, что клиенты не жалуются. Потом, постепенно, будут доверять little-endian машинам всё более важные операции. И только потом - начнут потихоньку выключать big endian. Как-то так (в очень упрощённом изложении и не затрагивая взаимодействие этого процесса с другими событиями).

two_oceans писал(а):Меня вот озаботило другое - я думал делать внутренний УЦ на ГОСТ-2001 и корневой сертификат до 2040 года бахнуть (подчиненный УЦ лет на 5 и сертификаты на ПК (машинные) года на 3). Но если ГОСТ-2001 придется менять через полтора года, то наверно надо сразу ГОСТ-2012 закладывать. Вот печаль-то.

Внутренний - беспроблемнее на RSA делать, imho. По крайней мере, там криптопровайдеры во всех ОС из коробки доступны и бесплатны. А если вдруг RSA сломают, то внутренний УЦ будет не самой большой проблемой. Но если хочется гост, то, конечно, "безумству храбрых поём мы песню".

two_oceans писал(а):Все так, проблема в том, что все сделано по инструкции: установлен КриптоПро 3.6,

Ну вот с 2019 года криптопро 3.6 превратится в тыкву. Поэтому я бы предложил, добившись хоть какой-то работоспособности на 3.6, не затягивать и как можно скорее попробовать 4.0. Получится - хорошо. Не получится - отправить запрос в техподдержку и жить на 3.6, пока не ответят.
Второй вариант - не пробовать, а просто спросить у ГИС, как и когда она собирается переходить на новый гост, и не пора ли обновить инструкцию (она, небось, с выхода 3.6 ни разу не обновлялась).

PS. Вообще, это позор, что гост появился в 2012 году, а его реализация - только в 2016. И второй позор - отсутствие бесплатной реализации и прочие vendor lock'и. Но - "это не беда, это расходы".

two_oceans
Бывалый
Сообщений: 438
Зарегистрирован: 30 сен 2016, 17:17
Благодарил (а): 386 раза
Поблагодарили: 351 раза

Поддержка длинных строк

#17 Сообщение two_oceans » 20 июл 2017, 07:45

Sergey Cheban писал(а):Источник цитаты Как-то так (в очень упрощённом изложении и не затрагивая взаимодействие этого процесса с другими событиями).
Ясно.. впрочем, разово не значит одновременно и все выключить. С учетом сказанного, а если так: переключить один жесткий диск на только чтение, скопировать, перевернуть данные на копии, подключить копию к новому хранилищу для чтения, протестить, при успехе перенести процессы связанные с данными на том диске на little endian компьютер (то есть создание процесса на LE, тест процесса, запрет процесса на BE), включить полный доступ на копии, исходный диск отключить (до конца переноса всех дисков), скопировать следующий диск и т.д. При ошибке - откат шага (запретить процесс на LE, отменить запрет на процесс BE, полный доступ на исходный диск), проанализировать что "не так" и повторить с учетом исправлений. Если процессы включают резервирование, то проблем с переключением одного диска на чтение вообще не должно быть, но будет проблема с дифференциальным копированием и его переворотом. Однако "разницу" обработать еще быстрее чем целый диск, так что это тоже решаемо.
В этом случае тоже потребуется некое ПО для копирования и правильного переворота, но его можно сделать сильно упрощенным по сравнению с бизнес-ПО для каждого endian, так как переворот можно заранее отладить по каждому типу файлов.
Sergey Cheban писал(а):Источник цитаты Внутренний - беспроблемнее на RSA делать, imho. По крайней мере, там криптопровайдеры во всех ОС из коробки доступны и бесплатны. ... Но если хочется гост, то, конечно, "безумству храбрых поём мы песню".
На американских алгоритмах уже есть внутренний УЦ (Майкрософтовский) в домене. При установке компонента УЦ можно было выбрать ГОСТ (КриптоПро 3.6 на сервере тоже есть), но вроде бы варианты взаимоисключающие. Там тоже свои заморочки - ставить IIS для веб-интерфейса я не хочу (много дыр), а из оснастки сертификаты можно только фиксированные типы сертификатов ("профили") запрашивать, несоответствующие профилю расширения можно заполнить, но их срезает при выпуске сертификата. Например, в сертификат для сервера терминалов я хотел включить и доменное имя и IP-адрес, но IP срезался. Теперь если зайти по IP, то предупреждает "сертификат не соответствует имени узла". Как добавлять профили - не разбирался. Мне наверно проще будет сделать подчиненный УЦ в OpenSSL, приладить к нему интерфейс HTA и издавать там, чем разбираться в надуманных ограничениях УЦ Майкрософта.

По ГОСТ: проблема даже не в том, что "хочется" ГОСТ - персональные данные передающиеся из одного подразделения в другое подразделение по общей сети провайдера должны быть защищены ГОСТ. Хотя сеть провайдера практически как локальная, но это не отменяет необходимость ГОСТ. Сейчас сетевая связность настроена, как обычная VPN (средствами Windows, а VPN нужна для обхода ограничений Windows по маске) и с этим 2 проблемы: 1) шифр не ГОСТ, ключ смешной длины. Для более надежного нужно серьезно разбираться с политиками VPN; 2) VPN соединение нужно устанавливать вручную. Конечно, можно настроить различные сценарии автозапуска, только со всеми одна проблема - допустим, соединение установили, потом я перезагрузил сервер, сервер считает соединения разорванными, но на клиенте соединение все еще считается подключенным! Чтобы работало его приходится вручную разъединить и подключить снова (ну или перезагрузиться).
Есть всем известное решение - Vipnet клиент, вот только там: 1) много лишнего, в данном случае нет необходимости шифровать ВСЕ соединения, фильтровать посторонние; постоянно запрашивает пароль на контейнер при входе, компьютер существенно тормозит; 2) клиент должен подключаться к координатору либо нужно по координатору в каждом подразделении + если сеть своя нужен комплекс администратора, в итоге выходит дорого; 3) конфликтует с КриптоПро - можно разрулить, но работать будет один криптопровайдер. Есть какое-то VPN решение от КриптоПро, подробности не узнавал, но тоже тянет на круглую сумму.

Для ГОСТ-2001 есть реализация stunnel (на основе исходников OpenSSL), то есть для внутреннего использования подойдет, дело только в сертификатах. Более того есть версия stunnel работающая с КриптоПро (так уж получается, что на большинстве ПК с персональными данными КриптоПро уже установлен), есть библиотека позволяющая из OpenSSL использовать сам КриптоПро (к слову, позволяет настроить веб-сервер с 2 сертификатами: один для ГОСТ с поддержкой TLS 1.0, другой обычный американского алгоритма с поддержкой TLS 1.2). Такая библиотека выручит, если вдруг кто скажет, что конкретная сборка OpenSSL не сертифицирована. Как я понимаю, туннель устанавливается для каждого входящего отдельно, то есть вручную переподключать тоже не надо. Для конкретной задачи - идеально.
Естественно для внутреннего использования сертификаты не стоят всех заморочек/денег получения в аккредитованном УЦ, да и российские УЦ все больше на ФЛ, ИП и ЮЛ ориентируются, внести дополнительное имя для сертификата узла или наименование ИС целая проблема. Поэтому все сводится к еще одному внутреннему УЦ с ГОСТ на OpenSSL, где я смогу рулить составом сертификата как пожелаю.

С ГОСТ-2012 будет проблема при отсутствии реализации в OpenSSL. Хотя и тут есть шанс попробовать библиотеку связывающую OpenSSL и КриптоПро, а вдруг она сумеет из КриптоПро 4.0 ГОСТ-2012 подключить (помечтать не вредно, но с учетом, что библиотека до сих пор TLS 1.2 не может обработать - маловероятно). Похоже все идет к тому, что придется сделать три версии внутреннего УЦ (с ГОСТ-2001 на 3 года, с RSA и ГОСТ-2012 до 2040 года).

Отправлено спустя 22 минуты 16 секунды:
Sergey Cheban писал(а):Источник цитаты И второй позор - отсутствие бесплатной реализации и прочие vendor lock'и
OpenSSL доберется и до него, вопрос времени.

Sergey Cheban
Стажер
Сообщений: 112
Зарегистрирован: 05 ноя 2016, 07:45
Благодарил (а): 55 раза
Поблагодарили: 60 раза

Поддержка длинных строк

#18 Сообщение Sergey Cheban » 20 июл 2017, 15:18

two_oceans писал(а):С учетом сказанного, а если так: переключить один жесткий диск на только чтение, скопировать, перевернуть данные на копии, подключить копию к новому хранилищу для чтения,

Я, честно говоря, предпочёл бы уйти от этой темы. Во-первых, здесь это махровый оффтопик, поскольку к ЖКХ не относится никаким боком. Во-вторых, я о ней имею только самое общее представление, на уровне "Мы не можем перейти на новый стандарт C++, поскольку пока не избавились от компьютеров, для которых нет компиляторов, поддерживающих этот стандарт". Плюс, конечно, общая эрудиция и общее представление о том, чем занимается компания. В-третьих, всё, что не общеизвестно, закрыто NDA.

two_oceans писал(а):По ГОСТ: проблема даже не в том, что "хочется" ГОСТ - персональные данные передающиеся из одного подразделения в другое подразделение по общей сети провайдера должны быть защищены ГОСТ.

Да, это многое объясняет (тех, кто придумал всю эту возню с персональными данными, поубивал бы). Конкретно, увы, ничего не подскажу: я не сисадмин, со всем этим практически не пересекаюсь.

two_oceans писал(а):С ГОСТ-2012 будет проблема при отсутствии реализации в OpenSSL. Хотя и тут есть шанс попробовать библиотеку связывающую OpenSSL и КриптоПро, а вдруг она сумеет из КриптоПро 4.0 ГОСТ-2012 подключить (помечтать не вредно, но с учетом, что библиотека до сих пор TLS 1.2 не может обработать - маловероятно). Похоже все идет к тому, что придется сделать три версии внутреннего УЦ (с ГОСТ-2001 на 3 года, с RSA и ГОСТ-2012 до 2040 года).

Зачем сейчас начинать делать на гост-2001 - не очень понимаю. Тем более с корневым ключом на три года (с учётом, что он окончательно сдохнет через полтора).

two_oceans писал(а):Отправлено спустя 22 минуты 16 секунды:
Sergey Cheban писал(а):Источник цитаты И второй позор - отсутствие бесплатной реализации и прочие vendor lock'и
OpenSSL доберется и до него, вопрос времени.

Реализация гост для openssl есть в виде внешнего engine, подключаемого через конфиг: https://github.com/gost-engine/engine. Но - это и всё, кажется. В NSS (firefox, chrome, thunderbird etc) госта нет, криптопровайдер для windows - только проприетарный cryptopro, и т.д. Российских корневых сертификатов нет по умолчанию в windows и браузерах, хотя процедура включения известна.

two_oceans
Бывалый
Сообщений: 438
Зарегистрирован: 30 сен 2016, 17:17
Благодарил (а): 386 раза
Поблагодарили: 351 раза

Поддержка длинных строк

#19 Сообщение two_oceans » 21 июл 2017, 06:12

Sergey Cheban писал(а):Источник цитатыЯ, честно говоря, предпочёл бы уйти от этой темы.
OK.
Sergey Cheban писал(а):Источник цитатыТем более с корневым ключом на три года (с учётом, что он окончательно сдохнет через полтора).
1) Приобретение лицензий КриптоПро 4.0/добавление поддержки нового ГОСТ в Openssl займет некоторое время, а переделать каналы связи на туннели планирую до конца года (и неспешно осваивать новый стандарт в течение года).
2)Как я понимаю, запрет на гост-2001 касается схемы подписи и хэша, остальные алгоритмы благополучно переехали в новый ГОСТ, то есть, если 31 декабря 2018 года прекратить выпускать новые сертификаты (выпуск подразумевает их подпись), то выпущенными ранее можно будет работать (в плане шифрования соединения, не используя хеш 2001 года и не подписывая что-либо) еще до 15 месяцев (хотя это максимум срока клиентского сертификата в аккредитованных УЦ, во внутреннем УЦ можно и больше, но не буду зарываться). Срок сертификата УЦ должен перекрывать максимальный срок действия выпущенных им сертификатов чтобы цепочка доверия работала (в случае если не планируется его перевыпуск, на гост-2001 явно не планируется).
Теоретически возможно включить в новый сертификат УЦ сведения о ключе либо хэше старого сертификата, но полагаю это не сработает, если алгоритм хэша отличается. Во вложении пример 2 сертификатов одного УЦ, в сертификате 2014 года указан хэш оригинального сертификата 2012 года.
CA new version.rar
(2.68 KiB) Загружено 6 раз

Общий срок действия сертификата УЦ при этих условиях составит (считая от сегодня до 1 января 2019 плюс 15 месяцев = 1 апреля 2020 года) 2 года 8 месяцев 10 дней, округленно 3 года. Так что через полтора года УЦ все еще будет действующим, но фактически не будет ничего выпускать/отзывать. Собственно, такая фаза (действующий, но не выпускающий новых сертификатов) предусматривается при любом выводе УЦ из использования. Конечно, все сертификаты, которыми нужно подписывать (не только шифровать) должны закончится раньше 1 января 2019 года и пройти замену на сертификаты с ГОСТ-2012.

Есть заминки - подписание списков отзыва (они должны быть подписаны тем же сертификатом УЦ, но если не отзывать, можно поставить срок действия "крайнего" списка отзыва с 31 декабря 2018 года до конца сертификата УЦ) и при авторизации по сертификату малый объем данных тоже подписывается (хотя никуда не сохраняется и дальше своего сервера уходить не будет, так что не такая уж проблема). Естественно, расчеты справедливы для OpenSSL туннелей и старых версий криптопровайдеров, в новый КриптоПро наверняка заложат запрет в том числе на авторизацию с 1 января 2019 года.
Sergey Cheban писал(а):Источник цитатыРеализация гост для openssl есть в виде внешнего engine, подключаемого через конфиг: https://github.com/gost-engine/engine. Но - это и всё, кажется.
Наверно этого и достаточно, его можно много куда прикрутить. Спасибо за ссылку, вижу, что ГОСТ-2012 там есть.
Sergey Cheban писал(а):Источник цитаты В NSS (firefox, chrome, thunderbird etc) госта нет
Могу ошибаться, но дело как правило в использовании старой версии OpenSSL (0.9.8, в которой ГОСТ не было - в каких-то программах как внешние библиотеки, в каких-то вкомпилированы в саму программу) и в системе управления сертификатами. КриптоПро, например, выпускает свой клон Firefox с поддержкой ГОСТ. Еще есть dll hell библиотек OpenSSL (они как правило лежат в папке программы, но недавно на ПК с XP обнаружил в windows/system32 обе библиотеки версии 0.9.8, попробовал заменить на 1.0.2 - защита системных файлов на них не сработала, не Майкрософтовские файлы, dll hell в полный рост) и отсутствие на среднем ПК под Windows файла конфигурации OpenSSL и переменной окружения на него указывающей. Есть подозрение, что если проблемы разрешить и настроить, добавить корневые сертификаты, то и в Firefox стандартном (хотя после таких модификаций сложно назвать стандартным) внезапно появится ГОСТ. Проблемы совместимости клиентских сертификатов с Firefox пропускаю.
Sergey Cheban писал(а):Источник цитатыРоссийских корневых сертификатов нет по умолчанию в windows и браузерах, хотя процедура включения известна.
Это логично: если Windows гостовские корневые примет в программу, даже если только сертификаты ГУЦ, то должна будет поддерживать алгоритм ГОСТ "из коробки". Однако, это будет означать, что, например, ФСБ получив в ГУЦ сертификат своего УЦ сможет получить некий доступ ко всем ПК с Windows. Американские спецслужбы просто не согласятся добавить ГУЦ, как и другие УЦ, которые не аккредитованы у них. Конечно, частично проблему бы решило включение ГУЦ и поддержки ГОСТ только в русские версии. С браузерами чуть попроще, но фундаментально проблема такая же - кроме включения корневого сертификата нужна еще поддержка алгоритма.

Плюс порой складывается впечатление, что у нас на государственном уровне лоббируют пропиетарные (зато отечественные) средства: криптопровайдера сертифицированного и бесплатного нет, средств XMLDSig тоже, VPN тоже. Зато предлагают их приобрести у определенных компаний. При этом известно, что за достаточную плату можно стать партнером КриптоПро (так поступило Федеральное казначейство, но сумму не знаю) и раздавать лицензии и криптопровайдер бесплатно "во временное пользование" (казначейство раздает для бюджетников, хотя бумажная волокита при этом изрядная).

two_oceans
Бывалый
Сообщений: 438
Зарегистрирован: 30 сен 2016, 17:17
Благодарил (а): 386 раза
Поблагодарили: 351 раза

Поддержка длинных строк

#20 Сообщение two_oceans » 21 июл 2017, 11:55

Посмотрел.. оказывается в основной код openssl тоже добавили "Кузнечика" (Grasshopper) и хэш 34.11-2012 (смотрел в стабильных ветках, нашлось в 1.1.0g, в 1.0.2 еще вроде бы нет, точнее добавилось определение в crypto/objects/obj_dat.h) попробую ближайшие дни собрать 1.1.0g (или найти готовую сборку) и проверить есть ли в списке алгоритмов.


Вернуться в «ГИС ЖКХ. Форум разработчиков программного обеспечения и всего, что с ним связано»

Кто сейчас на форуме

Количество пользователей, которые сейчас просматривают этот форум: нет зарегистрированных пользователей и 1 гость