Как браузеры реализуют отзыв цифровых сертификатов

    В нашем посте, посвященном уязвимости Heartbleed, мы указывали, что одной из дополнительных мер безопасности при работе с HTTPS подключением является включенная в браузере опция проверки отозванного цифрового сертификата. Для Heartbleed это особенно актуально, так как после обновления уязвимой версии OpenSSL на сервере, специалистам компании необходимо заново получить новый приватный ключ (SSL/TLS) и сгенерировать новый сертификат, а старый отозвать. Браузеры должны различать подобные ситуации (использования в HTTPS отозванного цифрового сертификата) и уведомлять своих пользователей о том, что используемое ими соединение с сервером уже не является доверенным.

    Цифровые сертификаты SSL или TLS используются для привязки криптографического открытого ключа к информации об организации (компании, сервисе и т. д.). Таким образом, будучи выданным центром сертификации (Certification Authority), он гарантирует клиенту этой организации, что используемый открытый ключ шифрования принадлежит именно этой организации. Безопасное HTTPS соединение использует преимущество такой системы шифрования с открытым ключом, при которой сертификаты SSL/TLS, а также закрытый ключ сервера, используются для установки полностью безопасного подключения, которому пользователь может безоговорочно доверять при передаче своих данных.

    Ранее уже публиковалась информация о том, что исследователям с использованием уязвимости Heartbleed удалось успешно скомпрометировать такие защищенные сервисы как CloudFlare, OpenVPN, а также, Yahoo mail. Похитив секретный ключ атакующие могут расшифровать данные пользовательских сессий и позднее представиться сервером, при этом пользователь будет думать, что работает с легитимным источником. В таком случае, сам сертификат открытого ключа является скомпрометированным и CA, который выдал сертификат, не может гарантировать, что пользователь работает с настоящим сервером.


    Рис. Перевыпущенный Yahoo цифровой сертификат.

    Когда на сервере выполнено обновление одной из уязвимых версий OpenSSL до необходимой 1.0.1g, был получен новый сертификат открытого ключа (и соответствующий ему закрытый ключ сервера), старый сертификат отозван, а пользователь сменил пароль на свой аккаунт, он все равно может оставаться уязвим, работая со своим браузером. Мы указывали, что злоумышленники могут позднее использовать похищенный закрытый ключ для того, чтобы представиться сервером или организовать атаку типа Man-in-the-Middle, скомпрометировав таким образом HTTPS. Так может произойти потому, что используемый браузер не обновил информацию об отозванном цифровом сертификате и продолжает считать его доверенным.

    Существуют два основных способа, с помощью которых браузер может проверить информацию о состоянии сертификата (т. е. является ли он действительным или отозванным): протокол получения статуса сертификата (Online Certificate Status Protocol, OCSP) и список отозванных сертификатов (Certificate Revocation List, CRL). Через OCSP клиент может получить информацию от CA о статусе сертификата перед созданием HTTPS подключения с соответствующим сервером. CRL содержит список отозванных цифровых сертификатов, причем этот список кэшируется браузером в процессе работы.

    Google Chrome

    В феврале 2012 г., Google отключил проверку отозванных цифровых сертификатов для Chrome в новых версиях браузера. Такое решение было обусловлено медленностью и временными задержками, которые необходимы для обработки запроса получения статуса сертификата через OCSP. Проверка статуса занимала около 300 миллисекунд или почти секунду для каждого нового HTTPS подключения. В Google также посчитали, что такая задержка может препятствовать переходу сервисов на использование HTTPS из-за того, что мало кому из их клиентов понравилась бы такая задержка при каждом подключении к серверу (установке нового подключения). Также компания отказалась от постоянного контроля статуса сертификатов, поскольку исследования показали, что большинство сертификатов были отозваны не из-за их компрометации со стороны злоумышленников, а из-за иных административных решений компаний.

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


    Рис. Настройка Google Chrome.

    Mozilla Firefox

    Разработчики Firefox отказались от постоянной проверки статуса сертификатов с использованием списков CRL в последних версиях браузера, вместо этого там используется протокол OCSP, который включен по умолчанию. В то же время, списки CRL в браузере все еще присутствуют и информация для них обновляется на регулярной основе (асинхронно, вне зависимости от устанавливаемых подключений, через т. н. механизм Revocation List Push). Также как и Chrome, Firefox предупреждает пользователя об использовании сервером отозванного сертификата, блокируя таким образом доступ пользователя к запрашиваемой странице. Как видно на скриншоте ниже, браузер содержит опцию «При ошибке соединения с сервером OCSP рассматривать сертификат как недействительный», которая по умолчанию выключена. Таким образом в случае, если запрашиваемый CA недоступен, для проверки статуса сертификата, пользователь получит сообщение об ошибке при работе с любым сертификатом, так как невозможно утверждать является ли он действительным или отозванным.


    Рис. Соответствующая опция проверки статуса цифрового сертификата с Mozilla Firefox.

    MS Internet Explorer

    Поведение браузера зависит от соответствующей версии и используемой ОС. На современных выпусках Windows 7 и Windows 8 Internet Explorer (начиная с 8-й версии) поддерживает проверку сертификатов новых подключений через OCSP, а также использует списки CRL в качестве запасного варианта. По умолчанию для проверки статуса сертификата используется OCSP. Как Google Chrome и Mozilla Firefox, Internet Explorer не разрешает пользователю просматривать веб-страницы, для подключения к которым используется отозванный цифровой сертификат.


    Рис. Настройка проверки отозванных сертификатов в IE 8+ на Windows 7+ (включено по умолчанию).

    Apple Safari

    Этот браузер не имеет встроенных механизмов проверки отозванных сертификатов. Вместо этого он использует т. н. Apple Keychain Access. Настройки, связанные с проверкой отозванных сертификатов, находятся в меню «Настройки»->«Сертификаты». Настройка «Лучшая попытка» используется для задания проверок сертификатов с помощью проверок OCSP и CRL. По умолчанию проверка сертификатов отключена. В отличие от трех вышеупомянутых браузеров, Safari позволяет пользователю пропустить предупреждение об отозванном сертификате. Для этого пользователю нужно нажать на пункт «Продолжить» в всплывающем окне.



    На основе первоисточника: blog.cisecurity.org/how-browsers-handle-certificate-revocation
    ESET NOD32
    107,00
    Компания
    Поделиться публикацией

    Похожие публикации

    Комментарии 11

      +6
      opera:config

      По умолчанию включено.
        0
          +2
          А вот здесь www.imperialviolet.org/2014/04/19/revchecking.html умный товарищ из Гугла доходчиво объясняет, почему включение этой опции абсолютно бесполезно для вашей безопасности.

          Основной его довод:

          Что делать, если от OCSP не придет ответ? Режектить по умолчанию — режим hard-fail — или пропускать — режим soft-fail? Hard-fail неюзабелен. Тут я с автором согласен: прожив с hard-fail режимом пару дней, я убедился, что интернет становится абсолютно непригодным к использованию, т.к. постоянно то для одного, то для другого сертификата проверка не проходит и может не проходить часам. Жить без Гугла или Википедии по полдня жутко неудобно.

          В режиме Soft-fail эти проверки также абсолютно бесполезны. Чтобы воспользоваться украденным сертификатом, злоумышленнику придется перенаправлять ваш трафик на его сервер. Значит, трафик он контролирует, и значит, все запросы по OCSP он может блокировать. Браузер такие блокировки в режиме soft-fail проигнорирует и пустит вас на сайт злоумышленника. В своем посте автор описывает еще возможные варианты обхода злоумышленником проверок вплоть до того, что он может зарегистрировать свой сервер у CA и тогда CA будет отдавать валидный OSCP-ответ для этого сервера.

          Самое главное: чтобы провести на вас атаку, злоумышленник должен работать на довольно высоком уровне — уровне государств и крупных провайдеров. Как всегда, правильным решением для вашей защиты — для тех, кто рискует жизнью (вы дисидент или революционер, или еще что-то в том же духе) — может быть VPN-сервер с сертификатом, который вы проверили сами и сами добавили себе в список доверенных. Если вы просто ходите в Гугл и платите в интернете картой, то вам это в целом не нужно.
            0
            Ок, что с вероятно похищенными с помощью heartbleed сертификатами?
            Если не ошибаюсь, то победитель конкурса на утаскивание сертификата у CloudFlare мог продемонстрировать поддельный сайт.

            Т.е.
            чтобы провести на вас атаку, злоумышленник должен работать на довольно высоком уровне — уровне государств и крупных провайдеров.

            Не совсем верно?
              0
              Он имел закрытый ключ, но для того, чтобы им воспользоваться, ему надо успешно провести mitm-атаку
                0
                Но, это уже гораздо более понятная, с технической точки зрения, атака.
                0
                У Федора нужно было IP поддельного сайта себе в hosts прописать. Без этого браузер спрашивал DNS, а тот направлял его на настоящий сайт CloudFlare.
                  0
                  Таким образом, задача усложнилась на целую подмену ответа от DNS-сервера. А это, конечно же, невозможно.
                0
                Да, OCSP — кривой неюзабельный костыль.
                Нормальным решением было бы распространение информации о сертификатах через DNS-записи специального типа — например, как это предлагается в RFC 6698. Но, боюсь, не дождемся: DNSSEC-то мало где нормально работает.
                0
                Также стоит заметить, что при использовании OCSP браузер кому-то сообщает о каждом посещенном https-сайте.
                  0
                  Почему бы не проверять раз в день, а не при каждом соединении?

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое