Java 6 ECDHE Cipher Suite Support

java ssl

15,091

Solution 1

The SSL/TLS implementation "JSSE" in Java 1.6 and later supports ECDHE suites IF there is an available (JCE) provider for needed ECC primitives. Java 1.6 OOTB does NOT include such an ECC provider, but you can add one. Java 7 and 8 do include SunECC provider.

This seems to be a hot topic today. See also https://security.stackexchange.com/questions/74270/which-forward-secrecy-cipher-suites-are-supported-for-tls1-0-protocols and https://superuser.com/questions/848698/testing-cipher-suite-using-openssl-for-tomcat-server-is-resulting-in-wrong-manne (which, suprisingly to me, was migrated from security).

Ristic's book undoubtedly means the v3 format ClientHello. There was a major format change between SSL2 and SSL3, and SSL2 ClientHello can't represent the data (particularly extensions) for ECC. All versions of TLS (to date) use the same format as SSL3, with (importantly) different contents. In the early oughties SSL clients often used SSL2 format ClientHello but with content allowing upgrade to SSL3 and even TLS1.0 in order to succeed against both/all servers, because many SSL2 were still in use.

Java 1.6 client circa 2006 was transitional -- by default it uses SSL2 format specifying versions up to TLS1.0, but if the server agrees to version SSL2 and not higher, the client aborts with an exception saying in effect "SSL2 is not secure". This is controlled by a pseudo-protocol string SSLv2Hello, so on Java 1.6 client you should .setEnabledProtocols to remove/exclude that.

Java 7 and 8 still implement SSLv2Hello but no longer enable it by default, so v3 format is used by default, or as long as you specify protocols to be (all) SSL3 or better. 7 and 8 also implement TLS1.1 and 1.2 which 6 did not, although only 8 enables them in client by default. You should only specify SSLv2Hello if you are connecting to way-old SSL2-only servers -- which of course you should try very hard not to do at all.

Solution 2

The answer that dave_thompson_085 provided is correct and helped me, but I would like to add some clarification. As he states, the available algorithms depend on the JCE provider. I have Sun/Oracle Java 6 release 45 on Centos 5.4, which has no support for ECDHE OOTB.

So I need to add an additional JCE provider and Bouncy Castle (bouncycastle.org) is one. Follow the instructions here https://www.bouncycastle.org/specifications.html#install This extends the support to e.g. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

An alternative is to use the sun.security.pkcs11.SunPKCS11 provider bundled with the Hotspot JRE. You need a ${java.home}/lib/security/nss.cfg with the following content:

name = NSS
nssDbMode = noDb
attributes = compatibility

This will utilize libnss3, which may provide the necessary algorithms through the native OS library. This has been verified on Ubuntu 12.04, but may also work in other distros. It does not work on Centos 5.4, since RH/Centos 5 is known to have limited Elliptic Curve support.

Solution 3

You need to turn on -Djavax.net.debug=all and see what's going on here, and provide sample code and logs.

In 1.6, SunJSSE supports TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider

So you should set your SSLContext with that as the enabled protocol. Look at http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLContext for details. You also need to swap your enabled protocols so that 1.2 is enabled and in the lead.

Also see

15,091

Author by

chashi

Updated on June 09, 2022

Comments

chashi almost 2 years

The Java Cryptography Architecture Standard Algorithm Name Documentation page for Java 6 lists ECDHE cipher suites. Thus I would expect they are supported in Java 6. Yet neither OOTB Java 6 nor the addition of the JCE Unlimited Strength policy files is enabling them.

The book Bulletproof SSL and TLS also indicates Java 6 supports ECDHE, with a caveat:

Enable and prioritize ECDHE suites on the server. Java 6 and 7 clients support these, and will happily use them. (But do note that with Java 6 you must switch to using the v3 handshake in order to utilize ECDHE suites at the client level.)

I'm assuming by v3 handshake he means SSLv3? I haven't tried it but even if this works, SSLv3 is not a viable option due to the POODLE vulnerability.

What am I missing?