что означает сертификат отозван
Как отозвать ЭЦП для госзакупок
Как закрыть электронную подпись:
Основания для прекращения действия сертификата
Регламентируется отмена электронной подписи новым приказом Казначейства России №11н от 16.03.2020. Прекращает действие не сам ключ подписи (электронный носитель), а сертификат, который изначально и запускает действие верифицирующей системы. Инициаторами отзыва выступают не только заказчики и владельцы ЭЦП, но и специалисты Федерального казначейства.
Правила устанавливает Казначейство. Для этого выпускают специальные нормативные акты, в которых закреплены сроки и порядок отзыва ЭП. В регламенте работы с подписью указано, по какой причине удостоверяющий центр отзывает сертификат ЭЦП:
Существует процедура аннулирования ЭП. Аннулируют те ключи, которые не принадлежат владельцу ЭП и которые содержатся в ранее выпущенном сертификате. ЭЦП аннулируют и по решению суда. По регламенту ФК это происходит в течение 12 часов после сообщения заказчика о несоответствии данных, о чем вносится запись в реестр и список аннулированных сертификатов.
Как отозвать свою ЭЦП
Есть два способа, как отключить электронную подпись: лично или электронно.
Если заявка подается специалистом лично в удостоверяющий центр Казначейства, заявителю понадобится:
Так выглядит заявление в удостоверяющий центр:
Как отозвать ЭЦП уволенного сотрудника
Увольнение не имеет ключевого значения: такие действия предпринимают при смене реквизитов работника, при окончании срока действия и при ликвидации заказчика. Рассмотрим пошагово, как отозвать сертификат на электронную подпись при увольнении ответственного сотрудника.
Шаг 1. Заходим на сайт Казначейства. Переходим в сервис подачи документов для получения ЭЦП онлайн — на Портал заявителя.
Шаг 2. Выбираем в меню команду «Получение и изменение статуса сертификата». Переходим в раздел «Изменение статуса».
Шаг 3. Формируем заявление об изменении электронной подписи и заполняем все ячейки. Обязательно укажите формат изменений и основание для таких действий.
Шаг 4. Подписываем обращение и передаем в УЦ на рассмотрение.
Специалисты УЦ проводят проверку содержания обращения на соответствие реестру. Заказчик получит уведомление как о положительном, так и об отрицательном результате проверки. По итогам положительного решения электронную подпись отзовут.
Как проверить отозванную подпись
Закрытые и отозванные сертификаты казначейство отражает в специальном реестре — Списке аннулированных сертификатов. Перечень ведется онлайн и доступен каждому пользователю для проверки статуса его ЭП.
Как отзывается ЭЦП для отчетности
Помимо ключа, подписывающего закупочную документацию, в организациях и у индивидуальных предпринимателей действует ЭЦП для верификации и отправления бухгалтерской, финансовой и налоговой отчетности. Инструкция по отзыву ключа едина для всех пользователей. Все правила изложены в статье 14 63-ФЗ от 06.04.2011 (ч. 6–7, 9 ст. 14) и приказе ФНС №СА-7-6/ [email protected] от 20.08.2015. Вот алгоритм, как аннулировать электронную подпись для налоговой:
Помимо электронной версии, необходимо передать и отсканированный экземпляр, подписанный руководителем, и с печатью учреждения. Сведения об отозванном ключе отразятся в реестре.
В 2009 году закончила бакалавриат экономического факультета ЮФУ по специальности экономическая теория. В 2011 — магистратуру по направлению «Экономическая теория», защитила магистерскую диссертацию.
Как исправить ошибку в КриптоАРМ: «Нет полного доверия к сертификату подписи»
Из нашей статьи вы узнаете:
Программа «КриптоАРМ» сегодня входит в число стандартного ПО для простановки электронной цифровой подписи. Она постоянно совершенствуется, дорабатывается для предотвращения сбоев при использовании.
В большинстве случаев проблем при работе с «КриптоАРМ» не возникает, так как интерфейс программы интуитивно понятен, а алгоритмы безопасности полностью соответствуют актуальным стандартам. Одновременно пользователи периодически жалуются на наличие ошибки в виде отсутствия полного доверия к сертификату цифровой подписи. Выглядит ошибка так:
Проблему можно исправить своими силами, без обращения за помощью к техническим специалистам.
Особенности ошибки
Подобная проблема со стороны операционной системы ПК или ноутбука свидетельствует о невозможности определить уровень доверия к удостоверяющему центру, который оформил данный сертификат для ЭЦП. Это автоматически сказывается на уровне доверия к самой цифровой подписи.
Непосредственно эта ошибка никак не влияет на работу «КриптоАРМ» или ЭЦП, но для предотвращения последующих конфликтов во время проверки комплекта ключей стоит ее исправить. Сделать это можно самостоятельно, выполнив несколько следующих шагов.
Решение проблемы
Шаг № 1. Переводим программу в экспертный режим, который предоставляет доступ к полному перечню функций.
Шаг № 3. Добавляем проблемный сертификат в перечень доверенных (именно отсутствие в последнем служит причиной появления ошибки). Для этого:
Сам процесс занимает несколько секунд и требует последующей перезагрузки системы.
Шаг № 4. Финальным этапом остается проверка сертификата по перечню отозванных. Для этого:
Теперь можно перейти в личное хранилище, где должна быть обновлена вся информация. Если появилась зеленая галочка, то это признак устранения проблемы и наличия полного доверия со стороны операционной системы к данной ЭЦП.
Как установить отозванные
В отдельных случаях понадобится установка списка отозванных сертификатов (СОС) в дополнительном порядке. Для этого выполните следующие действия:
Иногда в перечне списка СОС может быть две ссылки. В этом случае понадобится повторить данный шаг.
После завершения всех действий перезагрузите ваш компьютер. Если все прошло корректно и действия были правильными, то проблем с исправлением ошибок, установкой СОС не возникает. Проблемой здесь может стать только нестабильность сетевого соединения с интернетом.
Если вам понадобилась дополнительная техническая консультация или появилась необходимость оформить ЭЦП любого типа, сделать это можно в УЦ «Астрал-М». Компания имеет аккредитацию Минкомсвязи и предлагает клиентам возможность открытия цифровых подписей любого типа. Обращаясь к нам, вы получаете:
Получить дополнительную информацию можно по телефону, либо оставив запрос на сайте. Мы в течение 5 минут после получения заявки свяжемся с вами для уточнения вопросов. Мы расскажем, как получить электронную подпись и какие документы потребуются для этого.
Как восстановить электронную подпись
Бывают ситуации, когда вам нужно восстановить свою электронную подпись, например, если вы ее потеряли или случайно удалили. В статье ответим на вопрос, можно ли восстановить электронную подпись, что делать, если вы ее потеряли или кто-то завладел ею без вашего согласия.
Можно ли восстановить электронную подпись?
Сперва ответим кратко: восстановить электронную подпись (ЭП или ЭЦП) нельзя — необходимо получать новую. За редкими исключениями.
А теперь разберемся, почему восстановление ЭП невозможно и какие исключения все-таки есть.
Электронная подпись состоит из нескольких элементов:
Обычно восстановление электронной подписи ищут те, кто удалил ключи ЭП или потерял носитель, на который были записаны ключи.
Удалил электронную подпись
Если вы случайно удалили все файлы ЭП, то они стерлись из памяти компьютера безвозвратно. Это сделано для безопасности персональных данных владельца и для его защиты от мошенников.
Потерял электронную подпись
Потерянную электронную подпись восстановить также не получится. Если вы потеряли токен, то вы потеряли ключи электронной подписи. Закрытый и открытый ключи — это набор уникальных цифровых символов, и сгенерировать повторно точно такие же не получится. Поэтому восстановить прежнюю ЭП невозможно — придется выпустить новую.
В этой ситуации исключений нет.
Восстановить электронную подпись нельзя — нужно оформлять новую электронную подпись. Чтобы подобрать ЭП, обратитесь за консультацией к нашим менеджерам.
Что делать, если вы потеряли ЭП
Если вы потеряли токен, подозреваете, что ЭП скомпрометирована или уверены, что вашей подписью завладел другой человек, то сертификат нужно срочно отозвать. Отзыв — это прекращение действия электронной подписи, ее блокировка.
Даже если вы спустя какое-то время нашли токен и еще не отозвали сертификат, мы рекомендуем отозвать его и выпустить новый. Злоумышленники могли воспользоваться сертификатом за время его отсутствия и подписать документы от вашего имени. Потом будет сложно доказать, что эти документы подписали не вы.
По этой же причине мы не рекомендуем делать копии ключей электронной подписи или относиться к ним особенно бережно. Если потеряется одна из копий токена с ключами ЭП — это тоже будет считаться компрометацией, при которой рекомендуется аннулировать сертификат. Чем быстрее вы это сделаете, тем меньше операций возможный злоумышленник успеет провести от вашего имени.
Как отозвать сертификат ЭП
1. Подайте заявление на аннулирование ЭП или ЭЦП
Бланк для заполнения можно запросить в том удостоверяющем центре, где вам выдали сертификат ЭП. Для клиентов Контура шаблон заявления опубликован на сайте в разделе «Документы».
В заявлении надо указать серийный номер сертификата. Узнать его можно через программу «КриптоПро CSP»:
Если сертификат еще не был установлен на компьютер, то заполнить заявление помогут специалисты того удостоверяющего центра, в котором вы его получали.
2. Принесите заполненное заявление в офис УЦ лично.
Отзыв сертификата — такая же важная процедура, как и его выдача. Специалисты УЦ должны идентифицировать владельца перед отзывом, поэтому отправить вместо себя доверенное лицо нельзя.
Если вы не можете посетить офис УЦ Контура лично, то можно вызвать нашего курьера. Он удостоверит личность и примет заявление.
3. Проверьте, что сертификат отозван.
Это произойдет в течение 12 часов после того, как УЦ получит от вас заявление.
Чтобы проверить отзыв, клиенты Контура могут скачать на сайте УЦ перечень отозванных сертификатов, который обновляется каждые 12 часов.
Какие проблемы могут возникнуть
Если владелец электронной подписи потерял токен или его ЭП кто-то завладел, то за время, пока он не отозвал сертификат, им могут воспользоваться злоумышленники. Например, открыть на физлицо фирму-однодневку, чтобы получить микрокредит или заключить сделки и уклониться от налогов. Также возможно перевести деньги со счетов юрлица, реализовать имущество организации, победить в торгах, получить аванс, но не исполнить договор, внести изменения в ЕГРЮЛ — например, сменить руководителя.
Поэтому мы рекомендуем владельцу ЭП никому не передавать токен с сертификатом ЭП и не давать доступ к закрытому ключу ЭП другим лицам. Соблюсти конфиденциальность ключа ЭП владелец должен по закону (пп.1 п.1 ст.10 63-ФЗ).
Другие лица могут злоупотребить доверием и воспользоваться ЭП в своих целях. Если вы подозреваете, что к ЭП имел доступ другой человек, рекомендуем отозвать сертификат по инструкции выше.
«Человек посередине», использующий отозванные сертификаты. Часть 2
В нашей предыдущей статье были описаны основные механизмы проверки статуса сертификатов (проверки, является ли сертификат отозванным). В этой статье мы ответим на следующие вопросы:
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-запросов на стороне клиента обусловлены следующими факторами:
Какие есть перспективы?
Очевидный вывод из всего сказанного ранее: проверки статуса сертификатов в браузерах не работают, и это не новость. При этом просто взять и перейти на 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-запросов на стороне клиента и всех присущих ему и описанных ранее недостатков.
Итак, в сухом остатке, «параноидальная» схема проверки статуса сертификатов основана на следующем:
В качестве решения второй проблемы на сервере можно попеременно использовать несколько сертификатов, выпущенных независимыми УЦ. В таком случае пока OCSP-серверы одного УЦ будут «лежать» из-за DDoS, TLS-сервер будет использовать альтернативный сертификат, выпущенный другим УЦ, не находящимся под атакой. Использование нескольких сертификатов также позволит балансировать нагрузку между УЦ.
Для того, чтобы оценить, насколько клиентская сторона (под Windows) готова к переходу в светлое будущее, можно взглянуть на следующую таблицу:
Схема для большинства
Как было сказано ранее, для большинства сервисов накладные расходы, связанные с обеспечением строгих онлайн-проверок статуса сертификатов в режиме hard fail, не окупают риски связанные с атакой «человек посередине» с использованием отозванных сертификатов. В таком случае лучше не защищаться от данной атаки, а максимально сократить временной промежуток, в течение которого проведение данной атаки будет возможным. Для этого используются сертификаты с коротким сроком действия (например, 1-2 дня).
Таким образом, большинство сервисов будет использовать сертификаты без расширения «TLS Feature», но с коротким сроком действия. Для таких сертификатов онлайн-проверки статуса сертификатов не будут выполняться вовсе. Вместо этого будет проводиться частое обновление быстро устаревающих сертификатов.
Добавим, что использование сертификатов с коротким сроком действия эквивалентно использованию сертификатов с расширением «TLS Feature», обязывающим использовать прикреплённые OCSP-ответы, вместе с прикреплёнными OCSP-ответами, не защищёнными от атаки повторного воспроизведения (т.е. OCSP-ответами, кэшируемыми на стороне TLS-сервера). При этом сертификаты с коротким сроком действия чуть более эффективны с точки зрения экономии трафика и количества операций, необходимых для проверки сертификата.
Подход с использованием сертификатов с коротким сроком действия обладает целым рядом достоинств, однако малопригоден для сертификатов УЦ. Для проверки статуса таких сертификатов можно использовать периодически обновляемые чёрные списки аналогичные «CRLSets» и «OneCRL», но предоставляющие пользователям больший контроль на агрегаторами CRL. Пользователи, например, должны иметь возможность добавлять новые опрашиваемые точки распространения CRL. Это важно, поскольку некоторые организации разворачивают собственные не публичные УЦ для внутреннего использования. Решением может стать возможность использования приватных агрегаторов CRL. При этом понадобится разработать открытый протокол взаимодействия клиента и агрегатора CRL, обеспечивающий совместимость клиентов и агрегаторов различных вендоров.
Что ж, пока что всё не очень хорошо: проверки статуса сертификатов в современных браузерах действительно не работают.
Однако свет в конце тоннеля всё же есть, и ситуация постепенно, хотя и медленно, движется к лучшему.