0

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?

4
  • You ask how to enable it, but you've shown that you have. You ask how to enforce it, but you have shown that you have. So, your only problem is with curl not connecting? Have you checked to see what ciphers it can use?
    – schroeder
    Oct 27, 2021 at 9:40
  • I'm not sure I understand the issue. From what I understand you successfully connect your Java client to your Java server, but you fail to connect with curl to the server. So the problem is not about enforcing 128 bit from Java, but making curl also support the ciphers expected by the server. Apart from that: why do you want to limit the key to 128 bit in the first place? And the limits to DH and ECC key sizes are kind of dangerous - I think you don't understand what these really mean. Oct 27, 2021 at 9:41
  • But why though?
    – user163495
    Oct 27, 2021 at 14:59
  • Thanks for your response, the java application that interact with each other over tls are running on private network and are not publicly accessible/exposed. The only reason to use 128 bit ciphers is to gain cpu performance since the applications interact with each other very frequently and the tls operations consume large number of cpu cycles leaving less cpu for application threads.
    – User12345
    Oct 27, 2021 at 16:45

1 Answer 1

2

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.

2
  • Thanks for your response, the java application that interact with each other over tls are running on private network and are not publicly accessible/exposed. The only reason to use 128 bit ciphers is to gain cpu performance since the applications interact with each other very frequently and the tls operations consume large number of cpu cycles leaving less cpu for application threads.
    – User12345
    Oct 27, 2021 at 16:43
  • Don't you have the AES-NI on your CPUs? AES-256 has only %40 slower.
    – kelalaka
    Oct 27, 2021 at 19:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .