У меня есть веб-сервер под управлением Apache 2.0 на RHEL4. Этот сервер недавно не прошел сканирование PCI.
Причина: уязвимость протокола SSLv3.0 / TLSv1.0 слабого режима CBC Решение: эта атака была обнаружена в 2004 г. и более поздних версиях протокола TLS, которые содержат исправление для этого. Если возможно, обновитесь до TLSv1.1 или TLSv1.2. Если обновление до TLSv1.1 или TLSv1.2 невозможно, отключение шифров в режиме CBC устранит уязвимость. Использование следующей конфигурации SSL в Apache снижает опасность этой уязвимости: SSLHonorCipherOrder On SSLCipherSuite RC4-SHA: HIGH:! ADH
«Простое решение, - подумал я. Я добавил строки в конфигурацию Apache, и это не сработало. По-видимому
«SSLHonorCipherOrder On» будет работать только на Apache 2.2 и новее. Я попробовал обновить Apache, вскоре столкнулся с адом зависимостей, и, похоже, мне придется обновить всю ОС, чтобы перейти на Apache 2.2. Мы снимаем этот сервер через несколько месяцев, так что оно того не стоит.
Решение говорит «Если обновление до TLSv1.1 или TLSv1.2 невозможно, отключение шифров в режиме CBC устранит уязвимость».
Как мне сделать это на Apache 2.0? Это вообще возможно? Если нет, есть ли другие способы обхода?
Помимо компиляции нового Apache вручную, единственное, что я могу придумать, - это сделать RC4-SHA только поддерживаемый шифр (проверено с openssl ciphers RC4-SHA на текущем openssl, чтобы убедиться, что он печатает только один шифр, вы можете сделать то же самое, чтобы убедиться, что он не соответствует какому-то странному старому шифру на вашем старом openssl):
SSLCipherSuite RC4-SHA
MS говорит, что Windows XP поддерживает TLS_RSA_WITH_RC4_128_SHA поэтому у вас не должно возникнуть проблем с совместимостью.
Есть только два способа "исправить" BEAST на уровне сервера.
Лучший вариант - обновить библиотеку SSL вашего сервера до той, которая поддерживает TLS v1.1 или более поздней версии (и убедитесь, что ваши клиенты тоже поддерживают ее, чтобы вы могли заставить их использовать ее).
Другой вариант - отключить любые алгоритмы шифрования CBC (Cypher-Block-Chaining) и переключиться на шифрование en ECB (Electronic Code Book) или что-то вроде RC4 (алгоритмы ECB теоретически «менее безопасны», потому что заданный входной открытый текст зашифрован до заданного key всегда сопоставляется с одним и тем же зашифрованным текстом, что упрощает взлом с помощью известных атак с открытым текстом, но с практической точки зрения это вряд ли будет большой проблемой. Google (в качестве примера) по-прежнему использует RC4).
Поскольку сервер, на котором вы работаете, мертв, похоронен, и его разложение, вероятно, не стоит того количества усилий, которые потребуются для создания исправленного Apache (вам нужно будет перестроить Apache и OpenSSL изолированно, чтобы не нарушить ничего, что требует версию OpenSSL, установленную в вашей системе по умолчанию - если вы делаете столько работы, вы можете также обновить всю систему до того, что действительно поддерживается), так что в значительной степени вы останетесь с «Переключиться на ECB Cyphers» в качестве ваше жизнеспособное решение.
BEAST в наши дни действительно ничто иное, как атака - Во всех популярных браузерах (IE, Chrome, Safari, Opera) реализован эффективный обходной путь., и из-за как работает атака это довольно сложно реализовать вне браузера (так что apt и yum все еще в значительной степени безопасны).
Адам Лэнгли из Google выступил с отличным докладом в начале этого года. в котором излагаются некоторые из проблем, на которых вам следует сосредоточиться на re: SSL и безопасности. Хотя BEAST и заслужил упоминание, он находится в конце списка вещей, о которых следует беспокоиться.
Единственное найденное мной решение, которое заставит вас пройти тест ssllabs.com, - это добавить следующие четыре строки в ваш apache httpd.conf и ваши файлы ssl.conf:
SSLHonorCipherOrder On
SSLProtocol -все + TLSv1 + SSLv3
SSLCipherSuite RC4-SHA: ВЫСОКИЙ:! MD5:! ANULL:! EDH:! ADH
SSLInsecureRenegotiation выкл.
Убедитесь, что ни один из этих параметров не опубликован дважды в файле ssl.conf.
Теперь мои сайты проходят с отметкой А.