Безопасность в интернете основывается на доверии к SSL-сертификатам, которые подтверждают подлинность веб-сайтов и обеспечивают шифрование передачи данных. Однако в случае компрометации сертификата или возникновения подозрений в его надежности, он должен быть отозван, чтобы предотвратить потенциальные атаки и защитить пользователей. Традиционные методы проверки отзыва сертификатов - это списки отозванных сертификатов (CRL) и протокол Online Certificate Status Protocol (OCSP). Однако Google внедрил собственное решение для браузера Chrome, известное как CRLSet, обещая более эффективную и упрощенную защиту. Но действительно ли CRLSet решают проблемы классической системы ревокации? Этот вопрос остается крайне актуальным и требует тщательного рассмотрения.
CRLSet представляет собой ограниченный, тщательно курируемый набор серийных номеров отозванных сертификатов, составляемый командой Chromium. По сути, это сжатая версия классических списков отзыва, включающая только ключевые сведения, призванные оптимизировать производительность браузера и снизить нагрузку на сеть. Тем не менее, ограничение размера CRLSet - 256 килобайт - подразумевает, что в нее может попасть лишь незначительная доля всех отозванных сертификатов. На практике это привело к тому, что CRLSet охватывает всего 53 органов сертификации (CA) из сотен существующих и содержит около 24 тысяч отозванных сертификатов, в то время как в общей сложности в публичных списках насчитываются более двух миллионов отозванных. Текущая ситуация с CRLSet вызывает серьезную озабоченность: при использовании Chrome пользователь оказывается фактически защищен лишь от отзыва сертификатов, выпущенных этими немногими CA.
Остальные сертификаты, отозванные большинством остальных центров сертификации, браузер попросту не распознает как недействительные. Особенно тревожно, что среди таких игнорируемых оказались сотни тысяч сертификатов, отозванных одним из самых популярных CA - Globalsign, включая те, которые были заменены в ответ на инцидент с уязвимостью Heartbleed. Это значит, что число потенциальных угроз, которым Chrome не способен противостоять с помощью CRLSet, очень велико. В попытке замаскировать этот недостаток, команда разработчиков вручную добавляет особо заметные или критичные отозванные сертификаты в специальный заголовок файла CRLSet. На практике это означает, что если веб-сайт с отозванным сертификатом имеет высокий профиль, его защитят, но это скорее исключение из правила, чем норма.
Например, сайт revoked.grc.com, который служит тестовым полигоном для проверки систем ревокации, был добавлен именно так. Однако подобный подход выглядит как временное решение, требующее постоянного обновления и сосредоточенности внимания на проблемных сайтах, что далеко не идеально для всеобщей безопасности. Сравнение с другими браузерами и операционными системами показывает, что Chrome существенно отстает.
Firefox и Internet Explorer, например, используют более традиционные методы проверки с онлайн-запросами к CRL и OCSP, что, несмотря на определенные недостатки, повышает эффективность обнаружения отозванных сертификатов. Firefox, например, сразу заблокировал доступ к revoked.grc.com без необходимости ручного вмешательства, тогда как Chrome потребовалось время и дополнительная корректировка CRLSet. Ценность онлайн-проверок заключается в том, что браузер может динамически получить актуальную информацию о статусе сертификата, что становится критичным в моменты резкого увеличения числа отзывов, как это случилось после Heartbleed.
Однако и традиционные методы далеко не безупречны. Они могут замедлять работу браузера за счет дополнительных сетевых запросов или могут быть скомпрометированы злоумышленниками путем блокировки этих запросов. Несмотря на это, они обеспечивают защиту в тех ситуациях, когда недавно отозванный сертификат попадет в список, а браузер получит обновление статуса. В отличие от CRLSet, которые работают по принципу офлайн-списка и ограничены размером и охватом, классические методы позволяют оставаться в курсе новых угроз и обеспечивают более гибкую защиту. В поисках оптимального решения в отрасли начали продвигать технологию OCSP Must-Staple.
Этот протокол предусматривает, что веб-сервер при каждом соединении предоставляет браузеру актуальное подтверждение от центра сертификации о статусе сертификата через "стейплинг" OCSP, что позволяет избежать задержек из-за сетевых запросов и повысить надежность проверки. Уже сегодня большинство популярных серверов поддерживают OCSP Stapling, а Firefox и IE активно продвигают проверку с обязательным использованием этой техники, что значительно повышает уровень безопасности пользователей. Подводя итоги, можно утверждать, что несмотря на удобство и оптимизацию, которые предлагает Chrome с CRLSet, эта система далека от идеала и не может считаться полноценной заменой традиционным механизмам проверки отзыва сертификатов. Ограниченный охват, зависимость от ручного добавления критичных сертификатов и игнорирование большинства центров сертификации создают существенные пробелы в безопасности. Пользователи Chrome рискуют не получить предупреждение о посещении сайта с отозванным сертификатом, что поднимает вопрос об адекватности предлагаемой Google защиты.
Для повышения безопасности необходимо объединение усилий индустрии на внедрение современных и стандартизированных технологий вроде OCSP Must-Staple, которые обеспечивают актуальную и надежную проверку статуса сертификатов без ущерба для производительности. Разработчикам Chrome и остальным участникам рынка следует пересмотреть стратегию обращения с отзывами сертификатов, оставив в прошлом модели, которые в своем нынешнем виде представляют скорее декоративное решение, нежели эффективный инструмент защиты. Обеспечение доверия и безопасности в интернете - ключевой вызов современности. Только открытое обсуждение проблем и готовность признавать существующие недостатки способны привести к реальным улучшениям и сделать веб-пространство более защищенным для миллионов пользователей во всем мире. .
