«Человек посередине», использующий отозванные сертификаты. Часть 1

Что делать, если у вашего сервера утёк закрытый ключ? Вопрос, ставший особенно актуальным после Heartbleed ^[1].

Последовательность действий, сразу приходящая в голову:

1. Связаться с удостоверяющим центром.
2. Отозвать сертификат сервера.
3. Перегенерировать ключи.
4. Запросить для сервера новый сертификат.
5. Поднять бокал за успех операции и попытаться жить дальше.

К сожалению, всё не так просто. В этой и следующей статьях мы подробно ответим на следующие вопросы:

• Какие механизмы проверки статуса сертификатов бывают?
• Как они реализованы в современных Веб-браузерах?
• Кто виноват? Почему они реализованы именно так?
• Что делать? Какие есть перспективы?

Эта статья будет полезна тем, кому интересно разобраться в применяющихся на практике механизмах проверки статуса сертификатов (проверки, является ли сертификат отозванным).

Кратко о протоколе TLS и инфраструктуре открытых ключей X.509

Современный защищённый Веб стоит на двух китах: протоколе TLS ^[2] и инфраструктуре открытых ключей X.509 ^[3]. Для установки защищённого TLS-соединения сервер должен передать клиенту свой открытый ключ. Аутентичность ключа сервера, пересылаемого через незащищённые публичные сети, обеспечивается цепочкой сертификатов открытых ключей инфраструктуры X.509 ^[4].

Удостоверяющий центр (УЦ, certification authority, CA) может отозвать подписанный (изданный) им ранее сертификат, например, в случае компрометации закрытого ключа, соответствующего этому сертификату. Поэтому, чтобы исключить возможность подключения к «человеку посередине», при установке TLS-соединения клиент должен не только проверять корректность подписей всей предоставленной сервером цепочки сертификатов, но и проверять статус предоставленных ему сертификатов (сертификат действителен или отозван).

Механизмы проверки статуса сертификатов

Применяющиеся на практике механизмы проверки статуса сертификатов основаны на списках отозванных сертификатов ^[3] (certificate revocation list, CRL) и протоколе онлайн-проверки статуса сертификатов ^[5] (online certificate status protocol, OCSP).

Дальше в качестве примера будем рассматривать сертификат сервера с доменным именем www.example.com ^[6], выданный УЦ «Example Certification Authority», схематично изображённый на рисунке:

Механизм CRL

УЦ публикуют CRL, в которые вносятся серийные номера отозванных сертификатов, в точках распространения CRL (CRL distribution point, CDP). Адреса (URL) точек распространения CRL, к которым следует обращаться для получения информации о статусе проверяемого сертификата, как правило, указываются в самом сертификате.

Для проверки статуса сертификата, изображённого на рисунке выше, нужно загрузить CRL, доступный по URL ca.example.com/crl ^[7], и проверить, содержится ли в нём серийный номер проверяемого сертификата (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 ^[6] (смотри второй рисунок к статье). Для получения информации о статусе сертификата 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 ^[8]) и переносящее ответственность за выполнение OCSP на TLS-сервер.

На рисунке изображена схема использования OCSP stapling:

Схема описывает следующие шаги:

1. TLS-сервер, выступая в роли OCSP-клиента, собирает информацию о статусе своей цепочки сертификатов, обращаясь к OCSP-серверам соответствующих УЦ;
2. TLS-сервер кэширует полученные OCSP-ответы;
3. При установке TLS-соединения сервер передаёт клиенту свою цепочку сертификатов вместе с соответствующими ей OCSP-ответами.

Таким образом:

• время установки TLS-соединения не увеличивается, поскольку в момент установки соединения OCSP не выполняется ни клиентом, ни сервером;
• снижается нагрузка на OCSP-серверы УЦ;
• клиент не раскрывает УЦ используемые им сетевые ресурсы.

«Но где же тут защита от атаки повторного воспроизведения?» — спросите вы. Тут её действительно нет, однако рассматриваемое расширение протокола TLS позволяет клиентам пересылать случайный одноразовый код при установке соединения:

Такой вариант использования OCSP stapling не позволяет кэшировать OCSP-ответы на сервере, из-за чего растёт время установки TLS-соединения и увеличивается нагрузка на серверы УЦ.

Следует отметить, что существует две версии OCSP stapling. Первая версия ^[9] по неясной причине позволяет прикреплять OCSP-ответ только для сертификата самого сервера. При использовании этой версии ответственность за получение информации о статусе остальных сертификатов цепочки лежит на клиенте. Этот недостаток исправлен в новой версии ^[10].

Продолжение следует… А пока — отличная новость!

В этой статье мы рассмотрели три основных механизма проверки статуса сертификатов. Проверки, осуществляемые на практике, являются надстройками над этими механизмами или их комбинацией. Тема дальнейшего обсуждения и следующей статьи — каким образом проверки статуса сертификатов реализованы в Веб-браузерах?

Про проблему отозванных сертификатов и «Кошмар скомпрометированных ключей» мы говорили на «очной ставке» NeoQUEST-2016. У нас даже есть отличное видео, в котором автор статьи рассказывает про отозванные сертификаты:

Пока у нас активно ведется подготовка к очередной «очной ставке» NeoQUEST-2017, которая пройдет в Питере 29 июня (и на которую мы ждём ВСЕХ желающих!), рассказываем интересную новость:

Мы объявляем конкурс докладов ^[11] на «очную ставку» NeoQUEST-2017!

Если у тебя есть интересные исследования по информационной безопасности и ты хочешь поделиться ими с миром — заходи на сайт neoquest.ru, отправляй заявку через специальную веб-форму, и организаторы с тобой обязательно свяжутся! По всем вопросам смело пиши на support@neoquest.ru!

Автор: НеоБИТ

Источник ^[12]