Не удается обновить протоколы или шифры 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» явно не ' t мое настоящее доменное имя):

<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>

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

2
задан 31 March 2016 в 03:49
3 ответа

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

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

1
ответ дан 3 December 2019 в 10:38

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

1
ответ дан 3 December 2019 в 10:38

Что касается 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

1
ответ дан 3 December 2019 в 10:38

Теги

Похожие вопросы