Инфраструктура открытых ключей: цепочки, имена, отзыв

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

Тема разбирает сертификат X.509 изнутри: поля, расширения, подпись. Затем построение и проверку цепочки: кто кому доверяет, как работают ограничения, что такое path length и name constraints. Дальше — сопоставление имени: SAN против CN, подстановочные знаки и типичные обходы. Потом отзыв: CRL, OCSP, stapling и Certificate Transparency. Завершается разбором инцидентов: DigiNotar, Comodo, Superfish — и выводом, что PKI ломается не криптографией, а процессом.

Сертификат X.509

Поля и назначение

Сертификат связывает открытый ключ с именем: субъект, издатель, серийный номер, срок действия, открытый ключ, расширения и подпись издателя. Подпись вычисляется по DER-кодировке tbsCertificate — той части, которая содержит все поля, кроме самой подписи ¹.

Расширения определяют, что сертификату разрешено: basicConstraints (является ли он CA, ограничение глубины), keyUsage (подпись, шифрование, только сертификаты), extendedKeyUsage (TLS-сервер, TLS-клиент, код), subjectAltName (имена, для которых он действителен), nameConstraints (какие имена может выдавать этот CA).

Доверие

Корневые сертификаты находятся в хранилище доверия операционной системы или браузера. Цепочка: лист → промежуточный → корень. Проверяющий строит путь до доверенного корня и проверяет подписи, сроки, расширения и ограничения.

Ключевая идея: доверие не «вычисляется», оно «назначено». Выдача сертификатов всё чаще автоматизируется по ACME ⁸, и это меняет профиль риска: скорость выдачи растёт, а проверка домена становится программной. Браузер доверяет корню, потому что его туда добавили; вся стойкость PKI сводится к тому, насколько аккуратно этот список ведётся.

Проверка цепочки

Что проверяется

Проверка цепочки (RFC 5280, раздел 6) включает: подпись каждого сертификата ключом издателя, срок действия на текущий момент, соответствие basicConstraints (промежуточный обязан быть CA), ограничение глубины pathLenConstraint, корректность keyUsage и extendedKeyUsage, ограничения имён nameConstraints, а также проверку отзыва — но её объём зависит от политики клиента, и ниже это оговорено отдельно.

Отдельно стоит различать два этапа, которые часто смешивают. Построение пути — поиск последовательности сертификатов от доверенного корня до проверяемого, с учётом AIA (откуда догружать промежуточные), перекрёстных подписей и альтернативных цепочек. Проверка выбранного пути — применение перечисленных выше ограничений к уже найденной цепочке. Ошибки первого этапа дают «сертификат не проверяется», ошибки второго — «проверяется то, что не должно»; лечатся они по-разному.

Пропуск любого пункта проверки — уязвимость. Классический пример: проверка подписи без проверки basicConstraints позволяет подписать сертификат ключом, который не является CA.

Ограничения имён

nameConstraints в корневом или промежуточном сертификате говорит, какие домены он вправе обслуживать. Это защита от «слишком широкого» промежуточного CA: если он скомпрометирован, противник не сможет выписать сертификат на чужой домен. Проверка nameConstraints обязательна и часто забывается в самописных проверках ².

Схема цепочки и ограничений на рисунке 1.

Сопоставление имени

SAN против CN

Современное правило: имя берётся из subjectAltName, поле commonName для этого не используется ³. Исторические реализации проверяли CN, что давало обходы: сертификат с CN=example.com и SAN на другой домен принимался по CN.

Подстановочные знаки

*.example.com соответствует a.example.com, но не a.b.example.com и не example.com. Ошибки в сопоставлении (принятие *.example.com за example.com.evil.com, или наоборот) — классика обходов. Правило: подстановка заменяет ровно одну метку слева и не может быть частью публичного суффикса.

Null-байты, юникод-гомоглифы, завершающие точки, регистр — всё это места, где строгий парсер обязан нормализовать имя до сравнения. Схема на рисунке 2.

Отзыв

CRL и OCSP

CRL — подписанный список отозванных серийных номеров, обновляется периодически. OCSP — запрос по конкретному сертификату, ответ подписан; формат запроса и ответа описан в RFC 6960 ⁴. Проблемы: CRL бывают огромными и устаревшими, OCSP создаёт зависимость от доступности службы и утечку приватности (запрос раскрывает, какие сайты посещает клиент).

Stapling и мягкий отказ

OCSP stapling позволяет серверу приносить подписанный ответ OCSP с собой, не раскрывая клиента. Мягкий отказ (soft-fail) — принимать сертификат, если проверить отзыв не удалось — на практике превращает отзыв в формальность: противник блокирует OCSP и проходит.

Отзыв как политика, а не как безусловное требование

Обязательность проверки отзыва зависит от клиента и сценария. Браузеры и публичные клиенты обычно применяют мягкий отказ: недоступность OCSP не блокирует соединение, иначе сбой одной службы останавливал бы половину интернета. Клиенты с жёсткой политикой (корпоративные, финансовые, часть библиотек с -crl_check) применяют жёсткий отказ и отвергают сертификат при любой неопределённости. Есть и промежуточные режимы: проверять только при наличии stapled-ответа, игнорировать CRL, ограничивать проверку списком известных издателей.

Практический вывод: «проверка отзыва обязательна» — не универсальное утверждение о X.509, а выбор политики. Уязвимость возникает не от отсутствия проверки самой по себе, а от расхождения между заявленной политикой и фактическим поведением кода; при мягком отказе противнику достаточно заблокировать канал к OCSP, при жёстком — достаточно недоступности службы, чтобы устроить отказ в обслуживании. Проектировщик выбирает, какой из этих рисков ему дороже.

Certificate Transparency

CT публикует все выданные сертификаты в журналы, построенные на деревьях Меркле (апокриф 7). Клиент проверяет наличие SCT (подписанной метки времени) и может обнаружить сертификат, выданный на его домен без его ведома ⁵. CT не предотвращает выдачу, но делает её обнаруживаемой — это сдвиг от предотвращения к прозрачности.

Механика доверия к журналу опирается на три проверяемых объекта. Signed Certificate Timestamp (SCT) — обещание журнала включить сертификат; подписан и содержит время. Proof of inclusion — доказательство, что конкретная запись находится в дереве с данным корнем: путь из хешей от листа к корню, проверяемый за логарифмическое число шагов. Proof of consistency — доказательство, что новая версия дерева продолжает старую и ничего из неё не удалено: без него журнал мог бы «переписать» историю, выдав новый корень на месте старого. Проверка включения без проверки согласованности оставляет ровно ту атаку, от которой CT защищает, поэтому в мониторинге нужны обе.

Инциденты

DigiNotar

В 2011 году голландский CA DigiNotar был скомпрометирован, и противник выдал сотни сертификатов, включая *.google.com. Браузеры отозвали доверие к корню, компания обанкротилась. Урок: компрометация CA — компрометация всего, что он подписал, а обнаружение зависит от внешнего мониторинга ⁶.

Comodo и Superfish

Comodo (2011) — поддельные сертификаты через взлом реселлера. Superfish (2015) — предустановленный корневой сертификат с известным закрытым ключом, который позволял перехватывать TLS на ноутбуках. Урок: доверие к корню — это доверие ко всему, что этот корень может подписать, включая скомпрометированный закрытый ключ.

Что общего

Все три случая — не взлом криптографии, а слабость процесса: контроль доступа к ключам, проверка выдачи, аудит хранилищ доверия. Массовые измерения перехвата TLS показывают, что подменённые корни встречаются в корпоративных и домашних сетях регулярно ⁷.

Вывод: PKI — организационная конструкция, и её надо оценивать как процесс.

Итоги темы

• Сертификат связывает ключ с именем; доверие назначается хранилищем.
• Проверка цепочки включает подписи, сроки, назначение и ограничения имён.
• Имя берётся из SAN; подстановка покрывает одну метку; нормализация обязательна.
• Отзыв работает только при жёстком отказе; CT делает выдачу обнаруживаемой.
• Инциденты PKI — про процесс, а не про математику.

Литература

1. RFC 5280: Internet X.509 Public Key Infrastructure — Certificate and CRL Profile. 2008. — структура сертификата и алгоритм проверки цепочки.
2. RFC 6125: Representation and Verification of Domain-Based Application Service Identity. 2011. — правила сопоставления имён, SAN и подстановочные знаки.
3. CA/Browser Forum Baseline Requirements. — требования к выдаче сертификатов и проверке доменов.
4. RFC 6960: Online Certificate Status Protocol. 2013. — OCSP и его ограничения.
5. RFC 6962: Certificate Transparency. 2013. — журналы, SCT и деревья Меркле.
6. Wilson R. How DigiNotar Was Hacked. 2012. — разбор инцидента и его последствий.
7. Durumeric Z. et al. The Security Impact of HTTPS Interception. NDSS 2017. — массовое измерение перехвата TLS.
8. RFC 8555: Automatic Certificate Management Environment (ACME). 2019. — автоматизация выдачи и её риски.

Дополнительные материалы к апокрифу 12

Вопросы для самопроверки

1. Какие поля сертификата подписываются?
2. Кто решает, какому корню доверять?
3. Что произойдёт, если не проверить basicConstraints?
4. Зачем нужен keyUsage и какие биты критичны для CA?
5. Как ограничить домены, которые может обслуживать промежуточный CA?
6. Почему SAN появился как замена CN?
7. Как подстановочный знак соотносится с публичными суффиксами?
8. Почему example.com. и example.com должны считаться одним именем?
9. Что проверяет CRL и в чём его слабость?
10. Почему OCSP ухудшает приватность?
11. Что такое stapling?
12. Почему soft-fail опасен?
13. Как SCT связан с деревом Меркле?
14. Почему компрометация CA — катастрофа?
15. Какие меры снижают ущерб от компрометации CA?

Глоссарий темы

Шпаргалка

bash make-pki.sh
openssl x509 -in certs/inter.pem -text -noout
openssl verify -CAfile certs/root.pem -untrusted certs/inter.pem certs/leaf.pem
openssl ca -config conf/inter.cnf -gencrl -out crl/inter.crl
cp verify_chain_template.py verify_chain.py && python3 check_chain.py

Что почитать и посмотреть

• RFC 5280 — профиль сертификата и алгоритм проверки.
• RFC 6125 — сопоставление имён.
• CA/Browser Forum Baseline Requirements — требования к выдаче.
• RFC 6960 — OCSP.
• RFC 6962 — Certificate Transparency.
• Wilson. How DigiNotar Was Hacked — разбор инцидента.
• Durumeric et al. The Security Impact of HTTPS Interception — измерение перехвата.
• RFC 8555 — ACME и автоматизация выдачи.

Углубление: почему доверие к корню абсолютно

Корневой сертификат в хранилище доверия — это разрешение подписывать что угодно в рамках его ограничений. Если у корня нет ограничений (а у большинства публичных корней их нет, кроме политик CA/Browser Forum), то компрометация ключа означает возможность выписать сертификат на любой домен.

Отсюда практики: промежуточные CA с ограничениями, разделение ключей по назначению, HSM для корневых ключей, аудит выдачи, CT для обнаружения. Ни одна из них не делает PKI «неуязвимой», но каждая уменьшает радиус поражения.

Углубление: почему отзыв не работает так, как задумано

Теория: клиент проверяет CRL или OCSP и отвергает отозванный сертификат. Практика: CRL огромны и обновляются редко; OCSP зависит от доступности и раскрывает приватность; многие клиенты при недоступности отзыва пропускают проверку (soft-fail), иначе сайт «сломался бы».

Именно поэтому появился CT: вместо предотвращения — обнаружение. Сертификат, выданный без ведома владельца, попадает в журнал, и владелец может это заметить. Это не заменяет отзыв, но делает атаку видимой, а видимость — часть защиты.

Углубление: почему проверка имени — источник обходов

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

Правило: нормализовать имя до сравнения, брать его только из SAN, использовать библиотечную функцию сопоставления, а не самописную. Самописная проверка имени — почти гарантированная уязвимость.

Лабораторная работа 12. Кому доверяет браузер

• Раздел курса: апокриф 12 «PKI: цепочки, имена, отзыв»

Введение

«Сейф» выдаёт сертификаты сотрудникам и сервисам. Есть корневой CA, промежуточный, шаблоны в openssl. Всё выглядит правильно — пока не выясняется, что промежуточный CA не имеет ограничений имён, проверка цепочки не смотрит на basicConstraints, а сопоставление имени берёт commonName вместо subjectAltName.

Работа идёт от структуры к процессу. Сначала собственная PKI: корень, промежуточный, лист, конфигурации openssl. Потом проверка цепочки: подписи, сроки, назначение, глубина. Затем продвинутая часть — собственная реализация проверки по RFC 5280 с ограничениями имён. Дальше сопоставление имён: SAN, подстановочные знаки, нормализация. Завершается отзывом, Certificate Transparency и разбором инцидентов.

Части: построение PKI, проверка цепочки, ограничения имён, сопоставление имени, отзыв и CT, инциденты.

Цель работы

Научиться проверять цепочку сертификатов так, как это делает браузер, и видеть, какие пропущенные проверки открывают какие атаки.

После выполнения работы получится:

• строить корневой, промежуточный и листовой сертификаты через openssl;
• проверять цепочку и объяснять каждую проверку;
• реализовывать проверку по RFC 5280 с basicConstraints, keyUsage и nameConstraints;
• сопоставлять имена по SAN с учётом подстановочных знаков;
• объяснять, как работают CRL, OCSP, stapling и CT;
• разбирать инциденты PKI как отказы процесса.

Теоретический минимум

Разделы «Сертификат X.509», «Проверка цепочки», «Сопоставление имени», «Отзыв», «Инциденты» апокрифа 12. Ключевые правила:

подпись проверяется ключом издателя по tbsCertificate
basicConstraints: CA:TRUE и pathLenConstraint
keyUsage: keyCertSign для CA, digitalSignature для листа
nameConstraints: permitted / excluded для доменов
имя: subjectAltName (dNSName), CN не используется
подстановка: *.example.com покрывает одну метку слева

Перечень оснащения

Ubuntu 24.04, Python 3.10+, cryptography, OpenSSL 3.0. Права root не нужны. Архив lr-env.

mkdir -p ~/lab-apocrypha-12 && cd ~/lab-apocrypha-12
unzip ~/lr-env.zip
bash make-pki.sh
python3 check_pki.py

Заготовка копируется в файл без суффикса _template: verify_chain.py.

Порядок выполнения работы

В журнале фиксируйте: параметры ключей, расширения каждого сертификата, результат каждой проверки цепочки и причину отказа. Провал — с причиной: неверный keyUsage, отсутствующий basicConstraints, несовпадение имени.

Часть 1. Построение PKI

Задание

1. Изучите conf/root.cnf и conf/inter.cnf: какие расширения заданы и зачем.
2. Запустите bash make-pki.sh. Разберите, какие команды создают ключи, CSR и сертификаты.
3. Проверьте результат: openssl x509 -in certs/inter.pem -text -noout. Убедитесь, что промежуточный имеет CA:TRUE и pathlen:0.
4. Запустите python3 check_pki.py pki: проверки структуры, расширений и подписей.
5. Ответьте: почему промежуточному CA нужен pathlen, и что произойдёт без него.

Часть 2. Проверка цепочки

Задание

1. Соберите цепочку вручную: openssl verify -CAfile certs/root.pem -untrusted certs/inter.pem certs/leaf.pem.
2. Испортите один байт в листе и проверьте, что подпись перестаёт сходиться.
3. Подмените издателя у листа на другой сертификат и посмотрите, какую ошибку вернёт openssl.
4. Запустите python3 check_pki.py pki — он проверяет то же самое через cryptography.
5. Ответьте: какие проверки выполняет openssl verify и какие остаются на приложении.

Часть 3. Ограничения имён

Задание

1. Добавьте в промежуточный сертификат nameConstraints с permitted;DNS:.seif.example и перевыпустите его.
2. Выпустите лист на evil.example и проверьте, что проверка цепочки отвергает его.
3. Реализуйте в verify_chain.py проверку basicConstraints, pathLenConstraint, keyUsage и nameConstraints.
4. Запустите python3 check_chain.py: проверки на корректные и испорченные цепочки.
5. Ответьте: почему ограничения имён обязательны для промежуточных CA и почему их часто забывают.

Часть 4. Сопоставление имени

Задание

1. Реализуйте hostname_matches(cert, host): имя берётся из SAN, commonName игнорируется, регистр приводится, завершающая точка отбрасывается.
2. Реализуйте подстановочные знаки: *.example.com покрывает a.example.com, но не a.b.example.com и не example.com.
3. Проверьте набор случаев: evil-example.com, example.com.evil.com, .., юникод-гомоглифы.
4. Запустите python3 check_chain.py — раздел сопоставления.
5. Ответьте: почему проверка CN вместо SAN даёт обход и как это связано с историческими реализациями.

Часть 5. Отзыв и CT

Задание

1. Соберите CRL для своей PKI: openssl ca -gencrl. Проверьте, что отозванный лист отвергается.
2. Разберите ответ OCSP: какие поля подписаны, кто отвечает, что видит клиент.
3. Объясните, чем stapling лучше обычного OCSP для приватности и почему soft-fail делает отзыв формальностью.
4. Опишите, как CT обнаруживает сертификат, выданный без ведома владельца: SCT, журнал, дерево Меркле.
5. Ответьте: почему отзыв — самое слабое место PKI на практике.

Часть 6. Инциденты

Задание

1. Разберите DigiNotar: как был скомпрометирован CA, какие сертификаты выданы, что сделали браузеры.
2. Разберите Comodo и Superfish: где находился закрытый ключ и почему доверие к корню оказалось чрезмерным.
3. Сформулируйте, какие организационные меры предотвратили бы каждый инцидент.
4. Соберите чек-лист проверки сертификата для приложения: цепочка, срок, назначение, имя, отзыв.
5. Ответьте: почему PKI оценивают как процесс, а не как алгоритм.

Журнал работы

Фиксируйте: расширения каждого сертификата, результат openssl verify, причину отказа при подмене, набор проверенных имён. Провал — с причиной.

Контрольные вопросы

1. Что связывает сертификат и на чём держится доверие?
2. Какие расширения ограничивают, что может подписывать CA?
3. Что проверяет алгоритм построения и проверки цепочки?
4. Зачем нужен pathLenConstraint?
5. Почему nameConstraints обязательны для промежуточных CA?
6. Почему имя берут из SAN, а не из CN?
7. Как работает подстановочный знак и где он не работает?
8. Почему нормализация имени обязательна?
9. Чем CRL отличается от OCSP?
10. Что даёт stapling и в чём опасность soft-fail?
11. Как CT делает выдачу сертификатов обнаруживаемой?
12. Что общего у DigiNotar, Comodo и Superfish?