Login/Register
ECDHE cipher suites not supported on OpenJDK 8 installed on EC2 Linux machine
Asked Answered
Solved jettyjava-8javajcejetty-9
A

4

18

When starting jetty-distribution-9.3.0.v20150612 with openjdk 1.8.0_51 running on an EC2 Amazon Linux machine, is prints that all configured ECDHE suites are not supported. 

2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA not supported

These are enabled in jetty/etc/jetty-ssl-context.xml -

<Set name="IncludeCipherSuites">
<Array type="java.lang.String">
 <!-- TLS 1.2 AEAD only (all are SHA-2 as well) -->
  <Item>TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256</Item>
  <Item>TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256</Item>
  <Item>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384</Item>
  <Item>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</Item>
  <Item>TLS_DHE_RSA_WITH_AES_256_GCM_SHA384</Item>
  <Item>TLS_DHE_RSA_WITH_AES_128_GCM_SHA256</Item>
...

I read Oracle Java 8 should support these protocols, but maybe that's not supported by OpenJDK? Or should I enable it somehow?

Update

Oracle's JCE cryptographic provider is installed under jre/lib/security/, but it didn't help.

Archimage answered 12/8, 2015 at 17:12 Comment(1)
installing Oracle's JCE cryptographic on an OpenJDK install has no effect as the ECDHE ciphers are implemented in native C code and are only shipped in the Oracle JDK (see armoredbarista.blogspot.co.uk/2013/10/…) – Carlstrom
F
17

So I'm running a similar setup, with an AWS box running openjdk-1.8.0.51. what solved it for me is to add bouncycastle as a provider like so:

  • Add the bcprov-<verion>.jar to /usr/lib/jvm/jre/lib/ext

  • Edit /usr/lib/jvm/jre/lib/security/java.security adding the following line to the list of providers: 

    security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider

(I added it as the 6th entry but you can add higher in the order if you prefer)

Restarted my application and was able to use EC-based cipher suites such as TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.

Furtherance answered 4/11, 2015 at 12:17 Comment(7)
You also need to remove 'EC, ECDHE, ECDH' from the jdk.tls.disabledAlgorithms definition in Ythat same java.security file in the current CentOS OpenJDK distributions, otherwise it still won't use those ciphers – Incapacious
Just want to confirm that installing the bouncycastle provider solved a similar problem for me. There are 2 provider jars available on the bouncycastle site: bcprov-jdk15on-<version>.jar and bcprov-ext-jdk15on-<version>.jar. Not sure what the difference is but I used the former and it worked fine. – Echinate
I am still not getting the EC algs after adding the BouncyCastle jar v1.55 in /usr/lib/jvm/jre/lib/ext and as @lenswipe suggested, removing 'EC, ECDHE, ECDH' from the jdk.tls.disabledAlgorithms. I am on OpenJDK 1.8.0_101 on RHEL7.2. BTW - I am not using Jetty - just building a custom Java app. The way I am testing for the availability of the algs is to call SSLServerSocket.getSupportedCipherSuites(). The returned list does not contain any EC ciphers. Any other things that might be blocking the EC algs? – Chlorella
To be clear, I also added the BC provider in the list, but position 9 in my case. – Chlorella
Ok - so I figured out my issue. @lenswipe was correct, but I "removed" EC, ECDHE, and ECDH incorrectly from the java.security file. This DOES NOT work: jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768, DES #, EC, ECDHE, ECDH – Chlorella
In other words, apparently using a hash sign '#' in java.security only works to comment things out when the hash is the first character on the line. – Chlorella
Be aware that BouncyCastle is a Pure Java implementation of cryptographic algorithms. They may not perform as well as native-implementations, especially when such native implementations are hardware-aware and can use e.g. hardware-accelerated AES (which is built-into all Intel chips after ~2010, AMD after ~2013, and others). You may find that using BC significantly reduces your performance. – Autoerotic
A
10

The root cause is that OpenJDK on CentOS/RHEL/Amazon Linux with OpenJDK on them simply do not ship with the required native libraries to support EC. The Unlimited Policy Files are a red herring, as are any attempts to un-disable various algorithms, etc. If the libraries aren't there, you can't use the features.

The accepted answer of "install Bouncy Castle" works because BC provides a pure-Java implementation of all the desired algorithms. Ideally, the JDK would provide native implementations which would yield higher performance.

It looks like OpenJDK on Amazon Linux will just have to wait. :(

Ref: http://armoredbarista.blogspot.de/2013/10/how-to-use-ecc-with-openjdk.html

Also: https://security.stackexchange.com/questions/117975/how-to-enable-ecdhe-in-openjdk-1-8-0-in-centos-6-7

UPDATE 2016-11-09

It seems that Oracle's Elliptic curve native library (libsunec.so) is licensed under the GPL. You can confirm this by going to Oracle's download page, clicking on Third Party Licenses, and checking the README for your version of Java.

This means that, if you can grab a copy of Oracle's JRE/JDK for the target platform and architecture, you can take the libsunec.so library from it and install it legally into the OpenJDK installation.

For me, that meant grabbing the file $JAVA_HOME/jre/lib/amd64/libsunec.so from an Oracle Java 8 JRE and dropping it into e.g. /usr/lib/jvm/jre-1.8.0/lib/amd64/. That is all that is required in order to enable Elliptic-Curve algorithms.

UPDATE 2018-03-08

Oracle Java 9 will include the "unlimited strength cryptography" libraries enabled by default, so that's nice. It looks like OpenJDK will still require you to set a system property to enable "unlimited strength cryptography".

Autoerotic answered 5/10, 2016 at 22:29 Comment(2)
Upgrading your instances to Amazon Linux 2016.09 AMIs or higher fixes the issue. These AMIs include openjdk 1.8.0_121 which ships libsunec.so by default. – Photocopier
@AlexGrigorovitch That is great news. I haven't verified this myself, but it looks like the Java world is finally moving past the stupid 1990s-era limited-strength cryptography rules and moving into the modern era. – Autoerotic
D
1

Try installing the JCE Unlimited Strength Jurisdiction Policy Files (these should help with your higher bit ciphers)

Also note, in the link you provided about java 8 cipher protocol support says

Cipher suites that use Elliptic Curve Cryptography (ECDSA, ECDH, ECDHE, ECDH_anon) require a JCE cryptographic provider ...

Did you install such a provider on your Java 8 VM?

Dinghy answered 12/8, 2015 at 18:53 Comment(3)
Yes, JARs replaced under jre-1.8.0-openjdk.x86_64/lib/security, server rebooted, but it still says "unsupported". I'm trying to figure out if it's an OpenJDK (running on EC2 Linux machine) issue. – Archimage
Installing Oracle JDK 1.8 with JCE cryptographic provider did make this work. So question is, how to enable this cryptology in OpenJDK? I'll remove Jetty from the question title. – Archimage
Just want to add this stack trace string to the post so that others might find this post when they search for the error. javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure – Carlstrom
C
-1
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA not supported
2015-08-12 16:51:20 main SslContextFactory [INFO] Cipher TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA not supported

Thes-e are enabled in jetty/etc/jetty-ssl-context.xm

Crunode answered 27/4, 2016 at 18:51 Comment(1)
Is this an attempt to answer the question? If so, please format it correctly. If not, and it's a question, it should be posted as a question (again with correct formatting). – Syriac

© 2022 - 2024 — McMap. All rights reserved.