From: Konstantin Lepikhov <lakostis@altlinux.org> To: ALT Linux Team development discussions <devel@lists.altlinux.org> Subject: Re: [devel] Взгляд на сертификаты в /usr/share/ca-certificates/ca-bundle.crt и сертификаты УЦ РФ Date: Tue, 1 Aug 2017 17:47:06 +0200 Message-ID: <20170801154706.GA13538@lks.home> (raw) In-Reply-To: <85c03fbd591d2075720764d1c19e7b33@altlinux.ru> 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.
next prev parent reply other threads:[~2017-08-01 15:47 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-07-31 21:31 Vitaly Lipatov 2017-08-01 6:06 ` Vladimir Didenko 2017-08-01 8:54 ` Paul Wolneykien 2017-08-01 14:22 ` Dmitry V. Levin 2017-08-01 15:47 ` Konstantin Lepikhov [this message] 2017-08-01 16:26 ` Dmitry Derjavin 2017-08-01 18:24 ` Konstantin Lepikhov 2017-08-01 19:47 ` Dmitry Derjavin 2017-08-01 21:17 ` Konstantin Lepikhov 2017-08-01 21:31 ` Alexey Gladkov 2017-08-01 21:47 ` Konstantin Lepikhov 2017-08-02 9:55 ` Michael Shigorin 2017-08-02 10:39 ` Paul Wolneykien 2017-08-02 10:48 ` Dmitry V. Levin 2017-08-02 11:03 ` Alexey Gladkov 2017-08-02 13:24 ` Paul Wolneykien 2017-08-02 13:30 ` Paul Wolneykien 2017-08-02 14:05 ` Konstantin Lepikhov 2017-08-04 11:36 ` Yury A. Romanov 2017-08-01 22:37 ` Vitaly Lipatov 2017-08-01 22:57 ` Vitaly Lipatov 2017-08-01 23:48 ` Alexey Gladkov 2017-08-02 14:34 ` Vitaly Lipatov 2017-08-02 15:29 ` Alexey Gladkov 2017-08-02 16:24 ` Vitaly Lipatov 2017-08-02 8:32 ` Vladimir Didenko 2017-08-02 9:13 ` Konstantin Lepikhov 2017-08-02 9:24 ` Vladimir Didenko 2017-08-02 10:21 ` Konstantin Lepikhov 2017-08-02 14:41 ` Vitaly Lipatov 2017-08-01 17:51 ` Paul Wolneykien 2017-08-04 11:40 ` Paul Wolneykien
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20170801154706.GA13538@lks.home \ --to=lakostis@altlinux.org \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git