Enabling AES_128_CBC and RC4_128 for JDBC connections to MS SQL Server 2005

Question

To ensure backward compatibility of my application, I'm testing JDBC over TLS behaviour when an MS SQL Server version vulnerable to CVE-2011-3389 is used (any 2005, or 2008/2008R2 w/o service packs fit). In theory, two options are available:

• either disable CBC protection via -Djsse.enableCBCProtection=false and continue to use a block cipher such as AES_128_CBC or 3DES_EDE_CBC,
• or fall back to a stream cipher such as RC4 (yes I'm aware this is insecure, too, due to CVE-2015-2808).

In practice, while I have no trouble establishing a connection using 3DES_EDE_CBC with CBC protection off, I'm still unable to use RC4_128 using an JDK newer than 1.8.0_51 (which happened to address CVE-2015-2808) or AES_{128,256}_CBC (using any 1.6+ JDK).

Here's the results broken down by Java version:

• 1.6.0_45 (jTDS)
  • SSL_RSA_WITH_RC4_128_MD5 is used
• 1.7.0_76 (jTDS) and any 1.8.0 up to 1.8.0_45 (MS SQL JDBC):
  • SSL_RSA_WITH_RC4_128_MD5 (default) or SSL_RSA_WITH_3DES_EDE_CBC_SHA can be used
  • won't use AES_128_CBC even if 3DES is disabled (3DES_EDE_CBC will be forced anyway)
• 1.8.0_45 (IBM J9 8.0 SR1) (MS SQL JDBC)
  • SSL_RSA_WITH_3DES_EDE_CBC_SHA is used (successful only if CBC protection is off), also if either AES or RC4 is requested
• 1.8.0_51+ (Oracle) (MS SQL JDBC)
  • SSL_RSA_WITH_3DES_EDE_CBC_SHA is used (successful only if CBC protection is off),
  • won't use AES_128_CBC or AES_256_CBC even if requested (unlike previous Java versions, 3DES is no longer forced, instead I get an IOException after ClientHello, which does list *_WITH_AES_128_CBC_SHA as compatible ciphersuites)
  • won't use RC4 even if both with AES and 3DES are disabled: "no negotiable cipher suite" (both jTDS and MS SQL JDBC).

Here's the java.security I use to request 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

and here's the version to request 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

Questions:

• Apparently, AES_{128,256}_CBC is supported by my Java clients, as I can use TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA when connecting to MS SQL Server 2014. Can anyone confirm it is not supported by MS SQL Server 2005? Since disabling AES effectively leads to "no negotiable cipher suite", I assume it is supported, but something happens server-side, even though CBC protection is off.
• How can I still use RC4 in Java 1.8.0_51+? This solution no longer works, nor has any effect https.cipherSuites system property (described here). There's a magical jdk.tls.enableRC4CipherSuites system property in 6u115 and 7u101, but it seems to have no effect in Java 1.8.
• What the heck is wrong with jTDS? It works fine with Java 1.6 and 1.7 (driver versions 1.2.8 and 1.3.1), but using Java 1.8 I'm constantly receiving "Connection reset by peer" whenever MS SQL JDBC would just use 3DES to encrypt connection data.