Ocsp stapling что это
Перейти к содержимому

Ocsp stapling что это

  • автор:

dxdt.ru: занимательный интернет-журнал

Ресурсы: техническое описание TLS, LaTeX — в картинки (img)

Техническое: OCSP stapling в Firefox

k11011101

(Продолжаем криптографическую серию заметок.) Оказывается, в Firefox версии 26 включили поддержку OCSP staplig. Что это такое? OCSP (Online Certificate Status Protocol) – это протокол, позволяющий клиенту (браузеру) в режиме онлайн проверить не был ли представленный сервером SSL-сертификат отозван. Напомню, что отзыв сертификата – это специальная процедура, позволяющая исключить из списка доверенных сертификат, срок действия которого ещё не истёк. Это требуется, например, в том случае, если скомпрометирован закрытый ключ, соответствующий сертификату.

Логика OCSP довольно проста: получив сертификат, браузер обращается с запросом, содержащим серийный номер сертификата, по адресу специального ответчика (“респондера”), обычно работающего на серверах удостоверяющего центра (УЦ), и может получить ответ о том, не отозван ли этот сертификат. А может и не получить – дело в том, что ответчики OSCP некоторых УЦ работают не так надёжно, как хотелось бы. У OCSP есть и ещё одна особенность: владельцы ответчика получают информацию о том, какие пользователи ходят на сайты, где установлены соответствующие сертификаты (очевидно, что эту информацию передают браузеры, запрашивающие проверку отзыва сертификата).

OCSP stapling позволяет побороть оба неприятных аспекта, упомянутых в предыдущем абзаце. Ответ OCSP содержит электронную подпись, поэтому браузеру всё равно, по какому каналу этот ответ получен, главное, чтобы там была валидная подпись. Подпись действует некоторое время, соответственно, копию ответа может передавать веб-сервер, в момент установления TLS-соединения. Веб-сервер получает ответ OCSP от удостоверяющего центра, независимо от запросов посетителей веб-сайта. Просто и логично. OCSP имеет особое значение для так называемых сертификатов с расширенной проверкой (сертификаты EV), так что технология, прежде всего, актуальна именно для них, а точнее – для сайтов, их использующих.

Я некоторое время назад наладил демонстрационный сервер под доменом 1d.pw, там поддерживается и OCSP stapling – только сертификат там не EV, а простой. Посмотреть на работу OCSP stapling можно при помощи OpenSSL, вот так:

$ openssl s_client -connect 1d.pw:443 -tlsextdebug -status

В выдаче отыскиваем строки, следующие за “OCSP response”:

OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)

Адрес записки: https://dxdt.ru/2013/12/19/6420/

Похожие записки:

  • Сервис проверки настроек веб-узлов
  • Взлом Twitter и влияние на офлайн
  • Навигация «гражданских беспилотников» в условиях помех
  • Экспериментальный сервер TLS 1.3: обновление
  • Кодирование в рунах
  • Кибератаки, самоуправляемые автомобили и бот в смартфоне
  • Постквантовый мир прикладной криптографии
  • «Двухфакторная» аутентификация и Google Authenticator
  • Скрытые сервисы и прокси
  • TLS для DevOps
  • Автомобили-роботы из «обязательной» сети такси

Введение в многопроцессорную систему OCSP

OCSP — это протокол, используемый для проверки действительности сертификатов, чтобы убедиться, что они не были отменены. OCSP является альтернативой Certificate Revocation Lists (CRLs) Ответы OCSP это всего нескольких сотен байтов, поэтому OCSP особенно полезен, когда у выдающего ЦС имеется относительно большие CRL, а также когда клиент имеет ограниченную память и вычислительную мощность.

OCSP также может предоставлять гораздо более своевременную информацию, чем CRL, о статусе сертификата, поскольку информация обычно выбирается чаще. Кроме того, OCSP может сообщить, действительно ли CA выдал сертификат. Это невозможно с помощью CRL, поскольку CRL содержит только список отозванных серийных номеров, тогда как ответчикам OCSP предоставляется серийный номер для проверки. Таким образом, можно сразу обнаружить использование определенных видов мошеннических сертификатов.

У OCSP есть несколько недостатков.
Во-первых, веб-браузер должен получать сам ответ, что может привести к задержкам в квитировании TLS с сервером и заставить пользователя ждать для отображаемой веб-страницы. Конкуренция среди браузеров заставила в значительной степени игнорировать отказы от ответа OCSP, создавая уязвимость безопасности.
Во-вторых, поскольку каждый клиент, посещающий веб-сайт, запрашивает ответ OCSP для сервера, который они посещают, количество запросов к респондентам будет зависеть от количества пользователей сайтов. Если крупные сайты пронумерованы среди клиентов ЦС, ЦС должен создать значительную инфраструктуру для обработки всех этих запросов.
Наконец, сбой в этой инфраструктуре может заставить клиента сомневаться в том, что сертификат действителен, если ответ недоступен.

Чтобы преодолеть проблемы с задержкой и производительностью, рабочая группа TLS рабочей группы Internet Engineering определила расширение статуса сертификата для протокола TLS, обычно называемое «Сшивание OCSP» Сшивание OCSP использует сервер TLS в качестве прокси для клиента, выбирая Ответ OCSP на сертификат своего сайта и передачу ответа клиентам, которые запрашивают ответ как часть рукопожатия TLS. Поскольку ответ получен непосредственно с сервера, клиенту не требуется запрашивать информацию у эмитента, что приводит к увеличению производительности сайта. Помимо преимуществ клиента и более быстрой загрузки страниц, сглаживание OCSP смягчает некоторые проблемы конфиденциальности, вызванные тем, что клиент сообщает CA, какие сайты посещают пользователь, а также снижает нагрузку на эмитента, уменьшая требования к инфраструктуре.

Сшивание OCSP в настоящее время поддерживается IIS 7+, Apache 2.4+, Nginx 1.7.3+.

Основным недостатком сшивки OCSP является то, что он немного увеличивает размер трафика веб-сайта — от нескольких сотен байтов до двух КБ за полное рукопожатие, в зависимости от размера ответа OCSP. Тем не менее, это увеличение незначительно по сравнению с количеством зашифрованных данных, отправленных по соединению, особенно если сервер настроен хорошо и использует возобновляемые сеансы SSL / TLS, что ограничит количество необходимых протоколов протокола TLS, что сократит затраты, как дорогостоящие операция закрытого ключа не требуется при возобновлении сеанса.

Другим недостатком является то, что основная сшивка OCSP работает только для сертификатов сайта и не проверяет достоверность промежуточных сертификатов ЦС в цепочке сертификатов, что также является требованием для надлежащей проверки сертификата. Это означает, что клиентам по-прежнему приходится отдельно проверять достоверность сертификата ЦС, загружая CRL или запрашивая ответы OCSP, в зависимости от того, что настроено в сертификате. Одной из возможных причин этого ограничения является то, что в то время, когда было определено расширение TLS сертификата, промежуточные сертификаты CA не включали информацию OCSP. Однако время изменилось, и теперь требуется информация OCSP в промежуточных продуктах.

Многократное скрепление OCSP

ЦС теперь выдают сертификаты, по крайней мере, с одним промежуточным ЦС в цепочке (или, по крайней мере, в большинстве случаев), а в базовых требованиях для CA / Browser Forum теперь требуются указатели OCSP в промежуточных сертификатах CA. При необходимой поддержке клиентов и серверов TLS можно было бы использовать скобки OCSP для промежуточных сертификатов ЦС. Проверка этой информации в связи со сшитым ответом OCSP называется «сшивание с несколькими типами».

Множественное сшивание должно быть таким же простым, как определение нового метода для расширения статуса сертификата и включение этого метода в список методов, поддерживаемых клиентом Расширение статуса сертификата в TLS не позволяло клиентам сигнализировать поддержку для двух методов. Это проблематично, потому что клиентам придется поддерживать как старые, так и новые методы сшивания, пока все клиенты не смогут поддерживать многошиточное сшивание. Новое расширение устраняет несколько проблем, позволяя клиентам использовать несколько методов проверки состояния и позволяя серверам пересылать несколько ответов OCSP клиенту.

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

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

Поддержка браузера для обоих OCSP и CRL смешанна: в настоящее время Firefox не загружает CRL из доверенных ЦС автоматически, поэтому пользователи Firefox должны полагаться только на OCSP; Google использует проприетарный механизм для распространения CRL для пользователей Google Chrome, который объединяет CRL CAC в одном обновлении, которое распространяется с использованием его автоматического канала обновления. Многие браузеры по умолчанию применяют «мягкий отказ», оставляя пользователей уязвимыми для подслушивающих устройств, способных блокировать или подделывать трафик OCSP. До тех пор, пока центры сертификации, отвечающие за ответы OCSP, не имеют надежной записи как для производительности, так и для надежности своих ответчиков OCSP, браузерам будет трудно оправдать переход на синхронное поведение «с жестким отказом»

Конфигурация сервера OCSP

  1. При использовании CRL — Certificate Revocation List — браузер загружает список серийных номеров отозванных сертификатов с сервера СА и проверяет не отозван ли текущий сертификат, что увеличивает время SSL-переговоров. Две основные проблемы CSR – это приватность и большая нагрузка на серверы центров сертификации. Чтобы связаться с CA и подтвердить статус сертификата требуется браузер. это нарушает конфиденциальность, поскольку ЦС знает к какому сайту вы обращаетесь и другу инфу (IP, браузер и др.). При большом количестве посетителей сайта CRL-сервер ЦС приходится обрабатывать все запросы посетителей в отдельности.
  2. OCSP — Online Certificate Status Protocol – это протокол, проверяющий, был ли отозван SSL-сертификат. OCSP stapling – это расширение TLS/SSL, целью которого является повышение производительности SSL-переговоров при сохранении конфиденциальности посетителя. Он был создан в качестве альтернативы CRL, с целью уменьшить время SSL-переговоров и уменьшить нагрузку на CRL сервер СА. Используя OCSP, браузер посылает запрос к вашему серверу (а не к серверу CRL центра сертификации) и получает ответ, содержащий состояние достоверности сертификата. Ваш сервер запрашивает не отозван ли сертификат у OCSP сервера CA и кэширует полученный ответ. Этот ответ «сшивается» (staple) с TLS/SSL рукопожатием. В результате серверы ЦС не перегружаются запросами, а браузеры больше не раскрывают деталий третьим лицам (CA).

Тестирование ответа OCSP при помощи OpenSSL

echo QUIT | openssl s_client -connect domain.com:443 -status 2> /dev/null | grep -A 17 ‘OCSP response:’ | grep -B 17 ‘Next Update’

FAQ по OCSP

Что такое OCSP Stapling
OCSP — Online Certificate Status Protocol — это модель расширения стандартного протокола OCSP, посредством которой веб-сервер получает ответ OCSP от ЦС и отправляет ответ OCSP браузеру в процессе рукопожатия SSL. Это может быть более эффективным, поскольку ответ OCSP действителен в течение нескольких часов или дней, а веб-сайт может кэшировать его и отправлять его всем пользователям в течение этого периода времени. Это повышает скорость и надежность OCSP, что устраняет необходимость того, чтобы клиентский браузер инициировал подключение к CA.

Зачем использовать OCSP Stapling
DigiCert рекомендует устанавливать OCSP нашим партнерам и клиентам, которые хотят воспользоваться этой улучшенной моделью OCSP, чтобы улучшить производительность браузера своих конечных пользователей при доступе к веб-сайту. Сшивание OCSP также затрагивает проблему конфиденциальности, поскольку CA больше не получает запросы проверки отзыва непосредственно от клиента (браузера).

Сертификаты DigiCert и OCSP
Инфраструктура DigiCert полностью поддерживает OCSP Stapling, и клиентам не нужен специальный SSL-сертификат, чтобы воспользоваться им. Фактически, им вообще не нужно участие DigiCert. Все, что им нужно сделать, это убедиться, что они используют одну из OCSP сшитых веб-серверных платформ, таких как Apache, Nginx или Windows Server, и что сшивание OCSP было настроено и включено на веб-сервере локально.

Конфигурирование OCSP stapling в Apache >=2.3.3

Существуют две директивы, которые необходимо добавить в конфигурационный файл apache

SSLUseStapling on
SSLStaplingCache «shmcb:/var/run/ocsp(128000)»

SSLUseStapling включает эту функцию, а SSLStaplingCache указывает, где хранить кеш и как большой он должен быть.

Note:Если вы используете Apache для Windows, убедитесь, что путь для SSLStaplingCache относится к пути к файлу Windows, например, «shmcb:C:/xampp/apache/logs/ocsp(128000)»]

Убедитесь, что SSLStaplingCache находится за пределами виртуального хоста или Apache, скорее всего, не запустится. Мы предлагаем поместить всю настройку за пределы раздела Virtual Host для простоты.
Примечание. При включении и / или настройке OCSP Stapling на ваших серверах имейте в виду, что запрос OCSP с вашего сервера на URL-адрес DigiCert OCSP должен быть разрешен. Если ваш сервер находится за брандмауэром. Вам необходимо создать исключение брандмауэра, чтобы сервер для исходящих подключений соответствовал URL-адресу DigiCert OCSP.

Сохраните файл конфигурации и перезапустите Apache, чтобы изменения вступили в силу

Проверка работы OCSP Stapling

Убедитесь, что вы используете самую последнюю версию openssl (0.9.8k или более поздней) для тестирования.

openssl s_client -connect yourdomain.com:443 -tls1 -tlsextdebug -status

В ответ обратите внимание на следующее:

OCSP response:
======================================
OCSP Response Data:
OCSP Response Status: successful (0x0)

Это означает, что сцепление OCSP включено. Если вы получите ответ, как показано ниже, то сшивание OCSP не выполняется:

OCSP response: no response sent

Конфигурация OCSP stapling в Nginx >=1.3.7

  1. В файле конфигурации Nginx необходимо добавить две директивы

ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
ssl_trusted_certificate /etc/ssl/CA.crt

Файл CA.crt в приведенном выше примере должен содержать все соответствующие корневые и промежуточные сертификаты ЦС. Ниже приведен пример конфигурации Nginx для сшивания OCSP.

server <
listen 443 ssl;
server_name serverhostname;
ssl_certificate /etc/ssl/SSL_Cert.crt;
ssl_certificate_key /etc/ssl/cert_key.key;
ssl_trusted_certificate /etc/ssl/CA.crt
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
>

Примечание. При включении и / или настройке OCSP Stapling на ваших серверах имейте в виду, что запрос OCSP с вашего сервера на URL-адрес DigiCert OCSP должен быть разрешен. Если ваш сервер находится за брандмауэром, вам необходимо создать исключение брандмауэра, чтобы ваш сервер мог использовать исходящие подключения к URL-адресу DigiCert OCSP.

Проверка работы OCSP Stapling

Убедитесь, что вы используете самую последнюю версию openssl (0.9.8k или более поздней) для тестирования.

openssl s_client -connect yourdomain.com:443 -tls1 -tlsextdebug -status

Обратите внимание на область ответа OCSP:

OCSP response:
======================================
OCSP Response Data:
OCSP Response Status: successful (0x0)

Это означает, что сшивание OCSP включено. Если вы получите ответ, как показано ниже, то сшивание OCSP не включено:

OCSP response: no response sent

Конфигурирование OCSP stapling в Windows Server

  • Сшивание OCSP поддерживается и включено по умолчанию в Windows Server 2008 или выше .
  • Для Windows Server 2008 или выше не требуются шаги настройки
  • Версия сервера Windows ниже 2008 г. не поддерживает OCSP Stapling

Для сшивки OCSP для работы на вашем сервере Windows все, что вам нужно сделать, это проверить версию сервера, на котором вы работаете, — 2008 или выше. А также требуется разрешение OCSP с вашего сервера на сервер OCSP DigiCert. Если ваш сервер находится за брандмауэром. Вам необходимо создать исключение брандмауэра, чтобы ваш сервер мог отправлять исходящие соединения на URL OCSP DigiCert.

NO russia - мы не осблуживаем резидентов из россии

Copyright © 1997-2023 adgrafics

Оптимизация загрузки страницы: сшивание OCSP

Когда пользователь посещает ваш веб-сайт HTTPS, он должен ответить с рабочим Открытый ключ, и действующий сертификат SSL, связывающий ключ с вашей личностью, будь то лицо, компания или организация. Сертификаты всегда выдаются с предопределенной датой истечения срока действия, которая указана в самом подписанном сертификате, а браузеры всегда проверяют дату истечения срока действия и отклоняют любой истекший сертификат.

Однако в некоторых случаях сертификат должен быть помечен как недействительный (и доверие к этим сертификатам должно быть отозвана) до это истекает. Типичные примеры включают владельца сервера, имеющего доказательства (или просто подозревающие), что их закрытый ключ был скомпрометирован (т. Е. Он был утерян, украден или уничтожен), поскольку третье лицо, владеющее этим закрытым ключом, может, по существу, обойти все элементы управления безопасностью сети браузера.

Как следствие, поставщики браузеров требуется публично доверенный центры сертификации (Центры сертификации) реализовать по крайней мере один метод для отзыва проблемных сертификатов и уведомления браузеров об отклонении этих отозванных сертификатов.

Примеры сообщений об ошибках браузера, вызванных отозванными сертификатами, см. В это руководство. Вы можете проверить статус отзыва сертификата на странице сертификат.revocationcheck.com.

Краткая история (проблем) проверки отзыва

На заре 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.

OCSP Stapling

1. ssl_trusted_certificate /etc/nginx/ssl/example.com.crtt; — это что и как его сгенерировать? 2. example.com.crtt для каждого сайта свой или можно один на весь сервер? 3. без ssl_trusted_certificate ssl_stapling on; ssl_stapling_verify on; бесполезны?

И еще впрос — ssl_session_ticket_key может быть один для всех сайтов сервера?

На сайте с 01.10.2013
21 ноября 2016, 14:36

example.com.crt — это корневой сертификат для проверки валидности сертификата OCSP сервера. Туда обычно вписывают общесистемное хранилище сертификатов, типа /etc/ssl/certs/ca-certificates.crt или /etc/ssl/certs/ca-bundle.trust.crt в зависимости от дистрибутива.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *