SSL/TLS Сильное шифрование: Часто задаваемые вопросы

Мудрый человек не даёт правильные ответы, он задаёт правильные вопросы.

-- Клод Леви-Стросс

Установка

• Почему при запуске Apache возникают ошибки разрешения доступа, связанные с SSLMutex?
• Почему mod_ssl завершается с ошибкой "Не удалось сгенерировать временный 512-битный закрытый ключ RSA" при запуске Apache?

Почему при запуске Apache возникают ошибки разрешения доступа, связанные с SSLMutex?

Ошибки, такие как ``mod_ssl: Child could not open SSLMutex lockfile /opt/apache/logs/ssl_mutex.18332 (System error follows) [...] System: Permission denied (errno: 13)'' обычно вызваны чрезмерно жёсткими правами доступа к каталогам родителей. Убедитесь, что все родительские каталоги (здесь /opt, /opt/apache и /opt/apache/logs) имеют установленный бит x для, как минимум, UID, под которым работают дочерние процессы Apache (см. директиву User).

Почему mod_ssl завершается с ошибкой "Не удалось сгенерировать временный 512-битный закрытый ключ RSA" при запуске Apache?

Криптографическое программное обеспечение нуждается в источнике непредсказуемых данных для корректной работы. Многие открытые операционные системы предоставляют "устройство генерации случайных чисел" для этой цели (обычно называется /dev/random). В других системах приложения должны вручную инициализировать генератор псевдослучайных чисел OpenSSL (PRNG) соответствующими данными перед генерацией ключей или выполнением шифрования с открытым ключом. Начиная с версии 0.9.5, функции OpenSSL, которые требуют случайности, сообщают об ошибке, если PRNG не был инициализирован, по крайней мере, 128 битами случайности.

Для предотвращения этой ошибки, mod_ssl должен предоставить достаточно энтропии PRNG, чтобы он работал корректно. Это можно сделать с помощью директивы SSLRandomSeed.

Настройка

• Можно ли предоставить HTTP и HTTPS с одного сервера?
• Какой порт использует HTTPS?
• Как вручную использовать HTTPS для тестирования?
• Почему соединение зависает при подключении к моему серверу Apache с поддержкой SSL?
• Почему я получаю ошибки «Соединение отклонено» при попытке доступа к моему новому серверу Apache+mod_ssl через HTTPS?
• Почему переменные SSL_XXX недоступны для моих скриптов CGI и SSI?
• Как переключаться между HTTP и HTTPS в относительных гиперссылках?

Можно ли предоставить HTTP и HTTPS с одного сервера?

Да. HTTP и HTTPS используют разные порты сервера (HTTP привязан к порту 80, HTTPS к порту 443), поэтому прямой конфликт между ними отсутствует. Вы можете запустить два отдельных экземпляра сервера, привязанных к этим портам, или использовать элегантную функцию виртуального хостинга Apache для создания двух виртуальных серверов, оба обслуживаемых одним экземпляром Apache — один отвечает по HTTP на запросы на порте 80, а другой — по HTTPS на запросы на порте 443.

Какой порт использует HTTPS?

HTTPS можно запускать на любом порту, но стандарты указывают на порт 443, где любой совместимый с HTTPS браузер будет искать по умолчанию. Вы можете заставить свой браузер искать на другом порту, указав его в URL. Например, если ваш сервер настроен на предоставление страниц по HTTPS на порте 8080, вы можете получить доступ к ним по адресу https://example.com:8080/

Как вручную использовать HTTPS для тестирования?

Хотя для простого тестирования Apache через HTTP обычно используется

$ telnet localhost 80
GET / HTTP/1.0

для HTTPS из-за протокола SSL между TCP и HTTP это не так просто. Однако с помощью команды s_client OpenSSL вы можете выполнить аналогичную проверку через HTTPS:

$ openssl s_client -connect localhost:443 -state -debug
GET / HTTP/1.0

Перед фактическим ответом HTTP вы получите подробную информацию о рукопожатии SSL. Для более общего командно-строчного клиента, который напрямую понимает как HTTP, так и HTTPS, может выполнять операции GET и POST, может использовать прокси, поддерживает диапазоны байтов и т.д., следует взглянуть на замечательный инструмент cURL. С его помощью можно проверить, что Apache правильно отвечает на запросы по HTTP и HTTPS следующим образом:

$ curl http://localhost/
$ curl https://localhost/

Почему соединение зависает при подключении к моему серверу Apache с поддержкой SSL?

Это может произойти, когда вы пытаетесь подключиться к серверу HTTPS (или виртуальному серверу) через HTTP (например, используя http://example.com/ вместо https://example.com). Это также может произойти при попытке подключиться по HTTPS к серверу HTTP (например, используя https://example.com/ на сервере, который не поддерживает HTTPS или который поддерживает его на нестандартном порту). Убедитесь, что вы подключаетесь к (виртуальному) серверу, который поддерживает SSL.

Почему я получаю сообщения «Соединение отклонено» при попытке доступа к моему новому серверу Apache+mod_ssl через HTTPS?

Эта ошибка может быть вызвана неправильной конфигурацией. Пожалуйста, убедитесь, что ваши директивы Listen соответствуют вашим директивам <VirtualHost>. Если ничего не помогает, начните заново, используя конфигурацию по умолчанию, предоставленную mod_ssl.

Почему переменные SSL_XXX недоступны для моих скриптов CGI и SSI?

Пожалуйста, убедитесь, что «SSLOptions +StdEnvVars» включен для контекста ваших запросов CGI/SSI.

Как переключаться между HTTP и HTTPS в относительных гиперссылках?

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

RewriteEngine on
RewriteRule   "^/(.*)_SSL$"   "https://%{SERVER_NAME}/$1" [R,L]
RewriteRule   "^/(.*)_NOSSL$" "http://%{SERVER_NAME}/$1"  [R,L]

Этот набор правил переписывания позволяет использовать гиперссылки вида <a href="document.html_SSL">, чтобы переключиться на HTTPS в относительной ссылке. (Замените SSL на NOSSL, чтобы переключиться на HTTP.)

Сертификаты

• Что такое закрытые ключи RSA, запросы на сертификат (CSR) и сертификаты?
• Есть ли разница при запуске между Apache без поддержки SSL и с её поддержкой?
• Как создать самозаверяющий SSL-сертификат для тестирования?
• Как создать реальный SSL-сертификат?
• Как создать и использовать свой собственный центр сертификации (CA)?
• Как изменить фразу-пароль для файла с моим закрытым ключом?
• Как избавиться от диалогового окна с запросом на фразу-пароль во время запуска Apache?
• Как проверить, соответствует ли закрытый ключ своему сертификату?
• Как преобразовать сертификат из формата PEM в DER?
• Почему браузеры сообщают о том, что не могут проверить сертификат моего сервера?

Что такое закрытые ключи RSA, запросы на сертификат (CSR) и сертификаты?

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

Запрос сертификата (CSR) — это цифровой файл, который содержит ваш открытый ключ и ваше имя. Вы отправляете CSR в центр сертификации (CA), который преобразует его в реальный сертификат, подписав его.

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

См. главу Введение для общего описания протокола SSL.

Есть ли разница при запуске между Apache без поддержки SSL и с её поддержкой?

Да. В общем случае запуск Apache с mod_ssl встроенным, аналогичен запуску Apache без него. Однако если у вас есть фраза-пароль для файла с закрытым SSL-ключом, появится диалоговое окно, которое попросит вас ввести фразу-пароль.

Необходимость вручную ввода фразы-пароля при запуске сервера может быть проблематичной — например, при запуске сервера из системных сценариев загрузки. В этом случае вы можете выполнить шаги ниже, чтобы удалить фразу-пароль из вашего закрытого ключа. Имейте в виду, что это создаёт дополнительные риски безопасности — действуйте осторожно!

Как создать самозаверяющий SSL-сертификат для тестирования?

1. Убедитесь, что OpenSSL установлен и находится в вашей PATH.
   
   
2. Выполните следующую команду, чтобы создать файлы server.key и server.crt:
   $ openssl req -new -x509 -nodes -out server.crt -keyout server.key
   Их можно использовать следующим образом в вашем файле httpd.conf:

   SSLCertificateFile    "/path/to/this/server.crt"
   SSLCertificateKeyFile "/path/to/this/server.key"

3. Важно понимать, что этот server.key не имеет фразы-пароля. Чтобы добавить фразу-пароль к ключу, выполните следующую команду и введите и подтвердите фразу-пароль, как запрошено.
   

   $ openssl rsa -des3 -in server.key -out server.key.new
$ mv server.key.new server.key
   

   Пожалуйста, сохраните копию файла server.key и введённого пароля в безопасном месте.

Как создать реальный SSL-сертификат?

Вот пошаговое описание:

1. Убедитесь, что OpenSSL установлен и находится в вашей PATH.
   
   
2. Создайте закрытый ключ RSA для вашего сервера Apache (будет зашифрован Triple-DES и отформатирован в PEM):
   
   $ openssl genrsa -des3 -out server.key 2048
   
   Пожалуйста, сделайте резервную копию этого server.key файла и фразы, которую вы ввели, в безопасном месте. Вы можете просмотреть детали этого закрытого ключа RSA, используя команду:
   
   $ openssl rsa -noout -text -in server.key
   
   При необходимости, вы также можете создать расшифрованный вариант PEM (не рекомендуется) этого закрытого ключа RSA с помощью:
   
   $ openssl rsa -in server.key -out server.key.unsecure
   
   
3. Создайте запрос на подпись сертификата (CSR) с использованием закрытого ключа RSA сервера (выходной формат будет PEM):
   
   $ openssl req -new -key server.key -out server.csr
   
   Убедитесь, что вы ввели FQDN ("полное доменное имя") сервера, когда OpenSSL запросит "CommonName", т.е. когда вы генерируете CSR для веб-сайта, к которому впоследствии можно будет получить доступ через https://www.foo.dom/, введите здесь "www.foo.dom". Вы можете просмотреть детали этого CSR, используя
   
   $ openssl req -noout -text -in server.csr
   
   
4. Теперь вам необходимо отправить этот запрос на подпись сертификата (CSR) в центр сертификации (ЦС) для его подписания. После подписания CSR вы получите действительный сертификат, который может быть использован Apache. Вы можете получить подписанный CSR от коммерческого ЦС или создать свой собственный ЦС для его подписания.
   Коммерческие ЦС обычно просят вас разместить CSR в веб-форме, оплатить подпись и затем отправляют подписанный сертификат, который вы можете сохранить в файле server.crt.
   Для получения подробной информации о создании собственного ЦС и использовании его для подписания CSR см. ниже.
   После подписания CSR вы можете просмотреть детали сертификата следующим образом:
   
   $ openssl x509 -noout -text -in server.crt
   
5. Теперь у вас должны быть два файла: server.key и server.crt. Их можно использовать следующим образом в вашем файле httpd.conf:

   SSLCertificateFile    "/path/to/this/server.crt"
   SSLCertificateKeyFile "/path/to/this/server.key"

   Файл server.csr больше не нужен.

Как создать и использовать свой собственный центр сертификации (ЦС)?

Короткий ответ: используйте скрипт CA.sh или CA.pl, предоставленный OpenSSL. Если у вас нет веских причин отказаться от их использования, следует использовать их по умолчанию. Если вы не можете, вы можете создать самоподписанный сертификат следующим образом:

1. Создайте закрытый ключ RSA для вашего сервера (будет зашифрован Triple-DES и отформатирован в PEM):
   
   $ openssl genrsa -des3 -out server.key 2048
   
   Пожалуйста, сделайте резервную копию этого server.key файла и фразы, которую вы ввели, в безопасном месте. Вы можете просмотреть детали этого закрытого ключа RSA, используя команду:
   
   $ openssl rsa -noout -text -in server.key
   
   При необходимости, вы также можете создать расшифрованный вариант PEM (не рекомендуется) этого закрытого ключа RSA с помощью:
   
   $ openssl rsa -in server.key -out server.key.unsecure
   
   
2. Создайте самоподписанный сертификат (структура X509) с использованием только что созданного ключа RSA (выходной формат будет PEM):
   
   $ openssl req -new -x509 -nodes -sha1 -days 365 -key server.key -out server.crt -extensions usr_cert
   
   Это подписывает CSR сервера и приводит к созданию файла server.crt.
   Вы можете просмотреть детали этого сертификата, используя:
   
   $ openssl x509 -noout -text -in server.crt
   
   

Как изменить фразу для защиты моего закрытого ключа?

Вам просто нужно прочитать его со старой фразой и записать заново, указав новую фразу. Это можно сделать с помощью следующих команд:

$ openssl rsa -des3 -in server.key -out server.key.new
$ mv server.key.new server.key

В первый раз, когда вас попросят ввести фразу PEM, введите старую фразу. После этого вас снова попросят ввести фразу — на этот раз используйте новую фразу. Если вас попросят подтвердить фразу, введите новую фразу еще раз.

Как избавиться от диалога ввода фразы при запуске Apache?

Причина, по которой этот диалог появляется при запуске и каждом перезапуске, заключается в том, что закрытый ключ RSA в вашем файле server.key хранится в зашифрованном формате по соображениям безопасности. Для расшифровки этого файла и его чтения и анализа требуется фраза. Удаление фразы снижает уровень безопасности вашего сервера — действуйте осторожно!

1. Удалите шифрование из закрытого ключа RSA (сохранив резервную копию исходного файла):
   
   $ cp server.key server.key.org
$ openssl rsa -in server.key.org -out server.key
   
   
2. Убедитесь, что файл server.key читаем только для root:
   
   $ chmod 400 server.key
   
   

Теперь server.key содержит незашифрованную копию ключа. Если вы укажете ваш сервер на этот файл, он не попросит вас ввести фразу. ОДНАКО, если кто-то получит этот ключ, они смогут выдать себя за вас в сети. ПОЖАЛУЙСТА, убедитесь, что разрешения на этот файл таковы, что его могут читать только root или пользователь веб-сервера (предпочтительнее запустить ваш веб-сервер от имени root, но с выполнением под другим пользователем, и иметь ключ, читаемый только root).

В качестве альтернативного подхода можно использовать функцию ``SSLPassPhraseDialog exec:/path/to/program''. Имейте в виду, что это не более и не менее безопасно, разумеется.

Как проверить соответствие закрытого ключа и сертификата?

Закрытый ключ содержит ряд чисел. Два из этих чисел образуют "открытый ключ", остальные — часть "закрытого ключа". "Открытый ключ" включен, когда вы генерируете CSR, и впоследствии становится частью связанного сертификата.

Чтобы проверить, что открытый ключ в вашем сертификате соответствует открытой части вашего закрытого ключа, вам просто нужно сравнить эти числа. Для просмотра сертификата и ключа выполните команды:

$ openssl x509 -noout -text -in server.crt
$ openssl rsa -noout -text -in server.key

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

$ openssl x509 -noout -modulus -in server.crt | openssl md5
$ openssl rsa -noout -modulus -in server.key | openssl md5

Это оставляет вам два несколько более коротких числа для сравнения. Теоретически, возможно, что эти числа могут быть одинаковыми без совпадения чисел модуля, но вероятность этого ничтожно мала.

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

$ openssl req -noout -modulus -in server.csr | openssl md5

Как преобразовать сертификат из формата PEM в DER?

По умолчанию формат сертификата в OpenSSL — PEM, который представляет собой просто DER, закодированный в Base64, с заголовком и подписью. Для некоторых приложений (например, Microsoft Internet Explorer) вам нужен сертификат в чистом формате DER. Вы можете преобразовать файл PEM cert.pem в соответствующий файл DER cert.der с помощью следующей команды: $ openssl x509 -in cert.pem -out cert.der -outform DER

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

Одна из причин, по которой это может произойти, заключается в том, что ваш сертификат сервера подписан промежуточным ЦС. Различные ЦС, такие как Verisign или Thawte, начали подписывать сертификаты не корневым сертификатом, а промежуточными сертификатами.

Промежуточные сертификаты ЦС находятся между корневым сертификатом ЦС (который установлен в браузерах) и сертификатом сервера (который вы установили на сервере). Чтобы браузер мог пройти и проверить цепочку доверия от сертификата сервера до корневого сертификата, ему необходимо предоставить промежуточные сертификаты. ЦС должны предоставить вам пакеты таких промежуточных сертификатов, которые можно установить на сервере.

Вам нужно включить эти промежуточные сертификаты с помощью директивы SSLCertificateChainFile.

Протокол SSL

• Почему при высокой нагрузке на сервере возникает много случайных ошибок протокола SSL?
• Почему нагрузка на мой веб-сервер возросла после того, как он стал обслуживать SSL-зашифрованный трафик?
• Почему подключения HTTPS к моему серверу иногда занимают до 30 секунд для установления соединения?
• Какие шифры SSL поддерживаются mod_ssl?
• Почему при попытке использовать шифры анонимного обмена ключами Diffie-Hellman (ADH) возникают ошибки «нет общего шифра»?
• Почему при подключении к моему недавно установленному серверу возникает ошибка «нет общих шифров»?
• Почему я не могу использовать SSL с виртуальными хостами на основе имени/не на основе IP?
• Можно ли использовать виртуальные хосты на основе имени для идентификации разных виртуальных хостов SSL?
• Как заставить работать сжатие SSL?
• Когда я использую аутентификацию Basic по HTTPS, значок замка в браузерах Netscape остается разблокированным при появлении диалогового окна. Это означает, что имя пользователя/пароль отправляется без шифрования?
• Почему при подключении через HTTPS к серверу Apache+mod_ssl с помощью Microsoft Internet Explorer (MSIE) возникают ошибки ввода-вывода?
• Как включить TLS-SRP?
• Почему при использовании Java-клиентов возникают сбои рукопожатия при использовании сертификата с более чем 1024 битами?

Почему при высокой нагрузке на сервере возникает много случайных ошибок протокола SSL?

Это может быть по многим причинам, но основной — проблемы с кэшем сессий SSL, заданным директивой SSLSessionCache. Кэш сессий DBM является наиболее вероятной причиной проблемы, поэтому использование кэша сессий SHM (или вообще без кэша) может помочь.

Почему нагрузка на мой веб-сервер возросла после того, как он стал обслуживать SSL-зашифрованный трафик?

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

Почему подключения HTTPS к моему серверу иногда занимают до 30 секунд для установления соединения?

Обычно это вызвано устройством /dev/random для SSLRandomSeed, которое блокирует вызов read(2) до тех пор, пока не будет достаточно энтропии для обработки запроса. Дополнительная информация доступна в справочном руководстве для директивы SSLRandomSeed.

Какие шифры SSL поддерживаются mod_ssl?

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

1. RC4 с SHA1
2. AES с SHA1
3. Triple-DES с SHA1

Чтобы определить фактический список доступных шифров, выполните следующее:

$ openssl ciphers -v

Почему при попытке использовать шифры анонимного обмена ключами Diffie-Hellman (ADH) возникают ошибки «нет общего шифра»?

По умолчанию OpenSSL не разрешает шифры ADH по соображениям безопасности. Убедитесь, что вы понимаете возможные побочные эффекты, если решите включить эти шифры.

Для использования шифров анонимного обмена ключами Diffie-Hellman (ADH) вы должны скомпилировать OpenSSL с ``-DSSL_ALLOW_ADH'', а затем добавить ``ADH'' в свой SSLCipherSuite.

Почему я получаю ошибку «нет общих шифров» при подключении к новому серверу?

Возможно, вы допустили ошибку в директиве SSLCipherSuite (сравните её с предварительно настроенным примером в extra/httpd-ssl.conf) или выбрали алгоритмы DSA/DH вместо RSA при генерации вашего закрытого ключа и проигнорировали или пропустили предупреждения. Если вы выбрали DSA/DH, ваш сервер не сможет общаться, используя RSA-шифры SSL (по крайней мере, пока вы не настроите дополнительную пару сертификата/ключа на основе RSA). Современные браузеры, такие как NS или IE, могут общаться по SSL только с использованием RSA-шифров. Результатом является ошибка «нет общих шифров». Чтобы исправить это, сгенерируйте пару сертификата/ключа сервера заново, используя алгоритм RSA.

Почему я не могу использовать SSL с виртуальными хостами на основе имени/не на основе IP?

Причина очень техническая и представляет собой проблему «курица и яйцо». Слой протокола SSL находится ниже слоя протокола HTTP и инкапсулирует HTTP. При установлении SSL-соединения (HTTPS) Apache/mod_ssl должен согласовать параметры протокола SSL с клиентом. Для этого mod_ssl должен обратиться к конфигурации виртуального сервера (например, он должен найти набор шифров, сертификат сервера и т. д.). Но для перехода к правильному виртуальному серверу Apache должен знать поле заголовка HTTP Host. Для этого нужно прочитать заголовок запроса HTTP. Это нельзя сделать до завершения рукопожатия SSL, но информация необходима для завершения фазы рукопожатия SSL. См. следующий вопрос о том, как обойти эту проблему.

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

Можно ли использовать виртуальные хосты на основе имени для идентификации различных виртуальных хостов SSL?

Виртуальные хосты на основе имени — очень популярный метод идентификации различных виртуальных хостов. Он позволяет использовать один и тот же IP-адрес и один и тот же номер порта для многих разных сайтов. Когда люди переходят к SSL, кажется естественным предположить, что тот же метод может использоваться для наличия множества различных виртуальных хостов SSL на одном сервере.

Это возможно, но только если вы используете веб-сервер версии 2.2.12 или более поздней, построенный с OpenSSL 0.9.8j или более поздней версии. Это связано с тем, что для этого требуется функция, добавленная только в последних пересмотрах спецификации SSL, называемая Server Name Indication (SNI).

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

Причина в том, что протокол SSL — это отдельный уровень, который инкапсулирует протокол HTTP. Таким образом, SSL-сессия — это отдельная транзакция, которая происходит до начала HTTP-сессии. Сервер получает запрос SSL по IP-адресу X и порту Y (обычно 443). Поскольку запрос SSL не содержал поля Host:, сервер не мог определить, какой виртуальный хост SSL использовать. Обычно использовался первый найденный виртуальный хост, соответствующий указанному порту и IP-адресу.

Однако, если вы используете версию веб-сервера и OpenSSL, которые поддерживают SNI, и браузер клиента также поддерживает SNI, имя хоста включается в исходный запрос SSL, и веб-сервер может выбрать правильный виртуальный хост SSL.

Конечно, вы можете использовать виртуальные хосты на основе имени для идентификации многих виртуальных хостов без SSL (например, все на порту 80), а затем иметь один виртуальный хост SSL (на порту 443). Но если вы это делаете, вы должны убедиться, что указали номер порта без SSL в директиве NameVirtualHost, например:

NameVirtualHost 192.168.1.1:80

Другие решения для обхода проблемы включают:

Использование отдельных IP-адресов для разных хостов SSL.

Использование разных номеров портов для разных хостов SSL.

Как заставить работать сжатие SSL?

Хотя согласование сжатия SSL было определено в спецификации SSLv2 и TLS, потребовалось до мая 2004 года, чтобы RFC 3749 определил DEFLATE как стандартный метод сжатия, который можно согласовать.

OpenSSL 0.9.8 начал поддерживать это по умолчанию при компиляции с опцией zlib. Если и клиент, и сервер поддерживают сжатие, оно будет использоваться. Однако большинство клиентов по-прежнему пытаются сначала подключиться с помощью SSLv2 Hello. Так как SSLv2 не включал массив предпочтительных алгоритмов сжатия в его рукопожатии, сжатие нельзя согласовать с этими клиентами. Если клиент отключит поддержку SSLv2, может быть отправлено SSLv3 или TLS Hello, в зависимости от используемой SSL-библиотеки, и сжатие может быть настроено. Вы можете проверить, используют ли клиенты сжатие SSL, записав переменную %{SSL_COMPRESS_METHOD}x.

Когда я использую аутентификацию Basic через HTTPS, значок замка в браузерах Netscape остается разблокированным, когда появляется диалоговое окно. Это означает, что имя пользователя/пароль отправляются без шифрования?

Нет, имя пользователя/пароль передаются зашифрованными. Значок в браузерах Netscape фактически не синхронизирован со слоем SSL/TLS. Он переключается в заблокированное состояние только тогда, когда передается первая часть фактических данных веб-страницы, что может сбить людей с толку. Модуль Basic Authentication является частью слоя HTTP, который находится над слоем SSL/TLS в HTTPS. Прежде чем произойдет любая передача данных HTTP в HTTPS, слой SSL/TLS уже завершил свою фазу рукопожатия и перешел к зашифрованной передаче. Поэтому не путайте это с иконкой.

Почему при подключении через HTTPS к серверу Apache+mod_ssl с более старыми версиями Microsoft Internet Explorer (MSIE) я получаю ошибки ввода-вывода?

Первая причина заключается в том, что реализация SSL в некоторых версиях MSIE имеет некоторые тонкие ошибки, связанные с механизмом HTTP keep-alive и оповещениями SSL close notify при закрытии соединения сокета. Кроме того, взаимодействие между SSL и функциями HTTP/1.1 проблематично в некоторых версиях MSIE. Вы можете обойти эти проблемы, запретив Apache использовать HTTP/1.1, соединения keep-alive или отправлять сообщения SSL close notify клиентам MSIE. Это можно сделать, используя следующую директиву в разделе виртуального хоста, поддерживающего SSL:

SetEnvIf User-Agent "MSIE [2-5]" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

Кроме того, некоторые версии MSIE имеют проблемы с определенными шифрами. К сожалению, нет возможности реализовать решение, специфичное для MSIE, для этого, потому что шифры нужны уже на фазе рукопожатия SSL. Таким образом, SetEnvIf , специфичное для MSIE, не решит этих проблем. Вместо этого вам придется внести более радикальные изменения в глобальные параметры. Прежде чем принять такое решение, убедитесь, что у ваших клиентов действительно есть проблемы. Если нет, не вносите эти изменения — они повлияют на всех ваших клиентов, MSIE или других.

Как включить TLS-SRP?

TLS-SRP (обмен ключами Secure Remote Password для TLS, определенный в RFC 5054) может дополнить или заменить сертификаты при аутентификации SSL-соединения. Для использования TLS-SRP установите директиву SSLSRPVerifierFile , чтобы она указывала на файл проверителя SRP OpenSSL. Чтобы создать файл проверителя, используйте инструмент openssl:

openssl srp -srpvfile passwd.srpv -add username

После создания этого файла укажите его в конфигурации сервера SSL:

SSLSRPVerifierFile /path/to/passwd.srpv

Чтобы принудительно заставить клиентов использовать наборы шифров TLS-SRP без сертификатов, используйте следующую директиву:

SSLCipherSuite "!DSS:!aRSA:SRP"

Почему у меня возникают сбои рукопожатия с клиентами на основе Java при использовании сертификата с более чем 1024 битами?

Начиная с версии 2.4.7, mod_ssl будет использовать параметры DH, которые включают простые числа длиной более 1024 бит. Однако Java 7 и более ранние версии ограничивают поддержку размеров простых чисел DH максимальным значением 1024 бит.

Если ваш клиент на основе Java прерывается с исключениями, такими как java.lang.RuntimeException: Could not generate DH keypair и java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive), и журнал httpd регистрирует tlsv1 alert internal error (SSL alert number 80) (в LogLevel info или выше), вы можете либо переупорядочить список шифров mod_ssl с помощью SSLCipherSuite (возможно, в сочетании с SSLHonorCipherOrder), либо использовать настраиваемые параметры DH с простым числом 1024 бита, которые всегда будут иметь приоритет над встроенными параметрами DH.

Для генерации настраиваемых параметров DH используйте команду openssl dhparam 1024. Кроме того, вы можете использовать стандартные параметры DH 1024-бит из RFC 2409, раздел 6.2:

-----BEGIN DH PARAMETERS-----
MIGHAoGBAP//////////yQ/aoiFowjTExmKLgNwc0SkCTgiKZ8x0Agu+pjsTmyJR
Sgh5jjQE3e+VGbPNOkMbMCsKbfJfFDdP4TVtbVHCReSFtXZiXn7G9ExC6aY37WsL
/1y29Aa37e44a/taiZ+lrp8kEXxLH+ZJKGZR7OZTgf//////////AgEC
-----END DH PARAMETERS-----

Добавьте настраиваемые параметры, включая строки «BEGIN DH PARAMETERS» и «END DH PARAMETERS», в конец первого файла сертификата, который вы настроили, используя директиву SSLCertificateFile.

Поддержка mod_ssl

• Какие информационные ресурсы доступны в случае проблем с mod_ssl?
• Какие контакты поддержки доступны в случае проблем с mod_ssl?
• Какую информацию я должен предоставить при отправке отчета об ошибке?
• У меня произошел сбой ядра, можете ли вы помочь?
• Как получить трассировку стека, чтобы помочь найти причину сбоя ядра?

Какие информационные ресурсы доступны в случае проблем с mod_ssl?

Доступны следующие информационные ресурсы. В случае проблем вы должны сначала искать здесь.

Ответы в списке часто задаваемых вопросов руководства пользователя (это)

http://httpd.apache.org/docs/2.4/ssl/ssl_faq.html
Сначала проверьте список часто задаваемых вопросов (этот текст). Если ваша проблема распространенная, она, возможно, уже была решена несколько раз и включена в этот документ.

Какие контакты поддержки доступны в случае проблем с mod_ssl?

Ниже перечислены все возможности поддержки mod_ssl в порядке предпочтения. Пожалуйста, пройдите по этим возможностям в указанном порядке — не выбирайте просто ту, которая вам больше нравится.

1. Отправьте отчет о проблеме на список рассылки поддержки пользователей Apache httpd
   users@httpd.apache.org
   Это второй способ отправки отчета о проблеме. Опять же, вам нужно сначала подписаться на список, но затем вы можете легко обсудить свою проблему со всем сообществом пользователей Apache httpd.
2. Напишите отчет о проблеме в базу данных отчетов об ошибках
   http://httpd.apache.org/bug_report.html
   Это последний способ отправки отчета о проблеме. Вы должны это сделать только в том случае, если вы уже опубликовали сообщение на списках рассылки и не добились успеха. Пожалуйста, следуйте инструкциям на указанной странице внимательно.

Какую информацию я должен предоставить при отправке отчета об ошибке?

Вы всегда должны предоставить по крайней мере следующую информацию:

Информация о версии Apache httpd и OpenSSL

Версию Apache можно определить, выполнив httpd -v. Версию OpenSSL можно определить, выполнив openssl version. В качестве альтернативы, если у вас установлен Lynx, вы можете выполнить команду lynx -mime_header http://localhost/ | grep Server, чтобы получить эту информацию в одном шаге.

Подробности о том, как вы построили и установили Apache httpd и OpenSSL

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

В случае дампов ядра, пожалуйста, включите трассировку стека

Если ваш Apache httpd создаёт дамп ядра, пожалуйста, прикрепите трассировку стека (см. ниже для получения информации о том, как её получить). Эта информация необходима для поиска причины дампа ядра.

Подробное описание вашей проблемы

Не смейтесь, мы это серьёзно! Многие сообщения об ошибках не содержат описания самой проблемы. Без этого очень сложно кому-либо помочь вам. Поэтому, в ваших же интересах (вам нужно, чтобы проблема была решена, не так ли?) включить как можно больше деталей, пожалуйста. Конечно, вы должны также включить все необходимые данные выше.

У меня произошёл дамп ядра, вы можете мне помочь?

В целом нет, по крайней мере, не тогда, когда вы не предоставите больше подробностей о расположении кода, где Apache создал дамп ядра. Что обычно всегда требуется, чтобы помочь вам - это трассировка стека (см. следующий вопрос). Без этой информации, в большинстве случаев, найти проблему и помочь вам в её исправлении невозможно.

Как получить трассировку стека, чтобы помочь найти причину дампа ядра?

Ниже приведены шаги, которые вам необходимо выполнить, чтобы получить трассировку стека:

1. Убедитесь, что доступны символы отладки, по крайней мере, в Apache. В платформах, где вы используете GCC/GDB, вам нужно будет скомпилировать Apache+mod_ssl с помощью ``OPTIM="-g -ggdb3"'', чтобы получить это. В других платформах, по крайней мере, необходимо ``OPTIM="-g"''.
2. Запустите сервер и попробуйте воспроизвести дамп ядра. Для этого вы можете использовать директиву, такую как ``CoreDumpDirectory /tmp'', чтобы убедиться, что файл дампа ядра может быть записан. Это должно привести к файлу /tmp/core или /tmp/httpd.core. Если вы не получите ни один из них, попробуйте запустить сервер под не-root UID. Многие современные ядра не позволяют процессу создать дамп ядра после того, как он выполнил setuid() (если он не выполняет exec() по причинам безопасности (могут остаться привилегированные данные в памяти). При необходимости, вы можете вручную запустить /path/to/httpd -X чтобы заставить Apache не выполнять fork.
3. Проанализируйте дамп ядра. Для этого выполните gdb /path/to/httpd /tmp/httpd.core или аналогичную команду. В GDB, всё, что вам нужно сделать, это ввести bt, и вуаля, вы получите трассировку стека. Для других отладчиков, обратитесь к руководству по вашей локальной системе отладки.