Пресертификаты в Certificate Transparency
Certificate Transparency – это набор связанных с иерархией Удостоверяющих Центров (УЦ) TLS технологий, который позволяет вести специальные логи выпускаемых и выпущенных сертификатов. Предполагается, что логи общедоступны, а их наличие позволит обнаружить сертификаты, выпущенные с нарушением правил. Чтобы усилить действие Certificate Transparency (CT), браузеры (или другие программы, которые выполняют валидацию сертификатов) могут требовать подтверждения того, что конкретный сертификат был учтён в том или ином логе CT. Удобная реализация такого требования подразумевает наличие некоторых подписанных ключами логов меток в составе самого сертификата. Такие метки называются SCT – Signed Certificate Timestamp.
Метку SCT выдаёт оператор CT-лога в ответ на добавление сертификата в лог. Когда Certificate Transparency первой версии только проектировали, то этот момент, к сожалению, не учитывали. Поэтому проявилась проблема “курицы и яйца”: чтобы выпустить сертификат с SCT-меткой – нужно получить метку, а чтобы получить метку – нужно выпустить сертификат (для того, чтобы отправить его в лог). В качестве некоторого “обходного решения” (“костыля” – скажут те, кто “хорошо в теме”) предложили ввести пресертификаты.
Пресертификат – он такой же, как и TLS-сертификат, но содержит специальное расширение (Poison), которое отмечено как критически важное (Critical), но при этом не должно распознаваться обычным валидатором. Хитрость, на которую делается расчёт, состоит в том, что, согласно рекомендациям, в случае обнаружения неизвестного расширения с флагом Critical процедура валидации должна считать сертификат не валидным. Все прочие поля пресертификата в точности совпадают с соответствующими полями сертификата, в этом весь смысл. Однако “отравленный” пресертификат как бы нельзя использовать на практике для аутентификации. И, обычно, это работает. Но, конечно, полагать, что все разнообразные валидаторы строго следуют рекомендациям по обработке расширений – слишком смело.
Тем не менее, пресертификаты широко используются в CT: УЦ, готовясь выпустить сертификат с SCT-меткой, прежде генерирует и подписывает пресертификат с теми же параметрами (имя, серийный номер и т.д.), но с poison-расширением, отправляет пресертификат в CT-лог, получает в ответ метку с подписью лога, которую уже размещает в полноценный сертификат. Таким образом в логе возникает отметка о пресертификате, которая позволяет получить все содержательные данные о сертификате. В сертификате же появляется SCT-метка, подтверждающая, что оператор лога видел сведения о сертификате. Валидность метки может проверить валидирующая программа – для проверки используется ключ лога. Этот процесс нарушает рекомендации по работе УЦ, поскольку запрещено выпускать два сертификата с одним серийным номером (и одним именем УЦ), но этот момент принято выносить за скобки.
Впрочем, во второй версии Certificate Transparency от пресертификатов отказались – для размещения сведений о сертификате используются сообщения другого формата, их формирование не требует выпуска как бы настоящего, но “испорченного” сертификата.
Адрес записки: https://dxdt.ru/2022/10/29/9293/
Похожие записки:
- TLS для DevOps
- TLS-сертификаты dxdt.ru
- Сетевая геолокация передатчиков
- Ссылка: bluetooth-атака на iOS
- Port knocking как инструмент управления доступом к скрытым сервисам
- RCE через ssh-agent
- TOR и анализ трафика в новостях
- Различительная способность "обезличенных" данных
- Поддержка STARTTLS сервисом audit.statdom.ru
- Очередная атака на предикторы в схемах оптимизации CPU
- Адреса DMARC rua в зоне cloudflare.com
Написать комментарий