Назад | Перейти на главную страницу

Не удается обновить протоколы или шифры Apache SSL

Я занимаюсь поиском и тестированием уже пару дней, и у меня кончились вещи, чтобы попробовать. Вот моя проблема. У меня есть веб-сервер Apache Lounge 2.4.18 (Win32) VC14, работающий на сервере Microsoft Windows 2008 R2 с использованием OpenSSL 1.0.2g. Наша группа корпоративной безопасности просканировала мой сервер и обнаружила, что используется RC4. (Использовали Nexpose от Rapid7). Они рекомендовали настроить сервер так, чтобы отключить поддержку шифров RC4, и предложили использовать конфигурацию шифров, показанную ниже. Они также рекомендовали не использовать TLSv1 и использовать только TLSv1.1 и TLSv1.2. Я также запустил SSLScan для дублирования результатов и увидел, что «TLSv1 128 бит RC4-SHA» был принят.

Нет проблем. Я подумал и изменил свой файл httpd.conf, как показано ниже, а затем перезапустил службу Apache2.4. Затем я попросил их повторно просканировать сервер, и они получили те же результаты. Я обыскал весь сервер в поисках файлов, содержащих «SSLCipherSuite» или «SSLProtocol», и удалил или переименовал их все, кроме \ Apache24 \ conf \ httpd.conf. У меня есть файл \ Apache24 \ conf \ openssl.cnf, но я не думаю, что он что-то делает, потому что это по-прежнему файл по умолчанию, поставляемый с Apache. Я также провел масштабную очистку и удалил все старые версии Apache, OpenSSL и PHP. Я обновил Apache и OpenSSL с Apache 2.2 и OpenSSL 0.9.x около 3 недель назад и работал без проблем. У меня нет ошибок при запуске в error.log или в средстве просмотра событий Windows.

Есть ли еще где-нибудь Apache / OpenSSL, определяющий протоколы или комплекты шифров?

Есть ли какое-то значение по умолчанию, которое игнорирует мои директивы, связанные с SSL?

Содержание моего файла httpd.conf («MYDOMAIN» явно не является моим настоящим доменным именем):

<VirtualHost *:80>

    DocumentRoot "C:/Apache24/htdocs"
    ServerName www.MYDOMAIN.com
</VirtualHost>

<VirtualHost *:443>
    DocumentRoot "C:/Apache24/htdocs_apps"
    ServerName apps.MYDOMAIN.com

    SSLEngine on
    SSLCertificateFile "C:/Apache24/certs/233afff052190aeb.crt"
    SSLCertificateKeyFile "C:/Apache24/certs/star_MYDOMAIN_com.key"
    # SSLCertificateChainFile "C:/Apache24/certs/gd_bundle-g2-g1.crt"

    SSLProtocol -ALL +TLSv1.1 +TLSv1.2 
    SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSAAES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSAAES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK

    <Location / >
        Options -ExecCGI -FollowSymLinks -Indexes
        Require all granted
    </Location>
</VirtualHost>

Любая помощь приветствуется.

Похоже, что настройка F5 может быть как «входящее предприятие», а не «сквозной входящий SSL». Похоже, разница заключается в том, что в первом случае трафик от пользователя к F5 зашифровывается с помощью настройки SSL F5, затем дешифруется в F5 и, наконец, повторно шифруется с использованием вашей настройки SSL только для связи между F5 и вашим сервером, а во втором трафик шифруется между пользователем и вашим сервером полностью с использованием вашей настройки SSL (и просто передается F5 без дешифрования / повторного шифрования). Если это так, возможно, ваш трафик только «безопасен» (без RC4) между вами и F5 и находится во власти настройки F5 в общедоступной сети. По крайней мере, стоит задать несколько вопросов вашим сетевым специалистам, прежде чем предполагать, что у вас безопасная установка.

Аааа успех! Оказывается, наша сеть использует устройство «F5», которое устанавливает SSL-соединение, а затем проксирует его обратно на мой сервер. Похоже, им нужно работать с ИХ шифрами! Благодаря этому небольшому упражнению мой сервер теперь более безопасен. Я также использую CloudFlare, поэтому соединение идет Cloudflare-> F5-> OpenSSL с использованием TLSv1.1 и TLSv1.2.

Время для обеда. Интересно, сохранилась ли у нас политика в отношении обеда из двух напитков ...

Что касается openssl.conf, есть ли в нем директива SSLCipherSuite и, если да, закомментирована ли она? Может быть проблема "слияния".

Глядя на вашу директиву SSLCipherSuite, я вижу следующие проблемы (которые могут быть или не быть частью проблемы здесь):

Опечатки:

  • ECDHE-ECDSAAES256-GCM-SHA384, вероятно, должен быть ECDHE-ECDSA-AES256-GCM-SHA384
  • хотя TLSv1.0, DHE-RSAAES256-SHA, вероятно, должен быть DHE-RSA-AES256-SHA

Протоколы TLSv1.0:

  • DHE-RSA-AES128-SHA - это TLSv1.0
  • DHE-DSS-AES256-SHA - это TLSv1.0

В любом случае использую:

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

с участием

SSLProtocol all -SSLv2 -SSLv3

и получить рейтинг A + от Qualys SSL Labs » Тест сервера SSL (включая проверку отсутствия RC4).

ПРИМЕЧАНИЕ. Хотя некоторые люди отказываются от TLSv1.0, у вас могут возникнуть проблемы с большим количеством браузеров, возможно, включая Android 5.0.0 и более ранние версии, IE 8-10 на Win 7, IE 10 на Win Phone 8.0, Safari 5.1.9. в OS X 10.6.8 и Safari 6.0.4 в OS X 10.8.4