Что делать, если у вашего сервера утёк закрытый ключ? Вопрос, ставший особенно актуальным после Heartbleed.
Последовательность действий, сразу приходящая в голову:
- Связаться с удостоверяющим центром.
- Отозвать сертификат сервера.
- Перегенерировать ключи.
- Запросить для сервера новый сертификат.
- Поднять бокал за успех операции и попытаться жить дальше.
К сожалению, всё не так просто. В этой и следующей статьях мы подробно ответим на следующие вопросы:
- Какие механизмы проверки статуса сертификатов бывают?
- Как они реализованы в современных Веб-браузерах?
Кто виноват?Почему они реализованы именно так?Что делать?Какие есть перспективы?
Эта статья будет полезна тем, кому интересно разобраться в применяющихся на практике механизмах проверки статуса сертификатов (проверки, является ли сертификат отозванным).
Кратко о протоколе TLS и инфраструктуре открытых ключей X.509
Современный защищённый Веб стоит на двух китах: протоколе TLS и инфраструктуре открытых ключей X.509. Для установки защищённого TLS-соединения сервер должен передать клиенту свой открытый ключ. Аутентичность ключа сервера, пересылаемого через незащищённые публичные сети, обеспечивается цепочкой сертификатов открытых ключей инфраструктуры X.509.
Удостоверяющий центр (УЦ, certification authority, CA) может отозвать подписанный (изданный) им ранее сертификат, например, в случае компрометации закрытого ключа, соответствующего этому сертификату. Поэтому, чтобы исключить возможность подключения к «человеку посередине», при установке TLS-соединения клиент должен не только проверять корректность подписей всей предоставленной сервером цепочки сертификатов, но и проверять статус предоставленных ему сертификатов (сертификат действителен или отозван).
Механизмы проверки статуса сертификатов
Применяющиеся на практике механизмы проверки статуса сертификатов основаны на списках отозванных сертификатов (certificate revocation list, CRL) и протоколе онлайн-проверки статуса сертификатов (online certificate status protocol, OCSP).
Дальше в качестве примера будем рассматривать сертификат сервера с доменным именем www.example.com, выданный УЦ «Example Certification Authority», схематично изображённый на рисунке:
Механизм CRL
УЦ публикуют CRL, в которые вносятся серийные номера отозванных сертификатов, в точках распространения CRL (CRL distribution point, CDP). Адреса (URL) точек распространения CRL, к которым следует обращаться для получения информации о статусе проверяемого сертификата, как правило, указываются в самом сертификате.
Для проверки статуса сертификата, изображённого на рисунке выше, нужно загрузить CRL, доступный по URL ca.example.com/crl, и проверить, содержится ли в нём серийный номер проверяемого сертификата (46:35:AC:5F).
На рисунке приведено схематическое изображение загруженного CRL.
В нём сообщается, что УЦ «Example Certification Authority» были отозваны три сертификата c серийными номерами 00:C9:79:0E, 46:35:AC:5F и 50:4E:6F:C7. Проверяемый сертификат является отозванным, поскольку его серийный номер находится в этом списке.
Клиенты получают свежие CRL одним из следующих способов:
- (условно в «пассивном» или оффлайн режиме) с помощью периодических обновлений. CRL в базе клиента могут обновляться автоматически, например, при обновлении клиентского ПО или в ручную администратором;
- (в «активном» или онлайн режиме) самостоятельно подгружая их по мере необходимости из CDP.
CRL чаще всего применяются для оффлайн-проверок и являются мало пригодными для систем, нуждающихся в наиболее актуальной информации о статусе сертификата и требующих упомянутых выше онлайн-загрузок CRL, по следующим причинам:
- CRL избыточны и плохо подходят для частых повторяющихся загрузок. Иногда их размеры приближаются к 1 МБ;
- CRL не защищены от атак повторного воспроизведения и позволяют «человеку посередине» подсовывать жертве неактуальные CRL, ещё не содержащие информацию о скомпрометированных ключах.
Механизм OCSP
OCSP, как следует из его названия, предназначен для получения наиболее актуальной информации о статусе сертификата в режиме онлайн и не обладает приведёнными выше недостатками CRL.
Рассмотрим работу этого протокола на примере для сертификата www.example.com (смотри второй рисунок к статье). Для получения информации о статусе сертификата TLS-клиент с помощью OCSP-клиента отправляет запрос OCSP-серверу (OCSP responder) УЦ, указанному в расширении authority information access (AIA) сертификата:
В запросе указывается серийный номер проверяемого сертификата (46:35:AC:5F). Также в запросе опционально может быть передан случайный одноразовый код (nonce), предназначенный для защиты ответа OCSP-сервера от атаки повторного воспроизведения. В ответе OCSP-сервера сообщается, что сертификат с серийным номером 46:35:AC:5F был отозван, поскольку соответствующий ему закрытый ключ был скомпрометирован. OCSP-ответ защищён от подделывания и атаки повторного воспроизведения, поскольку подписан доверенным ключом OCSP-сервера и содержит полученный от клиента случайный одноразовый код.
Следует отметить, что защита от атаки повторного воспроизведения в OCSP является опциональной и её отсутствие имеет свои преимущества. Отключение проверки значения случайного одноразового кода на клиенте позволяет кэшировать OCSP-ответы на стороне сервера, снижая накладные расходы на функционирование протокола.
Проблемами OCSP являются:
- увеличение времени установки TLS-соединения;
- раскрытие истории подключений клиента третьей стороне (УЦ).
OCSP stapling
Для решения этих проблем было предложено расширение протокола TLS, позволяющее прикреплять OCSP-ответы к сертификатам (OCSP stapling) и переносящее ответственность за выполнение OCSP на TLS-сервер.
На рисунке изображена схема использования OCSP stapling:
Схема описывает следующие шаги:
- TLS-сервер, выступая в роли OCSP-клиента, собирает информацию о статусе своей цепочки сертификатов, обращаясь к OCSP-серверам соответствующих УЦ;
- TLS-сервер кэширует полученные OCSP-ответы;
- При установке TLS-соединения сервер передаёт клиенту свою цепочку сертификатов вместе с соответствующими ей OCSP-ответами.
Таким образом:
- время установки TLS-соединения не увеличивается, поскольку в момент установки соединения OCSP не выполняется ни клиентом, ни сервером;
- снижается нагрузка на OCSP-серверы УЦ;
- клиент не раскрывает УЦ используемые им сетевые ресурсы.
«Но где же тут защита от атаки повторного воспроизведения?» — спросите вы. Тут её действительно нет, однако рассматриваемое расширение протокола TLS позволяет клиентам пересылать случайный одноразовый код при установке соединения:
Такой вариант использования OCSP stapling не позволяет кэшировать OCSP-ответы на сервере, из-за чего растёт время установки TLS-соединения и увеличивается нагрузка на серверы УЦ.
Следует отметить, что существует две версии OCSP stapling. Первая версия по неясной причине позволяет прикреплять OCSP-ответ только для сертификата самого сервера. При использовании этой версии ответственность за получение информации о статусе остальных сертификатов цепочки лежит на клиенте. Этот недостаток исправлен в новой версии.
Продолжение следует… А пока — отличная новость!
В этой статье мы рассмотрели три основных механизма проверки статуса сертификатов. Проверки, осуществляемые на практике, являются надстройками над этими механизмами или их комбинацией. Тема дальнейшего обсуждения и следующей статьи — каким образом проверки статуса сертификатов реализованы в Веб-браузерах?
Про проблему отозванных сертификатов и «Кошмар скомпрометированных ключей» мы говорили на «очной ставке» NeoQUEST-2016. У нас даже есть отличное видео, в котором автор статьи рассказывает про отозванные сертификаты:
Пока у нас активно ведется подготовка к очередной «очной ставке» NeoQUEST-2017, которая пройдет в Питере 29 июня (и на которую мы ждём ВСЕХ желающих!), рассказываем интересную новость:
Мы объявляем конкурс докладов на «очную ставку» NeoQUEST-2017!
Если у тебя есть интересные исследования по информационной безопасности и ты хочешь поделиться ими с миром — заходи на сайт neoquest.ru, отправляй заявку через специальную веб-форму, и организаторы с тобой обязательно свяжутся! По всем вопросам смело пиши на support@neoquest.ru!
Автор: НеоБИТ
