[Scala-2.3.2] WS to AWS CloudFront with HTTPS + SNI => SSL handshake_failure

[Jxtps]

I'm trying to run a couple of websites with AWS CloudFront whole site delivery and SSL. The sites make WS requests between each other. I can access them using all the major browsers without any problems, and "curl https://example.com" works without any issues.

However, the WS requests fail, with "javax.net.ssl.SSLException: Received fatal alert: handshake_failure". The code to issue the request (with the java.net.debug=all output below):

    WS.url("https://example.com").withVirtualHost("example.com").get().map(response => {
      Logger.info("Response: " + response.body.take(100))
    }).onComplete {
      case Failure(t) => Logger.info("Failed!", t)
      case a => Logger.info("Completed: " + a)
    }

Since curl & browsers work, and CloudFront uses Server Name Indication, I suspect it has something to do with that!? I tried adding "withVirtualHost" as you can see above, but to no avail (doesn't work without either).

How can I set the SNI used when making WS requests?

I've read through both http://www.playframework.com/documentation/2.3.x/WsSSL and http://www.playframework.com/documentation/2.3.x/ScalaWS and have read the source code, but have been unable to find how to enable that option - it seems to only have been made available Java 1.7, and since Play supports Java 1.6 maybe it was left out?

Also, "new URL("https://example.com").openStream()" successfully connects and can read the response, so "regular java 7" can clearly do it.

Thanks!

------ Dump of the handshake error -----

Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 for TLSv1.1
%% No cached client session
*** ClientHello, TLSv1.2
RandomCookie:  GMT: 1390607319 bytes = { 89, 214, 97, 202, 101, 254, 106, 176, 6, 73, 147, 164, 133, 96, 33, 4, 88, 103, 9, 118, 242, 241, 10, 211, 6, 174, 125, 238 }
Session ID:  {}
Cipher Suites: [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_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, 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, SSL_RSA_WITH_RC4_128_MD5, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods:  { 0 }
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA224withECDSA, SHA224withRSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA, MD5withRSA
***
[write] MD5 and SHA1 hashes:  len = 207
0000: 01 00 00 CB 03 03 53 E3   FC D7 59 D6 61 CA 65 FE  ......S...Y.a.e.
0010: 6A B0 06 49 93 A4 85 60   21 04 58 67 09 76 F2 F1  j..I...`!.Xg.v..
0020: 0A D3 06 AE 7D EE 00 00   46 C0 23 C0 27 00 3C C0  ........F.#.'.<.
0030: 25 C0 29 00 67 00 40 C0   09 C0 13 00 2F C0 04 C0  %.).g.@...../...
0040: 0E 00 33 00 32 C0 07 C0   11 00 05 C0 02 C0 0C C0  ..3.2...........
0050: 2B C0 2F 00 9C C0 2D C0   31 00 9E 00 A2 C0 08 C0  +./...-.1.......
0060: 12 00 0A C0 03 C0 0D 00   16 00 13 00 04 00 FF 01  ................
0070: 00 00 5C 00 0A 00 34 00   32 00 17 00 01 00 03 00  ..\...4.2.......
0080: 13 00 15 00 06 00 07 00   09 00 0A 00 18 00 0B 00  ................
0090: 0C 00 19 00 0D 00 0E 00   0F 00 10 00 11 00 02 00  ................
00A0: 12 00 04 00 05 00 14 00   08 00 16 00 0B 00 02 01  ................
00B0: 00 00 0D 00 1A 00 18 06   03 06 01 05 03 05 01 04  ................
00C0: 03 04 01 03 03 03 01 02   03 02 01 02 02 01 01     ...............
New I/O worker #18, WRITE: TLSv1.2 Handshake, length = 207
[Raw write]: length = 212
0000: 16 03 03 00 CF 01 00 00   CB 03 03 53 E3 FC D7 59  ...........S...Y
0010: D6 61 CA 65 FE 6A B0 06   49 93 A4 85 60 21 04 58  .a.e.j..I...`!.X
0020: 67 09 76 F2 F1 0A D3 06   AE 7D EE 00 00 46 C0 23  g.v..........F.#
0030: C0 27 00 3C C0 25 C0 29   00 67 00 40 C0 09 C0 13  .'.<.%.).g.@....
0040: 00 2F C0 04 C0 0E 00 33   00 32 C0 07 C0 11 00 05  ./.....3.2......
0050: C0 02 C0 0C C0 2B C0 2F   00 9C C0 2D C0 31 00 9E  .....+./...-.1..
0060: 00 A2 C0 08 C0 12 00 0A   C0 03 C0 0D 00 16 00 13  ................
0070: 00 04 00 FF 01 00 00 5C   00 0A 00 34 00 32 00 17  .......\...4.2..
0080: 00 01 00 03 00 13 00 15   00 06 00 07 00 09 00 0A  ................
0090: 00 18 00 0B 00 0C 00 19   00 0D 00 0E 00 0F 00 10  ................
00A0: 00 11 00 02 00 12 00 04   00 05 00 14 00 08 00 16  ................
00B0: 00 0B 00 02 01 00 00 0D   00 1A 00 18 06 03 06 01  ................
00C0: 05 03 05 01 04 03 04 01   03 03 03 01 02 03 02 01  ................
00D0: 02 02 01 01                                        ....
[Raw read]: length = 5
0000: 15 03 03 00 02                                     .....
[Raw read]: length = 2
0000: 02 28                                              .(
New I/O worker #18, READ: TLSv1.2 Alert, length = 2
New I/O worker #18, RECV TLSv1.2 ALERT:  fatal, handshake_failure
New I/O worker #18, fatal: engine already closed.  Rethrowing javax.net.ssl.SSLException: Received fatal alert: handshake_failure
New I/O worker #18, fatal: engine already closed.  Rethrowing javax.net.ssl.SSLException: Received fatal alert: handshake_failure
New I/O worker #18, called closeOutbound()
New I/O worker #18, closeOutboundInternal()
New I/O worker #18, SEND TLSv1.2 ALERT:  warning, description = close_notify
New I/O worker #18, WRITE: TLSv1.2 Alert, length = 2
New I/O worker #18, called closeInbound()
New I/O worker #18, fatal: engine already closed.  Rethrowing javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
[Raw write]: length = 7
0000: 15 03 03 00 02 01 00                               .......
New I/O worker #18, called closeOutbound()
New I/O worker #18, closeOutboundInternal()
INFO application - Failed!
java.net.ConnectException: Received fatal alert: handshake_failure to https://example.com/
 at com.ning.http.client.providers.netty.NettyConnectListener.operationComplete(NettyConnectListener.java:103) ~[async-http-client-1.8.8.jar:na]
 at org.jboss.netty.channel.DefaultChannelFuture.notifyListener(DefaultChannelFuture.java:427) ~[netty-3.9.2.Final.jar:na]
 at org.jboss.netty.channel.DefaultChannelFuture.notifyListeners(DefaultChannelFuture.java:413) ~[netty-3.9.2.Final.jar:na]
 at org.jboss.netty.channel.DefaultChannelFuture.setFailure(DefaultChannelFuture.java:380) ~[netty-3.9.2.Final.jar:na]
 at org.jboss.netty.handler.ssl.SslHandler.setHandshakeFailure(SslHandler.java:1566) ~[netty-3.9.2.Final.jar:na]
Caused by: javax.net.ssl.SSLException: Received fatal alert: handshake_failure
 at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) ~[na:1.8.0_05]
 at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1646) ~[na:1.8.0_05]
 at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1614) ~[na:1.8.0_05]
 at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1780) ~[na:1.8.0_05]
 at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:1075) ~[na:1.8.0_05]

[Jxtps]

This seems like the same issue as: http://stackoverflow.com/questions/24428727/connection-reset-by-peer-with-async-http-client-and-netty

Unfortunately the JDKAsyncHttpProvider mentioned as working in that post doesn't actually appear to work with Ning 1.8.8 (the Play 2.3.2 default).

@wsargent seems to be working on it: https://github.com/AsyncHttpClient/async-http-client/issues/513

Upgrading to "com.ning" % "async-http-client" % "1.9.0-BETA6" resolves the issue (but may introduce others).

[Jxtps]

Unfortunately "com.ning" % "async-http-client" % "1.9.0-BETA6" breaks play.api.libs.ws.ning.NingAsyncHttpClientConfigBuilder as there were interface changes (I was using AsyncHttpClient directly when testing).  

[Will Sargent]

I think for now, your best option is to upgrade to async-http-client 1.9-BETA -- the patch is already in, it's not just officially released yet.

Will Sargent

Consultant, Professional Services

Typesafe, the company behind Play Framework, Akka and Scala

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Will Sargent]

That shouldn't be fatal -- you can create your own AsyncHttpClientConfig and pass it into the NingWSClient.

Will Sargent

Consultant, Professional Services

Typesafe, the company behind Play Framework, Akka and Scala

On Fri, Aug 8, 2014 at 10:47 AM, Jxtps <jxtp...@gmail.com> wrote:

Unfortunately "com.ning" % "async-http-client" % "1.9.0-BETA6" breaks play.api.libs.ws.ning.NingAsyncHttpClientConfigBuilder as there were interface changes (I was using AsyncHttpClient directly when testing).  

--

[Raul Piaggio]

Hi Will, I am running into the same issue with Play 2.3.4.

Could you help me with the client code to use async-http-client 1.9-BETA
and create my own AsyncHttpClientConfig (and pass it to NingWSClient)?

I just do WS.url(...).get.map(...)

Thank you.

[Jxtps]

I have logged issue #3894 for this: https://github.com/playframework/playframework/issues/3894

(2.4 doesn't have the 1.9.x library. Yet)

[Matija Novak]

Hi,

has anyone figured out a smooth workaround for play 2.3.x?

Regards

[Angelo H]

Anyone has figured a solution for Play 2.3.x? Same ask.

[Will Sargent]

There is an SNI example in the Play TLS example on the downloads page.

-- 
Will Sargent

--
You received this message because you are subscribed to the Google Groups "Play Framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/81183087-0d64-41fc-acf9-99b0d9796ec4%40googlegroups.com.

[Angelo H]

Do you mean this https://github.com/playframework/play-scala-tls-example? I don't see a SNI example?

[Angelo H]

We have a play 2.3 application that needs connects to a HTTPS SNI enabled API server. I hope this is clear.

[Angelo H]

We have a play 2.3 application that needs connects to a HTTPS SNI enabled API server and we are running on Java 8. I hope this is clear.

[Will Sargent]

https://github.com/playframework/play-scala-tls-example/blob/2.5.x/app/https/SniKeyManager.scala

-- 
Will Sargent

To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/e236694d-a9ac-448c-a227-461ddfa83fc3%40googlegroups.com.

[Angelo H]

Is this for Play 2.5? We are using Play 2.3 though. Also, we are looking for client solution not server solution.

[Will Sargent]

The underlying library doesn't support it in 2.3.x:

https://github.com/playframework/playframework/issues/3894

Your best option is to use the standalone client, which is going to GA real soon now:

https://github.com/playframework/play-ws

--

Will Sargent

Engineer, Lightbend, Inc.

will.s...@lightbend.com

To unsubscribe from this group and stop receiving emails from it, send an email to play-framework+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/4c539178-9002-4574-838f-9c6c6fe436e4%40googlegroups.com.