Перевод статьи: OCSP Stapling on Apache
Автор: Реми ван Элст (Remy van Elst)
При подключении к серверу, клиент должен проверить действительность сертификата сервера по списку отозванных сертификатов - CRL, или по протоколу интерактивного статуса сертификата - OCSP. Проблема CRL заключается в том, что списки могут вырасти до огромных размеров и скачивание может затянуться на вечность.
OCSP намного легче, поскольку за один раз запрашивается одна запись. Но недостаток состоит в том, что при подключении к серверу нужно выполнить OCSP-запрос к стороннему ответчику, что увеличивает задержку и может оказаться причиной сбоев. Фактически, ответчики OCSP управляются удостоверяющим центром, недоступность которого для браузера приведёт к ошибке, если ответ не будет получен своевременно. Это уменьшает безопасность, позволяя атакующему наводнить запросами ответчик OCSP, чтобы отключить проверку.
Решение заключается в том, чтобы разрешить серверу отправлять в процессе рукопожатия TLS запись OCSP из кэша, так чтобы не затрагивать ответчика OCSP. Этот механизм избавляет клиента от необходимости связываться с ответчиком OCSP и называется вшиванием OCSP.
Сервер посылает ответ OCSP из кэша только если клиент его запрашивает, сообщая в CLIENT HELLO о поддержке расширения TLS status_request.
Большинство серверов сохраняют в кэш OCSP-ответы на 48 часов. Через регулярные интервалы времени сервер будет подключаться к ответчику OCSP удостоверяющего центра, чтобы получить свежую запись OCSP. Расположение ответчика OCSP берётся из подписанного сертификата, из поля Authority Information Access - доступ к информации о подлинности.
Это руководство также доступно для nginx.
Вшивание OCSP определено в IETF RFC 6066. "Вшивание" - это популярное слово, используемое для объяснения принципа получения OCSP-ответа от веб-сервера. Веб-сервер помещает в кэш ответ от удостоверяющего центра, выпустившего сертификат. В процессе рукопожатия SSL/TLS ответ клиенту возвращается веб-сервером, который прикладывает OCSP-ответ из кэша в сообщение CertificateStatus со статусом сертификата. Для использования вшивания OCSP клиент должен включить расширение status_request в его приветственном SSL/TSL-сообщении.
Вшивание OCSP имеет несколько дополнительных плюсов:
Обратитесь за дополнительной информацией об OCSP и вшивании OCSP по одной из следующих ссылок:
Для настройки потребуется Apache версии 2.3.3 или выше и OpenSSL версии 0.9.8h или выше. Они не доступны в текущем релизе Ubuntu LTS (12.04), где есть только 2.2.22, а в CentOS 6 есть только 2.2.15. Поищите неофициальный репозиторий в PPA или соберите программы самостоятельно.
Также нужно создать исключение в пакетном фильтре, чтобы разрешить веб-серверу совершать исходящие подключения к вышестоящим серверам OCSP. URI OCSP веб-сайта можно увидеть при помощи следующей команды:
OLDIFS=$IFS; \
IFS=':' certificates=$(openssl s_client -connect google.com:443 -showcerts -tlsextdebug -tls1 2>&1 </dev/null \
| sed -n '/-----BEGIN/,/-----END/ {/-----BEGIN/ s/^/:/; p}'); \
for certificate in ${certificates#:}; do \
echo $certificate | openssl x509 -noout -ocsp_uri; \
done; \
IFS=$OLDIFS
Вот результаты для google.com:
http://clients1.google.com/ocsp http://gtglobal-ocsp.geotrust.com
Замените google.com на ваш домен. Также отметим, что требуются GNU-версии sed и bash. Команда не работает в OS X и в BSD.
Добавим следующие настройки в секцию VirtualHost:
SSLUseStapling on SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
Далее приведём объяснение этих двух строк:
Вшивание OCSP освобождает клиента от необходимости обращаться к OCSP-ответчику самостоятельно, но необходимо отметить, что в соответствии со спецификацией RFC 6066, ответ сервера в поле CertificateStatus может содержать OCSP-ответ только для одного сертификата. Если же в сертификате сервера имеется цепочка сертификатов промежуточных удостоверяющих центров (что в наши дни встречается повсеместно), текущая реализация вшивания лишь частично достигает цели "снизить задержку и использование ресурсов". Обратитесь также к RFC 6961, где описывается TLS Multiple Certificate Status Extension - расширение TLS для проверки статуса нескольких сертификатов.
Настраивает кэш для хранения OCSP-ответов, которые будут использоваться в процедуре рукопожатия TLS, если включена директива SSLUseStapling. Необходима явная настройка кэша для вшивания OCSP. Поддерживаются те же типы хранилища, что и в SSLSessionCache, за исключением none и nonenotnull.
Глава о shmbc:
Создаёт высокопроизводительный циклический буфер (размером примерно size байт) в разделяемом сегменте оперативной памяти (создаётся через путь к файлу данных - /path/to/datafile) для синхронизации кэшей локальной памяти OpenSSL процессов сервера. Рекомендуется использовать его для кэширования сеансов. При использовании убедитесь, что загружен модуль mod_socache_shmcb.
Также можно указать несколько дополнительных опций. Например, время, через которое OCSP-ответ будет считаться устаревшим:
SSLStaplingResponseMaxAge 900
Эта директива разрешает держать ответ в кэше не более 15 минут (900 секунд).
Если сервер Apache находится за HTTP-прокси, может понадобиться выполнять OCSP-запросы через прокси. Для этого можно воспользоваться директивой SSLStaplingForceURL. Она заменяет URL из сертификата:
SSLStaplingForceURL http://internal-proxy.example.org
Перезапустите Apache, чтобы загрузить новую конфигурацию:
service apache2 restart
Теперь всё должно заработать. Давайте проверим.
Откройте терминал и воспользуйтесь следующей командой OpenSSL для подключения к вашему веб-сайту:
openssl s_client -connect example.org:443 -tls1 -tlsextdebug -status
В ответе обратим внимание на следующее:
OCSP response: # Ответ OCSP:
======================================
OCSP Response Data: # Данные ответа OCSP
OCSP Response Status: successful (0x0) # Статус ответа OCSP: успешно (0x0)
Response Type: Basic OCSP Response # Тип ответа: Базовый ответ OCSP
Version: 1 (0x0) # Версия: 1 (0x0)
Responder Id: 99E4405F6B145E3E05D9DDD36354FC62B8F700AC # Идентификатор ответчика
Produced At: Feb 3 04:25:39 2014 GMT # Сформирован: 3 февраля 2014 года в 04:25:39 по Гринвичу
Responses: # Ответы:
Certificate ID: # Идентификатор сертификата:
Hash Algorithm: sha1 # Алгоритм хэширования: sha1
Issuer Name Hash: 0226EE2F5FA2810834DACC3380E680ACE827F604 # Хэш имени эмитента
Issuer Key Hash: 99E4405F6B145E3E05D9DDD36354FC62B8F700AC # Хэш ключа эмитента
Serial Number: 1003 # Серийный номер
Cert Status: good # Статус сертификата: хороший
This Update: Feb 3 04:25:39 2014 GMT # Это обновление: 3 февраля 2014 года в 04:25:39 по Гринвичу
Next Update: Feb 7 04:25:39 2014 GMT # Следующее обновление: 7 февраля 2014 года в 04:25:39 по Гринвичу
Этот ответ означает, что всё работает. Если получен ответ, подобный следующему, то это значит что вшивание OCSP не работает:
OCSP response: no response sent # OCSP-ответ: ответ не получен
Вы также можете воспользоваться проверкой SSL Labs, чтобы проверить, что вшивание OCSP работает.