Почему удостоверяющие центры не соблюдают требование CA/Browser к сертификатам

Ежегодно форум CA/Browser обновляет базовые требования к серверным SSL/TLS-сертификатам (Baseline Requirements или BR).

Одно из таких требований указано в пункте 4.9.9 с пометкой MUST:

Ответы по OCSP (протокол статуса онлайн-сертификатов) ДОЛЖНЫ соответствовать RFC 6960 и/или RFC 5019. OCSP ответы ДОЛЖНЫ либо:
  1. Иметь подпись УЦ, выдавшим сертификаты, чей статус отзыва проверяется, или
  2. Иметь подпись OCSP Responder, сертификат которого подписан УЦ, выдавшим сертификаты, чей статус отзыва проверяется

В последнем случае подписывающий сертификат OCSP ДОЛЖЕН содержать расширение типа id-pkix-ocsp-nocheck, как прописано в RFC 6960.


Именно это правило нарушают практически все удостоверяющие центры (УЦ), что имеет некоторые последствия.
Вот скриншот из Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (последняя версия 1.7.0, 4 мая 2020 года, pdf):

rlsg6xh7ziohuqfi4plim9cafzi.png

Стандарт RFC6960 в разделе 4.2.2.2 даёт определение «OCSP Delegated Responder» по наличию id-kp-OCSPSigning.

Разработчик Райан Сливи (Ryan Sleevi), компания которого специализируется на работе с сертификатами, доказал, что центры сертификации массово нарушают пункт правил 4.9.9.

Изучив данные crt.sh, Райан Сливи обнаружил 293 промежуточных сертификата без расширения pkix-nocheck, из них на данный момент 180 валидных и 113 отозванных.

Фильтрация на Census.io выдаёт 276 сертификатов, соответствующих этим условиям.

zkhuo5_bfketo6vkb0gpdr4jigs.png

Таким образом, эти сертификаты нарушают базовые требования CA/Browser, причём обязательные к выполнению требования.

По мнению Райана Сливи, удостоверяющим центрам следует внимательнее отнестись к правилам CA/Browser. Вероятно, некоторые УЦ не знакомы с требованиями RFC 6960.

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

Реальная проблема в том, что в отсутствие расширения промежуточный УЦ теоретически может отменить отзыв сертификата другого промежуточного УЦ или самого корневого УЦ. Это действительно проблема. Фактически, у удостоверяющего центра в такой ситуации нет надёжного варианта для полного и необратимого отзыва сертификатов. Процедура отзыва не работает как положено, что открывает двери для злоумышленников, которые потенциально могут провести атаку с восстановлением отозванного сертификата.

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

В оправдание УЦ можно сказать, что и без этого недостатка процедура отзыва сертификатов сейчас не работает как положено. Так, основные браузеры поддерживают собственные копии списков отозванных сертификатов CRL — и не всегда проверяют их актуальность. Эти CRL содержат только базовую, самую важную информацию, но они далеко не полные. Например, Chrome вовсе не трудится проверять, не отозван ли каждый конкретный TLS-сертификат, тогда как Firefox это делает. То есть иногда с Chrome вы можете спокойно зайти на сайт с истёкшим сертификатом, а Firefox выдаст предупреждение и не пустит вас туда.

Интересно, что по правилам неправильные сертификаты должны быть аннулированы в браузерах в течение 7 дней, но для данной ситуации сделали исключение. Бен Уилсон (Ben Wilson) из Mozilla сказал, что они не будут аннулировать сертификаты с отсутствующим расширением id-pkix-ocsp-nocheck. Хотя такие сертификаты не соответствуют правилам, но браузер Firefox не подвержен этой конкретной уязвимости в безопасности, потому что OCSP-ответы за подписью промежуточных УЦ в нём не принимаются.

УЦ должны как-нибудь заменить некорректные сертификаты, но финального срока для них не установлено.


9qwbzsfapeaakd_obyftagefhny.jpeg

Подробнее о PKI-решениях для предприятий у менеджеров GlobalSign +7 (499) 678 2210, sales-ru@globalsign.com.

© Habrahabr.ru