Шифрование SSL/TLS: Руководство
Данный документ предназначен для начала работы и решения некоторых задач. Сильно рекомендуется прочитать остальную документацию по SSL и глубже изучить материал, прежде чем переходить к продвинутым техникам.
Пример базовой конфигурации
Ваша конфигурация SSL должна, как минимум, содержать следующие директивы.
LoadModule ssl_module modules/mod_ssl.so
Listen 443
<VirtualHost *:443>
ServerName www.example.com
SSLEngine on
SSLCertificateFile "/path/to/www.example.com.cert"
SSLCertificateKeyFile "/path/to/www.example.com.key"
</VirtualHost> Наборы шифров и обеспечение надёжной защиты
- Как создать сервер 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 для соответствия новой конфигурации. Это можно сделать следующим образом:
# be liberal in general SSLCipherSuite ALL:!aNULL:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP:+eNULL <Location "/strong/area"> # but https://hostname/strong/area/ and below # requires strong ciphers SSLCipherSuite HIGH:!aNULL:!MD5 </Location>
OCSP-подпись
Протокол OCSP (Online Certificate Status Protocol) — это механизм определения того, был ли сертификат сервера отозван, а OCSP-подпись — специальная форма этого механизма, в которой сервер, такой как httpd и mod_ssl, сохраняет текущие ответы OCSP для своих сертификатов и отправляет их клиентам, которые взаимодействуют с сервером. Большинство сертификатов содержат адрес ответчика OCSP, поддерживаемого сертифицирующим центром, и mod_ssl может взаимодействовать с этим ответчиком, чтобы получить подписанный ответ, который может быть отправлен клиентам, взаимодействующим с сервером.
Поскольку клиент может получить состояние отзыва сертификата от сервера, без необходимости дополнительного подключения от клиента к сертифицирующему центру, OCSP-подпись является предпочтительным способом получения статуса отзыва. Другими преимуществами исключения взаимодействия между клиентами и центром сертификации являются то, что история посещений клиента не раскрывается сертифицирующему центру, и получение статуса более надёжно, так как не зависит от потенциально сильно загруженных серверов сертифицирующего центра.
Поскольку ответ, полученный сервером, может быть повторно использован для всех клиентов, использующих тот же сертификат в течение времени действия ответа, нагрузка на сервер минимальна.
После правильной настройки общей поддержки SSL, включение OCSP-подписи обычно требует только незначительных изменений в конфигурации httpd — добавления этих двух директив:
SSLUseStapling On 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 response:
======================================
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
...
Cert Status: Good
... В следующих разделах рассмотрены наиболее распространённые ситуации, которые требуют дополнительных изменений в конфигурации. Смотрите также руководство по mod_ssl.
Если для сервера используется несколько сертификатов
Ответы OCSP хранятся в кэше OCSP-подписи. Хотя ответы обычно имеют размер от нескольких сотен до нескольких тысяч байт, 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: Can't retrieve issuer certificate!
Для поддержки OCSP-подписи при использовании определенного сертификата сервера необходимо настроить цепочку сертификатов для этого сертификата. Если она не была настроена при включении SSL, ошибка AH02217 будет выведена при включении подписи, и для клиентов, использующих данный сертификат, ответ OCSP не будет предоставлен.
Обратитесь к документации SSLCertificateChainFile и SSLCertificateFile за инструкциями по настройке цепочки сертификатов.
Аутентификация клиента и контроль доступа
- Как принудить клиентов к аутентификации с помощью сертификатов?
- Как принудить клиентов к аутентификации с помощью сертификатов для определённого URL, но разрешить произвольным клиентам доступ к остальной части сервера?
- Как разрешить доступ к определённому URL только клиентам с сертификатами, но разрешить доступ всем клиентам к остальной части сервера?
- Как потребовать HTTPS с сильными шифрами и либо базовую аутентификацию, либо сертификаты клиентов для доступа к части веб-сайта интрасети для клиентов из интернета? Я всё ещё хочу разрешить доступ по простому HTTP для клиентов в интрасети.
Как принудить клиентов к аутентификации с помощью сертификатов?
Когда вы знаете всех своих пользователей (например, как часто бывает в корпоративной интрасети), вы можете потребовать аутентификацию с помощью сертификатов. Всё, что вам нужно сделать, это создать сертификаты клиентов, подписанные вашим собственным сертификатом CA (ca.crt), и затем проверить клиентов по этому сертификату.
# require a client certificate which has to be directly # signed by our CA certificate in ca.crt SSLVerifyClient require SSLVerifyDepth 1 SSLCACertificateFile "conf/ssl.crt/ca.crt"
Как принудить клиентов к аутентификации с помощью сертификатов для определённого URL, но разрешить произвольным клиентам доступ к остальной части сервера?
Чтобы принудить клиентов к аутентификации с помощью сертификатов для определённого URL, вы можете использовать возможности переконфигурации по каталогам в mod_ssl:
SSLVerifyClient none SSLCACertificateFile "conf/ssl.crt/ca.crt" <Location "/secure/area"> SSLVerifyClient require SSLVerifyDepth 1 </Location>
Как разрешить доступ к определённому URL только клиентам с сертификатами, но разрешить доступ всем клиентам к остальной части сервера?
Ключ к этому — проверка соответствия части сертификата клиента тому, что вы ожидаете. Обычно это означает проверку всего или части имени Distinguished Name (DN), чтобы увидеть, содержит ли оно какую-то известную строку. Существует два способа сделать это, используя либо mod_auth_basic или SSLRequire.
Метод mod_auth_basic обычно необходим, когда сертификаты совершенно произвольные или когда их имена DN не имеют общих полей (обычно организация и т. д.). В этом случае вам следует создать базу данных паролей, содержащую *всех* разрешённых клиентов, следующим образом:
SSLVerifyClient none
SSLCACertificateFile "conf/ssl.crt/ca.crt"
SSLCACertificatePath "conf/ssl.crt"
<Directory "/usr/local/apache2/htdocs/secure/area">
SSLVerifyClient require
SSLVerifyDepth 5
SSLOptions +FakeBasicAuth
SSLRequireSSL
AuthName "Snake Oil Authentication"
AuthType Basic
AuthBasicProvider file
AuthUserFile "/usr/local/apache2/conf/httpd.passwd"
Require valid-user
</Directory> Пароль, используемый в этом примере, — это строка "password", зашифрованная с помощью DES. Более подробную информацию можно найти в документации SSLOptions.
httpd.passwd
/C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA /C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA /C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA
Когда ваши клиенты входят в общую иерархию, которая закодирована в DN, вы можете сопоставить их более легко с помощью SSLRequire, как показано ниже:
SSLVerifyClient none
SSLCACertificateFile "conf/ssl.crt/ca.crt"
SSLCACertificatePath "conf/ssl.crt"
<Directory "/usr/local/apache2/htdocs/secure/area">
SSLVerifyClient require
SSLVerifyDepth 5
SSLOptions +FakeBasicAuth
SSLRequireSSL
SSLRequire %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}
</Directory> Как потребовать HTTPS с сильными шифрами и либо базовую аутентификацию, либо сертификаты клиентов для доступа к части веб-сайта интрасети для клиентов из интернета? Я всё ещё хочу разрешить доступ по простому HTTP для клиентов в интрасети.
Эти примеры предполагают, что клиенты в интрасети имеют IP-адреса в диапазоне 192.168.1.0/24 и что часть веб-сайта интрасети, для которой вы хотите разрешить доступ из интернета, это /usr/local/apache2/htdocs/subarea. Данная конфигурация должна оставаться вне вашего виртуального хоста HTTPS, чтобы она применялась как к HTTPS, так и к HTTP.
SSLCACertificateFile "conf/ssl.crt/company-ca.crt"
<Directory "/usr/local/apache2/htdocs">
# Outside the subarea only Intranet access is granted
Require ip 192.168.1.0/24
</Directory>
<Directory "/usr/local/apache2/htdocs/subarea">
# Inside the subarea any Intranet access is allowed
# but from the Internet only HTTPS + Strong-Cipher + Password
# or the alternative HTTPS + Strong-Cipher + Client-Certificate
# If HTTPS is used, make sure a strong cipher is used.
# Additionally allow client certs as alternative to basic auth.
SSLVerifyClient optional
SSLVerifyDepth 1
SSLOptions +FakeBasicAuth +StrictRequire
SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128
# Force clients from the Internet to use HTTPS
RewriteEngine on
RewriteCond "%{REMOTE_ADDR}" "!^192\.168\.1\.[0-9]+$"
RewriteCond "%{HTTPS}" "!=on"
RewriteRule "." "-" [F]
# Allow Network Access and/or Basic Auth
Satisfy any
# Network Access Control
Require ip 192.168.1.0/24
# HTTP Basic Authentication
AuthType basic
AuthName "Protected Intranet Area"
AuthBasicProvider file
AuthUserFile "conf/protected.passwd"
Require valid-user
</Directory> Ведение журнала
mod_ssl может записывать чрезвычайно подробную отладочную информацию в журнал ошибок, когда его LogLevel устанавливается на более высокие уровни отслеживания. С другой стороны, на очень загруженном сервере уровень info уже может быть слишком высоким. Помните, что вы можете настроить LogLevel по модулям для соответствия вашим потребностям.
© 2018 The Apache Software Foundation
Licensed under the Apache License, Version 2.0.
https://httpd.apache.org/docs/2.4/en/ssl/ssl_howto.html
