Введение
Когда пользователь посещает ваш веб-сайт HTTPS, он должен ответить с рабочим Открытый ключ, и действующий сертификат SSL, связывающий ключ с вашей личностью, будь то лицо, компания или организация. Сертификаты всегда выдаются с предопределенной датой истечения срока действия, которая указана в самом подписанном сертификате, а браузеры всегда проверяют дату истечения срока действия и отклоняют любой истекший сертификат.
Однако в некоторых случаях сертификат должен быть помечен как недействительный (и доверие к этим сертификатам должно быть отозвана) до это истекает. Типичные примеры включают владельца сервера, имеющего доказательства (или просто подозревающие), что их закрытый ключ был скомпрометирован (т. Е. Он был утерян, украден или уничтожен), поскольку третье лицо, владеющее этим закрытым ключом, может, по существу, обойти все элементы управления безопасностью сети браузера.
Как следствие, поставщики браузеров требуется публично доверенный центры сертификации (Центры сертификации) реализовать по крайней мере один метод для отзыва проблемных сертификатов и уведомления браузеров об отклонении этих отозванных сертификатов.
Краткая история (проблем) проверки отзыва
На заре SSL ЦС использовали метод публикации своего статуса отзыва сертификата в общедоступных документах, называемых списки отзыва сертификатов (CRL). CRL - это просто список всех сертификатов, которые CA когда-либо аннулировал до истечения срока действия. Центры сертификации периодически публикуют последнюю версию своих списков отзыва сертификатов, с которыми браузеры должны были консультироваться до каждое соединение HTTPS.
Естественно, как HTTPS (и SSL /TLS) количество принятых CRL увеличилось с годами, так же как и размер публикуемых CRL. Требование загрузки и анализа большого списка отзыва сертификатов перед каждым подключением приводило к постоянно увеличивающимся накладным расходам сети. Вскоре стало очевидно, что метод CRL плохо масштабируется.
Чтобы смягчить эти проблемы масштабирования, браузеры и центры сертификации разработали и внедрили Протокол статуса сертификата онлайн (ОССП). Общественно доверенные центры сертификации, такие как SSL.com, теперь поддерживайте простые HTTP-серверы Ответчики OCSP, Браузеры теперь могут обращаться к респонденту, чтобы запросить статус отзыва одного сертификата, выданного ЦС, вместо того, чтобы получать и обрабатывать весь CRL.
Респонденты OCSP подписывают свои ответы закрытым ключом подписи ЦС, а браузеры могут проверить, что полученный ими статус отзыва действительно был сгенерирован настоящим ЦС.
К сожалению, несмотря на то, что OCSP на первый взгляд казался эффективным решением, новый протокол показал некоторые практические проблемы с производительностью, безопасностью и конфиденциальностью.
Проблемы с производительностью
Связь с респондентом для каждого сертификата, с которым сталкивается браузер, означает, что браузеры должны выполнить дополнительный HTTP-запрос для каждого нового HTTPS-соединения. Эта нагрузка на сеть была заметна для пользователей, особенно на страницах, содержащих сторонний контент, хранящийся на удаленных серверах распространения контента (на каждом из которых может быть один или несколько сертификатов).
Чувствительность является важным принципом хорошего дизайна пользовательского интерфейса. Длительные задержки могут стать основной причиной разочарования пользователей и могут заставить пользователей поверить, что ваш веб-сайт не работает или что их жест ввода был проигнорирован.
Более того, многие исследования В прошлом высокая скорость загрузки страниц и скорость реагирования были связаны с улучшением SEO и повышением коэффициента конверсии. На самом деле Amazon подсчитал, что задержка всего в одну секунду может стоить им $1.6 миллиард ежегодно.
(Для получения более подробной информации о том, как скорость загрузки страницы влияет на ваш веб-сайт и предлагаемые оптимизации, пожалуйста, посмотрите на наш гайд описание того, как удаление смешанного контента с вашего веб-сайта повысит его эффективность.)
Вопросы безопасности
Есть также важные проблемы безопасности с OCSP. Тот факт, что большинство практических реализаций OCSP были недостаточно надежными (либо из-за задержки в сети, либо из-за ошибок конфигурации или приложений), побудил браузеры и другое клиентское программное обеспечение выполнить проверку OCSP в мягкий обанкротиться Режим.
Это означает, что если сервер OCSP не может быть достигнут или время ожидания при предоставлении ответа, браузеры будут считать сертификат действительным и все равно продолжайте подключение HTTPS.
Причиной этого является то, что, поскольку сервер OCSP может потенциально обслуживать миллионы веб-сайтов, и сервер OCSP может в любой момент выйти из строя, разрыв соединения при каждом сбое OCSP нарушит возможности просмотра миллионов пользователей. Даже если сервер OCSP работает, но для ответа требуется много времени, это усугубляет задержку и разочарование пользователя.
Человек в середине (MITM) Злоумышленники, как известно, используют это поведение, блокируя Найти подключения к респондентам OCSP, что фактически означает, что они могут использовать украденный сертификат и пару ключей для вредоносного сайта независимо от статуса отзыва сертификата.
Вопросы конфиденциальности
Наконец, поскольку сертификат связан с ключом и доменным именем, и браузеры запрашивают статус отзыва перед каждым новым HTTPS-соединением, это означает, что браузеры передают значительную часть веб-истории своих пользователей респондентам OCSP.
Конечно, общедоступные доверенные центры сертификации не являются злонамеренными организациями, пытающимися поставить под угрозу конфиденциальность пользователей. (Авторитетные центры сертификации всегда активно пытаются для защиты безопасность и конфиденциальность их пользователей.) Однако в случае компрометации ответчика OCSP CA обмен данными с этим ненадежным сервером может привести к раскрытию конфиденциальной и частной информации.
OCSP сшивание на помощь
Чтобы смягчить эти проблемы, браузеры и центры сертификации разработали новый метод определения статуса сертификата, который называется OCSP Stapling, Сшивание OCSP позволяет веб-серверам (вместо браузеров) получать подписанные ответы OCSP для своих сертификатов, которые можно кэшировать на срок до 7 дней.
Серверы включают (или штапель) кэшированный ответ OCSP в своих ответах HTTPS вместе с самим сертификатом SSL. Таким образом, браузеры могут проверить подпись центров сертификации в ответе OCSP и быть уверенными в том, что сертификат не был отозван, до того, как будет установлено безопасное соединение, и без необходимости выполнять дорогостоящий дополнительный запрос к самому серверу OCSP.
Сшивание OCSP - это простое, но очень эффективное решение проблем, упомянутых выше. Серверы могут извлекать кэшированные ответы OCSP в свое время, что устраняет накладные расходы на производительность, налагаемые CRL и OCSP, а также сопутствующие проблемы конфиденциальности.
Однако сшивание OCSP само по себе не решает полностью проблему безопасности OCSP с мягким отказом. Поскольку сшивание реализовано на сервере, браузеры не могут знать, поддерживает ли сервер сшивание или нет.
Как следствие, злоумышленники MITM с украденным (но отозванным) сертификатом могут выполнить атаку перехода на более раннюю версию, обслуживая сертификат без сшивания OCSP. Браузер жертвы не может подтвердить, действительно ли сервер поддерживает сшивание, и приступить к опросу респондента OCSP, как обычно.
Затем злоумышленники MITM могут просто заблокировать этот запрос OCSP и заставить браузеры принять сертификат как действительный.
OCSP необходимо сшивать
Эта атака побудила центры сертификации и поставщиков браузеров ввести расширение для сертификатов SSL, определенное в RFC 7633, обычно называемый ОССП Must-степлера (хотя в самом RFC это имя не упоминается, что может вызвать некоторую путаницу.) Это просто требует сшивания сертификата OCSP. Если браузер обнаруживает сертификат с этим расширением, который используется без OCSP Stapling, он будет отклонен. OCSP Must-Staple смягчает вышеупомянутую атаку перехода на более раннюю версию, а также уменьшает ненужный трафик для ответчиков OCSP CA, что также может помочь улучшить общую производительность OCSP.
Если вы хотите включить расширение OCSP Must-Staple в свои сертификаты, обратитесь к одному из наших агентов поддержки по адресу support@ssl.com Больше подробностей.
Включите сшивание OCSP на вашем сервере
Чтобы избавить вас от необходимости искать это, в следующих разделах содержатся инструкции о том, как включить сшивание OCSP в вашем апаш и Nginx среды:
апаш
Чтобы включить сшивание OCSP в вашем апаш server, добавьте следующие строки в файл конфигурации вашего сервера.
# OCSP Stapling, только в httpd 2.3.3 и более поздних версиях SSLUseStapling на SSLStaplingResponderTimeout 5 SSLStaplingReturnResponderErrors off SSLStaplingCache shmcb: / var / run / ocsp (128000)
Nginx
Чтобы включить сшивание OCSP в вашем Nginx сервер, добавьте следующий текст в файл конфигурации вашего сервера.
# OCSP Stapling --- # извлечь записи OCSP из URL в ssl_certificate и кэшировать их при ssl_stapling; ssl_stapling_verify on;
Заключение
Сеть представляет собой сложную сеть взаимозависимых компонентов, все (обычно) работающие в гармонии, чтобы обеспечить бесперебойную работу в Интернете. Однако постоянно растущая сложность этой системы создает расширяющуюся поверхность атаки и позволяет разрабатывать и выполнять новые сетевые атаки.
Огромное количество компонентов естественным образом увеличивает задержку и вызывает задержки, что означает, что предприятиям необходимо искать способы повышения безопасности, не влияя на пользовательский опыт. Включение сшивания OCSP даст вам редкую возможность улучшить безопасность и производительность для вашего сайта в то же время.
Как всегда, мы будем рады ответить на ваши вопросы, касающиеся сшивания OCSP или других вопросов, просто отправьте нам письмо по адресу support@ssl.com.
