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

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

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

На Хабре уже писали на данную тему (например, тут и тут), мы же в этой статье решили привести ещё более подробное описание проверок, выполняемых современными браузерами, более актуальную информацию об их настройках, и, наконец, описание того, как можно исправить сложившуюся ситуацию в будущем.

Проверки статуса сертификатов, реализованные в Веб-браузерах

Механизмы проверки статуса сертификатов, реализованные в современных Веб браузерах, представляют собой комбинацию описанных ранее базовых механизмов (CRL, OCSP, OCSP stapling) и их модификаций. Комбинирование базовых механизмов осуществляется с целью обеспечения резервирования: если один из источников информации о статусе сертификата становится недоступным, то используется резервный. Например, в качестве основного механизма проверки статуса сертификатов может использоваться протокол OCSP, однако в случае недоступности или отказа OCSP-сервера будет выполнена более трудоёмкая для клиента загрузка CRL.

Для понимания основной проблемы проверок статуса сертификатов, реализованных в современных браузерах, достаточно рассмотреть следующий сценарий атаки «человек посередине».



Закрытый ключ сервера был скомпрометирован. Владелец сервера отозвал сертификат скомпрометированного ключа, сгенерировал новую пару ключей и получил новый сертификат.
Нарушитель завладел отозванным закрытым ключом и сертификатом сервера. В данном сценарии мы намеренно не говорим, каким образом он это осуществил: в результате компрометации самого сервера или в результате компрометации удостоверяющего центра (УЦ). Это сделано для того, чтобы продемонстрировать, как браузеры поведут себя в обеих ситуациях.

Нарушитель, «человек посередине», контролирует весь трафик, идущий от клиента. Он может перехватывать или блокировать этот трафик, может пытаться отвечать клиенту от имени других сетевых сервисов.

Веб-браузер клиента при попытке установки TLS-соединения с сервером подключается к «человеку посередине». «Человек посередине» представляется сервером, используя отозванный сертификат без прикреплённого OCSP-ответа (a.k.a. OCSP stapling). Нарушитель блокирует запросы, идущие от клиента ко всем OCSP-серверам и точкам распространения CRL (a.k.a. CDP). Также нарушитель блокирует попытки клиента обновить Веб-браузер или его компоненты (например, чёрные списки «CRLSets» или «OneCRL», речь о которых пойдёт позже).

Блокирование «человеком посередине» запросов ко всем OCSP-серверам и точкам распространения CRL, во-первых, поддерживает начальное условие, согласно которому нарушитель мог скомпрометировать, как сервер, так и УЦ, и, во-вторых, наиболее полно демонстрирует проверки статуса сертификатов, выполняемые современными браузерами.

Ниже приводится описание проверок статуса сертификатов, выполняемых различными Веб-браузерами под Windows. Для других платформ детали проверок могут незначительно отличаться.

Mozilla Firefox

Поведение браузера Mozilla Firefox версии 54 (наиболее актуальной на момент написания статьи) при такой атаке отличается в зависимости от типа сертификата сервера: DV или EV. Выпуская DV-сертификат (domain validated), УЦ лишь подтверждает, что владелец ключа, указанного в сертификате, контролирует указанный в сертификате домен. Большинство сертификатов являются DV. EV-сертификат (extended validation) подтверждает не только владение доменом, но и личность владельца домена. Такие сертификаты требуют дополнительных проверок со стороны УЦ, потому они значительно дороже и встречаются реже.

Проверка статуса DV-сертификатов, выполняемая Firefox, описывается следующей диаграммой:



В схеме для простоты не показано взаимодействие с кэшем полученных ранее OCSP-ответов, поскольку полагаем, что их либо нет (из-за атаки или из-за того, что к серверу обращаются впервые за достаточно долгое время), либо они устарели и говорят о том, что сертификат не отозван. Во втором случае поведение браузера тривиально: соединение будет разрешено.

Итак, браузер проверяет статус цепочки сертификатов сервера (сертификатов промежуточных УЦ и сертификата самого сервера). Для проверки статуса сертификатов промежуточных УЦ используется хранящуюся локально на клиенте черный список «OneCRL», содержащий информацию об отозванных сертификатах, собранную из различных точек распространения CRL. Актуальность состояния чёрного списка поддерживается с помощью агрегатора CRL, отдельного удалённого сервиса, работающего следующим образом:

1. Агрегатор периодически опрашивает некоторый набор точек распространения CRL.
2. Из полученных CRL выбирает наиболее критичную информацию об отозванных сертификатах (например, сертификаты, отозванные из-за компрометации закрытого ключа).
3. Обновляет на основе этой информации в чёрные списки в браузерах.

Агрегатор CRL и, как следствие, содержимое чёрного списка «OneCRL» контролируется Mozilla. «OneCRL» не покрывает все отозванные сертификаты, а лишь сертификаты некоторых промежуточных УЦ и небольшое количество сертификатов серверов. Это делается с целью сокращения размера чёрного списка. Текущий список «OneCRL» можно посмотреть тут.

Для проверки статуса сертификата сервера используется информация, полученная из «OneCRL», прикреплённых OCSP-ответов или ответов, полученных в результате выполнения OCSP-запроса. На диаграмме указана проверка наличия прикреплённого OCSP-ответа только для сертификата сервера, поскольку Firefox не поддерживает прикреплённые OCSP-ответы для сертификатов промежуточных УЦ (RFC 6961).

Важно, что если ни один из источников информации о статусе сертификата не доступен, то сертификат не считается отозванным. Иначе говоря, проверка осуществляется в режиме soft fail. Таким образом, атака «человек посередине» проходит успешно. При этом не имеет значения, чей ключ был скомпрометирован изначально, ключ самого сервера или УЦ.

В дополнение стоит отметить, что клиентская часть протокола OCSP, реализованная в Firefox, не поддерживает одноразовые случайные коды (nonce) и, следовательно, OCSP-ответы не защищены от атак повторного воспроизведения.

Аналогичная ситуация возникает и при проверке EV-сертификатов. Разница заключается лишь в том, что браузер дополнительно выполняет OCSP-запросы и для сертификатов промежуточных УЦ:



Изменить поведение браузера и включить режим hard fail (т.е., запрет установки TLS-соединения в случаях, когда информация о статусе сертификата недоступна) можно, установив в настройках браузера («about:config») параметр «security.OCSP.require» в значение «true»:



Следует отметить, что данная настройка не активирует использование протокола OCSP для сертификатов промежуточных УЦ в случаях, когда сервер предъявляет DV-сертификат.

Для конечного пользователя hard fail в Firefox выглядит так:



Отметим, что атака «человек посередине» всё ещё возможна!.. Нарушителю требуется провести атаку повторного воспроизведения OCSP-ответа, переслав «старый» OCSP-ответ, сгенерированный ещё до того, как сертификат был отозван. Однако проводить эту атаку можно только до тех пор, пока срок действия «старого» OCSP-ответа не истечёт. При этом срок действия OCSP-ответа может быть достаточно велик. Нередко он бывает равен неделе.

Microsoft Internet Explorer/Edge

Браузеры Microsoft Internet Explorer версии 11 и Microsoft Edge версии 40 ведут себя одинаково для DV- и EV-сертификатов:



В схеме, как и ранее, для простоты не показано взаимодействие с кэшем полученных ранее OCSP-ответов и CRL, хотя этому можно посвятить отдельную статью.

Для каждого проверяемого сертификата в цепочке при отсутствии прикреплённых OCSP-ответов выполняется OCSP-запрос. При этом Internet Explorer и Edge не поддерживают прикреплённые OCSP-ответы для сертификатов промежуточных УЦ (RFC 6961) и не обеспечивают защиту OCSP-ответов от атак повторного воспроизведения. Если OCSP-сервер недоступен, то выполняется попытка загрузки CRL.

Проверка также выполняется в режиме soft fail. Таким образом, атака «человек посередине» также проходит успешно и также не имеет значения, чей ключ был скомпрометирован изначально, ключ самого сервера или УЦ.

Изменить поведение Internet Explorer возможно, например, установив значение ключа реестра «HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Internet Explorer \ Main \ FeatureControl \ FEATURE_WARN_ON_SEC_CERT_REV_FAILED \ iexplore.exe» равным 1. Тогда при отсутствии информации о статусе сертификата соединение всё равно будет разрешено, однако в адресной строке будет появляться небольшое предупреждение:



Для Edge подобных настроек не нашли.

Google Chrome/Cromium

Браузеры Google Chrome и Chromium версии 59 при проверке DV-сертификатов ведут себя следующим образом:



Проверки, выполняемые Chrome похожи, на те, что выполняет Firefox, с тем исключением, что в Chrome вообще отказались от выполнения OCSP-запросов при проверке DV-сертификатов. «CRLSets» в Chrome является аналогом «OneCRL» в Firefox (строго говоря, механизм «CRLSets» появился даже раньше) и обладает теми же проблемами неполноты и неподконтрольности конечному пользователю.

OCSP-запросы используются при проверке EV-сертификатов (тут картина становится практически идентичной той, что мы наблюдали для Firefox):



Как и другие браузеры, Chrome и Chromium работают в режиме soft fail. Прикреплённые OCSP-ответы для сертификатов промежуточных УЦ (RFC 6961) и защита OCSP-ответов от атак повторного воспроизведения не поддерживаются.

Изменить поведение Chrome и Chromium возможно внесением изменений в групповую политику (инструкция здесь) и включением следующих опций:



Эквивалентная настройка возможна и под Linux (здесь).

После внесения этих изменений Chrome и Chromium будут выполнять проверки, аналогичные тем, что делает Internet Explorer (при отсутствии прикреплённых OCSP-ответов начнут выполнять OCSP-запросы с откатом на загрузку CRL для всей цепочки сертификатов), но в режиме hard ail, т.е., при недоступности OCSP-серверов и точек распространения CRL подключение будет запрещено:



Следует ещё раз отметить, что атака «человек посередине» всё ещё возможна. Нарушителю требуется заблокировать OCSP и провести атаку повторного воспроизведения CRL, переслав «старый» CRL, сгенерированный ещё до того, как сертификат был отозван. Однако проводить эту атаку можно только до тех пор, пока срок действия «старого» CRL не истечёт. При этом срок действия CRL может быть достаточно велик. Например, срок действия CRL для сертификата «www.google.com» составляет неделю.

Прочие браузеры и платформы

Для других популярных браузеров и платформ ситуация такая же: везде проверки статуса сертификатов выполняются в режиме soft fail, либо не выполняются вовсе. Подробнее можно почитать тут или тут.

Почему сейчас всё работает именно так?

Об этом хорошо написано в блоге Адама Лэнгли. Отсутствие hard fail и отказ от явного выполнения OCSP-запросов на стороне клиента обусловлены следующими факторами:

• инфраструктура УЦ станет единой точкой отказа. Недоступность OCSP-сервера может стать причиной отказа в обслуживании целого сегмента Интернета. Инфраструктура УЦ становится новой целью для DDoS;
• увеличение затрат УЦ на поддержку инфраструктуры. УЦ требуется покупать каналы с большей пропускной способностью и обеспечивать защиту от DDoS;
• снижение надёжности TLS-соединений в нестабильных или зашумлённых сетях (например, мобильных сетях);
• увеличивается объём пересылаемого трафика и требуется большая полоса пропускания, что критично, опять же, для мобильных клиентов;
• проблемы использования OCSP вместе captive portal. Пароли, как правило, передаются поверх TLS, однако установить TLS-соединение и аутентифицироваться не получится, пока не были получены ответы от OCSP-серверов. Отправить же OCSP-запросы нельзя, поскольку OCSP-серверы (как минимум для сертификатов промежуточных УЦ), как правило, находятся в Интернете, и на этом этапе доступа к ним нет. Эта проблема может быть решена с помощью прикреплённых OCSP-ответов, однако проверка статуса промежуточных сертификатов на текущий момент всё равно требует отправки OCSP запросов, поскольку ни один браузер не поддерживает прикреплённые OCSP-ответы для сертификатов промежуточных УЦ (RFC 6961).

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

Какие есть перспективы?

Очевидный вывод из всего сказанного ранее: проверки статуса сертификатов в браузерах не работают, и это не новость. При этом просто взять и перейти на hard fail нельзя по объективным причинам.

Есть ли применимое на практике решение данной проблемы? Проанализировав и собрав воедино множество уже предложенных частичных решений данной проблемы (в частности расширение сертификатов «TLS feature», сертификаты с коротким сроком действия, агрегаторы CRL и др., о чём подробно будет рассказано ниже), предлагаем вашему вниманию наше представление о том, как проверка статуса сертификатов должна происходить на практике.

В основе лежит утверждение о том, что не для всех сервисов требуется онлайн-проверки статуса сертификатов. Для большинства сервисов накладные расходы, связанные с обеспечением строгих онлайн-проверок статуса сертификатов в режиме hard fail, не окупают риски, связанные с атакой «человек посередине» с использованием отозванных сертификатов. Иначе говоря, с точки зрения проверки статуса сертификатов, сервисы делятся на два типа:

1. Меньшинство, для которого будут проводиться строгие онлайн-проверки статуса сертификатов в режиме hard fail.
2. Большинство, для которого онлайн-проверки статуса сертификатов не будут выполняться вовсе (будут предприниматься другие меры по защите).

Браузеры могут различать такие сервисы по наличию специального расширения в сертификате сервера. В зависимости от типа сервиса клиент либо будет выполнять «параноидальную» проверку статуса сертификатов, либо не будет выполнять её вовсе. Теперь подробнее о каждой из этих двух схем.

Параноидальная схема проверки статуса сертификатов для меньшинства

В 2015 году вышла спецификация нового расширения сертификатов стандарта X.509, называемого «TLS feature» (на ранних этапах разработки стандарта также известное, как «OCSP must staple»). Это расширение сертификата позволяет зафиксировать в сертификате те опции протокола TLS, которые TLS-сервер, предъявляющий данный сертификат, обязуется поддерживать. Такой опцией протокола TLS в частности являются прикреплённые OCSP-ответы. Пример сертификата с таким расширением схематически изображён ниже:



В сертификате присутствует расширение «TLS Feature» (выделено красным), сообщающее о том, что TLS-сервер обязан поддерживать прикреплённые OCSP-ответы, специфицированные в RFC 6066 («Status Request (Version 1)»), и более новую версию данной опции («Status Request (Version 2)»), специфицированную в RFC 6961 — множественные прикреплённые OCSP-ответы. Новая версия данной опции протокола TLS позволяет прикреплять OCSP-ответы и для сертификатов промежуточных УЦ.

Например, если при подключении клиента, поддерживающего опцию «Status Request (Version 1)», о чём тот сообщает в сообщении «ClientHello» протокола рукопожатия, сервер «www.example.com» вместе со своим сертификатом, приведённым на рисунке выше, не прислал прикреплённый OCSP-ответ версии 1, то установка TLS-соединения обрывается с ошибкой. Таким образом, «человек посередине», использующий отозванный сертификат такого вида, не сможет отбросить прикреплённый OCSP-ответ, говорящий о том, что этот сертификат отозван.

Поскольку мы строим «параноидальную» схему проверки статуса сертификатов, то в дополнение к использованию сертификатов с расширением «TLS Feature», следует также отметить следующее:

1. Прикреплённые OCSP-ответы должны быть защищены от атаки повторного воспроизведения (должны использоваться случайные одноразовые коды). Даже при использовании сертификатов с таким расширением у нарушителя остаётся окно для атаки, определяемое сроком действия OCSP-ответа: всё ещё возможно провести атаку повторного воспроизведения и прислать клиенту старый OCSP-ответ, полученный ещё до того как сертификат был отозван.
2. Должна использоваться опция «Status Request (Version 2)». Эта опция позволяет прикреплять OCSP-ответы для всех сертификатов в цепочке, а не только для сертификата сервера. Это позволяет вовсе отказаться от явного выполнения OCSP-запросов на стороне клиента и всех присущих ему и описанных ранее недостатков.

Итак, в сухом остатке, «параноидальная» схема проверки статуса сертификатов основана на следующем:

• TLS-сервер использует сертификат с расширением «TLS Feature», обязывающем сервер поддерживать опции протокола TLS «Status Request (Version 1)» и «Status Request (Version 2)»;
• TLS-клиент и TLS-сервер должны использовать прикреплённые OCSP-ответы, защищённые случайными одноразовыми кодами от атаки повторного воспроизведения;
• если TLS-клиент поддерживает опцию «Status Request (Version 1)», но не поддерживает опцию «Status Request (Version 2)», то получив от сервера сертификат с расширением «TLS Feature», он должен явно выполнить OCSP-запросы (с использованием случайных одноразовых кодов) для сертификатов промежуточных УЦ в режиме hard fail.

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

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

Решением первой проблемы может служить возобновление TLS-соединений с помощью механизмов session ID или session ticket. Данные механизмы защищены от рассматриваемой атаки «человек посередине» и позволяют возобновить ранее установленное TLS-соединение без пересылки сертификатов и, соответственно, без выполнения запросов OCSP-серверам УЦ. При использовании такого подхода снижение нагрузки на OCSP-серверы будет происходить ценой хранения дополнительной информации, необходимой для возобновления соединения, на клиенте и сервере (или только клиенте).

В качестве решения второй проблемы на сервере можно попеременно использовать несколько сертификатов, выпущенных независимыми УЦ. В таком случае пока OCSP-серверы одного УЦ будут «лежать» из-за DDoS, TLS-сервер будет использовать альтернативный сертификат, выпущенный другим УЦ, не находящимся под атакой. Использование нескольких сертификатов также позволит балансировать нагрузку между УЦ.

Для того, чтобы оценить, насколько клиентская сторона (под Windows) готова к переходу в светлое будущее, можно взглянуть на следующую таблицу:

Схема для большинства

Как было сказано ранее, для большинства сервисов накладные расходы, связанные с обеспечением строгих онлайн-проверок статуса сертификатов в режиме hard fail, не окупают риски связанные с атакой «человек посередине» с использованием отозванных сертификатов. В таком случае лучше не защищаться от данной атаки, а максимально сократить временной промежуток, в течение которого проведение данной атаки будет возможным. Для этого используются сертификаты с коротким сроком действия (например, 1-2 дня).

Таким образом, большинство сервисов будет использовать сертификаты без расширения «TLS Feature», но с коротким сроком действия. Для таких сертификатов онлайн-проверки статуса сертификатов не будут выполняться вовсе. Вместо этого будет проводиться частое обновление быстро устаревающих сертификатов.

Добавим, что использование сертификатов с коротким сроком действия эквивалентно использованию сертификатов с расширением «TLS Feature», обязывающим использовать прикреплённые OCSP-ответы, вместе с прикреплёнными OCSP-ответами, не защищёнными от атаки повторного воспроизведения (т.е. OCSP-ответами, кэшируемыми на стороне TLS-сервера). При этом сертификаты с коротким сроком действия чуть более эффективны с точки зрения экономии трафика и количества операций, необходимых для проверки сертификата.

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

Итог

Что ж, пока что всё не очень хорошо: проверки статуса сертификатов в современных браузерах действительно не работают.

Однако свет в конце тоннеля всё же есть, и ситуация постепенно, хотя и медленно, движется к лучшему.