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@×××××.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'ом собирать)