Я в своем уме закончить с этим! Я не являюсь специалистом по ИТ / сетям, поэтому прошу прощения, если задаю неправильный вопрос / даю неправильную информацию.
Я работаю над тем, чтобы клиентский сайт прошел проверку безопасности Trustwave, чтобы он мог продолжать принимать кредитные карты. Вот хронология событий на данный момент:
Я действительно хочу протестировать это сам, однако, как я уже сказал, это не моя настоящая работа - я разработчик, и, хотя я хочу много узнать о CI, у меня нет времени сегодня! То, что я сделал до сих пор, использует мой экземпляр openssl для попытки запроса, поскольку я думаю, что Trustwave представляет его, чтобы посмотреть, могу ли я воссоздать их доказательства:
openssl s_client -connect thenewtonproject.com:443 -cipher "TLSv1:ALL:eNULL:aNULL"
Когда я запускаю это, я вижу, что он говорит TLSv1/SSLv3. Cipher is RC4-SHA
, что заставило бы меня поверить, что сканирование Trustwave неверно, но поскольку я впервые делал что-то подобное с openssl, я даже не уверен, что использовал правильную команду / синтаксис. Может ли кто-нибудь помочь исправить мой синтаксис / проверить мой результат на том же сайте?
РЕДАКТИРОВАТЬ
Согласно Trustwave, проблема BEAST такова:
Протокол SSL шифрует данные, используя режим CBC с связанными векторами инициализации. Это позволяет злоумышленнику, который получил доступ к сеансу HTTPS с помощью атак типа «человек посередине» (MITM) или другими способами, получать заголовки HTTP в виде обычного текста с помощью блочной атаки с выбранной границей (BCBA) в сочетании с Javascript. код, использующий HTML5 WebSocket API, Java URLConnection API или Silverlight WebClient API. Эта уязвимость чаще упоминается как использование браузера против SSL / TLS или «ЗВЕРЬ».
Согласно Trustwave, шаги по исправлению ситуации:
Затронутые пользователи должны отключить все комплекты блочных шифров в конфигурации SSL сервера и поддерживать только шифры RC4, которые не уязвимы для полного устранения этой уязвимости. Эта уязвимость была устранена в TLS версии 1.1 / 1.2, однако на момент написания этой статьи поддержка этих новых версий TLS не широко поддерживается, что затрудняет отключение более ранних версий. Кроме того, затронутые пользователи также могут настроить SSL для предпочтения шифров RC4 над блочными шифрами, чтобы ограничить, но не устранить уязвимость. Затронутые пользователи, которые реализуют методы приоритезации для смягчения последствий, как описано выше, должны апеллировать к этой уязвимости и включить подробную информацию о конфигурации SSL.
На прошлой неделе я получил информацию об инструменте IISCrypto из обычного поиска в Google.
РЕДАКТИРОВАТЬ 2: По запросу вот как выглядят шифры в реестре:
[\AES 128/128]
"Enabled"=false
[\AES 256/256]
"Enabled"=false
[\DES 56/56]
"Enabled"=false
[\NULL]
"Enabled"=false
[\RC2 128/128]
"Enabled"=false
[\RC2 40/128]
"Enabled"=false
[\RC2 56/128]
"Enabled"=false
[\RC4 128/128]
"Enabled"=true
[\RC4 40/128]
"Enabled"=false
[\RC4 56/128]
"Enabled"=false
[\RC4 64/128]
"Enabled"=false
[\Triple DES 168/168]
"Enabled"=true
Первоначально ответ был дан здесь:
Я применил это, и он работает:
на него ответил https://security.stackexchange.com/users/12375/josh https://security.stackexchange.com/questions/14326/how-to-fix-ssl-2-0-and-beast-on-iis
Сообщите мне, сработало ли это