3

I am looking into documentation for JSSE ciphersuites in Java.

https://docs.oracle.com/en/java/javase/11/security/oracle-providers.html#GUID-7093246A-31A3-4304-AC5F-5FB6400405E2

enter image description here

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 is listed there 3 times and according to documentation for Java 8 is both enabled and not implemented.

TLS_ECDHE_RSA_WITH_RC4_128_SHA is listed there 2 times as both disabled and not implemented.

For more confusion older version of this document have yet different values for this ciphersuites for the same version of JDK (like disabled and enabled). Though I am guessing that some changes there are due to security updates.

https://docs.oracle.com/javase/10/security/oracle-providers.htm#JSSEC-GUID-9224B90B-7B2F-41F9-BB96-C0A1B6A0FEAA

I think this documentation is confusing. Have I found mistake in docs or I am missing something?

  • From how I read the footnotes, it seems to be because the cipher suite is available for one protocol version but not another. Then it's listed twice due to not being universally available – Natanael Feb 22 at 14:09
  • There are footnotes with protocol version but if it is added to JDK version there is no need to list twice cipher suite. Other than that TLS_ECDHE_RSA_WITH_RC4_128_SHA have no footnote. – Alameyo Feb 22 at 14:27
2

The duplicate lines must be an editting or perhaps text-generation glitch of some kind, because in that format the ciphersuite should be a unique key. There are also four lines for TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 -- all wrong!

You aren't specific, and I certainly see some other errors in the page you link, but differences about JSSE across different JDK versions could be correct. In particular:

Java 6 JSSE supported some suites using EC (Elliptic Curve) algorithms, though not the one you name, and they were even enabled in the sense of being in JSSE's 'enabledCiphers' list. But they were actually used in the protocol only if the JVM included a cryptoprovider with EC (including ECDH and ECDSA) primitives, as described in the note above table 4-11 on the page you link, and Sun-then-Oracle j6 did not include such a provider out of the box, but it could be added, and other builds could be different (which was a major point of the JCA design way back to its beginning).

Java 7 JSSE implemented TLS 1.1 and 1.2, which adds some additional suites including the one you name (since it uses AES-CBC and SHA384); by default it enabled these protocols (and thus this suite) only on server side not client side, but this could be overridden. Oracle j7 added an EC provider (SunEC) so that 'enabled' EC suites could actually be used; again other builds could differ. (RedHat OpenJDK in particular removed EC for several years.) However the free Oracle versions of j7 (like j6 and earlier) were subject to the 'limited crypto policy' restrictions originally created to satisfy arms export regulations in the 1990s, which primarily disabled all AES-256 suites by default; this could be fixed by downloading and installing the 'unlimited jurisdiction crypto policy' jars, about which you can find many stackexchange Qs dating from before 2018. The then-separate OpenJDK releases did not have the limited-crypto restrictions, and I believe some of the Oracle paid-support versions (after 7u80 in 2015) also changed this, but I don't pay for support.

Java 8 added some more TLS1.2 suites (using AES-GCM), and enabled TLS1.2 (and thus the SHA384 suite you name) on client by default. Starting with 8u151 in late 2017, it also removed the limited-crypto restriction so that AES-256 is enabled without an additional download.

Java 9 and 10 started out with TLS1.2 enabled and no limited-crypto, and did not make significant changes in this area TTBOMK. Java 11 adds TLS1.3, which radically changes the whole concept of ciphersuites; instead of specifying the whole range of keyexchange, server auth, cipher and MAC and PRF, they now specify only cipher-and-MAC (always combined because now only AEAD ciphers are allowed) and PRF.

RC4 used to be trusted, and suites using it enabled; for a while during BEAST in 2011 they were even recommended. But advances in cryptanalysis made them insecure and they were officially forbidden by rfc7465 in 2015. This just missed the last free release of Oracle j7 (7u80) but to my understanding later paid-support Oracle versions, and OpenJDK versions, did disable RC4. Java 8 (IINM both Oracle and OpenJDK) disabled it starting with 8u51, and 9 10 11 from their first releases.

Similarly SSLv3 was badly broken by POODLE in 2014, and thus disabled in 7 from 7u75, 8 from 8u31, and 9 10 11 from outset. (SSLv2 is not a security issue; the pseudoprotocol SSLv2Hello implemented by JSSE is not actual SSLv2 and JSSE has never implemented actual SSLv2. However, SSLv2Hello was a good idea only in the early 2000s when there were still v2 servers in the wild; nowadays it it is not needed and should not be used because it restricts features that use hello extensions like SNI and sigalgs, which are now more and more important.)

If there are any inconsistencies that does not explain, please feel free to ask a more specific question.

PS: note that Oracle 9 and 10 are officially no longer supported, because they were not designated 'long-term' under the new model and 11 has now been out for several months. And Oracle 8 similarly is now officially paid-support-only for commercial. But they still actually work, and of course the source is still available so open-source builds are not affected.

  • Thanks for response! Good that you spotted another cipher suite that repeats. So as I thought it is probably kind of copy/paste mistake in documentation? I have written to Oracle to clarify on this and maybe fix documentation if this is the case but still I am waiting for response. – Alameyo Feb 26 at 18:42

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.