Orange is my favorite color

As PCI DSS rules and general security best practices evolve, more people are configuring their web servers to eliminate less-secure versions of SSL and TLS for their HTTP connections. If you are using a Java or JVM-based application, this may manifest itself in a sudden inability to connect resulting in a fatal handshake_failure.

What this is telling you is that you were able to connect but your client and the remote server were unable to find a mutually acceptable encryption algorithm to communicate over so further communication was aborted.

An easy way to tell if this is your problem as a Java/JVM client is to use the Qualys SSL analyzer and see whether it reports a Java client can connect. In my case, I saw the following failures when I entered the SSL endpoint I wanted to access:

If you happen to be a ColdFusion user, you can add -Djavax.net.debug=ssl,handshake,verbose to your jvm.config, restart and make your HTTPS request and see the full list of ciphers being attempted and the ultimate failure in your log file. My logs with the handshake_failure can be seen in this gist for comparison.

Fix with Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files

The fix is easy to implement but not easy to find. I experienced this with Oracle’s JVM and not the OpenJDK so other JVM implementations may behave differently. In the case of Oracle’s JVM, strong encryption is disabled out of the box for export reasons so the JVM can not use an encryption algorithm stronger than 128-bit. Many web servers are now disabling 128-bit SSL in favor of 256-bit and 384-bit encryption algorithms so the fix is to turn these on in your JVM.

  1. Download the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files from Oracle (this link is for Java 1.8, Google for alternative JVM versions): http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
  2. Extract the two JAR files into your jre/lib/security folder overwriting the US_export_policy.jar and local_policy.jar.
  3. Restart the JVM

You should now be able to connect to the remote server. If you’re still unable to connect, try enabling debugging and see which ciphers are attempted/ignored. The remote server may have an exotic configuration that requires you to contact them but the unlimited strength jurisdiction policy files should fix handshake_failure issues.

1 Comment

  1. James Moberg said:

    on January 30, 2017 at 10:06 am

    If using Windows, another option that I prefer regardless of ColdFusion version is CFX_HTTP5. It uses WinHttp 5.1 API, the native Windows HTTP layer, and all SSL certificates are automatically updated with Windows and no restarting is necessary. I also like it because I can force TLS1.2 connections without having to completely disable TLS1.1. (PayPal was going to start requiring TLS1.2 for all HTTPS connections and CF10 couldn’t connect.)

    NOTE: You can also use CURL to override “lowest common denominator SSL” and force an elevated TLS1.2 handshake.

{ RSS feed for comments on this post}