Включение AES_128_CBC и RC4_128 для соединений JDBC с MS SQL Server 2005

Question

Чтобы обеспечить обратную совместимость моего приложения, я тестирую поведение JDBC поверх TLS, когда используется версия MS SQL Server, уязвимая для CVE-2011-3389 ( подходят любые 2005 или 2008/2008R2 без пакетов обновления). Теоретически доступны два варианта:

• либо отключите защиту CBC через -Djsse.enableCBCProtection=false и продолжать использовать блочный шифр, такой как AES_128_CBC или же 3DES_EDE_CBC,
• или вернуться к потоковому шифру, такому как RC4 (да, я знаю, что это тоже небезопасно из-за CVE-2015-2808).

На практике пока у меня нет проблем с установлением соединения с помощью 3DES_EDE_CBC при отключенной защите CBC я все еще не могу использовать RC4_128 используя JDK новее, чем 1.8.0_51 (что случилось с адресом CVE-2015-2808) или AES_{128,256}_CBC (используя любой 1.6+ JDK).

Вот результаты с разбивкой по версии Java:

• 1.6.0_45 (jTDS)
  • SSL_RSA_WITH_RC4_128_MD5 используется
• 1.7.0_76 (jTDS) и любые 1.8.0 до 1.8.0_45 (MS SQL JDBC):
  • SSL_RSA_WITH_RC4_128_MD5 (по умолчанию) или SSL_RSA_WITH_3DES_EDE_CBC_SHA может быть использован
  • не буду использовать AES_128_CBC даже если 3DES выключен (3DES_EDE_CBC все равно будет вынужден)
• 1.8.0_45 (IBM J9 8.0 SR1) (MS SQL JDBC)
  • SSL_RSA_WITH_3DES_EDE_CBC_SHA используется (успешно, только если защита CBC отключена), также если AES или же RC4 запрашивается
• 1.8.0_51 + (Oracle) (MS SQL JDBC)
  • SSL_RSA_WITH_3DES_EDE_CBC_SHA используется (успешно, только если защита CBC отключена),
  • не буду использовать AES_128_CBC или же AES_256_CBC даже если требуется (в отличие от предыдущих версий Java, 3DES больше не принуждается, вместо этого я получаю IOException после ClientHello, который делает список *_WITH_AES_128_CBC_SHA в качестве совместимых шифров)
  • не буду использовать RC4 даже если оба с AES а также 3DES отключены: "no negotiable cipher suite" (JTDS и MS SQL JDBC).

Вот java.security Я использую для запроса AES:

jdk.certpath.disabledAlgorithms=MD2
jdk.tls.disabledAlgorithms=SSLv3, RC4, TLSv1.1, TLSv1.2, 3DES_EDE_CBC
jdk.tls.legacyAlgorithms= \
        K_NULL, C_NULL, M_NULL, \
        RC4_128, RC4_40

и вот версия для запроса RC4:

jdk.certpath.disabledAlgorithms=MD2
jdk.tls.disabledAlgorithms=SSLv3, AES_128_CBC, TLSv1.1, TLSv1.2, AES_256_CBC, AES_128_GCM, AES_256_GCM, 3DES_EDE_CBC
jdk.tls.legacyAlgorithms= \
        K_NULL, C_NULL, M_NULL

Вопросы:

• По-видимому, AES_{128,256}_CBC поддерживается моими клиентами Java, так как я могу использовать TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA при подключении к MS SQL Server 2014. Кто-нибудь может подтвердить, что он не поддерживается MS SQL Server 2005? С отключением AES эффективно приводит к "no negotiable cipher suite" Я предполагаю, что это поддерживается, но что-то происходит на стороне сервера, даже если защита CBC отключена.
• Как я могу все еще использовать RC4 в Java 1.8.0_51 +? Это решение больше не работает и не имеет никакого эффекта https.cipherSuites системное свойство (описано здесь). Там волшебный jdk.tls.enableRC4CipherSuites Системное свойство в 6u115 и 7u101, но, похоже, не действует в Java 1.8.
• Что, черт возьми, не так с jTDS? Он отлично работает с Java 1.6 и 1.7 (версии драйверов 1.2.8 и 1.3.1), но с использованием Java 1.8 я постоянно получаю "Connection reset by peer" всякий раз, когда MS SQL JDBC будет просто использовать 3DES для шифрования данных подключения.