3

I am running my JDK8 application in JDK11 enviroment. I am using TLSv1.2 and TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 cipher suite algorithm which i am suspecting that it is not supported or disabled in JDK11. There are list of ciphers which are supported by jvm please refer https://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html Also if you see here someone has listed cipher which is supported by jdk upto jdk1.8 https://developer.ibm.com/answers/questions/301898/where-i-can-find-list-of-cipher-suites-that-suppor/

but I want to know which cipher suite algorithm is supported/enabled/disabled in jdk11. I am using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 cipher algorithm but when i am trying to run my application in jdk 11 run time environment I am getting SSLHandshakeException(Getting javax.net.ssl.SSLHandshakeException in JDK11). That's why I am trying to change my cipher suite algorithm and for the same i want to know which algorithm I can use in JDK11 enviroment. It will be helpful if i also get to know the ciphers which are supported by both jdk11 and jdk8. Please help me with it.

Thanks.

Keshav Soni
  • 41
  • 1
  • 1
  • 6
  • 1
    If you have problems with a specific cipher suite name it! Just referring to `the cipher suite` is not helpful. – Robert May 24 '19 at 11:22
  • I have updated it my problem. Please have a look into it. – Keshav Soni May 29 '19 at 07:34
  • Java 11 does not support insecure cipher suites. Therefore you don't have to specify the cipher at all. Let the client and the server negotiate the cipher they want to use. – Robert May 29 '19 at 07:49
  • But how they will come to know it. Currently we are hadcoding this value. Also this algorithm we are using between two application for handshake, not with client and server. – Keshav Soni May 29 '19 at 08:02
  • Learn how TLS works. Client sends supported ciphers to server, server calculates intersection and selects one, server sends info on selected cipher to client. No need to specify anything besides the default configuration of Java. – Robert May 29 '19 at 08:06
  • Sounds bit rude. But Thanks :) I got you. – Keshav Soni May 29 '19 at 08:18
  • @Robert It's the business requirement to Hard-code this value. Please let me know any good cipher algorithm of jdk11. – Keshav Soni May 30 '19 at 06:16
  • 1
    Your business requirements are very uncommon. The common way was to black/whitelist a set of ciphers and assign them a priority on server side (prefer those with best security), but pinning them to one algorithm is a strange practice. – Robert May 30 '19 at 12:19

1 Answers1

6

For revised Q:

Your first link is to (Oracle, and thus OpenJDK) java 7 not 8; there are differences in TLS ciphersuite support between 7 and 8, although not affecting the ciphersuite you name. Your link for 'upto 1.8' is for IBM Java which uses different cryptoproviders and is not good documentation for Oracle/OpenJDK crypto. Note the question at that link is specifically "... Cipher suites that supported by IBM Java" -- NOT Oracle/OpenJDK Java. For Oracle/OpenJDK 8 see https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#ciphersuites and for 11 see https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-names.html#jsse-cipher-suite-names . Both include TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 and as expected it works for me in Oracle 11.0.2, and numerous versions of 8. All TLSv1.2 ciphersuites supported in 8 are still supported in 11, although 11 additionally supports TLSv1.3 (which you apparently aren't using).

Aside from the fact that, as commented, the Java defaults usually do better at providing security than overrides by people who don't know what they're doing, the exception you report in your other Q (but didn't provide here)

 javax.net.ssl.SSLHandshakeException: Invalid ECDH ServerKeyExchange signature

does not in any way indicate that the ciphersuite you name is unsupported. First, please be clear whether your application is the TLS client or server -- even if there is not a client/server relationship in the application protocol, there always is in the TLS protocol; that's how TLS (and SSL before it) is defined. Second, follow the standard instructions for SSL/TLS=JSSE debugging by running with system property javax.net.debug=ssl and show the resulting output (probably just the last 100 lines or so, because it's quite voluminous).

Original Q was much vaguer and appeared to be about RC4, but actually wasn't.

Your question text gives no clue what 'cipher suite algorithm' you mean, but you tagged RC4-cipher. If your issue is using (any of the) ciphersuites that include RC4 in TLS 1.2 or earlier, then you shouldn't. RC4 was prohibited for TLS by RFC7465 in Feb. 2015 because of rapid advances in cryptanalytic attacks on it. This applies to all versions of TLS protocol existing in 2015 (1.0, 1.1 and 1.2), and was implemented by all supported versions of Java: 8 from 8u60 up, and all releases of 9 and higher.

If you really want to use RC4 and risk attackers stealing your data -- perhaps it is actually false, meaningless, or otherwise valueless -- either change the setting in the java.security file or call Security.setProperty early in your program (before loading JSSE); see the JSSE Reference Guide e.g. for Java11. Note in j8 the file location is different, <JREhome>/lib/security/java.security. See also RC4 related issue after Java 8 update .

If and when you (want or need to) use TLS 1.3, which Java 11 and up supports, this is no longer an option. TLS 1.3 only supports AEAD ciphers (or modes), which RC4 as originally defined is not, and no proposal for an AEAD construct based on RC4 will be accepted today.

On the other hand if you just want to use good, secure ciphersuites, don't change anything and just use the defaults. The defaults are the defaults precisely because they are secure, at least as far as is currently known. If analytic advances change that, then the defauts will be changed accordingly, and your programs using them will also be secure without you having to make, test, distribute, and verify new releases.

Community
  • 1
  • 1
dave_thompson_085
  • 34,712
  • 6
  • 50
  • 70
  • I have edited my problem and elaborated it. Hope it's clear now. – Keshav Soni May 29 '19 at 07:30
  • Please let me know if you want anything further information from me. – Keshav Soni May 29 '19 at 07:30
  • It's the business requirement to Hard-code this value. Please let me know any good cipher algorithm of jdk11. – Keshav Soni May 30 '19 at 06:17
  • 1
    First to be clear, although TLS ciphersuites are often lazily called ciphers, they are not. Java11 has lots of fine cipher algorithms which have nothing to do with TLS. As far as ciphersuites _for TLS_, all of the default suites in Java11 are also fine. Having 'business' requirements on crypto details is likely to cause serious problems over time, but the particular ciphersuite you have now in this case is fine. – dave_thompson_085 May 31 '19 at 07:22