[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.