3

为了确保我的应用程序的向后兼容性，当使用易受CVE-2011-3389影响的MS SQL Server版本（任何 2005 或 2008/2008R2 不适合服务包）时，我正在测试 JDBC over TLS 行为。理论上，有两种选择：

  • 通过禁用 CBC 保护-Djsse.enableCBCProtection=false并继续使用分组密码，例如AES_128_CBC或3DES_EDE_CBC，
  • 或回退到流密码，例如RC4（是的，我知道这也是不安全的，因为CVE-2015-2808）。

在实践中，虽然我在关闭 CBC 保护的情况下建立连接没有问题3DES_EDE_CBC，但我仍然无法使用RC4_128比1.8.0_51更新的 JDK （恰好地址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不再强制，而是我得到一个IOExceptionafter 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不支持它？由于禁用有效导致，我认为它是受支持的，但是服务器端发生了一些事情，即使 CBC 保护已关闭。AES"no negotiable cipher suite"
  • 我怎样才能RC4在 Java 1.8.0_51+中使用？此解决方案不再有效，也没有任何影响https.cipherSuites系统属性（在此处描述）。6u115和7u101中有一个神奇的jdk.tls.enableRC4CipherSuites系统属性，但在 Java 1.8 中似乎没有效果。
  • jTDS到底有什么问题？"Connection reset by peer"它适用于 Java 1.6 和 1.7（驱动程序版本 1.2.8 和 1.3.1），但使用 Java 1.8，只要MS SQL JDBC仅用于3DES加密连接数据，我就会不断收到。
4

0 回答 0