[gentoo-user-ru] openssl: CRL Distribution Point

[gentoo-user-ru] openssl: CRL Distribution Point

[Anton Ananich]

Здравствуйте!

Это письмо в продолжение темы "openssl: certificate authority".

Описание ситуации: есть компания "Рога и Копыта". Сотрудники Бендер и
Паниковский работают за компьютерами с Gentoo Linux и обмениваются
сообщениями e-mail. В силу специфики их работы они имеют потребность
шифровать свою переписку с помощью SSL сертификатов. В компании
имеется Certificate Authority (CA) и у каждого из сотрудников на
компьютере установлен корневой сертификат. Здесь неявно
предполагается, что CA включает корневой сертификат, все выданные
пользовательские сертификаты, а также список отозванных сертификатов
(CRL)

В один день Паниковский теряет свой ноутбук вместе с сертификатом. Он
сообщает об этом администратору, администратор с помощью
# openssl -revoke panikovsky.pem
делает сертификат невалидным, выдает новый ноутбук и новый сертификат.

Вопросы:
1) Как _правильно_ нужно настроить CA, чтобы Бендер мог об этом узнать
о том, что сертификат скомпрометирован как можно скорее?
2) Как протестировать, что CRL действительно блокирует сертификаты в
   a) браузере (например firefox)
   б) почтовом клиенте ( например Thunderbird или Microsoft Outlook)

Ранее в рассылке было упомянуто решение: CRL Distribution Point,
однако поиск в сети не дал желаемых результатов. Надеюсь мы сможем
найти истину вместе :)

С уважением,
Антон Ананич

Re: [gentoo-user-ru] openssl: CRL Distribution Point

[Denis V. Rybakov]

Anton Ananich wrote:

> В силу специфики их работы они имеют потребность
> шифровать свою переписку с помощью SSL сертификатов.

Нет такого понятия "ssl-сертификат".
Не надо выдумывать отсебятину, это запутывает и тебя, и собеседника.
Лучше почитать RFC3280, RFC2510 и принять существующую терминологию,
а заодно и получить ответы на 90% своих вопросов :)

> В один день Паниковский теряет свой ноутбук вместе с сертификатом. Он
> сообщает об этом администратору, администратор с помощью
> # openssl -revoke panikovsky.pem
> делает сертификат невалидным, выдает новый ноутбук и новый сертификат.
>
> Вопросы:
> 1) Как _правильно_ нужно настроить CA, чтобы Бендер мог об этом узнать
> о том, что сертификат скомпрометирован как можно скорее?
> 2) Как протестировать, что CRL действительно блокирует сертификаты в
>    a) браузере (например firefox)
>    б) почтовом клиенте ( например Thunderbird или Microsoft Outlook)
>   

Есть множество этапов, которые выполняют при проверке сертификата на 
валидность
Что касается проверки на отозванность, то это вообще отдельная тема, 
т.к. каждый строит свою
схему в зависимости от жесткости требований.
Ну например приведу более менее полную схему.
1. NotBefore <= NOW <= NotAfter
2. Поиск CRL для данного УЦ в хранилище.
2.1 Попытка обновить CRL через CDP (CRL Distrubution Point, опциональна, 
указывается в качестве расширения в сертификате УЦ)
2.1.1 Если удалось, проверяем на присутствие в списке
2.1.2 Если не удалось, можем игнорировать, при условии наличия в 
локальном хранилище
неистекшего CRL, а можем обломать, в зависимости от параноидальности.
3. Проверка статуса через службу OCSP, опять же возможны варианты, если 
не удалось до нее достучаться (доверять локальному CRL или нет).

И это еще не все. Тема вопроса обширнейшая.
В криптографической подсистеме винды есть даже понятие Revocation 
Provider, т.е. это отдельная сущность, которая
исходя из своей логики, говорит тебе валиден сертификат или нет и 
которую можно написать под свои требования.

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

Единственное - в мозилле (firefox, thinderbird, etc) криптуха более 
менее реализована, оно даже OCSP держит.

> Ранее в рассылке было упомянуто решение: CRL Distribution Point,
> однако поиск в сети не дал желаемых результатов. 

CDP это всего лишь вершина айсберга.

> Надеюсь мы сможем найти истину вместе :)
>   

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

Тупое решение в лоб.
1. Создаешь CA с расширением id-ce-cRLDistributionPoints (CDP по 
простому), там можно всякие URI указывать,
самое простое - http. Будет типа http://blabla.bla/ca.crl 
(на чем CA поднимать не спрашивай, тут тоже все печально. самое простое 
- можешь из openvpn выдрать)
2. На CA обеспечиваешь, чтобы текущий crl был доступен по тому же урлу, 
что и в расширении корневого сертификта.
3. Магическим образом заставляешь клиентское ПО использовать проверку 
сертификатов по CRL вытащенгному с CDP
(могу ошибаться, но вроде в openssl есть механизмы, которые сами это 
делают, если с curl'ом собирать)

Re: [gentoo-user-ru] openssl: CRL Distribution Point

[Anton Ananich]

Трудно не согласиться, ведь если бы с криптографией в gentoo не было
проблем, то я бы и не стал вопрос задавать :-)

На счет openssl и curl не совсем понятно: поизводится ли в принципе
проверка сертификата на нахождение в revokation list. Скорее всего
если такая возможность и есть, то curl не задействован в реализации:

# ./Configure --help
Usage: Configure [no-<cipher> ...] [enable-<cipher> ...] [-Dxxx]
[-lxxx] [-Lxxx] [-fxxx] [-Kxxx] [no-hw-xxx|no-hw] [[no-]threads]
[[no-]shared] [[no-]zlib|zlib-dynamic] [enable-montasm] [no-asm]
[no-dso] [no-krb5] [386] [--prefix=DIR] [--openssldir=OPENSSLDIR]
[--with-xxx[=vvv]] [--test-sanity] os/compiler[:flags]

# emerge -pv openssl
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild   R   ] dev-libs/openssl-0.9.8h-r1  USE="(sse2) zlib -bindist
-gmp -kerberos -test" 0 kB
Total: 1 package (1 reinstall), Size of downloads: 0 kB

Всё это наталкивает на мысль, что проверка НЕ выполняется. Думаю стоит
попробовать провести эксперимет.

2009/1/5 Denis V. Rybakov <denis.rybakov@gmail.com>:
> Anton Ananich wrote:
>
>> В силу специфики их работы они имеют потребность
>> шифровать свою переписку с помощью SSL сертификатов.
>
> Нет такого понятия "ssl-сертификат".
> Не надо выдумывать отсебятину, это запутывает и тебя, и собеседника.
> Лучше почитать RFC3280, RFC2510 и принять существующую терминологию,
> а заодно и получить ответы на 90% своих вопросов :)
>
>> В один день Паниковский теряет свой ноутбук вместе с сертификатом. Он
>> сообщает об этом администратору, администратор с помощью
>> # openssl -revoke panikovsky.pem
>> делает сертификат невалидным, выдает новый ноутбук и новый сертификат.
>>
>> Вопросы:
>> 1) Как _правильно_ нужно настроить CA, чтобы Бендер мог об этом узнать
>> о том, что сертификат скомпрометирован как можно скорее?
>> 2) Как протестировать, что CRL действительно блокирует сертификаты в
>>   a) браузере (например firefox)
>>   б) почтовом клиенте ( например Thunderbird или Microsoft Outlook)
>>
>
> Есть множество этапов, которые выполняют при проверке сертификата на
> валидность
> Что касается проверки на отозванность, то это вообще отдельная тема, т.к.
> каждый строит свою
> схему в зависимости от жесткости требований.
> Ну например приведу более менее полную схему.
> 1. NotBefore <= NOW <= NotAfter
> 2. Поиск CRL для данного УЦ в хранилище.
> 2.1 Попытка обновить CRL через CDP (CRL Distrubution Point, опциональна,
> указывается в качестве расширения в сертификате УЦ)
> 2.1.1 Если удалось, проверяем на присутствие в списке
> 2.1.2 Если не удалось, можем игнорировать, при условии наличия в локальном
> хранилище
> неистекшего CRL, а можем обломать, в зависимости от параноидальности.
> 3. Проверка статуса через службу OCSP, опять же возможны варианты, если не
> удалось до нее достучаться (доверять локальному CRL или нет).
>
> И это еще не все. Тема вопроса обширнейшая.
> В криптографической подсистеме винды есть даже понятие Revocation Provider,
> т.е. это отдельная сущность, которая
> исходя из своей логики, говорит тебе валиден сертификат или нет и которую
> можно написать под свои требования.
>
> Основная беда в том, что в линуксе ничего такого централизованного нет -
> хранилища сертификатов, единое криптоапи и т.д.
> Да даже нецентрализованного тоже в общем то нет, openssl который с ооочень
> большим натягом можно посчитать за стандарт
> каждое приложение использует как ему вздумается.
>
> Единственное - в мозилле (firefox, thinderbird, etc) криптуха более менее
> реализована, оно даже OCSP держит.
>
>> Ранее в рассылке было упомянуто решение: CRL Distribution Point,
>> однако поиск в сети не дал желаемых результатов.
>
> CDP это всего лишь вершина айсберга.
>
>> Надеюсь мы сможем найти истину вместе :)
>>
>
> Истина в том, что криптуха в линуксе в плачевном состоянии.
> А если говорить о каком-то стандарте на уровне системы, то ее просто нет.
>
> Тупое решение в лоб.
> 1. Создаешь CA с расширением id-ce-cRLDistributionPoints (CDP по простому),
> там можно всякие URI указывать,
> самое простое - http. Будет типа http://blabla.bla/ca.crl (на чем CA
> поднимать не спрашивай, тут тоже все печально. самое простое - можешь из
> openvpn выдрать)
> 2. На CA обеспечиваешь, чтобы текущий crl был доступен по тому же урлу, что
> и в расширении корневого сертификта.
> 3. Магическим образом заставляешь клиентское ПО использовать проверку
> сертификатов по CRL вытащенгному с CDP
> (могу ошибаться, но вроде в openssl есть механизмы, которые сами это делают,
> если с curl'ом собирать)

Re: [gentoo-user-ru] openssl: CRL Distribution Point

[Vlad "SATtva" Miller]

Anton Ananich (07.01.2009 02:11):
> Трудно не согласиться, ведь если бы с криптографией в gentoo не было
> проблем, то я бы и не стал вопрос задавать :-)

Здесь имеет место подмена понятий. Утверждать, что в Линуксе вообще и в
Генте в частности проблема с криптографией значит не понимать ни того,
ни другого (с тем же успехом можно заявить, что в Линуксе проблемы с
профессиональной 3d-графикой, потому что не работает Макс). Речь в
данном треде идёт конкретно об X.509 PKI, который успешно поддерживается
де-факто стандартный openssl. При этом ничто не мешает построить
инфраструктуру на основе более гибкого OpenPGP.

> На счет openssl и curl не совсем понятно: поизводится ли в принципе
<trimmed>

> Вопросы:
> 1) Как _правильно_ нужно настроить CA, чтобы Бендер мог об этом узнать
> о том, что сертификат скомпрометирован как можно скорее?
> 2) Как протестировать, что CRL действительно блокирует сертификаты в
>    a) браузере (например firefox)
>    б) почтовом клиенте ( например Thunderbird или Microsoft Outlook)

http://openssl.org/docs/apps/x509v3_config.html#CRL_distribution_points_
http://www.openssl.org/docs/apps/ocsp.html

-- 
SATtva | security & privacy consulting
www.vladmiller.info | www.pgpru.com

Re: [gentoo-user-ru] openssl: CRL Distribution Point

[Anton Ananich]

Здравствуйте!

Я попытался проверить как работает CRL в openssl, и написал, что из
этого вышло. К сожалению похвастаться нечем: при выполнении команды

openssl verify -verbose -crl_check -CAfile cacert.pem usercert.pem

получаю фигвам -- unable to get certificate CRL; Почему? После
полутарочасового копания в исходниках я обнаружил, что в OpenSSL есть
косяк. Дело в том, что при поиске CRL сравниваются два поля: Issuer
сертификата, который выглядит примерно так:

Issuer: O=TestCompany, CN=Root CA

и Issuer списка отозванных сертификатов (CRL)

Issuer: /O=TestCompany/CN=Root CA

А они почему-то оказались не равны... Почему? А в исходниках коммент:

Retrieve CRL corresponding to certificate: currently just a
subject lookup: maybe use AKID later...

Думаю, что естественней было бы сравнивать не Issuerы а Authority Key
Identifierы

Вывод: есть два варианта: либо я что-то не так сгенерировал, либо
openssl-0.9.8h не поддерживает CRL из-за этого бага. То есть скорее
всего раньше поддерживал, а потом были внесены изменения, и т.д.

С уважением,
Антон Ананич

2009/1/7 Vlad SATtva Miller <sattva@vladmiller.info>:
> Anton Ananich (07.01.2009 02:11):
>> Трудно не согласиться, ведь если бы с криптографией в gentoo не было
>> проблем, то я бы и не стал вопрос задавать :-)
>
> Здесь имеет место подмена понятий. Утверждать, что в Линуксе вообще и в
> Генте в частности проблема с криптографией значит не понимать ни того,
> ни другого (с тем же успехом можно заявить, что в Линуксе проблемы с
> профессиональной 3d-графикой, потому что не работает Макс). Речь в
> данном треде идёт конкретно об X.509 PKI, который успешно поддерживается
> де-факто стандартный openssl. При этом ничто не мешает построить
> инфраструктуру на основе более гибкого OpenPGP.
>
>> На счет openssl и curl не совсем понятно: поизводится ли в принципе
> <trimmed>
>
>> Вопросы:
>> 1) Как _правильно_ нужно настроить CA, чтобы Бендер мог об этом узнать
>> о том, что сертификат скомпрометирован как можно скорее?
>> 2) Как протестировать, что CRL действительно блокирует сертификаты в
>>    a) браузере (например firefox)
>>    б) почтовом клиенте ( например Thunderbird или Microsoft Outlook)
>
> http://openssl.org/docs/apps/x509v3_config.html#CRL_distribution_points_
> http://www.openssl.org/docs/apps/ocsp.html
>
> --
> SATtva | security & privacy consulting
> www.vladmiller.info | www.pgpru.com
>
>
>