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

[Vitaly Lipatov <lav@altlinux.ru>]

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