Contents of this directory is archived and no longer updated.

Недавняя тема «Мифы о мифах» подтолкнула меня к очередному эпосу на тему мифов в целом и PKI в частности. Основная мысль заключается в том, что частный результат может быть очень даже противоположным общему. Хоть фундамент PKI и выглядит монолитным, его основание закладывается из множества составных деталей. И, следуя указанной мысли, одна деталька не всегда соответствует конечному итогу.

Возьмём один абстрактный пример: администратор X нашёл способ обхождения ограничения RFC (RFC5280, §4.2.1.9) путём подписания пользовательским сертификатом (например, сертификатом EFS или secure email) другого сертификата. Здесь нужно дать большое пояснение сути проблемы.

В бытность использования сертификатов версии 1 было отмечено множество проблем. Например, невозможно было определить тип сертификата — конечный сертификат или сертификат промежуточного CA. Так же было невозможно узнать для каких целей может использоваться сертификат (например, только для шифрования файлов). Нельзя было проверить сертификат на отзыв, если CRL издателя не установлен (закеширован) в системе. Так же, проблемы начинались при обновлении сертификатов самих CA. Вобщем, проблем было много и гибко использовать сертификаты не представлялось возможным. Версия 2 решила только одну проблему — обновление сертификата CA. И только сертификаты версии 3 стали способны решить многие проблемы тех времён. Это было достигнуто за счёт появления расширений сертификата. Расширения сертификатов могут содержать всевозможную информацию о самом сертификате, издателе, владельце ключа и т.д. Например, мы можем применить расширение Enhanced Key Usage и на основании его содержимого принимать решение, можно ли использовать предъявленный сертификат для конкретной задачи или нет. Например, в правильном мире ни одно приложение (rfc-conformant) не согласится использовать сертификат с EKU = Encrypting File System для установки цифровой подписи и т.д. Дальнейшая дискуссия пойдёт только о сертификатах версии 3.

Вернёмся же, к нашему вопросу. Согласно RFC5280, §4.2.1.9, подписывать сертификаты можно только сертификатом, которое содержит расширение Basic Constraints и свойство cA (certification authority) выставлено в true. Так же это расширение должно быть помечено как критичное. Если одно из этих условий не выполняется, такой сертификат не может использоваться для подписи других сертификатов (условно говоря, выступать в роли CA). Но пытливые умы находят лазейку (в виде утилит вида openssl, makecert или низкоуровневых API) и подписывают пользовательским сертификатом другой сертификат. Слабонервные могут впасть в панику, хвататься за острые и режущие предметы или выбрасываться из окон верхних этажей небоскрёбов, потому что мир рухнул. Они так верили в PKI, а тут какой-нибудь openssl взял и дискредитировал всю нерушимую идею PKI. Необходимо как-то запретить такие вольности.

Но я спешу успокоить вас. PKI существует очень давно и сегодня подобные фокусы не пройдут. Давайте посмотрим, как это выглядит на картинках. Я взял свой сертификат, предназначенный только для Code и Document Signing и подписал другой сертификат:

This certificate is not valid for the selected purpose #1

посмотрим вкладку Certification path:

This certificate is not valid for the selected purpose #2

А тут конечный сертификат ВНЕЗАПНО is Ok. Правда, можно заметить, что на предыдущем сертификате в цепочке стоит треугольничек. Когда я запустил файл, Windows пропустил сертификат через упрощённый движок построения цепочки (certificate chaining engine или сокращённо CCE). Поскольку CCE очень любит rfc и не любит openssl, он задетектировал ошибку, что предъявленный сертификат не может использоваться для указанного применения. Но мы пока не видим, каким боком тут вырос Basic Constraints. Для этого мы воспользуемся certutil'ом и посмотрим более детальный трейс CCE (публикую только отрывок):

ChainContext.dwErrorStatus = CERT_TRUST_IS_NOT_VALID_FOR_USAGE (0x10)
ChainContext.dwErrorStatus = CERT_TRUST_INVALID_BASIC_CONSTRAINTS (0x400)

вот тут мы и видим, что проблема с Basic Constraints. Дело в том, что мой сертификат подписи не содержит этого расширения, следовательно не может использоваться для подписывания других сертификатов. Вот описание этой ошибки по версии MSDN:

The certificate or one of the certificates in the certificate chain has a basic constraints extension, and either the certificate cannot be used to issue other certificates, or the chain path length has been exceeded.

Следовательно, если предъявить подобный сертификат любому приложению, которое использует rfc-conformant certificate chaining engine (будь то встроенный в Windows или что-то своё), приложение должно очень сильно ругнуться на сертификат и отклонить его.

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

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


Share this article:

Comments:

gexeg.blogspot.com
gexeg.blogspot.com 19.04.2011 23:55 (GMT+3) Знакомьтесь, Basic Constraints

rfc это конечно же хорошо, и best practices... но есть еще требования: к системе, к процессам и т.д. а если требования не совпадают с rfc или best practices? тут на помощь приходит гибкость использования криптографии и PKI. приходится отходить от rfc... организовывать свои способы проверки валидности сертификата. Например, Exchange 2007/2010 использует аутентификацию Kerberos или механизм direct-trust при anonymous TLS, а ключи (не важно в каком они виде) использует только для шифрования.

URANUS
URANUS 20.04.2011 06:45 (GMT+3) Знакомьтесь, Basic Constraints

Vadims Podāns - продолжайте серию статей по PKI, крайне интересно.

Ruslan V. Karmanov
Ruslan V. Karmanov 26.04.2011 22:16 (GMT+3) Знакомьтесь, Basic Constraints

Всё достаточно логично - если использовать низкоуровневое API, а не приложение, то можно делать напрямую отдельные функции, которые, в случае их применения в приложении, просто были бы ошибочны/нарушали логику обработки. Можно так же и отдельно ключами пользоваться, или вообще только san читать. На то оно и API. Кстати, а это кто - http://likesd.ru/sertifikat-i-basic-constraints/ ? Называется Сергей, аккуратно из копипасты вырезал финальный кусок со ссылками. Нехорошо как-то.

Ruslan V. Karmanov
Ruslan V. Karmanov 26.04.2011 22:22 (GMT+3) Знакомьтесь, Basic Constraints

Видимо, это будущий MVP, потому что он трёт комментарии с вопросом про удивительную схожесть данного постинга и его.

Vadims Podāns
Vadims Podāns 26.04.2011 23:09 (GMT+3) Знакомьтесь, Basic Constraints

Шапку поста потёр тоже. Кстати, в почте у него работает автоответчик.

Ruslan V. Karmanov
Ruslan V. Karmanov 26.04.2011 23:48 (GMT+3) Знакомьтесь, Basic Constraints

Странный вообще дяденька какой-то.

Vadims Podāns
Vadims Podāns 26.04.2011 23:58 (GMT+3) Знакомьтесь, Basic Constraints

Домен зареган почти 3 недели назад и сайт завален копипастами. Обычный SEO-мусор.

Comments are closed.