Re: [devel] Вопросы новичка

Re: [devel] Вопросы новичка

[Victor B. Wagner]

On 2009.05.07 at 10:13:51 +0400, Afanasov Dmitry wrote:

> On Tue, May 05, 2009 at 06:11:13PM +0400, Victor B. Wagner wrote:
> > On 2009.05.05 at 16:26:09 +0300, Alexander Bokovoy wrote:
> > > "Список, сестра!". 
> > Лично у меня план действий такой:
> > 
> > 1. Запакетировать openssl-1.0. С тем чтобы она максимально
> > соответстовала текущей полиси дистрибутива и перевод приложений на неё
> > был возможно более безболезненным. 
> мне как админу от сертификатов хотелось бы:
> 1. иметь "машинный" сертификат, которым автоматом бы подписывались все
> остальные сервисные. подписать этот сертификат чем-нибудь другим, как я
> помнимаю, можно и позже.

Насчет подписать можно и позже - будут проблемы.
Если вы отправите заявку на получение сертификата intermediate CA на 
свой ключ, которым вы уже подписали несколько сертификатов,
то вам будет выдан сертификат с определенным сроком действия. 

Честно сказать, никогда не проверял, как различный софт относится к
тому, что сертификат сервера имеет срок действия, начавшийся раньше, чем
срок действия сертификата CA, на котором он выдан. 

Но в принципе "подписать на чем-нибудь" сертификат своего CA - не
обязательно. Можно распространить самоподписанный сертификат вашего CA
по всем клиентским машинам и установить его там в Trusted CA store. 
После этого он будет ничем не хуже Verisign-а.

В принципе, и перевыпустить сертификаты серверов после получения
сертификата CA недолго.



> 2. иметь возможность подставлять свои параметры в автогенерируемые
> сертификаты: organization там, organizationUnit, ссылку на crl.

Угу. Причем по-русски. Сделать это можно достаточно просто. Для этого
необходимо, чтобы

1. При установке сервисов сертификаты генерировались с использованием
системного openssl.cnf.

2. Иметь какой-то достаточно удобный инструмент, чтобы в этот самый
openssl.cnf прописывать параметры вашей организации.

3. Не забыть прописать в openssl.cnf прямо при создании пакета
необходимые параметры, которые обеспечат корректную обработку кириллицы.

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

1-е и 3-е я уже делал в CryptoPack 1.0. К сожалению, до второго - руки
не дошли.


> все пакеты, что используют ssl, при установке генерируют сертификаты.

Что вообще говоря, не обязательно. В Debian, например, есть отдельный
пакет ssl-cert, который генерирует один-единственный сертификат на
hostname данной машины, которым потом польузются все установленные
сервисы.

> как сделать эту генерацию интерактивной при установке пакета я не
> представляю - rpm и все такое. но пусть хотя бы берут мои данные, а не
> какой-нибудь cat << EOF | openssl req. и ещё и подпишутся напоследок
> "машинным CA" :)
> 
> subject'ом таким сертификатам можно проставлять имя сервиса. ftp - для
> ftp, mail - для MTA, etс. мыло - одно на всех мыло админа. suport@, или
> личное.

subject сертификата - это набор полей. Куда входят как раз
organization, unit etc. Вы, наверное, имеете в виду поле CN (Common
Name). Так оно ОБЯЗАНО в случае серверного сертификата TLS совпадать
с именем хоста. Причем именно того, к которому идет обращение со стороны
клиента. До OpenSSL 0.9.8f не было никакой возможности иметь разные 
сертификаты на разные виртуальные хосты на одном IP, что создавало
определенные проблемы с виртуальными хостами в apache.

Начиная с 0.9.8f поддерживается TLS extension SNI (Server Name
Indication), так что теперь в принципе можно делать виртуальные хосты с
разными сертификатами. При условии что SNI поддерживается и клиентским
приложением (Firefox >= 2, MSIE >= 7 его поддерживают), и сервером (не
только на уровне библиотеки, но и на уровне приложения, так как именно
приложение решает какой именно сертификат отдать)

Что сейчас с поддержкой SNI у Apache - давно не смотрел.
Feature Request с соответствующим патчем был в апачевском SVN еще год
назад, но попал он в релиз или нет - не в курсе.

Для других сервисов, как правило, задача виртуальных хостов менее
актуальна.

Но общий принцип такой - иметь имя сервиса в CN можно только если 
имеется алиас в DNS (CNAME или A), содержащий это имя в DNS-имени
машины.



> > 2. Взаимодействие с мейнтейнерами
> если что нужно сделать в gnutls - предлагайте. к сожалению, "как это
> тикает" я не разобрался, но будет задача - будем думать :)

В данном случае, я имел в виду скорее мейнтейнеров приложений.
Apache, openvpn, postfix, dovecot, postgresql, mysql etc - неполный список тех
приложений которые я уже тестировал на работу с российской криптографией
и точно знаю что нужно, чтобы оно работало.

(например, в случае с postgresql нужно только его пересобрать с OpenSSL 
поддерживающей российскую криптографию и прописать в openssl.cnf
соответствующий модуль)

В gnutls - нужно начать и кончить. Написать поддержку российских
алгоритмов, поддержку российских шифрсьютов etc. Если алгоритмы
шифрования и хэширования можно тупо содрать из моей реализации для
OpenSSL (они там ни от чего не зависят), то алгоритмы подписи и
распределения ключей там сильно завязаны на библиотеку длинной
арифметики и эллиптических кривых OpenSSL, так что придется переписывать 
с нуля.

И, насколько я понимаю, нет никаких шансов сделать на базе gnutls
сертифицированное решение. В результате чего оно абсолютно неинтересно
моему руководству.


----- End forwarded message -----

Re: [devel] Вопросы новичка

[Anton Farygin]

Victor B. Wagner пишет:

> 
> И, насколько я понимаю, нет никаких шансов сделать на базе gnutls
> сертифицированное решение. В результате чего оно абсолютно неинтересно
> моему руководству.

А почему, кстати ?

Чем он кому-то не угодил ?

Re: [devel] Вопросы новичка

[Aleksey Avdeev]

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

Victor B. Wagner пишет:
...
> 
> subject сертификата - это набор полей. Куда входят как раз
> organization, unit etc. Вы, наверное, имеете в виду поле CN (Common
> Name). Так оно ОБЯЗАНО в случае серверного сертификата TLS совпадать
> с именем хоста. Причем именно того, к которому идет обращение со стороны
> клиента. До OpenSSL 0.9.8f не было никакой возможности иметь разные 
> сертификаты на разные виртуальные хосты на одном IP, что создавало
> определенные проблемы с виртуальными хостами в apache.
> 
> Начиная с 0.9.8f поддерживается TLS extension SNI (Server Name
> Indication), так что теперь в принципе можно делать виртуальные хосты с
> разными сертификатами. При условии что SNI поддерживается и клиентским
> приложением (Firefox >= 2, MSIE >= 7 его поддерживают), и сервером (не
> только на уровне библиотеки, но и на уровне приложения, так как именно
> приложение решает какой именно сертификат отдать)
> 
> Что сейчас с поддержкой SNI у Apache - давно не смотрел.
> Feature Request с соответствующим патчем был в апачевском SVN еще год
> назад, но попал он в релиз или нет - не в курсе.
> 
...
> 
>>> 2. Взаимодействие с мейнтейнерами
>> если что нужно сделать в gnutls - предлагайте. к сожалению, "как это
>> тикает" я не разобрался, но будет задача - будем думать :)
> 
> В данном случае, я имел в виду скорее мейнтейнеров приложений.
> Apache, openvpn, postfix, dovecot, postgresql, mysql etc - неполный список тех
> приложений которые я уже тестировал на работу с российской криптографией
> и точно знаю что нужно, чтобы оно работало.

   Что надо сделать в apache и apache2 чтобы оно взлетело?

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [devel] Вопросы новичка

[Victor B. Wagner]

On 2009.05.07 at 12:41:04 +0400, Anton Farygin wrote:

> Victor B. Wagner пишет:
> 
> >
> >И, насколько я понимаю, нет никаких шансов сделать на базе gnutls
> >сертифицированное решение. В результате чего оно абсолютно неинтересно
> >моему руководству.
> 
> А почему, кстати ?
> 
> Чем он кому-то не угодил ?

Требования, предьявляемые к сертифицированным средствам
криптографической защиты вступают в прямое противоречие с по крайней
мере с духом (L)GPL.

Не уверен, что не вступают в противоречие и с буквой v3. Я не юрист, а
тут нужно в юридическом крючкотворстве разбираться.

(L)GPL требует предоставить пользователю свободу модифицировать софт.
А сертифицирующие органы сертифицируют определенный бинарник, и любой
секьюрити фикс или пересборка под более новый дистрибутив требует
пересертификации.

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

Мы, конечно, можем предоставить ради удовлетворения буквы LGPL исходники
наших модификаций. Но то, что пользователи из них соберут,
сертифицированным уже не будет (собственно поэтому нам абсолютно не
жалко эти модификации  раздавать). А по-моему GPLv3 подобные выкрутасы
явно змпрещает.

Далее, (L)GPL требует предоставить пользователю свободу дальнейшего
распространения софта. А для сертифицированных криптосредств существует
поэкземплярный учет.

В случае с OpenSSL с её BSD-like лицензией я по крайней мере уверен, что
распространяя сертифицированные бинарники, собранные из доступных
сообществу исходников, мы ничего не нарушаем.

В случае LGPL я как-то не очень в этом уверен.

Re: [devel] Вопросы новичка

[Victor B. Wagner]

On 2009.05.07 at 12:45:29 +0400, Aleksey Avdeev wrote:

> >приложений которые я уже тестировал на работу с российской криптографией
> >и точно знаю что нужно, чтобы оно работало.
> 
>   Что надо сделать в apache и apache2 чтобы оно взлетело?

1. Использовать OpenSSL в которой есть поддержка российских алгоритмов,
то есть либо модифицированную 0.9.8, которую можно скачать с
www.cryptocom.ru как триальную версию MagPro CryptoPack 1.0, либо 
OpenSSL 1.0.

2. Apache очень хитрым образом работает с ключами и подгружаемыми
модулями, он их внутри себя обратно сериализует, а потом опять
разбирает. При этом в код, который этим занимается, забито гвоздями что
криптоалгоритмов кроме RSA и DSA не бывает. 
Поэтому требуется патчик.

Патчи для mod_ssl для apache1.3 для работы с MagPro CryptoPack и 
для apache 2.2 и для MagPro CryptoPack и для OpenSSL 1.0 можно взять
на www.cryptocom.ru/OpenSource/OpenSSL_rus.html.

Обращаю ваше внимание на то, что патчи для работы с расширенным списокм
алгоритмов в OpenSSL 1.0 и в модифицированной 0.9.8 - разные. 
mod_ssl для Apache 1.3 я с OpenSSL 1.0 пересобирать не пробовал.

Теоретически, патчи к Apache 2.2 для работы с OpenSSL 1.0 должны
обеспечить работу не только с ГОСТ, но и с ECDSA/EECDH, но я не
проверял.

В принципе, патч к Apache 2.2 для OpenSSL 1.0 я года полтора назад 
постил в apache-dev, но там он энтузиазма почему-то не вызвал.

3. Сосуществование двух версий OpenSSL в одном процессе невозможно.
Даже если у них разный soname.
Поэтому требуется чтобы все библиотеки с которыми линкуется apache,
а также libaprutil и libapr были пересобраны с той же самой версией
OpenSSL.  

То есть для того, чтобы заставить apache 2.2 из Alt 4.0 работать с ГОСТ
мне потребовалось пересобрать openldap, postgresql и mysql.

Собственно libaprutil, что самое смешное, пересобирать не потребовалось.

Re: [devel] Вопросы новичка

[Max Ivanov]

Зачем вообще эта сертификация нужна?  Это же большой вопрос, что
безопаснее - изученный бинарник, но без секьюрити фиксов или просто
пакет последней версии.


А с технической стороны есть разница между gnutls и openssl? И то и
другое вродебы поддерживают всё что нужно, раньше везде был openssl
потом окуда-то вылез gnutls и началась какая-то непонятная миграция на
него.

Re: [devel] Вопросы новичка

[Afanasov Dmitry]

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

On Thu, May 07, 2009 at 12:38:36PM +0400, Victor B. Wagner wrote:
> On 2009.05.07 at 10:13:51 +0400, Afanasov Dmitry wrote:
> > все пакеты, что используют ssl, при установке генерируют сертификаты.
> 
> Что вообще говоря, не обязательно. В Debian, например, есть отдельный
> пакет ssl-cert, который генерирует один-единственный сертификат на
> hostname данной машины, которым потом польузются все установленные
> сервисы.
это кстати вопрос. на данынй момент mod_ssl для apache, pure-fptpd,
courier-imap, наверняка ещё кто-то, используют независимые сертификаты.

вопрос к мантейнерам:
1. оставим как есть, каждой твари по сертификату
2. сделам один сертификат на всех.

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

во втором случае ничего подписывать не надо.

реализовать можно наверное через связку макрос+скрипт, как %post_service,
например, реализован. к примеру, макрос %add_ssl_cert name будет вызваеть
этот самый скрипт добавления сертификата. скрипт будет шастать по
openssl.cnf, или что нам там ещё взбредет.

-- 
С уважением
Афанасов Дмитрий

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

Re: [devel] Вопросы новичка

[Afanasov Dmitry]

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

On Thu, May 07, 2009 at 12:38:36PM +0400, Victor B. Wagner wrote:
> On 2009.05.07 at 10:13:51 +0400, Afanasov Dmitry wrote:
> > subject'ом таким сертификатам можно проставлять имя сервиса. ftp - для
> > ftp, mail - для MTA, etс. мыло - одно на всех мыло админа. suport@, или
> > личное.
> 
> subject сертификата - это набор полей.
виноват, попутал терминологию :)

> Вы, наверное, имеете в виду поле CN (Common
> Name). Так оно ОБЯЗАНО в случае серверного сертификата TLS совпадать
> с именем хоста. 
я помню. но кроме iod'ов ou, cn, есть ещё море, а можно и добавить. что
мешает добавить oid serviceName, а commonName отдать на hostname.

как я помню, есть ещё subjectAltName, экспериментировал когда-то. но, к
сожалению, подержка cn является общепринятой, а вот всякие
subjectAltName=DNS:... нет :(

-- 
С уважением
Афанасов Дмитрий

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

Re: [devel] Вопросы новичка

[Afanasov Dmitry]

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

On Thu, May 07, 2009 at 12:38:36PM +0400, Victor B. Wagner wrote:
> On 2009.05.07 at 10:13:51 +0400, Afanasov Dmitry wrote:
> > > 2. Взаимодействие с мейнтейнерами
> > если что нужно сделать в gnutls - предлагайте. к сожалению, "как это
> > тикает" я не разобрался, но будет задача - будем думать :)
> 
> В данном случае, я имел в виду скорее мейнтейнеров приложений.
> Apache, openvpn, postfix, dovecot, postgresql, mysql etc - неполный список тех
> приложений которые я уже тестировал на работу с российской криптографией
> и точно знаю что нужно, чтобы оно работало.
понял. как будет готово, проверю на своих proftpd и pure-ftpd.

> В gnutls - нужно начать и кончить.
> [...]
> И, насколько я понимаю, нет никаких шансов сделать на базе gnutls
> сертифицированное решение. В результате чего оно абсолютно неинтересно
> моему руководству.
значит оставляем его в покое до лучших времен.

-- 
С уважением
Афанасов Дмитрий

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

Re: [devel] Вопросы новичка

[Aleksey Avdeev]

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

Victor B. Wagner пишет:
> On 2009.05.07 at 12:45:29 +0400, Aleksey Avdeev wrote:
> 
>>> приложений которые я уже тестировал на работу с российской криптографией
>>> и точно знаю что нужно, чтобы оно работало.
>>   Что надо сделать в apache и apache2 чтобы оно взлетело?
> 
> 1. Использовать OpenSSL в которой есть поддержка российских алгоритмов,
> то есть либо модифицированную 0.9.8, которую можно скачать с
> www.cryptocom.ru как триальную версию MagPro CryptoPack 1.0, либо 
> OpenSSL 1.0.
> 
> 2. Apache очень хитрым образом работает с ключами и подгружаемыми
> модулями, он их внутри себя обратно сериализует, а потом опять
> разбирает. При этом в код, который этим занимается, забито гвоздями что
> криптоалгоритмов кроме RSA и DSA не бывает. 
> Поэтому требуется патчик.
> 
> Патчи для mod_ssl для apache1.3 для работы с MagPro CryptoPack и 
> для apache 2.2 и для MagPro CryptoPack и для OpenSSL 1.0 можно взять
> на www.cryptocom.ru/OpenSource/OpenSSL_rus.html.
> 
> Обращаю ваше внимание на то, что патчи для работы с расширенным списокм
> алгоритмов в OpenSSL 1.0 и в модифицированной 0.9.8 - разные. 
> mod_ssl для Apache 1.3 я с OpenSSL 1.0 пересобирать не пробовал.
> 
> Теоретически, патчи к Apache 2.2 для работы с OpenSSL 1.0 должны
> обеспечить работу не только с ГОСТ, но и с ECDSA/EECDH, но я не
> проверял.
> 
> В принципе, патч к Apache 2.2 для OpenSSL 1.0 я года полтора назад 
> постил в apache-dev, но там он энтузиазма почему-то не вызвал.
> 
> 3. Сосуществование двух версий OpenSSL в одном процессе невозможно.
> Даже если у них разный soname.
> Поэтому требуется чтобы все библиотеки с которыми линкуется apache,
> а также libaprutil и libapr были пересобраны с той же самой версией
> OpenSSL.  
> 
> То есть для того, чтобы заставить apache 2.2 из Alt 4.0 работать с ГОСТ
> мне потребовалось пересобрать openldap, postgresql и mysql.
> 
> Собственно libaprutil, что самое смешное, пересобирать не потребовалось.

   Т. е. для меня план действий такой:

1. Жду пока в Сизифе окажется OpenSSL 1.0 (т. к. в текущей сизифовской 
версии такой поддержки нет, если я правильно понимаю).

2. Жду пересборки libapr, openldap, postgresql и mysql с данной OpenSSL.

3. Собираю apache{,2} с вашими патчами.

   Так?

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [devel] Вопросы новичка

[Alexander Bokovoy]

2009/5/7 Victor B. Wagner <vitus@altlinux.org>:
>> Чем он кому-то не угодил ?
>
> Требования, предьявляемые к сертифицированным средствам
> криптографической защиты вступают в прямое противоречие с по крайней
> мере с духом (L)GPL.
>
> Не уверен, что не вступают в противоречие и с буквой v3. Я не юрист, а
> тут нужно в юридическом крючкотворстве разбираться.
>
> (L)GPL требует предоставить пользователю свободу модифицировать софт.
> А сертифицирующие органы сертифицируют определенный бинарник, и любой
> секьюрити фикс или пересборка под более новый дистрибутив требует
> пересертификации.
LGPL требует, чтобы пользователь мог заменить LGPL компоненту
закрытого решения без необходимости пересобирать это решение заново.
Сертифицированная версия LGPL компоненты формально такому
удовлетворяет, поскольку само понятие сертификата вынесено за пределы
LGPL, а потому никаким образом не фигурирует в требованиях лицензии.
То, что при этом пользователь может потерять (другой) сертификат -- не
проблема LGPL.

>
> Сертифицируется набор бинарников с определенными хэш-суммами.
> Просто пересобрать библиотеку из тех же исходников, не меняя ни одной
> буквы, компилятор впишет в бинарник другую дату компиляции - и приехали
> - это уже не сертифицированный бинарник.
Это ерунда и по крайней мере в рамках сертификации RHEL в России нами
было продемонстрировано сертификаторам, что применяемый ими алгоритм
верификации кода ущербен, поскольку не учитывает подобные инвариантные
изменения скомпилированного кода. Ущербность была признана, однако
отказаться от нее сертификатор не смог в связи с тем, что "... у нас
уже этим алгоритмом куча проприетарщины сертифицирована". Так что
сертификат на свободное ПО при пересборке получен был, даже при
формальной разнице в коде на датах и прочих подобных инвариантах. В
рамках той сертификации даже был разработан специальный набор
скриптов, которые верифицируют правильно, с учетом специфичных
gcc-инвариантов.

> Мы, конечно, можем предоставить ради удовлетворения буквы LGPL исходники
> наших модификаций. Но то, что пользователи из них соберут,
> сертифицированным уже не будет (собственно поэтому нам абсолютно не
> жалко эти модификации  раздавать). А по-моему GPLv3 подобные выкрутасы
> явно змпрещает.
Запрещено несколько другое -- невозможность эксплуатации замененного
кода на оригинальном программно-аппаратном комплексе. Требования
государственной сертификации не имеют отношения к условиям, в которых
осуществляется право пользователя на модификацию кода и запуск его в
оригинальных условиях. Проблемы взаимодействия частно-собственнических
лицензионных соглашений и государственной тайны/законов страны
использования не имеют никакого отношения к коду. Гостайной, например,
можно вообще все что угодно закрыть и что?

> Далее, (L)GPL требует предоставить пользователю свободу дальнейшего
> распространения софта. А для сертифицированных криптосредств существует
> поэкземплярный учет.
Насколько я понимаю, неотъемлемой частью такого сертифицированного
криптосредства является материальная сущность "бумажка",
распространение которой ограничено ее уникальным контролируемым
происхождением без возможности признания подделки за легитимную копию.
Соответственно, свободное распространение кода возможно, а свойства
сертифицированности -- нет. Но это не имеет никакого отношения к LGPL,
как я уже указал выше.

> В случае с OpenSSL с её BSD-like лицензией я по крайней мере уверен, что
> распространяя сертифицированные бинарники, собранные из доступных
> сообществу исходников, мы ничего не нарушаем.
>
> В случае LGPL я как-то не очень в этом уверен.
IANAL и все такое, но если учесть, что nss сертифицирована под тройной
лицензией, включая LGPL, и при этом также сертифицирована по
стандартам США, как и openssl, это по крайней мере показывает, что на
западном рынке проблема не существует в том виде, в котором ты ее
формулируешь.
-- 
/ Alexander Bokovoy

Re: [devel] Вопросы новичка

[Victor B. Wagner]

On 2009.05.07 at 13:26:50 +0400, Aleksey Avdeev wrote:

>   Т. е. для меня план действий такой:
> 
> 1. Жду пока в Сизифе окажется OpenSSL 1.0 (т. к. в текущей сизифовской 
> версии такой поддержки нет, если я правильно понимаю).
> 
> 2. Жду пересборки libapr, openldap, postgresql и mysql с данной OpenSSL.
> 
> 3. Собираю apache{,2} с вашими патчами.
> 
>   Так?

В общем так. Только по п.2 видимо, нужны согласованные единовременные
действия нескольких мейнтейнеров, чтобы в процессе перехода не возникло 
такой ситуации, когда какие-то библиотеки из загружаемых в один и тот же
процесс, еще хотят старой версии OpenSSL, а какие-то - уже новой.

Re: [devel] Вопросы новичка

[Victor B. Wagner]

On 2009.05.07 at 13:24:42 +0400, Afanasov Dmitry wrote:
> > приложений которые я уже тестировал на работу с российской криптографией
> > и точно знаю что нужно, чтобы оно работало.
> понял. как будет готово, проверю на своих proftpd и pure-ftpd.

Вот в эти я пока не лазил. Как правило, в большинстве случаев для
поддержки приложением подгружаемых модулей с алгоритмами/реализациями
необходимо и достаточно добавить перед вызовом SSL_library_init
вызов OPENSSL_config(NULL).
Эта функция считывает конфигурационный файл openssl.cnf и инициализирует
описанные в нем подгружаемые модули.


В man на эту функцию написано:

       It is strongly recommended that all new applications call OPENSSL_con-
       fig() or the more sophisticated functions such as CONF_modules_load()
       during initialization (that is before starting any threads). By doing
       this an application does not need to keep track of all configuration
       options and some new functionality can be supported automatically.


Это так со времен OpenSSL 0.9.7.

К сожалению, авторы приложений, в которые поддержка OpenSSL была добавлена
во времена более ранних версий, при переходе на версию 0.9.7 и выше этот man, 
видимо, не читали. 

В свое время мне удалось пропихнуть это только в PostgreSQL.
Вот он, начиная с 8.3 это делает. Правда, с выходом 8.4 и OpenSSL 1.0 наверное, опять придется его патчить на предмет поддержки сертификатов на всяких железных токенах (в клиентской библиотеке). Потому что до 1.0 в OpenSSL не было API
для добывания клиентского сертификата через engine. А в PostgreSQL до 8.4
не было авторизации пользователей по клиентским сертификатам.

Re: [devel] Вопросы новичка

[Ivan Fedorov]

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

"Victor B. Wagner" <vitus-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org>
writes:

> В свое время мне удалось пропихнуть это только в PostgreSQL.
> Вот он, начиная с 8.3 это делает. Правда, с выходом 8.4 и OpenSSL 1.0
> наверное, опять придется его патчить на предмет поддержки сертификатов
> на всяких железных токенах (в клиентской библиотеке). Потому что до
> 1.0 в OpenSSL не было API для добывания клиентского сертификата через
> engine. А в PostgreSQL до 8.4 не было авторизации пользователей по
> клиентским сертификатам.

Ну положим в сборку для ALT я это добавлю сам. Кстати говоря, pg8.4 уже
перешел в стадию beta, так что советую озаботиться пропихиванием уже
сейчас. Ибо даже сейчас уже поздновато слегка, но думаю что там патч не
очень большой и его удастся пропихнуть.

PS: 8.4 я потихоньку уже начал собирать в ALT... Думаю на выходных
выкатить первую сборку.

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

Re: [devel] Вопросы новичка

[Anton Farygin]

Victor B. Wagner пишет:
> On 2009.05.07 at 12:41:04 +0400, Anton Farygin wrote:
> 
> Далее, (L)GPL требует предоставить пользователю свободу дальнейшего
> распространения софта. А для сертифицированных криптосредств существует
> поэкземплярный учет.
> 
> В случае с OpenSSL с её BSD-like лицензией я по крайней мере уверен, что
> распространяя сертифицированные бинарники, собранные из доступных
> сообществу исходников, мы ничего не нарушаем.
> 
> В случае LGPL я как-то не очень в этом уверен.

Никаких проблем/коллизий в плане сертификации и пересборки не 
существует. То, что пользователь потеряет довесок под названием 
"сертификат" - это вполне обыденная плата за свободу изменения кода. 
Сертифицируется действительно бинарник, а не исходник, поэтому всё 
честно и законно. Изменил код/пересобрал - потерял сертификат 
(подтверждение происхождения _бинарной_ сборки).

Re: [devel] Вопросы новичка

[Mykola S. Grechukh]

7 мая 2009 г. 13:16 пользователь Anton Farygin <> написал:
> код/пересобрал - потерял сертификат (подтверждение происхождения _бинарной_
> сборки).

кстати да, это ничем не отличается от "оригинальный бинарный пакет был
подписан альтовским ключом" а на изменённом подписи нет.

Re: [devel] Вопросы новичка

[Aleksey Avdeev]

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

Victor B. Wagner пишет:
> On 2009.05.07 at 13:26:50 +0400, Aleksey Avdeev wrote:
> 
>>   Т. е. для меня план действий такой:
>>
>> 1. Жду пока в Сизифе окажется OpenSSL 1.0 (т. к. в текущей сизифовской 
>> версии такой поддержки нет, если я правильно понимаю).
>>
>> 2. Жду пересборки libapr, openldap, postgresql и mysql с данной OpenSSL.
>>
>> 3. Собираю apache{,2} с вашими патчами.
>>
>>   Так?
> 
> В общем так. Только по п.2 видимо, нужны согласованные единовременные
> действия нескольких мейнтейнеров, чтобы в процессе перехода не возникло 
> такой ситуации, когда какие-то библиотеки из загружаемых в один и тот же
> процесс, еще хотят старой версии OpenSSL, а какие-то - уже новой.

   В apache2 у меня применена следующая защита:

1. Определены макросы жёстко задающие libssl (в пакете rpm-macros-apache2):

# Macros for libssl selected
%apache2_libssl_name		libssl
%apache2_libssl_soname		%(rpm -qR %apache2_libssl_name-devel | sed -rn 
'/^[[:space:]]*%apache2_libssl_name[0-9.]+[[:space:]]+[=<>]/s/^[[:space:]]*libssl([0-9.])+[[:space:]]+[=<>].*$/\\1/p')
%apache2_libssl			%apache2_libssl_name%apache2_libssl_soname

2. В apache2-common определено:

Provides: %name-%apache2_libssl_name = %apache2_libssl_soname

3. Остальные подпакеты (линкующиеся с libssl) данный Provides требуют.

   Если другие библиотеки будут каким то образом отображать на 
зависимости то, с какой именно libssl они собраны -- можно будет 
объезжать подобные (несовместимые libssl загруженные одним процессом) 
грабли в полуавтоматическом режиме.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]

Re: [devel] Вопросы новичка

[Victor B. Wagner]

On 2009.05.07 at 13:55:13 +0300, Mykola S. Grechukh wrote:

> 7 мая 2009 г. 13:16 пользователь Anton Farygin <> написал:
> > код/пересобрал - потерял сертификат (подтверждение происхождения _бинарной_
> > сборки).
> 
> кстати да, это ничем не отличается от "оригинальный бинарный пакет был
> подписан альтовским ключом" а на изменённом подписи нет.


Отличается. См закон об ЭЦП и соответствующие подзаконные акты.

Вопрос в том, что одно из назначений сертифицированной криптографии -
обеспечение юридически признаваемой электронной подписи.

Re: [devel] Вопросы новичка

[Mikhail Gusarov]

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


Twas brillig at 15:10:16 07.05.2009 UTC+04 when vitus@altlinux.org did gyre and gimble:

 VBW> Отличается. См закон об ЭЦП и соответствующие подзаконные акты.

Не отличается.

 VBW> Вопрос в том, что одно из назначений сертифицированной
 VBW> криптографии - обеспечение юридически признаваемой электронной
 VBW> подписи.

Лицензии ничего не говорят о назначении кода.

Если изменённый бинарник нельзя использовать для создания юридически
признаваемой электронной подписи в России - это не значит, что это
каким-либо образом нарушена лицензия.

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

-- 

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

Re: [devel] Вопросы новичка

[Ivan Fedorov]

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

"Victor B. Wagner" <vitus-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org>
writes:

> В свое время мне удалось пропихнуть это только в PostgreSQL.
> Вот он, начиная с 8.3 это делает. Правда, с выходом 8.4 и OpenSSL 1.0
> наверное, опять придется его патчить на предмет поддержки сертификатов
> на всяких железных токенах (в клиентской библиотеке). Потому что до
> 1.0 в OpenSSL не было API для добывания клиентского сертификата через
> engine. А в PostgreSQL до 8.4 не было авторизации пользователей по
> клиентским сертификатам.

Ну положим в сборку для ALT я это добавлю сам. Кстати говоря, pg8.4 уже
перешел в стадию beta, так что советую озаботиться пропихиванием уже
сейчас. Ибо даже сейчас уже поздновато слегка, но думаю что там патч не
очень большой и его удастся пропихнуть.

PS: 8.4 я потихоньку уже начал собирать в ALT... Думаю на выходных
выкатить первую сборку.

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

Re: [devel] Вопросы новичка

[Victor B. Wagner]

On 2009.05.07 at 15:21:02 +0400, Ivan Fedorov wrote:

> Ну положим в сборку для ALT я это добавлю сам. Кстати говоря, pg8.4 уже
> перешел в стадию beta, так что советую озаботиться пропихиванием уже
> сейчас. Ибо даже сейчас уже поздновато слегка, но думаю что там патч не

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

Ну попадет в 8.5...

Помнится, предыдущий патч я пропихивал когда 8.2 был в стадии beta, и в
итоге попал он в 8.3

Re: [devel] Вопросы новичка

[Ivan Fedorov]

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

"Victor B. Wagner" <vitus-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org>
writes:

> On 2009.05.07 at 15:21:02 +0400, Ivan Fedorov wrote:
>
>> Ну положим в сборку для ALT я это добавлю сам. Кстати говоря, pg8.4 уже
>> перешел в стадию beta, так что советую озаботиться пропихиванием уже
>> сейчас. Ибо даже сейчас уже поздновато слегка, но думаю что там патч не
>
> Э, для этого мне надо сначала сделать поддержку хотя бы одной железяки
> на которой умеют храниться сертификаты. Не с CAPI engine же
> отлаживаться.
Ммм... а какого класса железки имеются ввиду? Токены аля
eToken/ruToken/iKey или что?

> Ну попадет в 8.5...
Ну это ещё не скоро будет... года эдак через 1.5-2 скорее всего.

> Помнится, предыдущий патч я пропихивал когда 8.2 был в стадии beta, и в
> итоге попал он в 8.3
Ну логично...

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

Re: [devel] Вопросы новичка

[Victor B. Wagner]

On 2009.05.07 at 17:49:47 +0400, Ivan Fedorov wrote:

> Ммм... а какого класса железки имеются ввиду? Токены аля
> eToken/ruToken/iKey или что?

Ну вот у меня сейчас eToken свеженький с поддержкой ГОСТ на столе
валяется.

USBID 0529:0620 Product=Token JC

С него и буду начинать. 

А вообще для данного приложения, видимо, более интересны Smart Card
Readers. 

Основная область применения видится такая - point of sale application
на магазинном терминале. Вся бизнес-логика - в хранимых процедурах на
сервере БД.
Бегает куча продавцов как в Макдональдсе. Продавец подбегает к любому
терминалу, сует свою карточку, приложение тут же автомагически логинится
в базу с его именем пользователя.

Понятно, что событие вставления/вынимания смарткарты придется ловить на
уровне приложения. Но вот вся работа по собственно аутентификации должна
быть спрятана внутрь libpq openssl и pcsc

Re: [devel] Вопросы новичка

[Ivan Fedorov]

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

"Victor B. Wagner" <vitus-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org>
writes:

> On 2009.05.07 at 17:49:47 +0400, Ivan Fedorov wrote:
>
>> Ммм... а какого класса железки имеются ввиду? Токены аля
>> eToken/ruToken/iKey или что?
>
> Ну вот у меня сейчас eToken свеженький с поддержкой ГОСТ на столе
> валяется.
>
> USBID 0529:0620 Product=Token JC
>
> С него и буду начинать. 
>
> А вообще для данного приложения, видимо, более интересны Smart Card
> Readers. 
Ясно.

> Понятно, что событие вставления/вынимания смарткарты придется ловить на
> уровне приложения. Но вот вся работа по собственно аутентификации должна
> быть спрятана внутрь libpq openssl и pcsc
Одно уточнение - многие железки работают только через opensc/openct и не
имеют родных драйверов для pcsc... собсно говоря pcsc вооще неродной
стандарт на *nix-like системах. Это подарок мира MS Win.

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