Из-за недавнего шума об SSL BEAST уязвимость Я хотел попытаться повысить безопасность защищенного SSL веб-сайта, основанного на Tomcat 6. С этой целью я попробовал подход Google: Цепочка блоков шифров (CBC) приоритет шифров в моем Tomcat server.xml файл в объявлении соединителя HTTP:
ciphers="TLS_ECDHE_RSA_WITH_RC4_128_SHA,
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,
TLS_ECDH_RSA_WITH_RC4_128_SHA,
TLS_ECDH_ECDSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_RC4_128_MD5,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA"
Но похоже, что Tomcat не использует порядок шифров, а вместо этого выбирает лучший шифр на основе силы ключа. Также SSL Labs указывает, что мой сайт не показывает предпочтение шифрования, тогда как google.com показывает. Я не хочу удалять 256-битные шифры CBC, чтобы использовать 128-битный шифр RC4, опасаясь несовместимости с SSL. Я предполагаю, что выбор шифра выполняется на уровне Java JSSE, а не в Tomcat.
Кто-нибудь знает простой способ настроить приоритет / порядок шифров SSL с помощью стандартного HTTP-коннектора Tomcat? Есть ли способ добиться этого с помощью простого пользовательского класса Java? Предлагает ли коннектор Tomcat APR и некоторые параметры конфигурации openSSL альтернативу. Есть ли другой простой способ сделать это?
Обратите внимание: я понимаю, что эта атака требует межсайтового скриптинга или какой-либо другой подобной уязвимости, и поэтому она не так серьезна (для моего сайта). Однако, если есть простые шаги для смягчения этой атаки, я приму их. Кроме того, я не хочу вводить интерфейс Apache (при условии, что в Apache есть способ сделать это) из-за дополнительной сложности и, следовательно, риска.
У меня такая же проблема. Кажется, мы не можем делать то, что хотим.
Реализация Sun (Oracle) Java SSL проверяет только порядок (приоритеты) набора шифров на стороне клиента и игнорирует серверную сторону.
Связанные классы:
sun.security.ssl.ServerHandshaker
sun.security.ssl.CipherSuite
На ServerHandshaker,
"private void chooseCipherSuite (ClientHello mesg)"
http://www.java2s.com/Open-Source/Java-Document/6.0-JDK-Modules-sun/security/sun/security/ssl/ServerHandshaker.java.htm
/*
* Choose cipher suite from among those supported by client. Sets
* the cipherSuite and keyExchange variables.
*/
private void chooseCipherSuite(ClientHello mesg) throws IOException {
for (CipherSuite suite : mesg.getCipherSuites().collection()) {
if (isEnabled(suite) == false) {
continue;
}
if (doClientAuth == SSLEngineImpl.clauth_required) {
if ((suite.keyExchange == K_DH_ANON) || (suite.keyExchange == K_ECDH_ANON)) {
continue;
}
}
if (trySetCipherSuite(suite) == false) {
continue;
}
return;
}
fatalSE(Alerts.alert_handshake_failure,
"no cipher suites in common");
}
Мы видим, что он включает комплекты шифров в приветственном сообщении клиента и выбирает комплект шифров.
Начиная с Tomcat 6.0.37/7.0.30/8.0.x, собственный коннектор на основе / APR / OpenSSL поддерживает SSLHonorCipherOrder параметр конфигурации, который позволяет серверу иметь указанный порядок выбора шифров. Этот порядок зависит от вас и не основан на нечетких определениях, таких как «сила», поскольку в определенных ситуациях высокобитовый шифр может быть хуже, чем низкоразрядный.
Tomcat 8.0.21 и более поздние версии на Java 8 и более поздних версиях будут использовать предпочтительный порядок набора шифров сервера, если useServerCipherSuitesOrder установлено значение «true» (по умолчанию) для соединителей на основе Java.
Tomcat 7.0.60 и более поздние версии на Java 8 и более поздних версиях будут использовать предпочтительный порядок набора шифров сервера, если useServerCipherSuitesOrder установлено значение «true» (по умолчанию) для соединителей на основе Java.
Tomcat 6 никогда не имел такой возможности для соединителей на основе Java; Предпочтительный для сервера порядок наборов шифров на Tomcat 6 потребует использования APR / собственного коннектора.
Во время рукопожатия клиент отправляет предпочтительные наборы шифров, а сервер выбирает самый надежный, который оба могут поддерживать.
Я не уверен, какой заказ вы ожидаете.
Также SSL Labs указывает, что мой сайт не показывает предпочтения шифрования, тогда как google.com показывает
Я не могу понять, что вы здесь имеете в виду.
В чем конкретно заключается жалоба? Что из включенных шифров Tomcat выбрал меньше недели, чем предполагалось?
Я не верю, что вы можете упорядочить их по предпочтениям, и как только вы избавитесь от CBC, появится ужасно короткий список доступных вариантов шифрования! Однако большинство клиентов собираются подключиться к RC4-128 любым способом - по крайней мере, это то, что показывают все журналы моих серверов, когда мне хочется включить эту опцию ведения журнала.
Используя коннектор OpenSSL, вы получаете возможность использовать более сжатый синтаксис для разрешения или запрета определенных шифров, но не можете установить порядок шифров или даже предпочтительный шифр.