Enabling 128 bit cipher suite for TLS for java application

Question

I have multiple java based application that interact with each over over TLS and I am trying to enforce 128 bit ciphers for TLS communication. The way I am enforcing 128 bit cipher on the java(server side) is by setting following property in the java.security file of the JDK :

jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize > 128,
EC keySize > 128,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_256_CCM,
TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8, 3DES_EDE_CBC, anon, NULL

I have test java program that uses HttpsURLConnection to access a web resource deployed in the jetty container which also uses same JDK(configured to present 128 ciphers only for TLS communicaiton) and the test program works fine with successful SSL handshake(client-server hello messages exchanged successfully and server presenting TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and client also accepting the same cipher).

But when I try to use curl to access the same web resource, the curl command fails with following error :

curl: (35) schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed).

Similar exception is seen when a network traffic is captured using wireshark.

Question : How can I enforce 128 cipher for TLS communication for java based applications?

Answer 1

I am trying to enforce 128 bit ciphers for TLS communication

This is a weird objective, and you're doing it wrong.

Anything cipher with a key size that's less than 128 bits is obsolete and should not be used. For TLS, this means no DES. DES and RC4 are both obsolete and weak in TLS, for reasons that go beyond the key size, and should not be used.

I can't think of a reason to forbid keys that are larger than 128 bits. Symmetric ciphers with 128-bit keys are fine, and you might prefer them to larger key sizes, for performance. But why would you forbid talking to a client or server that only supports 256-bit keys?

DH keySize > 128, EC keySize > 128

DH and EC are not symmetric ciphers. They're asymmetric cryptographic mechanisms. There is no relation between sensible key sizes for different kinds of cryptographic mechanisms. 128-bit keys is ridiculously small for EC, DH and RSA. You can get an idea of sensible key sizes for common cryptographic mechanisms on https://www.keylength.com/; “factoring modulus” means RSA and “discrete logarithm” means DH. In practice, a “normal” key size for DH is 2048 bits, and a “normal” key size for ECC is 256 bits.

So assuming the snippet above means what it looks like it means (I'm not familiar with the java.security syntax), you're forbidding all sensible key sizes for EC or DH. I think most TLS implementations can't be made to work with ≤128-bit DH, and there are no standard curves with a ≤128-bit size. This only leaves cipher suites based on RSA encryption, which is itself deprecated. It's also possible that you get errors during the handshake because the TLS stack expects to be able to use ECC and DH, but then fails because they're unusable due to forbidding all usable key sizes.

---

To disable 256-bit ciphers, only disable cipher suites with _256 in their name. Do disable obsolete mechanisms as well: anything with EDE, NULL, RC4, anything without ECDHE or DHE… (This is not an exhaustive list.) Once again, I can't think of a good reason to do this.