Failing to use ECDSA cipher suites with version AsyncHttpClient v2.1.0

[pgc-13]

I have written a simple Java application, running on OpenJDK 1.8 on Mac OS X 10.9.5 and Redhat Linux (RHEL 6), to test AsyncHttpClient connectivity to my nginx based https enabled server. The server cert uses ECDSA.

For some strange reason, it works fine when I try with an old version of AsyncHttpClient (com.ning.async-http-client v1.9.31). Here's the example program:

    AsyncHttpClient asyncHttpClient = new AsyncHttpClient();
    ListenableFuture<Response> f =
            asyncHttpClient.prepareGet("https://myserver/foo").execute();
    Response r = f.get();
    logger.info("STATUS CODE: " + r.getStatusCode());
    System.exit(r.getStatusCode() == 200 ? 0 : 1);

And from the logs:

$ grep "Cipher Suites" ssltest-asynchttpclient-1.9.31.log
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]

However, when I upgrade to org.asynchttpclient.async-http-client v2.1.0-alpha1 (and use DefaultAsyncHttpClient instead of AsyncHttpClient), I get a much shorter list, which contains RSA suites only:

grep "Cipher Suites" ssltest-asynchttpclient-2.1.0.log
Cipher Suites: [TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA]

This fails with "javax.net.ssl.SSLException: Received fatal alert: handshake_failure", and on the server side (nginx error log), I see:

2016/10/26 14:03:00 [info] 30663#30663: *1 SSL_do_handshake() failed (SSL: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher) while SSL handshaking, client: X.X.X.X, server: 0.0.0.0:443

The same thing happens with Gatling, which depends on AsyncHttpClient, so I'm quite sure it's not a problem exclusive to my test application.

Any ideas what's going on?

Cheers
Henry

[slandelle]

Netty enforces a secured list of copier suites and they most likely consider yours as unsecured. Note the list was updated lately and change is not reflected in 2.1-alpha1.
Can't investigate atm. You have control over enabled cipher suites in config. Cf gatling.conf file too.

[pgc-13]

Thanks! I added the long list of suites from my 1.9.31 test log to gatling.conf (http/ahc/sslEnabledProtocols), which solved the problem!

[slandelle]

Then, I strongly advice you to investigate why you use a cipher suites that was identified by the Netty experts as unsecured. Gatling 2.2.3-SNAPSHOT uses by default their latest "safe" list.

[pgc-13]

Looks like the relevant cipher suites have been added to netty in a very recent commit (netty/netty@8ba5b5f), so that will eventually solve the problem for us without the config workaround.

[slandelle]

As I said, Gatling 2.2.3-SNAPSHOT already ships this change. And you claimed it didn't work by default either.

[pgc-13]

Yeah that's odd. I will have to look into that.

[slandelle]

So:

• 2.1.0-alpha1 doesn't work, as expected, as it was just a preview with upgraded Netty 4.1 for the Play! committers. It lags behind master and will be completely replaced when master will switch to Netty 4.1.
• AHC 2.0.19 works perfectly fine
• so does Gatling 2.2.3-SNAPSHOT, as it ships AHC 2.0.19. I guess you had an old snapshot.

[pgc-13]

For the records, I used 2.2.3-SNAPSHOT from the gatling repository (https://oss.sonatype.org/content/repositories/snapshots/io/gatling/highcharts/gatling-charts-highcharts-bundle/2.2.3-SNAPSHOT/), which is relatively speaking a bit old and uses ahc 2.0.9. Will try to find a newer snapshot release or build one myself.

Cheers

[slandelle]

It seems Travis has stopped deploying our snapshots, for whatever reason...

[slandelle]

The actual issue is that gatling-highcharts is no longer built downstream of gatling, so bundle isn't up-to-date.