Отключение RC4 в наборе шифров SSL на сервере Apache

Question

Пожалуйста, смотрите раздел РЕДАКТИРОВАТЬ в моем собственном ответе; они содержат объяснение этой головоломки.

Я пытаюсь отключить RC4 для сервера Apache 2.2.9, работающего на CentOS 6.5 VPS, и не могу добиться успеха.

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

При проверке конфигурации с помощью Qualys SSL Labs на странице результатов отображается сообщение «Этот сервер принимает шифр RC4, который является слабым. Оценка ограничена до ".

Тем не менее, я поместил это в ssl.conf:

 SSLCipherSuite HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!SSLv2:!SSLv3

Я сохранил сценарий, приведенный в ответе на этот вопрос, в файл с именем test-ssl-ciphers.sh и изменил IP-адрес на адрес обратной связи. Это результат ./test-ssl-ciphers.sh | grep -i "RC4":

Testing ECDHE-RSA-RC4-SHA...NO (sslv3 alert handshake failure)
Testing ECDHE-ECDSA-RC4-SHA...NO (sslv3 alert handshake failure)
Testing AECDH-RC4-SHA...NO (sslv3 alert handshake failure)
Testing ADH-RC4-MD5...NO (sslv3 alert handshake failure)
Testing ECDH-RSA-RC4-SHA...NO (sslv3 alert handshake failure)
Testing ECDH-ECDSA-RC4-SHA...NO (sslv3 alert handshake failure)
Testing RC4-SHA...NO (sslv3 alert handshake failure)
Testing RC4-MD5...NO (sslv3 alert handshake failure)
Testing RC4-MD5...NO (sslv3 alert handshake failure)
Testing PSK-RC4-SHA...NO (no ciphers available)
Testing KRB5-RC4-SHA...NO (no ciphers available)
Testing KRB5-RC4-MD5...NO (no ciphers available)
Testing EXP-ADH-RC4-MD5...NO (sslv3 alert handshake failure)
Testing EXP-RC4-MD5...NO (sslv3 alert handshake failure)
Testing EXP-RC4-MD5...NO (sslv3 alert handshake failure)
Testing EXP-KRB5-RC4-SHA...NO (no ciphers available)
Testing EXP-KRB5-RC4-MD5...NO (no ciphers available)

Каждая из этих строк содержит "НЕТ", что, согласно сценарию, означает, что сервер не поддерживает указанную комбинацию шифров.

Более того, команда grep -i -r "RC4" /etc/httpd выдает мне только вышеупомянутый файл ssl.conf.

Кроме того, запуск openssl ciphers -V в моем наборе шифров вообще не показывает шифров RC4, что имеет смысл, учитывая строку конфигурации.

Поэтому я почему-то растерялся относительно того, почему веб-сайты проверки SSL говорят мне, что "сервер принимает RC4". Они даже перечисляют следующие шифры как принятые:

TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA

У кого-нибудь есть возможное объяснение? Что я делаю не так? Может быть, есть другое место, где настраивается поддержка RC4 или "принятие"?

Благодарю.

[ EDIT ] Используя CentOS 6.6 на домашней виртуальной машине, я снова запустил скрипт для своего VPS, используя его доменное имя вместо адреса обратной связи. Эта настройка подразумевает, что список шифров предоставляется экземпляром openssl в виртуальной машине: у меня все еще нет RC4 среди шифров, которые дают YES.

Answer 1

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

Другими словами, удаление набора данных привело к тесту Qualys для оценки домена A и одновременно удаления предупреждений о RC4. Возврат подробностей приводит к возвращению предупреждений и повторной оценке степени B, что не оставляет места для сомнений относительно причинно-следственной связи.

Это похоже на то, что предоставление деталей для каждого vhost каким-то образом создало новую среду, в которой некоторые значения по умолчанию переопределили набор шифров, который я указал в ssl.conf. Weird.

Решением является добавление спецификации SSLCipherSuite в текстовое поле Apache Directives для каждого vhost. Это то, что у меня есть в конфигурации, которая дает мне оценку A:

SSLProtocol ALL -SSLv2 -SSLv3
SSLHonorCipherOrder on
# Compression is disabled by default on my distribution (CentOS 6)
# SSLCompression off 
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

РЕДАКТИРОВАТЬ (2017-05-16): Дополнительная информация об этой проблеме: указание SSLCipherSuite является обязательным. Я не могу понять, почему эта конкретная директива, хотя указанная на уровне сервера, не применяется автоматически к конфигурациям виртуальных хостов. Я использую Apache 2.2.15 на CentOS 6.9.

РЕДАКТИРОВАТЬ (2018-06-18): Более подробная информация. Я только что обнаружил, что директиву SSLCipherSuite можно указывать один раз, и она будет применяться ко всем виртуальным хостам: в базовом файле конфигурации mod_ssl (в CentOS 6 этот файл находится по адресу /etc/httpd/conf.d/ssl.conf), вы просто должны указать директиву вне виртуального хоста по умолчанию. В документации Apache 2.2 указано, что значением по умолчанию для этой директивы является SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP . Я считаю, что именно отсюда и происходит шифр RC4: при отсутствии какой-либо спецификации, что было для меня, поскольку ни одна спецификация не была в "глобальном" контексте, применяется значение по умолчанию. Это понимание заканчивает то, что было для меня загадкой. По иронии судьбы, я собираюсь перейти на CentOS 7, когда найду это объяснение! НТН.

Answer 2

SSLCipherSuite HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!SSLv2:!SSLv3
                                                                    ^^^^^^^

Плохая идея. Отключение всех шифров SSLv3 приводит к отключению шифров, используемых с TLS1.0 и TLS1.1, и оставляет только несколько шифров, недавно представленных с TLS1.2 (если ваш сервер поддерживает TLS1.2)

Поэтому я почему-то растерялся относительно того, почему веб-сайты проверки SSL говорят мне, что "сервер принимает RC4". Они даже перечисляют следующие шифры как принятые:

Убедитесь, что локальные и внешние тесты обращаются к одному и тому же серверу (IP-адресу). Я видел много сайтов, где example.com находится на другом хосте, чем www.example.com и поэтому тесты отличаются.

Answer 3

Лаборатории Qualys SSL кажутся очень чувствительными к хостам по умолчанию и т.д. Убедитесь, что ВСЕ ваши HTTPS VirtualHosts на этом IP-адресе используют одни и те же настройки (кроме файлов сертификатов), у меня была похожая проблема, когда некоторые из тестов Qualys тестировались с моим целевым VirtualHost, а некоторые из них, похоже, выбирали VirtualHost по умолчанию , У моего целевого vhost был включен только один шифр, но Qualys находил гораздо больший список из стандартного vhost.

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

Answer 4

Просто просматривал это для одного из моих сайтов. Исходя из ответа @ AbVog, я обнаружил, что мои директивы на самом деле были только внутри стандартного vhost. Когда я переместил директивы в глобальный контекст, все было хорошо.

Кроме того, я также натолкнулся на https://cipherli.st/, в котором есть хороший список настроек SSL для нескольких пакетов. Текущая рекомендация для apache выглядит следующим образом:

SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff

# Requires Apache >= 2.4
SSLCompression off 
SSLSessionTickets Off
SSLUseStapling on 
SSLStaplingCache "shmcb:logs/stapling-cache(150000)" 

Answer 5

На моей Fedora 25 с Apache/2.4.25 шифры обрабатываются крипто-политиками (см. /Etc /cryptopolicies /backends). В настройке по умолчанию RC4 полностью отключен, поэтому нет необходимости вмешиваться в шифры в настройке Apache. За исключением того, что вы используете последний ssl.conf, так как он не установлен по умолчанию, но оставлен как ssl.conf.rpmnew в каталоге conf.d.

Чтобы настроить SSL, мне просто нужно было указать сертификаты, ServerName и DocumentRoot. Для Squirrelmail это.

SSLCertificateFile /etc/letsencrypt/live/mail.xxxx.dk/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mail.xxxx.dk/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/mail.xxxx.dk/chain.pem
SSLCACertificateFile /etc/letsencrypt/live/mail.xxxx.dk/fullchain.pem
ServerName mail.xxxx.dk:443
DocumentRoot "/usr/share/squirrelmail"