Как браузеры реализуют отзыв цифровых сертификатов
В нашем посте, посвященном уязвимости Hearbleed, мы указывали, что одной из дополнительных мер безопасности при работе с 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/
