Apache: Шифрование SSL/TLS: инструкции

RU EN

Пункт 47. Шифрование SSL/TLS: инструкции

Этот документ предназначен для того, чтобы вы начали работу и кое-что заработали. Вам настоятельно рекомендуется прочитать остальную часть документации по SSL и глубже понять материал, прежде чем переходить к продвинутым методам.

Пример базовой конфигурации

Ваша конфигурация SSL должна содержать как минимум следующие директивы.

 Модули LoadModule ssl_module/mod_ssl.so
Слушай 443
<Виртуальный хост *:443>
 Имя сервера www.example.com
 SSLEngine включен
 SSLCertificateFile "/path/to/www.example.com.cert"
 SSLCertificateKeyFile "/path/to/www.example.com.key"
</ виртуальный хост>

Наборы шифров и обеспечение строгой безопасности

Как я могу создать сервер SSL, который принимает только надежное шифрование?
Как я могу создать сервер SSL, который в целом принимает все типы шифров, но требует надежного шифра для доступа к определенному URL-адресу?

Как я могу создать сервер SSL, который принимает только надежное шифрование?

Следующее включает только самые стойкие шифры:

 SSLCipherSuite HIGH:!aNULL:!MD5

В следующей конфигурации вы указываете предпочтение для определенных шифров, оптимизированных по скорости (которые будут выбраны mod_ssl при условии, что они поддерживаются клиентом):

 SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:!aNULL:!MD5
SSLHonorCipherOrder on

Как я могу создать сервер SSL, который принимает все типы шифров в целом, но требует надежных шифров для доступа к определенному URL-адресу?

Очевидно, что общесерверный SSLCipherSuite , который ограничивает шифры сильными вариантами, здесь не подходит. Однако mod_ssl его можно перенастроить в Location блоках, чтобы получить решение для каждого каталога, и может автоматически принудительно принудительно пересмотреть параметры SSL для соответствия новой конфигурации. Это можно сделать следующим образом:

 # быть либеральным в целом
SSLCipherSuite ВСЕ:!aNULL:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP:+eNULL
<Расположение "/strong/область">
# но https://hostname/strong/area/ и ниже
# требует надежных шифров
SSLCipherSuite HIGH:!aNULL:!MD5
</местоположение>

Сшивание OCSP

Протокол статуса онлайн-сертификата (OCSP) — это механизм для определения того, был ли отозван сертификат сервера, а сшивание OCSP — это особая его форма, в которой сервер, такой как httpd и mod_ssl, поддерживает текущие ответы OCSP для своих сертификатов. и отправляет их клиентам, которые общаются с сервером. Большинство сертификатов содержат адрес ответчика OCSP, который поддерживается выдавшим его центром сертификации, и mod_ssl может взаимодействовать с этим ответчиком для получения подписанного ответа, который можно отправить клиентам, взаимодействующим с сервером.

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

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

После правильной настройки общей поддержки SSL для включения OCSP Stapling обычно требуются лишь очень незначительные изменения в конфигурации httpd — добавление следующих двух директив:

 SSLUseStapling включен
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

Эти директивы размещаются в глобальном масштабе (т. е. вне определения виртуального хоста) везде, где размещаются другие глобальные директивы конфигурации SSL, например, для conf/extra/httpd-ssl.conf обычных сборок httpd с открытым исходным кодом, /etc/apache2/mods-enabled/ssl.conf для httpd, поставляемого в комплекте с Ubuntu или Debian, и т. д.

Путь в SSLStaplingCache директиве (например, logs/ ) должен совпадать с путем в SSLSessionCache директиве. Этот путь относится к ServerRoot .

Эта конкретная SSLStaplingCache директива требует mod_socache_shmcb (из shmcb префикса аргумента директивы). Этот модуль обычно уже включен для SSLSessionCache или от имени какого-либо модуля, отличного от mod_ssl . Если вы включили кеш сеанса SSL с помощью механизма, отличного от mod_socache_shmcb , используйте этот альтернативный механизм SSLStaplingCache и для . Например:

 SSLSessionCache "dbm:logs/ssl_scache"
SSLStaplingCache "dbm:logs/ssl_stapling"

Вы можете использовать программу командной строки openssl, чтобы убедиться, что ответ OCSP отправлен вашим сервером:

 $ openssl s_client -connect www.example.com:443 -status -servername www.example.com
...
Ответ ОССП:
=======================================
Данные ответа OCSP:
 Статус ответа OCSP: успешно (0x0)
 Тип ответа: базовый ответ OCSP
...
 Статус сертификата: Хороший
...

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

Если для сервера используется несколько SSL-сертификатов

Ответы OCSP хранятся в кэше сшивания SSL. Хотя ответы обычно имеют размер от нескольких сотен до нескольких тысяч байт, mod_ssl поддерживает ответы OCSP размером до 10 КБ. При наличии нескольких сертификатов может потребоваться увеличить размер кэша сшивания (32768 байт в приведенном выше примере). Сообщение об ошибке AH01929 будет зарегистрировано в случае ошибки сохранения ответа.

Если сертификат не указывает на ответчик OCSP или если необходимо использовать другой адрес

Обратитесь к SSLStaplingForceURL директиве.

Вы можете подтвердить, что сертификат сервера указывает на ответчик OCSP, используя программу командной строки openssl следующим образом:

 $ openssl x509 -in ./www.example.com.crt -text | grep 'OCSP.*http'
OCSP — URI: http://ocsp.example.com

Если указан URI OCSP и веб-сервер может взаимодействовать с ним напрямую без использования прокси-сервера, настройка не требуется. Обратите внимание, что правила брандмауэра, контролирующие исходящие соединения с веб-сервера, могут потребовать корректировки.

Если URI OCSP не указан, обратитесь в свой центр сертификации, чтобы узнать, доступен ли он; если это так, настройте его SSLStaplingForceURL на виртуальном хосте, использующем сертификат.

Если настроено несколько виртуальных хостов с поддержкой SSL, а сшивание OCSP должно быть отключено для некоторых

Добавьте SSLUseStapling Off к виртуальным хостам, для которых необходимо отключить сшивание OCSP.

Если ответчик OCSP работает медленно или ненадежно

Доступно несколько директив для обработки тайм-аутов и ошибок. Обратитесь к документации по директивам SSLStaplingFakeTryLater , SSLStaplingResponderTimeout , и SSLStaplingReturnResponderErrors .

Если mod_ssl регистрирует ошибку AH02217

 AH02217: ssl_stapling_init_cert: Не удается получить сертификат издателя!

Для поддержки сшивания OCSP при использовании определенного сертификата сервера необходимо настроить цепочку сертификатов для этого сертификата. Если он не был настроен как часть включения SSL, при включении сшивания будет выдаваться ошибка AH02217, и клиентам, использующим сертификат, не будет предоставлен ответ OCSP.

Инструкции по настройке цепочки сертификатов см. в разделе SSLCertificateChainFile и . SSLCertificateFile

Аутентификация клиента и контроль доступа

Как я могу заставить клиентов аутентифицироваться с использованием сертификатов?
Как я могу заставить клиентов аутентифицироваться с использованием сертификатов для определенного URL-адреса, но при этом разрешить произвольным клиентам доступ к остальной части сервера?
Как я могу разрешить только клиентам, имеющим сертификаты, доступ к определенному URL-адресу, но разрешить всем клиентам доступ к остальной части сервера?
Как я могу требовать HTTPS с надежными шифрами и либо базовой аутентификацией, либо клиентскими сертификатами для доступа к части веб-сайта интрасети для клиентов, поступающих из Интернета?

Как я могу заставить клиентов аутентифицироваться с использованием сертификатов?

Когда вы знаете всех своих пользователей (например, как это часто бывает в корпоративной интрасети), вы можете потребовать простой аутентификации по сертификату. Все, что вам нужно сделать, это создать клиентские сертификаты, подписанные вашим собственным сертификатом ЦС ( ca.crt ), а затем проверить клиентов по этому сертификату.

 # требуем клиентский сертификат, который должен быть напрямую
# подписано нашим сертификатом ЦС в ca.crt
SSLVerifyClient требует
SSLVerifyDepth 1
SSLCACertificateFile "conf/ssl.crt/ca.crt"

Как я могу заставить клиентов аутентифицироваться с использованием сертификатов для определенного URL-адреса, но при этом разрешить произвольным клиентам доступ к остальной части сервера?

Чтобы заставить клиентов аутентифицироваться с использованием сертификатов для определенного URL-адреса, вы можете использовать функции реконфигурации для каждого каталога mod_ssl :

 SSLVerifyClient нет
SSLCACertificateFile "conf/ssl.crt/ca.crt"
<Местоположение "/secure/area">
SSLVerifyClient требует
SSLVerifyDepth 1
</местоположение>

Как я могу разрешить только клиентам, имеющим сертификаты, доступ к определенному URL-адресу, но разрешить всем клиентам доступ к остальной части сервера?

Ключом к этому является проверка того, что часть сертификата клиента соответствует вашим ожиданиям. Обычно это означает проверку всего или части отличительного имени (DN) на наличие известной строки. Есть два способа сделать это, используя или mod_auth_basic или SSLRequire .

Этот mod_auth_basic метод обычно требуется, когда сертификаты совершенно произвольны или когда их DN не имеют общих полей (обычно организация и т. д.). В этом случае вы должны создать базу данных паролей, содержащую всех разрешенных клиентов, следующим образом:

 SSLVerifyClient нет
SSLCACertificateFile "conf/ssl.crt/ca.crt"
SSLCACertificatePath "conf/ssl.crt"
<Каталог "/usr/local/apache2/htdocs/secure/area">
 SSLVerifyClient требует
 SSLVerifyDepth 5
 SSLOptions+FakeBasicAuth
 SSLRequireSSL
 AuthName "Аутентификация Snake Oil"
 Основной тип авторизации
 Файл AuthBasicProvider
 AuthUserFile "/usr/local/apache2/conf/httpd.passwd"
 Требовать действительного пользователя
</Каталог>

Пароль, используемый в этом примере, представляет собой зашифрованную строку DES «password». См. SSLOptions документы для получения дополнительной информации.

httpd.passwd

 /C=DE/L=Мюнхен/O=Snake Oil, Ltd./OU=Персонал/CN=Foo:xxj31ZMTZzkVA
/C=US/L=SF/O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA
/C=US/L=LA/O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA

Когда все ваши клиенты являются частью общей иерархии, которая закодирована в DN, вы можете легко сопоставить их с помощью SSLRequire , как показано ниже:

 SSLVerifyClient нет
SSLCACertificateFile "conf/ssl.crt/ca.crt"
SSLCACertificatePath "conf/ssl.crt"
<Каталог "/usr/local/apache2/htdocs/secure/area">
 SSLVerifyClient требует
 SSLVerifyDepth 5
 SSLOptions+FakeBasicAuth
 SSLRequireSSL
 SSLRequire %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
 и %{SSL_CLIENT_S_DN_OU} в {"Персонал", "ЦС", "Разработчик"}
</Каталог>

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

В этих примерах предполагается, что клиенты в интрасети имеют IP-адреса в диапазоне 192.168.1.0/24 и что часть веб-сайта интрасети, к которой вы хотите разрешить доступ в Интернет, — это /usr/local/apache2/htdocs/subarea . Эта конфигурация должна оставаться за пределами вашего виртуального хоста HTTPS, чтобы она применялась как к HTTPS, так и к HTTP.

 SSLCACertificateFile "conf/ssl.crt/company-ca.crt"
<Каталог "/usr/local/apache2/htdocs">
 # За пределами подзоны предоставляется доступ только к Интранету
 Требовать ip 192.168.1.0/24
</Каталог>
<Каталог "/usr/local/apache2/htdocs/subarea">
 # Внутри подзоны разрешен любой доступ в Интранет
 # а из интернета только HTTPS + Strong-Cipher + Password
 # или альтернативный HTTPS + Strong-Cipher + Client-Certificate
 
 # Если используется HTTPS, убедитесь, что используется надежный шифр.
 # Дополнительно разрешить клиентские сертификаты в качестве альтернативы базовой аутентификации.
 SSLVerifyClient необязательно
 SSLVerifyDepth 1
 SSLOptions +FakeBasicAuth +StrictRequire
 SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128
 
 # Заставить клиентов из Интернета использовать HTTPS
 RewriteEngine включен
 RewriteCond "%{REMOTE_ADDR}" "!^192\.168\.1\.[0-9]+$"
 RewriteCond "%{HTTPS}" "!=on"
 Правило перезаписи "." "-" [Ф]
 
 # Разрешить доступ к сети и/или базовую аутентификацию
 Удовлетворить любой
 
 # Контроль доступа к сети
 Требовать ip 192.168.1.0/24
 
 # Базовая HTTP-аутентификация
 Основной тип авторизации
 AuthName "Защищенная область интрасети"
 Файл AuthBasicProvider
 AuthUserFile "conf/protected.passwd"
 Требовать действительного пользователя
</Каталог>

Ведение журнала

mod_ssl может регистрировать чрезвычайно подробную информацию об отладке в журнале ошибок, если для него LogLevel установлены более высокие уровни трассировки. С другой стороны, на очень загруженном сервере уровень info может быть уже слишком большим. Помните, что вы можете настроить LogLevel каждый модуль в соответствии с вашими потребностями.