[devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Vitaly Lipatov]

Прошу помощи в обсуждении ситуации с корневыми сертификатами, которые у 
нас помещаются пакетом ca-certificates в 
/usr/share/ca-certificates/ca-bundle.crt и (в идеале) используются всеми 
средствами работы с сертификатами.

Стоит задача добавить к этому списку сертификатов как минимум корневые 
сертификаты (самоподписанные сертификаты головного удостоверяющего 
центра (ГУЦ) РФ
https://e-trust.gosuslugi.ru/MainCA

Ситуация осложняется тем, что ГУЦ передало функции по выдаче 
сертификатов различным УЦ (аккредитованным), что приводит к появлению 
нескольких тысяч промежуточных сертификатов
https://e-trust.gosuslugi.ru/CA

Чтобы посмотреть на это в действии, я собрал пакет ca-gost-certificates 
с сертификатами всех УЦ, формируя файл 
/usr/share/ca-gost-certificates/ca-gost-bundle.crt
на основе опубликованного XML-файла, содержащего все сертификаты 
https://e-trust.gosuslugi.ru/CA/DownloadTSL?schemaVersion=0

Приклеив (concatenate) 
/usr/share/ca-gost-certificates/ca-gost-bundle.crt к системному 
/usr/share/ca-certificates/ca-bundle.crt можно добавить в поле видимости 
OpenSSL эти сертификаты и он будет с ними работать после настройки 
согласно https://www.altlinux.org/ГОСТ_в_OpenSSL

После этого совершенно свободно удалось проверить подпись на упомянутом 
XML-файле с помощью xmlsec и модуля xmlsec-openssl.

Поскольку нынешняя архитектура не предусматривает подключение 
промежуточных сертификатов, хочу посоветоваться, что мы с ними будем 
делать.

Судя по всему, есть мнение, что такие сертификаты не должны включаться в 
список ca-bundle.crt:
https://bugzilla.altlinux.org/show_bug.cgi?id=33498
С другой стороны, как я понимаю, ничего опасного в них тоже нет (они 
подписаны корневыми УЦ, хотя это пока никто не проверял), кроме того, 
что их много и их добавление сильно замедляет подгрузку файла 
сертификатов (и запуск команды openssl, например).

Насколько я понимаю ситуацию в мире веб-сервисов (смотрю на примере 
nginx, postfix, jabberd2 и т.п.) с установленными SSL-сертификатами, там 
приходится применять следующий подход: указывается не только
сертификат, полученный для сайта, но ещё и все промежуточные 
сертификаты, чтобы клиент, имеющий скудный набор корневых сертификатов 
(в браузере или в ca-bundle.crt) мог удостовериться в его подлинности.

Сертификаты УЦ РФ сейчас практически не используются на сайтах (в 
основном по причине проблем с браузерами), но планируются к активному 
использованию в подписывании документов, проверке подписей.
Как правило, во всех случаях использования пользователю предлагается 
скачать и установить необходимую цепочку сертификатов, что при 
повседневном широкой работе с различными организациями мало приемлемо.

К моему большому удивлению, (в openssl) нет механизма (или я его не 
заметил) использования нескольких файлов с сертификатами. Даже не 
существует стандартного пути, и программы (библиотеки), использующие 
ca-bundle.crt, должны сами указывать к нему путь.

Вот перечень проблем на эту тему:

В общем-то в клиенты вшиты разные свои пути, мы делаем для них ссылки
https://bugzilla.altlinux.org/show_bug.cgi?id=31213

add generation /etc/pki/java/cacerts
https://bugzilla.altlinux.org/show_bug.cgi?id=25027

GO не находит корневой сертификат
https://bugzilla.altlinux.org/show_bug.cgi?id=29449

В самом Qt, например, вшито в код
systemCerts.append(QSslCertificate::fromPath(QLatin1String("/etc/pki/tls/certs/ca-bundle.crt")


Пакет openssl делает ссылку /var/lib/ssl/cert.pem на 
/usr/share/ca-certificates/ca-bundle.crt

Как я понимаю, потом открывает его, исходя из определения в 
openssl/crypto/cryptlib.h
#  define X509_CERT_FILE          OPENSSLDIR "/cert.pem"

Вопросы:
1. Существуют ли механизмы, упрощающие совмещение нескольких наборов 
сертификатов
(чтобы совместить наборы, идущие в ca-certificates и в 
ca-gost-certificates), или предложения, как красиво решить этот вопрос.

2. Существуют ли механизмы, подразумевающие локальное хранение и 
обновление промежуточных сертификатов?


И отдельно риторический вопрос: почему поддержка GOST не включена у нас 
в openssl из коробки? И хотя бы нет готовой ручки в control. Без этого 
массового использования не получится.


-- 
С уважением,
Виталий Липатов,
Etersoft

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Vladimir Didenko]

1 августа 2017 г., 0:31 пользователь Vitaly Lipatov написал:
>
>
> Судя по всему, есть мнение, что такие сертификаты не должны включаться в
> список ca-bundle.crt:
> https://bugzilla.altlinux.org/show_bug.cgi?id=33498

На мой взгляд, правильное мнение.


> Насколько я понимаю ситуацию в мире веб-сервисов (смотрю на примере nginx,
> postfix, jabberd2 и т.п.) с установленными SSL-сертификатами, там приходится
> применять следующий подход: указывается не только
> сертификат, полученный для сайта, но ещё и все промежуточные сертификаты,
> чтобы клиент, имеющий скудный набор корневых сертификатов (в браузере или в
> ca-bundle.crt) мог удостовериться в его подлинности.

Да, это требование RFC SSL/TLS.

>
> К моему большому удивлению, (в openssl) нет механизма (или я его не заметил)
> использования нескольких файлов с сертификатами.

Ну как же, у функции SSL_CTX_load_verify_locations
(https://wiki.openssl.org/index.php/Manual:SSL_CTX_load_verify_locations(3))
есть параметр CApath - путь к директории с файлами сертификатов. Более
того, файлы подгружаются по мере надобности, а не сразу во время
старта.

> Даже не существует
> стандартного пути, и программы (библиотеки), использующие ca-bundle.crt,
> должны сами указывать к нему путь.

А X509_get_default_cert_*() не решают эту проблему?

-- 
С уважением,
Владимир.

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Paul Wolneykien]

01.08.2017 00:31, Vitaly Lipatov пишет:
> К моему большому удивлению, (в openssl) нет механизма (или я его не
> заметил) использования нескольких файлов с сертификатами. Даже не
> существует стандартного пути, и программы (библиотеки), использующие
> ca-bundle.crt, должны сами указывать к нему путь.

  А если просто конкатенировать несколько PEM в один, как это делается
обычно для того же nginx?

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 299 bytes --]

On Tue, Aug 01, 2017 at 12:31:07AM +0300, Vitaly Lipatov wrote:
> 
> Прошу помощи в обсуждении ситуации с корневыми сертификатами, которые у 
> нас помещаются пакетом ca-certificates в 

Давайте отложим обсуждение PKI infrastructure, пока заинтересованные
находятся в отпусках.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Konstantin Lepikhov]

Hi Vitaly!

On 08/01/17, at 12:31:07 AM you wrote:

> 
> Прошу помощи в обсуждении ситуации с корневыми сертификатами, которые у 
> нас помещаются пакетом ca-certificates в 
> /usr/share/ca-certificates/ca-bundle.crt и (в идеале) используются всеми 
> средствами работы с сертификатами.
До сих пор не используются, но такой файл есть и про него знает openssl.

> 
> Стоит задача добавить к этому списку сертификатов как минимум корневые 
> сертификаты (самоподписанные сертификаты головного удостоверяющего 
> центра (ГУЦ) РФ
> https://e-trust.gosuslugi.ru/MainCA
> 
> Ситуация осложняется тем, что ГУЦ передало функции по выдаче 
> сертификатов различным УЦ (аккредитованным), что приводит к появлению 
> нескольких тысяч промежуточных сертификатов
> https://e-trust.gosuslugi.ru/CA
А где можно ознакомиться с регламентом предоставления статуса ЦА и
отчетом аудита, что данные ЦА являются ЦА?

> 
> Чтобы посмотреть на это в действии, я собрал пакет ca-gost-certificates 
> с сертификатами всех УЦ, формируя файл 
> /usr/share/ca-gost-certificates/ca-gost-bundle.crt
> на основе опубликованного XML-файла, содержащего все сертификаты 
> https://e-trust.gosuslugi.ru/CA/DownloadTSL?schemaVersion=0
> 
> Приклеив (concatenate) 
> /usr/share/ca-gost-certificates/ca-gost-bundle.crt к системному 
> /usr/share/ca-certificates/ca-bundle.crt можно добавить в поле видимости 
> OpenSSL эти сертификаты и он будет с ними работать после настройки 
> согласно https://www.altlinux.org/ГОСТ_в_OpenSSL
> 
> После этого совершенно свободно удалось проверить подпись на упомянутом 
> XML-файле с помощью xmlsec и модуля xmlsec-openssl.
Если напрячься то можно и не так раскорячится. Ну проверили вы что-то,
через какой-то блоб, дальше то что?

> 
> Поскольку нынешняя архитектура не предусматривает подключение 
> промежуточных сертификатов, хочу посоветоваться, что мы с ними будем 
> делать.
Нынешняя архитектура предусматривает работу openssl через список
сертификатов, которые прошли процедуру доверия в Mozilla в соответствии с
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

Все остальное не является сертификатами, которым можно доверять как
корневым. Данная система гарантирует, что у вас на уровне утилит которые
используют libssl будет ровно такое же поведение как и при использовании
браузеров Firefox и Chromium.

Официальной поддержки ГОСТ в браузерах нет и не предвидится по целому
ряду факторов, если интересно я могу их озвучить отдельным письмом но об
этом знают и в руководстве ООО.

> 
> Судя по всему, есть мнение, что такие сертификаты не должны включаться в 
> список ca-bundle.crt:
> https://bugzilla.altlinux.org/show_bug.cgi?id=33498
> С другой стороны, как я понимаю, ничего опасного в них тоже нет (они 
> подписаны корневыми УЦ, хотя это пока никто не проверял), кроме того, 
> что их много и их добавление сильно замедляет подгрузку файла 
> сертификатов (и запуск команды openssl, например).
Если вы внимательно читали комментарии к багу, то могли увидеть что
сертификаты выпустил Symantec, да-да, тот самый, который хотят забанить и
в Chromium и в Mozilla ибо там творится бардак с защитой данных и
сертификатов от третьих лиц.

Вы же предлагаете еще больший бардак вроде добавить сертификаты УЦ
какой-то администрации какого-то края где вообще непонятно что происходит
и кто вообще имеет доступы к этим сертификатам. Например, компьютер в сети
администрации Х будет хакнут хакером Васей, который потом переподпишет
этими сертификатами имена gosuslugi или sberbank.ru. И ваш openssl это
проглотит.

> 
> Насколько я понимаю ситуацию в мире веб-сервисов (смотрю на примере 
> nginx, postfix, jabberd2 и т.п.) с установленными SSL-сертификатами, там 
> приходится применять следующий подход: указывается не только
> сертификат, полученный для сайта, но ещё и все промежуточные 
> сертификаты, чтобы клиент, имеющий скудный набор корневых сертификатов 
> (в браузере или в ca-bundle.crt) мог удостовериться в его подлинности.
А еще в браузерах используется CRL URL и OCSP для проверки и еще некоторые
техники, гарантирующие что ваша база сертификатов не скомпрометирована.
Сертификат вам как таковой гарантирует только целостность данных а их не
подлинность.

> 
> Сертификаты УЦ РФ сейчас практически не используются на сайтах (в 
> основном по причине проблем с браузерами), но планируются к активному 
> использованию в подписывании документов, проверке подписей.
> Как правило, во всех случаях использования пользователю предлагается 
> скачать и установить необходимую цепочку сертификатов, что при 
> повседневном широкой работе с различными организациями мало приемлемо.
У вас есть коммерческие заказчики, которые сидят на Сизифе? Думаю, у них
продукты _на базе_ Сизифа где вы как продавец или интегратор вольны делать
что хотите. Не надо выставлять собственные проблемы как проблемы
мифических "пользователей". Точно также как и рядовой пользователь
поставит что-то от ООО где вместо firefox будет firefox-gost с одобренным
ФСБ бэкдорами )

> 
> К моему большому удивлению, (в openssl) нет механизма (или я его не 
> заметил) использования нескольких файлов с сертификатами. Даже не 
> существует стандартного пути, и программы (библиотеки), использующие 
> ca-bundle.crt, должны сами указывать к нему путь.
Вам уже ответили письмом ниже, что все есть в libssl нужно только
внимательно читать документацию.

> Вопросы:
> 1. Существуют ли механизмы, упрощающие совмещение нескольких наборов 
> сертификатов
> (чтобы совместить наборы, идущие в ca-certificates и в 
> ca-gost-certificates), или предложения, как красиво решить этот вопрос.
Убедите ФСБ отказаться от сертификации для ГСЦ и вам не нужно будет
решать эту проблему.

> 
> 2. Существуют ли механизмы, подразумевающие локальное хранение и 
> обновление промежуточных сертификатов?
??

> 
> 
> И отдельно риторический вопрос: почему поддержка GOST не включена у нас 
> в openssl из коробки? И хотя бы нет готовой ручки в control. Без этого 
> массового использования не получится.
см. выше.

-- 
WBR et al.

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Dmitry Derjavin]

Вт, 01 авг 2017, 18:47, Konstantin Lepikhov:

>> Ситуация осложняется тем, что ГУЦ передало функции по выдаче 
>> сертификатов различным УЦ (аккредитованным), что приводит к появлению 
>> нескольких тысяч промежуточных сертификатов
>> https://e-trust.gosuslugi.ru/CA
> А где можно ознакомиться с регламентом предоставления статуса ЦА и
> отчетом аудита, что данные ЦА являются ЦА?

Видимо, там же, где и с данными о статусе аудитора и отчёте о
подтверждении его аутентичности.

> Официальной поддержки ГОСТ в браузерах нет и не предвидится по целому
> ряду факторов, если интересно я могу их озвучить отдельным письмом но об
> этом знают и в руководстве ООО.

Да, это действительно очень интересно! Озвучьте, пожалуйста.

> Вы же предлагаете еще больший бардак вроде добавить сертификаты УЦ
> какой-то администрации какого-то края где вообще непонятно что происходит

Не-не, речь о том, чтобы добавить сертификаты УЦ, аккредитованных
Минкомсвязью. Которыми подписаны, например, сертификаты физических лиц.
Не сайтов. Чтобы иметь возможность проверить данные этих сертификатов.

> Например, компьютер в сети администрации Х будет хакнут хакером Васей,
> который потом переподпишет этими сертификатами имена gosuslugi или
> sberbank.ru. И ваш openssl это проглотит.

Теоретически, видимо, можно так сделать. Но бояться не нужно, вы ведь
сейчас расскажете, почему в браузерах поддержки ГОСТ нет и не будет. ;)

> Не надо выставлять собственные проблемы как проблемы мифических
> "пользователей".

+1

Согласен, давайте не будем додумывать друг за друга, насколько актуальна
поставленная задача. А задача на данный момент такова — задействовать
имеющуюся весьма развитую PKI. Которая уже существует и прекрасно работает.
Учитывая при этом, конечно же, возможные нюансы вроде «хакера Васи» и
сайта Госуслуг.

-- 
~dd

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Paul Wolneykien]

01.08.2017 00:31, Vitaly Lipatov пишет:
> И отдельно риторический вопрос: почему поддержка GOST не включена у нас
> в openssl из коробки? И хотя бы нет готовой ручки в control.

  Я только что её написал:


http://git.altlinux.org/people/manowar/packages/openssl10.git?p=openssl10.git;a=commitdiff;h=e82035a81d673cea76e3e1f59d8bdc4524b21b36

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Konstantin Lepikhov]

Hi Dmitry!

On 08/01/17, at 07:26:09 PM you wrote:

> Вт, 01 авг 2017, 18:47, Konstantin Lepikhov:
> 
> >> Ситуация осложняется тем, что ГУЦ передало функции по выдаче 
> >> сертификатов различным УЦ (аккредитованным), что приводит к появлению 
> >> нескольких тысяч промежуточных сертификатов
> >> https://e-trust.gosuslugi.ru/CA
> > А где можно ознакомиться с регламентом предоставления статуса ЦА и
> > отчетом аудита, что данные ЦА являются ЦА?
> 
> Видимо, там же, где и с данными о статусе аудитора и отчёте о
> подтверждении его аутентичности.
т.е. спросить товарища майора?

> 
> > Официальной поддержки ГОСТ в браузерах нет и не предвидится по целому
> > ряду факторов, если интересно я могу их озвучить отдельным письмом но об
> > этом знают и в руководстве ООО.
> 
> Да, это действительно очень интересно! Озвучьте, пожалуйста.
https://bugzilla.mozilla.org/show_bug.cgi?id=518787#c19

> 
> > Вы же предлагаете еще больший бардак вроде добавить сертификаты УЦ
> > какой-то администрации какого-то края где вообще непонятно что происходит
> 
> Не-не, речь о том, чтобы добавить сертификаты УЦ, аккредитованных
> Минкомсвязью. Которыми подписаны, например, сертификаты физических лиц.
> Не сайтов. Чтобы иметь возможность проверить данные этих сертификатов.
Насколько требования Минкомсвязи соответствуют документу от Mozilla? Как
используя несертифицированные СКЗИ вы сможете убедиться в достоверности
этих сертификатов?

> 
> > Например, компьютер в сети администрации Х будет хакнут хакером Васей,
> > который потом переподпишет этими сертификатами имена gosuslugi или
> > sberbank.ru. И ваш openssl это проглотит.
> 
> Теоретически, видимо, можно так сделать. Но бояться не нужно, вы ведь
> сейчас расскажете, почему в браузерах поддержки ГОСТ нет и не будет. ;)
очень смешно.

> 
> > Не надо выставлять собственные проблемы как проблемы мифических
> > "пользователей".
> 
> +1
> 
> Согласен, давайте не будем додумывать друг за друга, насколько актуальна
> поставленная задача. А задача на данный момент такова — задействовать
> имеющуюся весьма развитую PKI. Которая уже существует и прекрасно работает.
> Учитывая при этом, конечно же, возможные нюансы вроде «хакера Васи» и
> сайта Госуслуг.
Давайте займемся развитием поддержки PKI Северной Кореи и Китая, там же
большой рынок и куча пользователей, если перефразировать вашу шутку.

-- 
WBR et al.

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Dmitry Derjavin]

Вт, 01 авг 2017, 21:24, Konstantin Lepikhov:

>> >> https://e-trust.gosuslugi.ru/CA
>> > А где можно ознакомиться с регламентом предоставления статуса ЦА и
>> > отчетом аудита, что данные ЦА являются ЦА?
>> 
>> Видимо, там же, где и с данными о статусе аудитора и отчёте о
>> подтверждении его аутентичности.
> т.е. спросить товарища майора?

Вы имеете в виду официальный запрос в ФСБ? Да, это один из вариантов.

>> > Официальной поддержки ГОСТ в браузерах нет и не предвидится по целому
>> > ряду факторов, если интересно я могу их озвучить отдельным письмом но об
>> > этом знают и в руководстве ООО.
>> 
>> Да, это действительно очень интересно! Озвучьте, пожалуйста.
> https://bugzilla.mozilla.org/show_bug.cgi?id=518787#c19

Думаю, что сейчас, спустя 7 лет, эти инсинуации уже, к счастью, не имеют
особого значения. Во многом — благодаря работе ТК26.

>> Не-не, речь о том, чтобы добавить сертификаты УЦ, аккредитованных
>> Минкомсвязью. Которыми подписаны, например, сертификаты физических лиц.
>> Не сайтов. Чтобы иметь возможность проверить данные этих сертификатов.
> Насколько требования Минкомсвязи соответствуют документу от Mozilla? Как
> используя несертифицированные СКЗИ вы сможете убедиться в достоверности
> этих сертификатов?

Для того, чтобы убедиться в достоверности сертификатов, не нужны
сертифицированные СКЗИ. Этот же момент сознательно или специально
эксплуатировали те, кому отвечал автор комментария по ссылке выше.

Смотрите, сейчас речь идёт не только о применении ГОСТ там, где его
обязательно нужно применять. Наоборот — идея в том, чтобы задействовать
имеющуюся инфраструктуру также и «в мирных целях».

-- 
~dd

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Konstantin Lepikhov]

Hi Dmitry!

On 08/01/17, at 10:47:47 PM you wrote:

<skip>
> Думаю, что сейчас, спустя 7 лет, эти инсинуации уже, к счастью, не имеют
> особого значения. Во многом — благодаря работе ТК26.
У вас свой мир, у остальных свой. И если вы живете вместе с товарищем
майором и считаете это правильным, не надо это обобщать на других. В
Mozilla, как и в остальном мире, не интересно куда прос$#%#$ потратили
деньги налогоплательщиков на игрушки под названием "Электронная Россия",
ФСТЭК или ТК26.

> 
> >> Не-не, речь о том, чтобы добавить сертификаты УЦ, аккредитованных
> >> Минкомсвязью. Которыми подписаны, например, сертификаты физических лиц.
> >> Не сайтов. Чтобы иметь возможность проверить данные этих сертификатов.
> > Насколько требования Минкомсвязи соответствуют документу от Mozilla? Как
> > используя несертифицированные СКЗИ вы сможете убедиться в достоверности
> > этих сертификатов?
> 
> Для того, чтобы убедиться в достоверности сертификатов, не нужны
> сертифицированные СКЗИ. Этот же момент сознательно или специально
> эксплуатировали те, кому отвечал автор комментария по ссылке выше.
Как вы проверите достоверность промежуточного ЦА не имея в наличии
корневой сертификат?

> 
> Смотрите, сейчас речь идёт не только о применении ГОСТ там, где его
> обязательно нужно применять. Наоборот — идея в том, чтобы задействовать
> имеющуюся инфраструктуру также и «в мирных целях».
Есть поле для деятельности, называется "Платформа от ООО", вот там и
дерзайте в "мирных целях".

-- 
WBR et al.

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Alexey Gladkov]

On Tue, Aug 01, 2017 at 11:17:38PM +0200, Konstantin Lepikhov wrote:
> Hi Dmitry!
> 
> On 08/01/17, at 10:47:47 PM you wrote:
> 
> <skip>
> > Думаю, что сейчас, спустя 7 лет, эти инсинуации уже, к счастью, не имеют
> > особого значения. Во многом — благодаря работе ТК26.
> У вас свой мир, у остальных свой. И если вы живете вместе с товарищем
> майором и считаете это правильным, не надо это обобщать на других. В
> Mozilla, как и в остальном мире, не интересно куда прос$#%#$ потратили
> деньги налогоплательщиков на игрушки под названием "Электронная Россия",
> ФСТЭК или ТК26.

Госпада, давайте не выходить за рамки.

Вместе с тем, я хочу отметить, что эти "инсинуации" всё ещё имеют значение
и чтобы добавить ГОСТ в апстрим nss авторам патча предётся приложить
определённые усилия.

-- 
Rgrds, legion

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Konstantin Lepikhov]

Hi Aleksey!

On 08/02/17, at 12:32:00 AM you wrote:

> 2 авг. 2017 г. 12:17 AM пользователь "Konstantin Lepikhov" <
> lakostis@altlinux.org> написал:
> 
> Hi Dmitry!
> 
> On 08/01/17, at 10:47:47 PM you wrote:
> 
> <skip>
> > Думаю, что сейчас, спустя 7 лет, эти инсинуации уже, к счастью, не имеют
> > особого значения. Во многом — благодаря работе ТК26.
> У вас свой мир, у остальных свой. И если вы живете вместе с товарищем
> майором и считаете это правильным, не надо это обобщать на других. В
> Mozilla, как и в остальном мире, не интересно куда прос$#%#$ потратили
> деньги налогоплательщиков на игрушки под названием "Электронная Россия",
> ФСТЭК или ТК26.
> 
> 
> 
> 
> Прошу _тут_ без политики.
> Замечу, что роль "товарища майора", который все сводит к политике, играете
> тут Вы и пока только Вы. Пожалуйста, не надо.
Если ко мне лезут с политикой ответ будет соответствущий. По существу -
есть американский FIPS и есть процедура валидации на соответствие
стандарту FIPS, длинный документ, но он в открытом доступе, каждый может
ознакомится:

http://csrc.nist.gov/groups/STM/cavp/validation.html

Расскажите, где достать этот документ для Российской криптографии?

-- 
WBR et al.

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Vitaly Lipatov]

Konstantin Lepikhov писал 1.8.17 21:24:
...
>> > А где можно ознакомиться с регламентом предоставления статуса ЦА и
>> > отчетом аудита, что данные ЦА являются ЦА?
>> 
>> Видимо, там же, где и с данными о статусе аудитора и отчёте о
>> подтверждении его аутентичности.
> т.е. спросить товарища майора?
Возможно, следует начать с порядка аккредитации:
https://e-trust.gosuslugi.ru/AccreditationProcess


>> > Официальной поддержки ГОСТ в браузерах нет и не предвидится по целому
>> > ряду факторов, если интересно я могу их озвучить отдельным письмом но об
>> > этом знают и в руководстве ООО.
>> 
>> Да, это действительно очень интересно! Озвучьте, пожалуйста.
> https://bugzilla.mozilla.org/show_bug.cgi?id=518787#c19
В этой баге написана какая-то ерунда. Кроме того, что за 5 лет так и не 
приняли патч, никакого конструктива там не видно. Можно перевести на 
русский хоть один фактор, кроме вранья о том, что использование не 
сертифицированной криптографии может быть криминальным?

...
>> Не-не, речь о том, чтобы добавить сертификаты УЦ, аккредитованных
>> Минкомсвязью. Которыми подписаны, например, сертификаты физических 
>> лиц.
>> Не сайтов. Чтобы иметь возможность проверить данные этих сертификатов.
> Насколько требования Минкомсвязи соответствуют документу от Mozilla?
Mozilla Firefox — не единственный  браузер. И я сомневаюсь, что документ 
от Mozilla соответствует требованиям Минкомсвязи. И пока для меня некие 
правила на таком уровне выглядят не более, чем предрассудки. Говоря 
по-другому, всем известно, что продажа SSL-сертификатов — это продажа 
воздуха за хорошие деньги, а люди 20 лет этим занимались и довольно 
успешно.

> Как используя несертифицированные СКЗИ вы сможете убедиться в 
> достоверности этих сертификатов?
Повторюсь,
https://www.altlinux.org/ГОСТ_в_OpenSSL
Берём openssl и проверяем, сертификаты все стандартные, не вижу проблем.

>> > Например, компьютер в сети администрации Х будет хакнут хакером Васей,
>> > который потом переподпишет этими сертификатами имена gosuslugi или
>> > sberbank.ru. И ваш openssl это проглотит.
Сертификаты публикует не администрация Х, а уполномоченный федеральный 
орган на странице
https://e-trust.gosuslugi.ru/CA
и подписывает список своим ключом.

Векторы атаки лучше обсуждать с ними.


>> > Не надо выставлять собственные проблемы как проблемы мифических
>> > "пользователей".
Какие собственные проблемы? Есть ресурсы, к которым нужно подключаться, 
используя выданные в РФ сертификаты. Это торговые площадки, ГосУслуги, 
налоговая (сдача налоговой отчётности). И их становится всё больше. И 
да, у меня, как одного из пользователей всего этого, есть такие 
проблемы.

Не надо грубить, это невежливо.




-- 
С уважением,
Виталий Липатов,
Etersoft

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Vitaly Lipatov]

Konstantin Lepikhov писал 1.8.17 18:47:
> Hi Vitaly!
> 
> On 08/01/17, at 12:31:07 AM you wrote:
> 
>> 
>> Прошу помощи в обсуждении ситуации с корневыми сертификатами, которые 
>> у
>> нас помещаются пакетом ca-certificates в
>> /usr/share/ca-certificates/ca-bundle.crt и (в идеале) используются 
>> всеми
>> средствами работы с сертификатами.
> До сих пор не используются, но такой файл есть и про него знает 
> openssl.
Он про него знает всего лишь с помощью /var/lib/ssl/cert.pem is link to 
/usr/share/ca-certificates/ca-bundle.crt

...
>> После этого совершенно свободно удалось проверить подпись на 
>> упомянутом
>> XML-файле с помощью xmlsec и модуля xmlsec-openssl.
> Если напрячься то можно и не так раскорячится. Ну проверили вы что-то,
> через какой-то блоб, дальше то что?
Я проверил не что-то, а файл, содержащий сертификаты всех УЦ, 
публикуемый уполномоченным органом.
Не через блоб, а обычным openssl. Надеюсь, openssl engine, добавляющий 
поддержку ГОСТ, блобом не считается?

>> Поскольку нынешняя архитектура не предусматривает подключение
>> промежуточных сертификатов, хочу посоветоваться, что мы с ними будем
>> делать.
> Нынешняя архитектура предусматривает работу openssl через список
> сертификатов, которые прошли процедуру доверия в Mozilla в соответствии 
> с
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
> 
> Все остальное не является сертификатами, которым можно доверять как
> корневым. Данная система гарантирует, что у вас на уровне утилит 
> которые
Вопрос доверия на самом деле достаточно условный. Мы же много лет 
наблюдали за тем, как CACert, выдававший сертификаты бесплатно, так и не 
допустили (и я уверен, из-за нежелания терять доходы), а Let's Encrypt 
раз и взлетел без проблем. Вы вот доверяете инфраструктуре выдачи и 
получения ключей, предлагаемой Let's Encrypt?

> используют libssl будет ровно такое же поведение как и при 
> использовании
> браузеров Firefox и Chromium.
Пока не понял, зачем нужно одинаковое поведение, поэтому не впечатлился.

...
>> Насколько я понимаю ситуацию в мире веб-сервисов (смотрю на примере
>> nginx, postfix, jabberd2 и т.п.) с установленными SSL-сертификатами, 
>> там
>> приходится применять следующий подход: указывается не только
>> сертификат, полученный для сайта, но ещё и все промежуточные
>> сертификаты, чтобы клиент, имеющий скудный набор корневых сертификатов
>> (в браузере или в ca-bundle.crt) мог удостовериться в его подлинности.
> А еще в браузерах используется CRL URL и OCSP для проверки и еще 
> некоторые
> техники, гарантирующие что ваша база сертификатов не скомпрометирована.
> Сертификат вам как таковой гарантирует только целостность данных а их 
> не
> подлинность.
Это очень хорошо, что они там используются. Но на браузерах жизнь не 
заканчивается, и ведь
хочется увидеть такие же механизмы на уровне openssl CLI, и вдобавок не 
привязанные к сети.

И всё же: администраторы веб-сервисов вынуждены выкладывать на сайты 
также и промежуточные сертификаты,
чтобы пользователи (браузеры) могли проверить подлинность сертификата на 
сайт.
Неужели это так замечательно? А где механизм подгрузки промежуточных 
сертификатов?


>> Сертификаты УЦ РФ сейчас практически не используются на сайтах (в
>> основном по причине проблем с браузерами), но планируются к активному
>> использованию в подписывании документов, проверке подписей.
>> Как правило, во всех случаях использования пользователю предлагается
>> скачать и установить необходимую цепочку сертификатов, что при
>> повседневном широкой работе с различными организациями мало приемлемо.
> У вас есть коммерческие заказчики, которые сидят на Сизифе? Думаю, у 
> них
При чём тут Сизиф? У меня вообще не заказчики, но я смотрю на p8 как на 
платформу, на которой ещё долго придётся работать.

...
> поставит что-то от ООО где вместо firefox будет firefox-gost с 
> одобренным
> ФСБ бэкдорами )
Я думаю, прогрессивному мировому сообществу не составит труда обнаружить 
бэкдор в свободном коде.

>> К моему большому удивлению, (в openssl) нет механизма (или я его не
>> заметил) использования нескольких файлов с сертификатами. Даже не
>> существует стандартного пути, и программы (библиотеки), использующие
>> ca-bundle.crt, должны сами указывать к нему путь.
> Вам уже ответили письмом ниже, что все есть в libssl нужно только
> внимательно читать документацию.
Это вы разработчикам Go, Qt и прочим, которые не осилили?
Я подозреваю, что ничего нет в документации.

>> Вопросы:
>> 1. Существуют ли механизмы, упрощающие совмещение нескольких наборов
>> сертификатов
>> (чтобы совместить наборы, идущие в ca-certificates и в
>> ca-gost-certificates), или предложения, как красиво решить этот 
>> вопрос.
> Убедите ФСБ отказаться от сертификации для ГСЦ и вам не нужно будет
> решать эту проблему.
Ещё раз: сейчас у нас сложилась схема, при которой добавить произвольный 
сертификат (для пользователя, для системы) невозможно.
Сравните со структурой хранения и добавления сертификатов в Windows.

>> 2. Существуют ли механизмы, подразумевающие локальное хранение и
>> обновление промежуточных сертификатов?
> ??
В мире конечное число удостоверяющих центров. Я хочу загрузить их все на 
компьютер не обращаться
в сеть за проверкой сертификатов (да и обращаться некуда).
И я спрашивал о том, можно ли сказать openssl, как ему обратиться в 
локальное хранилище промежуточных сертификатов.
Видимо, суть в том, что никто не использует сертификаты, кроме как для 
сайтов.



-- 
С уважением,
Виталий Липатов,
Etersoft

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Alexey Gladkov]

On Wed, Aug 02, 2017 at 01:57:04AM +0300, Vitaly Lipatov wrote:
> Это вы разработчикам Go, Qt и прочим, которые не осилили?
> Я подозреваю, что ничего нет в документации.

Что-то я не очень понял в чём проблема в golang ?

-- 
Rgrds, legion

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Vladimir Didenko]

2 августа 2017 г., 1:57 пользователь Vitaly Lipatov  написал:
> И всё же: администраторы веб-сервисов вынуждены выкладывать на сайты также и
> промежуточные сертификаты,
> чтобы пользователи (браузеры) могли проверить подлинность сертификата на
> сайт.
> Неужели это так замечательно? А где механизм подгрузки промежуточных
> сертификатов?

Во-первых, в чем проблема? При выпуске сертификатов сразу дают нужный
бандл с промежуточными CA, нужно только серверу скормить. Где
неудобство?

Во-вторых, как вы себе это представляете? Если сервер не будет
отдавать сертификаты промежуточных CA, то есть два варианта

1. Запихивать все промежуточные сертификаты на клиент. Но тут сразу
возникают проблемы
 * Их много и они будут жрать место на диске, даже если пользователь
ими не разу не воспользуется
 * Самое главное, этот список весьма динамичный, а программное
обеспечение на машинах может не обновляться годами. В результате, если
не обновляться, то очень быстро пользователь не сможет заходить на
свои любимые сайты.

2. В конечные сертификаты помещать ссылку, по которой можно скачать
промежуточные сертификаты, и загружать их во время установки
соединения. Вообще говоря, в большинстве случаев, эта ссылка в
существующих сертификатах уже есть, и ЕМНИП Internet Explorer умеет по
ним ходить и подгружать недостающие звенья, если сервер, вдруг, вернул
не полную цепочку. Но тут есть одна большая проблема - добавляется
одна лишняя точка отказа, то место откуда скачивается сертификат.
Сейчас это сервера CA, и если все ринутся массово оттуда скачивать
сертификаты, то
 * это будет медленно и увеличит время на установление соединения
 * это приведет к удоражанию сертификатов, поскольку CA придется
изыскивать дополнительные деньги на сервера, которые будут отдавать
промежуточные сертификаты
На самом деле, эта же самая проблема уже стоит с отзывом сертификатов,
когда информация о том отозван сертификат или нет получается от
серверов CA. В результате сложилась ситуация, когда проверка на то,
отозван сертификат или нет является в современных браузерах не
обязательной: получится получить информацию - хорошо, нет - ну и фиг с
ним. Это происходит по тому, что
 * У некоторых CA CRL/OCSP сервера не работают вовсе
 * У тех у кого работает, они работают не стабильно и не справляются с нагрузкой
Так что современная тенденция, это перенести обязанность на
возвращение информации об отзыве сертификата на сам сервер - см. OCSP
stapling.

-- 
С уважением,
Владимир.

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Konstantin Lepikhov]

Hi Vladimir!

On 08/02/17, at 11:32:01 AM you wrote:

<skip>
>  * У некоторых CA CRL/OCSP сервера не работают вовсе
>  * У тех у кого работает, они работают не стабильно и не справляются с нагрузкой
Вы так пишете, будто это прям везде и повмеместно. На самом деле это
происходит с вашим CA, то лучше сменить этот CA на что-то другое,
поскольку недоступность веб-ресурсов это проблема организации
инфраструктуры раздачи контента а не PKI.

> Так что современная тенденция, это перенести обязанность на
> возвращение информации об отзыве сертификата на сам сервер - см. OCSP
> stapling.
Это один из вариантов использования OCSP stapling, на самом деле он создан
совсем для другого - чтобы защититься от MITM атак.

-- 
WBR et al.

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Vladimir Didenko]

2 августа 2017 г., 12:13 пользователь Konstantin Lepikhov написал:

> Вы так пишете, будто это прям везде и повмеместно.

Насколько я знаю, везде и повсеместно. Были добровольцы (читал в
багзилле Mozilla), которые принудительно включали обязательную
проверку revocation статуса - жить с этим не возможно.

>> Так что современная тенденция, это перенести обязанность на
>> возвращение информации об отзыве сертификата на сам сервер - см. OCSP
>> stapling.
> Это один из вариантов использования OCSP stapling, на самом деле он создан
> совсем для другого - чтобы защититься от MITM атак.
>

Я не понял суть замечания. OCSP stapling был создан для того, чтобы
информацию об отзыве сертификата возвращал непосредственно сам TLS
сервер, а не сервер CA. Это то, что я написал. Это ортогонально тому,
что информация об отзыве нужна для предотвращения MITM.

-- 
С уважением,
Владимир.

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Michael Shigorin]

On Tue, Aug 01, 2017 at 11:17:38PM +0200, Konstantin Lepikhov wrote:
> В Mozilla, как и в остальном мире, не интересно куда прос$#%#$
> потратили деньги налогоплательщиков на игрушки под названием
> "Электронная Россия", ФСТЭК или ТК26.

Костик, мне вот интересно, куда "деньги налогоплательщиков"
про2384 Mo[FC]o.  Да, заодно и Брендана Айка как они протеряли.

Осетра урежь, иными словами.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Konstantin Lepikhov]

Hi Vladimir!

On 08/02/17, at 12:24:18 PM you wrote:

> 2 августа 2017 г., 12:13 пользователь Konstantin Lepikhov написал:
> 
> > Вы так пишете, будто это прям везде и повмеместно.
> 
> Насколько я знаю, везде и повсеместно. Были добровольцы (читал в
> багзилле Mozilla), которые принудительно включали обязательную
> проверку revocation статуса - жить с этим не возможно.
У меня она включена везде, проблемы замечал только если пользуешься
каким-нибудь кривым прокси, который режет запросы или пытается засунуть
свой сертификат в сессию.

> > Это один из вариантов использования OCSP stapling, на самом деле он создан
> > совсем для другого - чтобы защититься от MITM атак.
> >
> 
> Я не понял суть замечания. OCSP stapling был создан для того, чтобы
> информацию об отзыве сертификата возвращал непосредственно сам TLS
> сервер, а не сервер CA. Это то, что я написал. Это ортогонально тому,
> что информация об отзыве нужна для предотвращения MITM.
Окей, это один из вариантов использования:

> While it may appear that allowing the site operator to control
> verification responses would allow a fraudulent site to issue false
> verification for a revoked certificate, the stapled responses can't be
> forged as they need to be directly signed by the certificate authority,
> not the server.
https://en.wikipedia.org/wiki/OCSP_stapling#cite_note-Gibson-OCSP-Must-Staple-3

-- 
WBR et al.

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Paul Wolneykien]

02.08.2017 12:59, Aleksey Novodvorsky пишет:
> 
> 
> 2 авг. 2017 г. 12:56 PM пользователь "Michael Shigorin"
> <mike@altlinux.org <mailto:mike@altlinux.org>> написал:
> 
>     On Tue, Aug 01, 2017 at 11:17:38PM +0200, Konstantin Lepikhov wrote:
>     > В Mozilla, как и в остальном мире, не интересно куда прос$#%#$
>     > потратили деньги налогоплательщиков на игрушки под названием
>     > "Электронная Россия", ФСТЭК или ТК26.
> 
>     Костик, мне вот интересно, куда "деньги налогоплательщиков"
>     про2384 Mo[FC]o.  Да, заодно и Брендана Айка как они протеряли.
> 
> 
> В курилку!
> Неужели нельзя сдержаться и не выходить за тематику devel@?

  Если отвлечься от формы, то видно, что коллеги спорят о
целесообразности работы над проблемой, об уровнях безопасности гостовой
и "западной" криптографий и об уровнях доступа к ней "гостовых" и
западных спецслужб соответственно. ИМХО, по содержанию, всё это
укладывается в тематику devel@, поскольку каждый FSF developer, так или
иначе, берёт на себя ответственность за безопасность пользователя, даже
не смотря на "ABS. NO WARRANTY" и т.д.

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

On Wed, Aug 02, 2017 at 01:39:03PM +0300, Paul Wolneykien wrote:
>   Если отвлечься от формы, то видно, что коллеги спорят о
> целесообразности работы над проблемой, об уровнях безопасности гостовой
> и "западной" криптографий и об уровнях доступа к ней "гостовых" и
> западных спецслужб соответственно. ИМХО, по содержанию, всё это
> укладывается в тематику devel@, поскольку каждый FSF developer, так или
> иначе, берёт на себя ответственность за безопасность пользователя, даже
> не смотря на "ABS. NO WARRANTY" и т.д.

Нет.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Alexey Gladkov]

On Wed, Aug 02, 2017 at 01:39:03PM +0300, Paul Wolneykien wrote:
> 02.08.2017 12:59, Aleksey Novodvorsky пишет:
> > 
> > 
> > 2 авг. 2017 г. 12:56 PM пользователь "Michael Shigorin"
> > <mike@altlinux.org <mailto:mike@altlinux.org>> написал:
> > 
> >     On Tue, Aug 01, 2017 at 11:17:38PM +0200, Konstantin Lepikhov wrote:
> >     > В Mozilla, как и в остальном мире, не интересно куда прос$#%#$
> >     > потратили деньги налогоплательщиков на игрушки под названием
> >     > "Электронная Россия", ФСТЭК или ТК26.
> > 
> >     Костик, мне вот интересно, куда "деньги налогоплательщиков"
> >     про2384 Mo[FC]o.  Да, заодно и Брендана Айка как они протеряли.
> > 
> > 
> > В курилку!
> > Неужели нельзя сдержаться и не выходить за тематику devel@?
> 
>   Если отвлечься от формы, то видно, что коллеги спорят о
> целесообразности работы над проблемой, об уровнях безопасности гостовой
> и "западной" криптографий и об уровнях доступа к ней "гостовых" и
> западных спецслужб соответственно. ИМХО, по содержанию, всё это
> укладывается в тематику devel@, поскольку каждый FSF developer, так или
> иначе, берёт на себя ответственность за безопасность пользователя, даже
> не смотря на "ABS. NO WARRANTY" и т.д.

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

Но я бы всё-таки подождал с обсуждением этого вопроса, как уже просил
Дима.

-- 
Rgrds, legion

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Paul Wolneykien]

02.08.2017 16:16, Павел Исопенко пишет:
> Добрый день.
> 
> 02.08.2017 14:03, Alexey Gladkov пишет:
>> Тема безусловно горячая т.к. не все мантейнеры пакетов сизифа проживают в
>> России, не говоря уже о пользователях. Поэтому безусловное добавление
>> специфичных сертификатов мне кажется спорным решением.
> Согласен. Как инициатор упоминавшегося выше
> https://bugzilla.altlinux.org/show_bug.cgi?id=33498, склоняюсь к
> варианту всё-таки условного добавления специфичных сертификатов решением
> администратора конкретной системы. Другое дело, что механизм добавления
> крайне желательно запроектировать более-менее удобным и пригодным для
> автоматизации. Может быть Alterator?

  +1. А если иерархия УЦ РФ подразделяется на какие-то достаточно
крупные самостоятельные части, то стоит, наверное, так и представить это
для пользователя. Примерно так, как сейчас выбираются группы пакетов в
инсталляторе. Чтобы можно было указать: вот этим доверяю, а вот этим — нет.

  И в принципе, всё это относится также и к "западным" сертификатам,
разве нет? Взять ту же историю с WoSign: одни люди склонны ей доверять,
а другие — нет.
  Так что может быть имеет смысл сделать единый модуль
"alterator-trusted-cas", в котором пользователь мог бы включать и
выключать группы доверенных корневых сертификатов, как RSA, так и ГОСТ
или что-то иное.
В том числе при установке системы.

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Paul Wolneykien]

02.08.2017 16:29, Aleksey Novodvorsky пишет:
> Возможно.
> 
>     В том числе при установке системы.
> 
> Не стоит перегружать разными функциями установщик. Опытный пользователь
> сам настроит систему, а начинающего это вгонит в ступор.

  Да. Но это решается через flavour установщика. Может быть для меня
критично, чтобы первый запуск системы совершался с правильным набором
сертификатов. И мы сможем сделать такой образ.

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Konstantin Lepikhov]

Hi Paul!

On 08/02/17, at 04:24:41 PM you wrote:

<skip>
>   +1. А если иерархия УЦ РФ подразделяется на какие-то достаточно
> крупные самостоятельные части, то стоит, наверное, так и представить это
> для пользователя. Примерно так, как сейчас выбираются группы пакетов в
> инсталляторе. Чтобы можно было указать: вот этим доверяю, а вот этим — нет.
Это все имеет очень косвенное отношение к проблеме. Проблема в том, что
предлагается упростить правила по обеспечению безопасности списка
доверенных корневых сертификатов на уровне системы с формулировкой "я не хочу
заморачиваться, сделайте красиво". К сожалению, тут такие формулировки
неуместны. Неважно какие сертификаты и от какого УЦ там будут, это просто
работает по другому: когда есть формальные критерии и изменения им
удовлетворяют.

Я привел документ (Mozilla Root Store policy)[1], на котором основан список
сертификатов ca-bundle в системе, и хотелось бы получить что-то со стороны
сторонников "по мирному" и "инсинуаций".

PS Mozilla тут только в качестве хранителя ресурса, сертификацией и
поддержкой NSS вообще-то занимается RedHat[2].

1. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
2. https://wiki.mozilla.org/FIPS_Validation

-- 
WBR et al.

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Vitaly Lipatov]

Alexey Gladkov писал 2.8.17 2:48:
> On Wed, Aug 02, 2017 at 01:57:04AM +0300, Vitaly Lipatov wrote:
>> Это вы разработчикам Go, Qt и прочим, которые не осилили?
>> Я подозреваю, что ничего нет в документации.
> 
> Что-то я не очень понял в чём проблема в golang ?

Я приводил багу об этом в первом письме:
GO не находит корневой сертификат
https://bugzilla.altlinux.org/show_bug.cgi?id=29449

Проблема в том, что разработчикам по явно архитектурной недоработке 
приходится в каждой программе / библиотеке самостоятельно отслеживать 
расположение файла с сертификатами,который к тому же скачет в 
зависимости от дистрибутива.

-- 
С уважением,
Виталий Липатов,
Etersoft

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Vitaly Lipatov]

Vladimir Didenko писал 2.8.17 11:32:
> 2 августа 2017 г., 1:57 пользователь Vitaly Lipatov  написал:
>> И всё же: администраторы веб-сервисов вынуждены выкладывать на сайты 
>> также и
>> промежуточные сертификаты,
>> чтобы пользователи (браузеры) могли проверить подлинность сертификата 
>> на
>> сайт.
>> Неужели это так замечательно? А где механизм подгрузки промежуточных
>> сертификатов?
> 
> Во-первых, в чем проблема? При выпуске сертификатов сразу дают нужный
> бандл с промежуточными CA, нужно только серверу скормить. Где
> неудобство?
Проблемы нет, если владелец сервиса способен собрать всю цепочку 
сертификатов, и даже принуждён это сделать. Возможно, что деятели с 
ГОСТ-сертификатами просто не умеют или не считают нужным это делать.

> Во-вторых, как вы себе это представляете? Если сервер не будет
> отдавать сертификаты промежуточных CA, то есть два варианта
> 
> 1. Запихивать все промежуточные сертификаты на клиент. Но тут сразу
> возникают проблемы
>  * Их много и они будут жрать место на диске, даже если пользователь
> ими не разу не воспользуется
Надуманная проблема? Знаете сколько гигабайт библиотек у меня в системе, 
которыми я ни разу не воспользуюсь. Тут не до подсчётов нескольких 
десятков мегабайт.

>  * Самое главное, этот список весьма динамичный, а программное
> обеспечение на машинах может не обновляться годами. В результате, если
> не обновляться, то очень быстро пользователь не сможет заходить на
> свои любимые сайты.
Вы правда считаете, что может быть такая Линукс-система, которая не 
будет обновляться годами, но у неё будет пользователь, заходящий на 
сайты? Мне кажется, она долго не проживёт. В наше время надо либо 
обновляться, либо не заходить на сайты. Как вариант, можно обновлять 
только список сертификатов, это вопрос регламента.

> 
> 2. В конечные сертификаты помещать ссылку, по которой можно скачать
> промежуточные сертификаты, и загружать их во время установки
> соединения. Вообще говоря, в большинстве случаев, эта ссылка в
> существующих сертификатах уже есть, и ЕМНИП Internet Explorer умеет по
> ним ходить и подгружать недостающие звенья, если сервер, вдруг, вернул
Вот мне радость от того, что IE умеет что-то :)

Спасибо за комментарий!


-- 
С уважением,
Виталий Липатов,
Etersoft

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Alexey Gladkov]

On Wed, Aug 02, 2017 at 05:34:57PM +0300, Vitaly Lipatov wrote:
> Alexey Gladkov писал 2.8.17 2:48:
> > On Wed, Aug 02, 2017 at 01:57:04AM +0300, Vitaly Lipatov wrote:
> >> Это вы разработчикам Go, Qt и прочим, которые не осилили?
> >> Я подозреваю, что ничего нет в документации.
> > 
> > Что-то я не очень понял в чём проблема в golang ?
> 
> Я приводил багу об этом в первом письме:
> GO не находит корневой сертификат
> https://bugzilla.altlinux.org/show_bug.cgi?id=29449

Эта бага закрыта 4 года назад. Список приведённый в этой баге показывает,
что нет стандартного места, где должны быть расположены сертификаты. Это
не проблема языка.

> Проблема в том, что разработчикам по явно архитектурной недоработке 
> приходится в каждой программе / библиотеке самостоятельно отслеживать 
> расположение файла с сертификатами,который к тому же скачет в 
> зависимости от дистрибутива.

Я всё ещё не понимаю о какой недоработке ты говоришь.

Что мы держим ca-bundle.crt не там, где большинство дистрибутивов ?

-- 
Rgrds, legion

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Vitaly Lipatov]

Alexey Gladkov писал 2.8.17 18:29:
> On Wed, Aug 02, 2017 at 05:34:57PM +0300, Vitaly Lipatov wrote:
>> Alexey Gladkov писал 2.8.17 2:48:
>> > On Wed, Aug 02, 2017 at 01:57:04AM +0300, Vitaly Lipatov wrote:
>> >> Это вы разработчикам Go, Qt и прочим, которые не осилили?
>> >> Я подозреваю, что ничего нет в документации.
>> >
>> > Что-то я не очень понял в чём проблема в golang ?
>> 
>> Я приводил багу об этом в первом письме:
>> GO не находит корневой сертификат
>> https://bugzilla.altlinux.org/show_bug.cgi?id=29449
> 
> Эта бага закрыта 4 года назад. Список приведённый в этой баге 
> показывает,
> что нет стандартного места, где должны быть расположены сертификаты. 
> Это
> не проблема языка.
Это не проблема языка. Возможно, проблема отсутствия стандартизации или 
механизма, позволяющего получить доступ к набору сертификатов. Допустим, 
проблема отсутствия crypto api на платформе.

> 
>> Проблема в том, что разработчикам по явно архитектурной недоработке
>> приходится в каждой программе / библиотеке самостоятельно отслеживать
>> расположение файла с сертификатами,который к тому же скачет в
>> зависимости от дистрибутива.
> 
> Я всё ещё не понимаю о какой недоработке ты говоришь.
> 
> Что мы держим ca-bundle.crt не там, где большинство дистрибутивов ?
Нет, нет, только о том, что для Linux-платформ что-то не додумали на 
тему доступного для различных потребителей хранилища сертификатов.

Вот Владимир спрашивал
> А X509_get_default_cert_*() не решают эту проблему?

Это то самое, о чём я спрашиваю? Надо будет проверить.

Вот как вопрос с получением пути решён в библиотеке python requests

# cat /usr/lib/python2.7/site-packages/requests/certs.py
#!/usr/bin/env python
# -*- coding: utf-8 -*-

"""
requests.certs
~~~~~~~~~~~~~~

This module returns the preferred default CA certificate bundle.

If you are packaging Requests, e.g., for a Linux distribution or a 
managed
environment, you can change the definition of where() to return a 
separately
packaged CA bundle.

We return "/etc/pki/tls/certs/ca-bundle.crt" provided by the 
ca-certificates
package.
"""

try:
     from certifi import where
except ImportError:
     def where():
         """ Don't use the certs bundled with requests, use 
ca-certificates. """
         return "/etc/pki/tls/certs/ca-bundle.crt"


И они уже три года обсуждают, что же тут можно сделать
https://github.com/requests/requests/pull/1907


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



-- 
С уважением,
Виталий Липатов,
Etersoft

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Yury A. Romanov]

On 01.08.2017 22:47, Dmitry Derjavin wrote:
> Вт, 01 авг 2017, 21:24, Konstantin Lepikhov:
> 
>>>>> https://e-trust.gosuslugi.ru/CA
>>>> А где можно ознакомиться с регламентом предоставления статуса ЦА и
>>>> отчетом аудита, что данные ЦА являются ЦА?
>>>
>>> Видимо, там же, где и с данными о статусе аудитора и отчёте о
>>> подтверждении его аутентичности.
>> т.е. спросить товарища майора?
> 
> Вы имеете в виду официальный запрос в ФСБ? Да, это один из вариантов.
> 
>>>> Официальной поддержки ГОСТ в браузерах нет и не предвидится по целому
>>>> ряду факторов, если интересно я могу их озвучить отдельным письмом но об
>>>> этом знают и в руководстве ООО.
>>>
>>> Да, это действительно очень интересно! Озвучьте, пожалуйста.
>> https://bugzilla.mozilla.org/show_bug.cgi?id=518787#c19
> 
> Думаю, что сейчас, спустя 7 лет, эти инсинуации уже, к счастью, не имеют
> особого значения. Во многом — благодаря работе ТК26.
> 
Да они и раньше не имели никакого смысла: Мозилла не производит и не 
продаёт СКЗИ. При этом, в апстриме OpenSSL поддержка ГОСТ ещё с версии 
1.0.0, а первые патчи в опенсорсе ещё с 2008 года. Здесь смысл в том, 
что если ты строишь и аттестуешь информационную систему, в требованиях 
которой есть обязательное использование СКЗИ, туда нельзя поставить 
апстримный фаерфокс и сказать, что это СКЗИ.


>>> Не-не, речь о том, чтобы добавить сертификаты УЦ, аккредитованных
>>> Минкомсвязью. Которыми подписаны, например, сертификаты физических лиц.
>>> Не сайтов. Чтобы иметь возможность проверить данные этих сертификатов.
>> Насколько требования Минкомсвязи соответствуют документу от Mozilla? Как
>> используя несертифицированные СКЗИ вы сможете убедиться в достоверности
>> этих сертификатов?
> 
> Для того, чтобы убедиться в достоверности сертификатов, не нужны
> сертифицированные СКЗИ. Этот же момент сознательно или специально
> эксплуатировали те, кому отвечал автор комментария по ссылке выше.
> 
> Смотрите, сейчас речь идёт не только о применении ГОСТ там, где его
> обязательно нужно применять. Наоборот — идея в том, чтобы задействовать
> имеющуюся инфраструктуру также и «в мирных целях».
> 

Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ

[Paul Wolneykien]

01.08.2017 20:51, Paul Wolneykien пишет:
> 01.08.2017 00:31, Vitaly Lipatov пишет:
>> И отдельно риторический вопрос: почему поддержка GOST не включена у нас
>> в openssl из коробки? И хотя бы нет готовой ручки в control.
> 
>   Я только что её написал:
> 
> 
> http://git.altlinux.org/people/manowar/packages/openssl10.git?p=openssl10.git;a=commitdiff;h=e82035a81d673cea76e3e1f59d8bdc4524b21b36

  Ручка в control называется openssl-gost. Имеет два состояния "enabled"
и "disabled". При включении, в openssl.cnf вносятся изменения, описанные
на странице https://www.altlinux.org/ГОСТ_в_OpenSSL . Контрол упакован в
один пакет с /usr/lib/openssl/engines/libgost.so, чтобы пользователь,
установивший эту библиотеку, всегда мог включить её поддержку одной
командой.

  Прошу понять и пропустить в Сизиф (#186615:500).