Re: [devel] [sisyphus] Q: SSL in ALT Linux

Re: [devel] [sisyphus] Q: SSL in ALT Linux

[Dmitry V. Levin]

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

Обсуждать policy IMHO лучше в devel@.

On Mon, Jan 22, 2007 at 02:18:20AM +0300, Mikhail Yakshin wrote:
> Dmitry V. Levin wrote:
> > On Sun, Jan 21, 2007 at 05:29:04AM +0300, Mikhail Yakshin wrote:
> >> А не может ли кто-нибудь прояснить ситуацию, которая складывается в ALT
> >> Linux с SSL, в частности - есть ли какой-то общий единый CA root ALT
> >> Linux, сертификат которого бы включался в дистрибутив и обязывался бы к
> >> использованию и принятию всеми программами (в основном - клиентами).
> 
> [...]
> 
> > Я вижу разумным сделать новый root CA, положить его в пакеты и дальше
> > использовать.
> > 
> >> Ну и, соответственно, вопрос в продолжение первого - если таковая
> >> authority все-таки будет воскрешена - какова политика получения
> >> удостоверенных ею сертификатов?
> > 
> > Политику предстоит утвердить.  Какие будут предложения?
> 
> Предлагаю сделать нечто вроде SSL policy и закрепить в ней примерно
> следующие основные пункты:
> 
> ==========================================================================
> 
> 1. Существует ALT root CA, принадлежащий ООО (как и все остальные
> основные подписи и ключи по репозитариями и по проекту в целом).

Я сомневаюсь в том, что всё это принадлежит OOO.

> 1.1. Сертификат имеет CN=<такой-то>, OU=<такой-то>, O=<такой-то>,
> C=<такой-то> (и т.п.)
> 1.2. Срок действия CA устанавливается в <X> лет.

А какой срок является традиционным?  3 года?  5 лет?

> 1.3. Его поддержанием, регенерацией, выписыванием сертификатов
> занимается <видимо, кто-то из суппорта?>

Это мы уже проходили.  К сожалению, в суппорте для этого слишком низкая
мера ответственности.  Думаю что security@altlinux для этого лучше
подходит.

> 1.4. Регенерация делается за <полгода> до окончания срока действия
> очередного основного CA: генерируется новый сертификат и в эти полгода
> все носят 2 сертификата. Старый сертификат выкидывается отовсюду по
> возможности, как его срок действия совсем заканчивается.

Судя по опыту замены gpg-ключей, полгода будет мало.  Лучше если год.

> 1.5. Сертификат всегда доступен для скачивания с
> <https://tls.altlinux.org>, а также в пакете openssl (из тех
> соображений, что он у нас наиболее системообразующий).
> 
> 2. Все https-серверы и XMMP-серверы ALT (как минимум, перечисленные в
> gory details в первом письме) используют сертификаты, выписанные этим
> ALT root CA.
> 
> 2.1. Сертификаты должны иметь корректно установленные, в том числе,
> например, правильный CN.
> 2.2. Т.к. есть, как минимум, 3 домена (altlinux.org, altlinux.ru,
> altlinux.com), видимо, на каждый сервис нужно выписывать 3 сертификата.

Точнее говоря, на каждый поддерживаемый этим сервисом домен.

> 2.3. Там, где https объективно не нужен - его вообще быть не должно, 443
> порт закрыт.

Мне кажется, что это требование более универсально, чем SSL policy.

> 3. Все члены команды ALT имеют право попросить заверенные этим CA
> сертификаты в любом количестве для своих личных нужд.

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

> Пункт 4
> гарантирует, что такой сертификат, заверенный ALT, будет, как минимум,
> восприниматься всеми системами, работающими под управлением ALT Linux.
> 
> 3.1. Сертификаты, подписанные этим CA, для третьих лиц и организаций, не
> являющихся членами команды ALT, распространяются ООО по своему усмотрению.
> 
> 4. Все пакеты в Сизифе, которые могут использоваться в качестве клиентов
> для доступа к серверам к TLS/SSL и которые не используют обычные
> системные хранилища сертификатов, должны носить в своем списке CA
> дополнительно еще и ALT root CA, и, таким образом.
> 
> 4.1. Проверить работоспособность клиента в плане принятия сертификатов
> ALT можно на https://bugs.altlinux.org/ и на xmpp://altlinux.org
> 4.2. Несоответствие пакета пункту 4 настоящей policy - <block> bug.
> 
> 5. Все пакеты в Сизифе, которые могут использоваться как серверы с
> TLS/SSL должны иметь упоминание (например, в README.alt) о наличии ALT
> root CA, о пункте 3 и давать ссылку на настоящую policy.
> 
> 5.1. Примерный текст упоминания (приветствуется изменение его для
> лучшего отражения специфики пакета - http, xmpp, imap-сервер и т.п.):
> 
> Данный пакет позволяет организовать сервер, соединения с которым будут
> защищены с помощью TLS/SSL. Для этого нужен сертификат сервера.
> Сертификат может быть самоподписанным, в таком случае он будет
> восприниматься только ограниченным рядом систем, на каждую такую систему
> его придется переносить вручную. Для того, чтобы его принимало
> автоматически больше систем, нужен сертификат, подписанный какой-то
> известной большинству систем организацией - Certificate Authority.
> 
> В ALT Linux есть собственная Certificate Authority. В соответствии с TLS
>  policy, члены команды ALT могут получать неограниченное число
> подписанных ей сертификатов, которые, таким образом, будут корректно
> приниматься на всех системах ALT Linux.
> 
> Подробности получения сертификатов можно узнать на https://tls.altlinux.org/
> 
> ALT Linux TLS policy доступна на http://<URL где будет лежать policy>

SSL policy или TLS policy? :)

> 5.2. Отсутствия такого текста - <minor> bug.
> 
> ==========================================================================
> 
> Оно же закинуто на http://www.freesource.info/wiki/Altlinux/Policy/TLS
> 
> Прошу помочь вписать значения в <...> и высказаться насчет общего
> видения возможности принятия такой policy.

Не вижу принципиальных трудностей.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [sisyphus] Q: SSL in ALT Linux

[Mikhail Yakshin]

Dmitry V. Levin wrote:

>> Предлагаю сделать нечто вроде SSL policy и закрепить в ней примерно
>> следующие основные пункты:
>>
>> ==========================================================================
>>
>> 1. Существует ALT root CA, принадлежащий ООО (как и все остальные
>> основные подписи и ключи по репозитариями и по проекту в целом).
> 
> Я сомневаюсь в том, что всё это принадлежит OOO.

Кому сейчас принадлежат GPG-ключи, которыми подписывается репозитарий,
пакет openssl и защищаемые сервера *.altlinux.*? Как это лучше
переформулировать?

>> 1.1. Сертификат имеет CN=<такой-то>, OU=<такой-то>, O=<такой-то>,
>> C=<такой-то> (и т.п.)
>> 1.2. Срок действия CA устанавливается в <X> лет.
> 
> А какой срок является традиционным?  3 года?  5 лет?

Ну, вообще, из практики - у коммерческих CA этот срок очень сильно
отличается. Вменяемые и серьезные CA имеют 10 лет, а
среднеестатистические - где-то от 20 лет, а то и под 30.

Большинство самоподписанных сертификатов генерируются часто для галочки
и имеют фактически неограниченный срок действия.

В свое время Thawte и VeriSign на этом очень погорели, когда выпустили
свои первые сертификаты с первыми версиями Netscape на 5 или на 7 лет,
кажется - и потом вдруг столкнулись с тем, что сертификат уже кончается,
а масса народа не обновляло браузеры с тех пор и, вообще говоря, как-то
не особенно планирует обновлять.

Регенерация сертификата CA - даже для нас - я так понимаю, это довольно
нетривиальный набор действий (если только не придумать некий макрос в
RPM, который бы добавлял его автоматически - тогда можно было бы
пересобирать все нужные пакеты роботом и все), а для коммерческих CA -
так совсем неподъемная задача.

Так что, думаю, разумным будет установить этот срок в 10 лет и придумать
некую обвязку, которая бы позволила все пакеты, носящие в себе этот
сертификат быстро пересобрать?

>> 1.3. Его поддержанием, регенерацией, выписыванием сертификатов
>> занимается <видимо, кто-то из суппорта?>
> 
> Это мы уже проходили.  К сожалению, в суппорте для этого слишком низкая
> мера ответственности.  Думаю что security@altlinux для этого лучше
> подходит.

Согласен.

>> 1.4. Регенерация делается за <полгода> до окончания срока действия
>> очередного основного CA: генерируется новый сертификат и в эти полгода
>> все носят 2 сертификата. Старый сертификат выкидывается отовсюду по
>> возможности, как его срок действия совсем заканчивается.
> 
> Судя по опыту замены gpg-ключей, полгода будет мало.  Лучше если год.

Согласен.

>> 1.5. Сертификат всегда доступен для скачивания с
>> <https://tls.altlinux.org>, а также в пакете openssl (из тех
>> соображений, что он у нас наиболее системообразующий).
>>
>> 2. Все https-серверы и XMMP-серверы ALT (как минимум, перечисленные в
>> gory details в первом письме) используют сертификаты, выписанные этим
>> ALT root CA.
>>
>> 2.1. Сертификаты должны иметь корректно установленные, в том числе,
>> например, правильный CN.
>> 2.2. Т.к. есть, как минимум, 3 домена (altlinux.org, altlinux.ru,
>> altlinux.com), видимо, на каждый сервис нужно выписывать 3 сертификата.
> 
> Точнее говоря, на каждый поддерживаемый этим сервисом домен.

Согласен.

>> 2.3. Там, где https объективно не нужен - его вообще быть не должно, 443
>> порт закрыт.
> 
> Мне кажется, что это требование более универсально, чем SSL policy.

Ну, тем не менее -

>> 3. Все члены команды ALT имеют право попросить заверенные этим CA
>> сертификаты в любом количестве для своих личных нужд.
> 
> Это утверждение надо переформулировать таким образом, чтобы исключить
> неправильную трактовку, напр. рост количества сертификатов в
> геометрической прогрессии.

Да в общем - и в геометрической - я ничего особенно страшного не вижу.
Если будет необходимость выписывать их тысячами - для этого есть
всевозможный более-менее свободный софт (всякие http://www.openca.info/,
http://pki.openca.org/ и т.п.), стандартная процедура - запрос
сертификата - выписывание сертификата.

>> ALT Linux TLS policy доступна на http://<URL где будет лежать policy>
> 
> SSL policy или TLS policy? :)

Вообще - лучше использовать термин TLS, он полностью заменил собой SSL
еще в 1999 году.

http://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development

>> 5.2. Отсутствия такого текста - <minor> bug.
>>
>> ==========================================================================
>>
>> Оно же закинуто на http://www.freesource.info/wiki/Altlinux/Policy/TLS
>>
>> Прошу помочь вписать значения в <...> и высказаться насчет общего
>> видения возможности принятия такой policy.
> 
> Не вижу принципиальных трудностей.

Хорошо, тогда, насколько я понимаю - надо дорешать вопросы с
формулировками и можно сделать первые шаги:

1. Сгенерировать этот самый root CA
2. Положить его в пакет openssl
3. Выписать нужные сертификаты на серверы *.altlinux.* и разложить их
где нужно
4. Ввести policy в действие

Мне, соответственно, как мейнтейнеру всяких *qca* будет главным образом
интересно включить в них этот сертификат для xmpp-серверов.

-- 
WBR, Mikhail Yakshin AKA GreyCat
ALT Linux [http://www.altlinux.ru] [xmpp:greycat@altlinux.org]

Re: [devel] Q: SSL/TLS in ALT Linux

[Dmitry V. Levin]

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

Обсуждение SSL/TLS policy с прошлого месяца, цитирую полностью.

On Mon, Jan 22, 2007 at 09:58:55AM +0300, Mikhail Yakshin wrote:
> Dmitry V. Levin wrote:
> 
> >> Предлагаю сделать нечто вроде SSL policy и закрепить в ней примерно
> >> следующие основные пункты:
> >>
> >> ==========================================================================
> >>
> >> 1. Существует ALT root CA, принадлежащий ООО (как и все остальные
> >> основные подписи и ключи по репозитариями и по проекту в целом).
> > 
> > Я сомневаюсь в том, что всё это принадлежит OOO.
> 
> Кому сейчас принадлежат GPG-ключи, которыми подписывается репозитарий,
> пакет openssl и защищаемые сервера *.altlinux.*? Как это лучше
> переформулировать?

Я не знаю, как это лучше переформулировать.  Нужна помощь.

> >> 1.1. Сертификат имеет CN=<такой-то>, OU=<такой-то>, O=<такой-то>,
> >> C=<такой-то> (и т.п.)
> >> 1.2. Срок действия CA устанавливается в <X> лет.
> > 
> > А какой срок является традиционным?  3 года?  5 лет?
> 
> Ну, вообще, из практики - у коммерческих CA этот срок очень сильно
> отличается. Вменяемые и серьезные CA имеют 10 лет, а
> среднеестатистические - где-то от 20 лет, а то и под 30.
> 
> Большинство самоподписанных сертификатов генерируются часто для галочки
> и имеют фактически неограниченный срок действия.
> 
> В свое время Thawte и VeriSign на этом очень погорели, когда выпустили
> свои первые сертификаты с первыми версиями Netscape на 5 или на 7 лет,
> кажется - и потом вдруг столкнулись с тем, что сертификат уже кончается,
> а масса народа не обновляло браузеры с тех пор и, вообще говоря, как-то
> не особенно планирует обновлять.
> 
> Регенерация сертификата CA - даже для нас - я так понимаю, это довольно
> нетривиальный набор действий (если только не придумать некий макрос в
> RPM, который бы добавлял его автоматически - тогда можно было бы
> пересобирать все нужные пакеты роботом и все), а для коммерческих CA -
> так совсем неподъемная задача.
> 
> Так что, думаю, разумным будет установить этот срок в 10 лет и придумать
> некую обвязку, которая бы позволила все пакеты, носящие в себе этот
> сертификат быстро пересобрать?

OK, пусть будет 10 лет, тогда торопиться с обвязкой не потребуется. :)

> >> 1.3. Его поддержанием, регенерацией, выписыванием сертификатов
> >> занимается <видимо, кто-то из суппорта?>
> > 
> > Это мы уже проходили.  К сожалению, в суппорте для этого слишком низкая
> > мера ответственности.  Думаю что security@altlinux для этого лучше
> > подходит.
> 
> Согласен.

OK

> >> 1.4. Регенерация делается за <полгода> до окончания срока действия
> >> очередного основного CA: генерируется новый сертификат и в эти полгода
> >> все носят 2 сертификата. Старый сертификат выкидывается отовсюду по
> >> возможности, как его срок действия совсем заканчивается.
> > 
> > Судя по опыту замены gpg-ключей, полгода будет мало.  Лучше если год.
> 
> Согласен.

OK

> >> 1.5. Сертификат всегда доступен для скачивания с
> >> <https://tls.altlinux.org>, а также в пакете openssl (из тех
> >> соображений, что он у нас наиболее системообразующий).
> >>
> >> 2. Все https-серверы и XMMP-серверы ALT (как минимум, перечисленные в
> >> gory details в первом письме) используют сертификаты, выписанные этим
> >> ALT root CA.
> >>
> >> 2.1. Сертификаты должны иметь корректно установленные, в том числе,
> >> например, правильный CN.
> >> 2.2. Т.к. есть, как минимум, 3 домена (altlinux.org, altlinux.ru,
> >> altlinux.com), видимо, на каждый сервис нужно выписывать 3 сертификата.
> > 
> > Точнее говоря, на каждый поддерживаемый этим сервисом домен.
> 
> Согласен.

OK

> >> 2.3. Там, где https объективно не нужен - его вообще быть не должно, 443
> >> порт закрыт.
> > 
> > Мне кажется, что это требование более универсально, чем SSL policy.
> 
> Ну, тем не менее -

Ну хорошо, пусть будет.

> >> 3. Все члены команды ALT имеют право попросить заверенные этим CA
> >> сертификаты в любом количестве для своих личных нужд.
> > 
> > Это утверждение надо переформулировать таким образом, чтобы исключить
> > неправильную трактовку, напр. рост количества сертификатов в
> > геометрической прогрессии.
> 
> Да в общем - и в геометрической - я ничего особенно страшного не вижу.
> Если будет необходимость выписывать их тысячами - для этого есть
> всевозможный более-менее свободный софт (всякие http://www.openca.info/,
> http://pki.openca.org/ и т.п.), стандартная процедура - запрос
> сертификата - выписывание сертификата.

OK

> >> ALT Linux TLS policy доступна на http://<URL где будет лежать policy>
> > 
> > SSL policy или TLS policy? :)
> 
> Вообще - лучше использовать термин TLS, он полностью заменил собой SSL
> еще в 1999 году.
> 
> http://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development

Только аббревиатура SSL всё ещё более распространена.  Тогда может
SSL/TLS?

> >> 5.2. Отсутствия такого текста - <minor> bug.
> >>
> >> ==========================================================================
> >>
> >> Оно же закинуто на http://www.freesource.info/wiki/Altlinux/Policy/TLS
> >>
> >> Прошу помочь вписать значения в <...> и высказаться насчет общего
> >> видения возможности принятия такой policy.
> > 
> > Не вижу принципиальных трудностей.
> 
> Хорошо, тогда, насколько я понимаю - надо дорешать вопросы с
> формулировками и можно сделать первые шаги:
> 
> 1. Сгенерировать этот самый root CA
> 2. Положить его в пакет openssl

OK, это я сделаю.

> 3. Выписать нужные сертификаты на серверы *.altlinux.* и разложить их
> где нужно

Это, видимо, тоже мне придётся делать, при содействии администраторов
соответствующих сайтов.

> 4. Ввести policy в действие

Как у нас принято вводить policy в действие?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: SSL/TLS in ALT Linux

[Pavlov Konstantin]

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

On Sunday 04 February 2007 01:16, Dmitry V. Levin wrote:
> > 4. Ввести policy в действие
>
> Как у нас принято вводить policy в действие?

Этот вопрос интересует и меня.

-- 
Pavlov Konstantin,
ALT Linux Team,
VideoLAN Team,
jid: thresh@altlinux.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: SSL/TLS in ALT Linux

[Dmitry V. Levin]

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

On Sun, Feb 04, 2007 at 01:39:29AM +0300, Pavlov Konstantin wrote:
> On Sunday 04 February 2007 01:16, Dmitry V. Levin wrote:
> > > 4. Ввести policy в действие
> >
> > Как у нас принято вводить policy в действие?
> 
> Этот вопрос интересует и меня.

Уточню вопрос: как у нас принято вводить в действие policy, которую нельзя
обеспечить техническими средствами типа rpmbuild и sisyphus_check?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: SSL/TLS in ALT Linux

[Mikhail Yakshin]

Dmitry V. Levin wrote:
> Обсуждение SSL/TLS policy с прошлого месяца, цитирую полностью.
> 
> On Mon, Jan 22, 2007 at 09:58:55AM +0300, Mikhail Yakshin wrote:
>> Dmitry V. Levin wrote:
>>
>>>> Предлагаю сделать нечто вроде SSL policy и закрепить в ней примерно
>>>> следующие основные пункты:
>>>>
>>>> ==========================================================================
>>>>
>>>> 1. Существует ALT root CA, принадлежащий ООО (как и все остальные
>>>> основные подписи и ключи по репозитариями и по проекту в целом).
>>> Я сомневаюсь в том, что всё это принадлежит OOO.
>> Кому сейчас принадлежат GPG-ключи, которыми подписывается репозитарий,
>> пакет openssl и защищаемые сервера *.altlinux.*? Как это лучше
>> переформулировать?
> 
> Я не знаю, как это лучше переформулировать.  Нужна помощь.

Можно сказать пафосное "принадлежит сообществу", только без
соответствующего юридического подкрепления это будут пустые слова,
красивые для завлечения людей, но ничего не значащие, как только дело
дойдет до каких-то разбирательств.

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

Такие публичные оферты есть на самом деле у большинства сервисов, таких,
как SourceForge, BerliOS и т.п.:

http://sourceforge.net/docman/display_doc.php?docid=6048&group_id=1
http://developer.berlios.de/tos/tos.php

Заодно, кстати, если уж обращаться к мировому опыту, нужен еще один
документ, напрямую связанный с этим - privacy statement, который будет
описывать, что ООО, как некий закрепленный предыдущим документом гарант
Sisyphus, имеет право делать с той личной информацией, что ей поступает.
В частности, в нем должно быть отражено то, что использование систем на
базе ALT Linux означает присутствие в нем сертификата CA root altlinux,
что ведет к таким-то последствиям.

В общем, вопрос для legal@, конечно.

>>>> ALT Linux TLS policy доступна на http://<URL где будет лежать policy>
>>> SSL policy или TLS policy? :)
>> Вообще - лучше использовать термин TLS, он полностью заменил собой SSL
>> еще в 1999 году.
>>
>> http://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development
> 
> Только аббревиатура SSL всё ещё более распространена.  Тогда может
> SSL/TLS?

Видимо, да. Если смотреть вульгарно по google - то разница примерно 107
миллионов против 12 миллионов - т.е. ~10 раз. Само по себе
переименование было весьма искусственным шагом, в первую очередь для
борьбы с претензиями Netscape,

>>>> 5.2. Отсутствия такого текста - <minor> bug.
>>>>
>>>> ==========================================================================
>>>>
>>>> Оно же закинуто на http://www.freesource.info/wiki/Altlinux/Policy/TLS
>>>>
>>>> Прошу помочь вписать значения в <...> и высказаться насчет общего
>>>> видения возможности принятия такой policy.
>>> Не вижу принципиальных трудностей.
>> Хорошо, тогда, насколько я понимаю - надо дорешать вопросы с
>> формулировками и можно сделать первые шаги:
>>
>> 1. Сгенерировать этот самый root CA
>> 2. Положить его в пакет openssl
> 
> OK, это я сделаю.
> 
>> 3. Выписать нужные сертификаты на серверы *.altlinux.* и разложить их
>> где нужно
> 
> Это, видимо, тоже мне придётся делать, при содействии администраторов
> соответствующих сайтов.
> 
>> 4. Ввести policy в действие
> 
> Как у нас принято вводить policy в действие?

У нас сейчас есть пакет openssl и libssl4/ssl6.
/var/lib/ssl/certs/ca-bundle.crt лежит в openssl. Правда жизни в том,
что openssl никто не requires, все хотят только библиотеки libssl*, и,
видимо, носят CA bundle с собой, либо не носят и ломаются, если пакет
openssl удалить.

У нас есть кто-нибудь, кто будет использовать общее хранилище
сертификатов CA и при этом не хочет быть завязан на openssl? Как
минимум, есть gnutls, который вроде бы является альтерантивной
реализацией - но там тоже все носят сертификаты с собой?

Если таких нет - то:

1.1. Объявляем единым хранилищем то, что в пакете openssl

Если есть такие:

1.1. Выделяем хранилище CA public certs в отдельный noarch-пакет
1.2. Пересобираем openssl с использованием хранилища из этого отдельного
пакета.

Дальше:

2.1. Объявляем полиси вступившим в действие, переносим его с
http://www.freesource.info/wiki/Altlinux/Policy на
http://wiki.sisyphus.ru/devel/policy

2.2. Смотрим, какие пакеты у нас носят такое хранилище с собой. По
предварительным подсчетам это:

# grep $'\.pem\t' /Sisyphus/i586/base/contents_index >$TMPDIR/suspicious
# grep $'\.crt\t' /Sisyphus/i586/base/contents_index >>$TMPDIR/suspicious
# cut -f2 $TMPDIR/suspicious | sort -u

MySQL-server
apache2-mod_ssl
courier-imap
dovecot
erlang
exim-common
freeradius
gnupg2
kdelibs
libcurl
libgwenhywfar
libqca2
mod_ssl
monit
mutt1.5
ntop
nut-server
openssl
openssl-doc
openvpn-docs
perl-Net-SSLeay
php5-devel
plt2
python-module-m2crypto
python-module-twisted
sendmail
stunnel
unreal
uw-imap

2.3. Каждый из этих пакетов смотрим глазами (благо, их немного) и
рассылаем их мейнтейнерам предупреждения и инструкции, что требуется
сделать.
2.4. Ждем grace time, допустим, неделю.
2.5. Вешаем баги + чиним своими силами через NMU.
2.6. Вводим в sisyphus_check проверку: по собранному пакету нужно
пройтись, в каждом файле поискать "-----BEGIN CERTIFICATE-----" и
"-----END CERTIFICATE-----". Если такое нашлось - то с помощью:

openssl -in имяфайла -text -noout -purpose

вытащить информацию по сертификату и посмотреть, является ли сертификат.
Это полумера, недостаточная для 100% уверенности, но по-моему, это
лучше, чем ничего.
2.7. Вводим соответствующий макрос relaxed, чтобы отключить эту проверку.

-- 
WBR, Mikhail Yakshin AKA GreyCat
ALT Linux [http://www.altlinux.ru] [xmpp:greycat@altlinux.org]

Re: [devel] Q: SSL/TLS in ALT Linux

[Konstantin A. Lepikhov]

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

Hi Mikhail!

Sunday 04, at 04:55:39 PM you wrote:

> > Как у нас принято вводить policy в действие?
> 
> У нас сейчас есть пакет openssl и libssl4/ssl6.
> /var/lib/ssl/certs/ca-bundle.crt лежит в openssl. Правда жизни в том,
> что openssl никто не requires, все хотят только библиотеки libssl*, и,
> видимо, носят CA bundle с собой, либо не носят и ломаются, если пакет
> openssl удалить.
> 
> У нас есть кто-нибудь, кто будет использовать общее хранилище
> сертификатов CA и при этом не хочет быть завязан на openssl? Как
> минимум, есть gnutls, который вроде бы является альтерантивной
> реализацией - но там тоже все носят сертификаты с собой?
еще есть NSS и все, что его использует
(firefox/thunderbird/xulrunner/seamonkey). BTW, если дима ничего не менял
относительно моей сборки libssl, то /var/lib/ssl/certs/ca-bundle.crt
должен быть из NSS. 

> 
> Если таких нет - то:
> 
> 1.1. Объявляем единым хранилищем то, что в пакете openssl
> 
> Если есть такие:
> 
> 1.1. Выделяем хранилище CA public certs в отдельный noarch-пакет
> 1.2. Пересобираем openssl с использованием хранилища из этого отдельного
> пакета.
> 
> Дальше:
> 
> 2.1. Объявляем полиси вступившим в действие, переносим его с
> http://www.freesource.info/wiki/Altlinux/Policy на
> http://wiki.sisyphus.ru/devel/policy
> 
> 2.2. Смотрим, какие пакеты у нас носят такое хранилище с собой. По
> предварительным подсчетам это:
> 
> # grep $'\.pem\t' /Sisyphus/i586/base/contents_index >$TMPDIR/suspicious
> # grep $'\.crt\t' /Sisyphus/i586/base/contents_index >>$TMPDIR/suspicious
> # cut -f2 $TMPDIR/suspicious | sort -u
> 
> MySQL-server
гон. Там только примеры сертификатов.

> monit
аналогично

> mutt1.5
> stunnel
аналогично

> uw-imap
аналогично

> 2.3. Каждый из этих пакетов смотрим глазами (благо, их немного) и
> рассылаем их мейнтейнерам предупреждения и инструкции, что требуется
> сделать.
> 2.4. Ждем grace time, допустим, неделю.
> 2.5. Вешаем баги + чиним своими силами через NMU.
> 2.6. Вводим в sisyphus_check проверку: по собранному пакету нужно
> пройтись, в каждом файле поискать "-----BEGIN CERTIFICATE-----" и
> "-----END CERTIFICATE-----". Если такое нашлось - то с помощью:
> 
> openssl -in имяфайла -text -noout -purpose
> 
> вытащить информацию по сертификату и посмотреть, является ли сертификат.
> Это полумера, недостаточная для 100% уверенности, но по-моему, это
> лучше, чем ничего.
> 2.7. Вводим соответствующий макрос relaxed, чтобы отключить эту проверку.
бредовая затея. Проще вправлять мозги апстриму на предмет использования
OPENSSL_config(3) перед проверкой сертификатов.

-- 
WBR et al.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] [sisyphus] Q: SSL in ALT Linux

[Michael Shigorin]

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

On Mon, Jan 22, 2007 at 02:47:49AM +0300, Dmitry V. Levin wrote:
> > 1.1. Сертификат имеет CN=<такой-то>, OU=<такой-то>, O=<такой-то>,
> > C=<такой-то> (и т.п.)
> > 1.2. Срок действия CA устанавливается в <X> лет.
> А какой срок является традиционным?  3 года?  5 лет?

IMCO не менее периода между дистрибутивами с некоторым запасом.
В данном разе это не менее трёх лет, но мне почему-то кажется,
что лучше пять.

> > 1.3. Его поддержанием, регенерацией, выписыванием
> > сертификатов занимается <видимо, кто-то из суппорта?>
> Это мы уже проходили.  К сожалению, в суппорте для этого
> слишком низкая мера ответственности.  Думаю что
> security@altlinux для этого лучше подходит.

+1

> > 3. Все члены команды ALT имеют право попросить заверенные
> > этим CA сертификаты в любом количестве для своих личных нужд.
> Это утверждение надо переформулировать таким образом, чтобы
> исключить неправильную трактовку, напр. рост количества
> сертификатов в геометрической прогрессии.

Для нужд, связанных с проектом ALT?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] policy fixation (was: Q: SSL/TLS in ALT Linux)

[Michael Shigorin]

On Sun, Feb 04, 2007 at 01:16:25AM +0300, Dmitry V. Levin wrote:
> > 4. Ввести policy в действие
> Как у нас принято вводить policy в действие?

Исполнить.  В случае текста, опубликованного на wiki, можно 
объявить соответствующую ревизию "принятой" и зафиксировать
текст в (как вон raorn@ предложил) пакете alt-policy-*.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Q: SSL/TLS in ALT Linux

[Mikhail Gusarov]

>> Как у нас принято вводить policy в действие?
> Этот вопрос интересует и меня.

Подозреваю, что исключительно своим хорошим примером. Если policy
окажется удачной - остальные подтянутся.

-- 
JID: dottedmag@jabber.dottedmag.net

Re: [devel] Q: SSL/TLS in ALT Linux

[Dmitry V. Levin]

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

On Sun, Feb 04, 2007 at 06:13:20PM +0300, Konstantin A. Lepikhov wrote:
[...]
> > У нас сейчас есть пакет openssl и libssl4/ssl6.
> > /var/lib/ssl/certs/ca-bundle.crt лежит в openssl. Правда жизни в том,
> > что openssl никто не requires, все хотят только библиотеки libssl*, и,
> > видимо, носят CA bundle с собой, либо не носят и ломаются, если пакет
> > openssl удалить.
> > 
> > У нас есть кто-нибудь, кто будет использовать общее хранилище
> > сертификатов CA и при этом не хочет быть завязан на openssl? Как
> > минимум, есть gnutls, который вроде бы является альтерантивной
> > реализацией - но там тоже все носят сертификаты с собой?
> еще есть NSS и все, что его использует
> (firefox/thunderbird/xulrunner/seamonkey). BTW, если дима ничего не менял
> относительно моей сборки libssl, то /var/lib/ssl/certs/ca-bundle.crt
> должен быть из NSS. 

$ rpmquery -f /var/lib/ssl/certs/ca-bundle.crt
openssl-0.9.8d-alt1
$ grep '^#' /var/lib/ssl/certs/ca-bundle.crt
# This is a bundle of X.509 certificates of public Certificate
# Authorities.  It was generated from the Mozilla root CA list.
#
# Source: mozilla/security/nss/lib/ckfw/builtins/certdata.txt
#
# Generated from certdata.txt RCS revision 1.39
#

> > Если есть такие:
> > 
> > 1.1. Выделяем хранилище CA public certs в отдельный noarch-пакет
> > 1.2. Пересобираем openssl с использованием хранилища из этого отдельного
> > пакета.

Значит так и поступим.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: SSL/TLS in ALT Linux

[Dmitry V. Levin]

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

On Mon, Feb 05, 2007 at 01:38:23AM +0300, Dmitry V. Levin wrote:
[...]
> > > 1.1. Выделяем хранилище CA public certs в отдельный noarch-пакет
> > > 1.2. Пересобираем openssl с использованием хранилища из этого отдельного
> > > пакета.
> 
> Значит так и поступим.

Как назвать пакет?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: SSL/TLS in ALT Linux

[Michael Shigorin]

On Mon, Feb 05, 2007 at 09:53:04PM +0300, Dmitry V. Levin wrote:
> > > > 1.1. Выделяем хранилище CA public certs в отдельный
> > > > noarch-пакет
> Как назвать пакет?

В демьяне назвали http://packages.debian.org/ca-certificates

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Q: SSL/TLS in ALT Linux

[Dmitry V. Levin]

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

On Sun, Feb 04, 2007 at 06:13:20PM +0300, Konstantin A. Lepikhov wrote:
[...]
> > У нас есть кто-нибудь, кто будет использовать общее хранилище
> > сертификатов CA и при этом не хочет быть завязан на openssl? Как
> > минимум, есть gnutls, который вроде бы является альтерантивной
> > реализацией - но там тоже все носят сертификаты с собой?
> еще есть NSS и все, что его использует

И теперь надо сконвертировать
http://git.altlinux.org/people/ldv/packages/?p=ca-certificates.git;a=blob;f=alt/alt.pem;h=2b4b4e71653384c1fdceb249ab4f956d7e52863c;hb=HEAD
из PEM в тот формат, который использует мозильная certdata.txt

> > 1.1. Выделяем хранилище CA public certs в отдельный noarch-пакет
> > 1.2. Пересобираем openssl с использованием хранилища из этого отдельного
> > пакета.

Пакет называется ca-certificates.

> > 2.1. Объявляем полиси вступившим в действие, переносим его с
> > http://www.freesource.info/wiki/Altlinux/Policy на
> > http://wiki.sisyphus.ru/devel/policy

Я не знаю, надо ли переносить страницы, но policy можно считать вступившим
в силу.

> > 2.2. Смотрим, какие пакеты у нас носят такое хранилище с собой. По
> > предварительным подсчетам это:
> > 
> > # grep $'\.pem\t' /Sisyphus/i586/base/contents_index >$TMPDIR/suspicious
> > # grep $'\.crt\t' /Sisyphus/i586/base/contents_index >>$TMPDIR/suspicious
> > # cut -f2 $TMPDIR/suspicious | sort -u
> > 
> > MySQL-server
> > monit
> > mutt1.5
> > stunnel
> > uw-imap
> Там только примеры сертификатов.

Это хорошо.  Надо проверить остальные.

Один неправильный я уже нашёл, libcurl называется:
$ strings /usr/lib64/libcurl.so.4 |fgrep curl-ca-bundle.crt
/usr/share/curl/curl-ca-bundle.crt
- см. http://curl.haxx.se/docs/sslcerts.html

> > 2.3. Каждый из этих пакетов смотрим глазами (благо, их немного) и
> > рассылаем их мейнтейнерам предупреждения и инструкции, что требуется
> > сделать.

Пора приступать.

> > 2.4. Ждем grace time, допустим, неделю.
> > 2.5. Вешаем баги + чиним своими силами через NMU.
> > 2.6. Вводим в sisyphus_check проверку: по собранному пакету нужно
> > пройтись, в каждом файле поискать "-----BEGIN CERTIFICATE-----" и
> > "-----END CERTIFICATE-----". Если такое нашлось - то с помощью:
> > 
> > openssl -in имяфайла -text -noout -purpose
> > 
> > вытащить информацию по сертификату и посмотреть, является ли сертификат.
> > Это полумера, недостаточная для 100% уверенности, но по-моему, это
> > лучше, чем ничего.
> > 2.7. Вводим соответствующий макрос relaxed, чтобы отключить эту проверку.
> бредовая затея. Проще вправлять мозги апстриму на предмет использования
> OPENSSL_config(3) перед проверкой сертификатов.

Вправлять мозги -- это нейрохирургическая операция, которая требует
навыков, времени и концентрации (я слышал, что некоторые недавно пытались
на скорую руку донести до апстрима исправления сборки --as-needed, пусть
они расскажут).  В данном случае пакетов, которые нужно исправить на
предмет OPENSSL_config(3), не так много, и ждать апстрима некогда.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]