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

[Pavel Isopenko]

02.08.2017 17:05, 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
>
При всём уважении к формальным критериям, в экосистеме RedHat мы видим
также и  update-ca-trust
<https://www.happyassassin.net/2015/01/14/trusting-additional-cas-in-fedora-rhel-centos-dont-append-to-etcpkitlscertsca-bundle-crt-or-etcpkitlscert-pem/>
.
Положим, необходимость соблюдения должных правил при опакечивании
цепочек доверия - никто не отрицает. Однако начали-то мы с проблем не
безопасности, но функциональности!
Да, речь действительно идёт о некотором упрощении жизни администратора,
и при некоторых обстоятельствах он может таким образом нанести ущерб
безопасности своей системы. Однако обращаю внимание на тот факт, что
суперпользователь по-любому сделает так как ему покажется правильным, и
попытка воспрепятствовать по сути - security through obscurity. И
вообще, кажется мы пытаемся "заморочить и сделать некрасиво" тому, кто
может при желании взять какой-нибудь более другой дистрибутив? Вот это
полагаю по-настоящему неуместным.

Моё мнение: правила аудита сертификатов перед опакечиванием - перевести,
опубликовать и принять в качестве Policy. Но это имеет косвенное
отношение к обсуждаемой проблеме.

-- 
С уважением, *Павел Исопенко*
тел. +79165329582
email: pauli на altlinux.org
XMPP: pavelri на jabber.credoaudit.ru
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20170802/dee8972f/attachment.html>