Я занимаюсь поиском и тестированием уже пару дней, и у меня кончились вещи, чтобы попробовать. Вот моя проблема. У меня есть веб-сервер 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, я вижу следующие проблемы (которые могут быть или не быть частью проблемы здесь):
Опечатки:
Протоколы 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