Реми ван Элст. Вшивание OCSP в Apache, 2014

Перевод статьи: 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.

1. Что такое "вшивание OCSP"?

Вшивание OCSP определено в IETF RFC 6066. "Вшивание" - это популярное слово, используемое для объяснения принципа получения OCSP-ответа от веб-сервера. Веб-сервер помещает в кэш ответ от удостоверяющего центра, выпустившего сертификат. В процессе рукопожатия SSL/TLS ответ клиенту возвращается веб-сервером, который прикладывает OCSP-ответ из кэша в сообщение CertificateStatus со статусом сертификата. Для использования вшивания OCSP клиент должен включить расширение status_request в его приветственном SSL/TSL-сообщении.

Вшивание OCSP имеет несколько дополнительных плюсов:

Обратитесь за дополнительной информацией об OCSP и вшивании OCSP по одной из следующих ссылок:

2. Требования

Для настройки потребуется 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.

3. Конфигурация Apache

Добавим следующие настройки в секцию VirtualHost:

SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"

Далее приведём объяснение этих двух строк:

3.1. SSLUseStapling

Вшивание OCSP освобождает клиента от необходимости обращаться к OCSP-ответчику самостоятельно, но необходимо отметить, что в соответствии со спецификацией RFC 6066, ответ сервера в поле CertificateStatus может содержать OCSP-ответ только для одного сертификата. Если же в сертификате сервера имеется цепочка сертификатов промежуточных удостоверяющих центров (что в наши дни встречается повсеместно), текущая реализация вшивания лишь частично достигает цели "снизить задержку и использование ресурсов". Обратитесь также к RFC 6961, где описывается TLS Multiple Certificate Status Extension - расширение TLS для проверки статуса нескольких сертификатов.

3.2. SSLStaplingCache

Настраивает кэш для хранения 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

Теперь всё должно заработать. Давайте проверим.

4. Тестирование

Откройте терминал и воспользуйтесь следующей командой 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 работает.

5. Источники

Написать автору перевода