0

Currently, we are having below cipher suites used in our platform.

AES128-GCM-SHA256

AES128-SHA256

AES128-SHA

ECDHE-RSA-AES128-GCM-SHA256

ECDHE-RSA-AES128-SHA256

ECDHE-RSA-AES128-SHA

Post security scan, team has asked us to block the below static cipher suites.

AES128-GCM-SHA256

AES128-SHA256

AES128-SHA

We've blocked above said cipher suites via underlying JDK (used by our app servers), by updating the tls.disabled algorithms section in java.security file.

This in turn is blocking the below ciphers too since above blocked cipher suites are used in the key exchange/MAC section of the below cipher suites.

ECDHE-RSA-AES128-GCM-SHA256

ECDHE-RSA-AES128-SHA256

ECDHE-RSA-AES128-SHA

Please advise if there is a way to block only the AES ones without blocking the ECDHE with AES.

migrated from crypto.stackexchange.com Mar 9 at 9:35

This question came from our site for software developers, mathematicians and others interested in cryptography.

3

You may not realize it, but the ciphersuites that OpenSSL for hysterical raisins labels with names that don't specify a key-exchange actually use RSA (aka plain-RSA) key-exchange. Those OpenSSL names (see man ciphers in section 1, or possibly 1ssl or similar, on your system or on the website) actually correspond to these standard names:

AES128-GCM-SHA256  TLS_RSA_WITH_AES_128_GCM_SHA256
AES128-SHA256      TLS_RSA_WITH_AES_128_CBC_SHA256
AES128-SHA         TLS_RSA_WITH_AES_128_CBC_SHA

The syntax for secprop jdk.tls.disabledAlgorithms only supports individual algorithms, not combinations, much less a complex combination like "RSA and not ECDHE". However, you can disable a TLS ciphersuite using the (full) name Java uses, which is the standard name as above. So just put those names as comma-separated entries in the secprop.

Note in TLS1.3 (implemented in Java 11) the ciphersuite no longer selects the key-exchange and authentication methods. However, 1.3 no longer supports non-PFS plain-RSA keyexchange at all, and since it appears that is what your 'team' is trying to avoid, the defaults for 1.3 should be good for you.

  • Hi Dave, Thanks for your response. I tried updating the java.tls.disabledAlogrithms section with AES_128_CBC and AES_128_GCM. This update has blocked all the 6 cipher suites mentioned in the question, since the ECDHE cipher suites in the question are also using the AES_128 as key exchange algorithm. But I am really looking for a way to block only the AES128 ciphering suites without disabling the ECDHE eventhough they are also using the same AES128 in key exchange section. We are using JDK 1.7 and TLS1.2. – chandu Mar 10 at 16:43
  • IHYM jdk.tls... not java. I didn't say AES_128_CBC; I said the full version of the standard (RFC) name for the suite, which is my right-hand column TLS_RSA_WITH_AES_128_GCM_SHA256 etc. AES128-GCM (or AES128-CBC) is not a keyexchange; it is the data/symmetric cipher and MAC. RSA and ECDHE_RSA are keyexchange-plus-authentication methods (in TLS below 1.3, kx and auth are linked). Are you using a paid or openjdk version of 7? The free Oracle versions of 7 (throuigh 7u80) didn't support GCM (in TLS), but 8+ does. (7 did support TLS1.2, and thus CBC+SHA2 suites.) – dave_thompson_085 Mar 11 at 1:09
  • Thanks Dave, This Really helped us. – chandu Mar 11 at 7:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.