SSL handshake failure: no cipher suites in common

[io.akk...@io7m.com]

'Lo.

It seems that I'm receiving strange handshake failures when attempting
to send a message to a remote actor over TLS. The following program
shows the available ciphers on my system:

--8<--

import javax.net.ssl.SSLSocketFactory
import javax.net.ssl.SSLSocket

object ListCiphers {
def main(args : Array[String]) : Unit = {
val sf = SSLSocketFactory.getDefault()
val so = sf.createSocket().asInstanceOf[SSLSocket]
so.getEnabledCipherSuites().foreach(System.out.println)
}
}

--8<--

Which prints:

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_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_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

I'm currently using TLS_RSA_WITH_AES_256_CBC_SHA but get the same error
with (apparently) any cipher.

The code is here:

https://github.com/io7m/akkatest-20130317/tree/ssl-test

The relevant output from the server when a client attempts to connect:

--8<--

[DEBUG] [03/17/2013 19:37:43.986] [New I/O server boss #1 ([id: 0x1c68a70f, /127.0.0.1:9000])] [NettyRemoteTransport(akka://test-...@127.0.0.1:9000)] Using server SSL context to create SSLEngine ...
Using SSLEngineImpl.
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
New I/O worker #5, READ: TLSv1 Handshake, length = 52
*** ClientHello, TLSv1
RandomCookie: GMT: 1363548807 bytes = { 16, 212, 35, 99, 147, 137, 244, 6, 84, 150, 202, 231, 67, 133, 76, 77, 114, 200, 34, 233, 93, 163, 141, 86, 143, 62, 246, 204 }
Session ID: {}
Cipher Suites: [TLS_RSA_WITH_AES_256_CBC_SHA]
Compression Methods: { 0 }
Extension renegotiation_info, renegotiated_connection: <empty>
***
%% Initialized: [Session-1, SSL_NULL_WITH_NULL_NULL]
New I/O worker #5, fatal error: 40: no cipher suites in common
javax.net.ssl.SSLHandshakeException: no cipher suites in common
%% Invalidated: [Session-1, SSL_NULL_WITH_NULL_NULL]
New I/O worker #5, SEND TLSv1 ALERT: fatal, description = handshake_failure
New I/O worker #5, WRITE: TLSv1 Alert, length = 2
New I/O worker #5, fatal: engine already closed. Rethrowing javax.net.ssl.SSLHandshakeException: no cipher suites in common
New I/O worker #5, called closeOutbound()
New I/O worker #5, closeOutboundInternal()
New I/O worker #5, called closeInbound()
New I/O worker #5, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
[ERROR] [03/17/2013 19:37:44.138] [test-server-9] [NettyRemoteTransport(akka://test-...@127.0.0.1:9000)] RemoteServerError@akka://test-...@127.0.0.1:9000] Error[javax.net.ssl.SSLHandshakeException: no cipher suites in common]
New I/O worker #5, called closeOutbound()
New I/O worker #5, closeOutboundInternal()

--8<--

The full output from both the client and server are (including the
expanded configuration):

http://waste.io7m.com/2013/03/17/ssl-server-out.txt
http://waste.io7m.com/2013/03/17/ssl-client-out.txt

This is on Akka 2.1.2, on:

java version "1.7.0_17"
OpenJDK Runtime Environment (IcedTea7 2.3.8) (ArchLinux build 7.u17_2.3.8-1-x86_64)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)

M

[√iktor Ҡlang]

Sounds like a JSSE related problem, does any of these help?

http://stackoverflow.com/questions/9548807/sslhandshakeexception-no-cipher-suites-in-common

http://nickfenwick.com/blog/2012/04/18/using-ssl-keys-and-certifications-from-httpd-in-jetty/

Cheers,

√

--
>>>>>>>>>>      Read the docs: http://akka.io/docs/
>>>>>>>>>>      Check the FAQ: http://akka.io/faq/
>>>>>>>>>>      Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

--

Viktor Klang
Director of Engineering

Typesafe

Twitter: @viktorklang

[io.akk...@io7m.com]

On Sun, 17 Mar 2013 23:01:33 +0100
√iktor Ҡlang <viktor...@gmail.com> wrote:

> Sounds like a JSSE related problem, does any of these help?
>
> http://stackoverflow.com/questions/9548807/sslhandshakeexception-no-cipher-suites-in-common
> http://nickfenwick.com/blog/2012/04/18/using-ssl-keys-and-certifications-from-httpd-in-jetty/

Unfortunately not.

The key/trust stores and the script used to create them are actually
included in that github repos, and you can see that the certificates are
exported and then imported into the trust stores for the server and
client:

https://github.com/io7m/akkatest-20130317/blob/ssl-test/tls/setup.sh

The commands executed seem to be correct.

One thing I have just noticed in the server output... It says:

trustStore is: /usr/lib/jvm/java-7-openjdk/jre/lib/security/cacerts
trustStore type is : jks
trustStore provider is :
init truststore

It then goes on to list the default CAs that come with the JDK, and
there doesn't seem to be any mention of the client's certificate.
Should it not be using the trust store that I've specified with
akka.remote.netty.ssl.trust-store?

M

[io.akk...@io7m.com]

On Sun, 17 Mar 2013 22:42:16 +0000
<io.akk...@io7m.com> wrote:
> One thing I have just noticed in the server output... It says:
>
> trustStore is: /usr/lib/jvm/java-7-openjdk/jre/lib/security/cacerts
> trustStore type is : jks
> trustStore provider is :
> init truststore
>
> It then goes on to list the default CAs that come with the JDK, and
> there doesn't seem to be any mention of the client's certificate.
> Should it not be using the trust store that I've specified with
> akka.remote.netty.ssl.trust-store?

Yes, as far as I can tell, akka is completely ignoring the trust store
given in "akka.remote.netty.ssl.trust-store" on the server side. For
some reason, it only uses the system-wide java truststore.

Can someone please verify this? It would seem to be a bug.

M

[√iktor Ҡlang]

Agreed, please open a ticket.

Thanks,

√

M

--
>>>>>>>>>>      Read the docs: http://akka.io/docs/
>>>>>>>>>>      Check the FAQ: http://akka.io/faq/
>>>>>>>>>>      Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[io.akk...@io7m.com]

On Tue, 19 Mar 2013 16:05:41 +0100
√iktor Ҡlang <viktor...@gmail.com> wrote:
> Agreed, please open a ticket.

Thanks.

https://www.assembla.com/spaces/akka/tickets/3161-ssl-truststores-ignored-on-server-side

M

[√iktor Ҡlang]

Cool, thanks

M

--
>>>>>>>>>>      Read the docs: http://akka.io/docs/
>>>>>>>>>>      Check the FAQ: http://akka.io/faq/
>>>>>>>>>>      Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[io.akk...@io7m.com]

So, I've been trying for about a week to get actors to talk to each
other over SSL. Initially, the problem appeared to be that Akka was
failing to read the given truststore on the server side, which was
fixed in a wip branch (thanks!):

https://www.assembla.com/spaces/akka/tickets/3161

However, even with this fix, I'm still unable to get akka actors to
communicate. The result is always the same:

RemoteServerError@akka://test-...@127.0.0.1:9000]
Error[javax.net.ssl.SSLHandshakeException: no cipher suites in common]

A full log of the akka client connecting to the akka server:

http://waste.io7m.com/2013/03/22/logs-20130322-143300/Client-to-Server-server.txt
http://waste.io7m.com/2013/03/22/logs-20130322-143300/Client-to-Server-client.txt

I've been trying to eliminate possibilities to find the root of the
problem.

Initially, I tried to eliminate problems on the client by connecting to
the "server" system with the openssl s_client command line tool. This
required exporting the private key from the java client's keystore, and
then running:

openssl s_client -pause -msg -debug -key tls/client/key.pem -connect
127.0.0.1:9000

https://github.com/io7m/akkatest-20130317/blob/ssl-test-fix/test-s_client.sh

However, this fails with the following output:

http://waste.io7m.com/2013/03/22/logs-20130322-143300/test-s_client-to-Server-server.txt
http://waste.io7m.com/2013/03/22/logs-20130322-143300/test-s_client-to-Server-client.txt

Note the immediate handshake failure on ClientHello.

A quick bit of research online turns up TLS_RSA_WITH_AES_128_CBC_SHA as
the only mandatory cipher suite in TLSv1.2, and both sides do support
that.

Next, I wrote a trivial "SimpleServer" program that doesn't use akka,
and simply opens an ordinary SSL server socket, reads one byte from any
connected client, and then exits.

https://github.com/io7m/akkatest-20130317/blob/ssl-test-fix/src/main/scala/com/io7m/test/SimpleServer.scala
https://github.com/io7m/akkatest-20130317/blob/ssl-test-fix/src/main/java/com/io7m/test/SSLUtils.java

Running the program, and then connecting to it with the openssl client
command line (using the same key/trust stores as the akka
server/client) works correctly:

http://waste.io7m.com/2013/03/22/logs-20130322-143300/test-s_client-to-SimpleServer-server.txt
http://waste.io7m.com/2013/03/22/logs-20130322-143300/test-s_client-to-SimpleServer-client.txt

So, the key/trust stores don't appear to be at fault. Presumably the
problem is in Akka, in either the client or server side SSL code.

Let's have the akka "client" connect to the SimpleServer:

http://waste.io7m.com/2013/03/22/logs-20130322-143300/Client-to-SimpleServer-client.txt
http://waste.io7m.com/2013/03/22/logs-20130322-143300/Client-to-SimpleServer-server.txt

Nope. Once more, the handshake immediately fails on ClientHello.

So... As far as I can tell, something is broken on both the client
and server side with the Akka code. I've tried commenting out
akka.remote.netty.ssl.protocol and
akka.remote.netty.ssl.enabled-algorithms in order to allow both
sides to negotiate these on their own. No change. I've tried forcing
TLS versions and known-good ciphers with the config file. No change.
I'm out of ideas!

All of the code, scripts, and key/trust stores are available in this
branch of the repository:

https://github.com/io7m/akkatest-20130317/tree/ssl-test-fix

It's obviously necessary to use the version of akka from the WIP
branch mentioned in the ticket on assembla:

https://github.com/akka/akka/tree/wip-3161-use-truststore-on-server-too-%E2%88%9A

Any ideas?

M

[Roland Kuhn]

Hi M,

the reason for the SSLEngine’s complaint is that you enabled only the RSA cipher, but your certificate uses DSA keys.

Another thing I noticed: you have set akka.actor.serialize-message=on, but the closest existing setting is “serialize-messages” (which is purely for testing serializability of your own messages and not to be used in production).

Regards,

Roland

> --
>>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

Dr. Roland Kuhn
Akka Tech Lead
Typesafe – Empowering professional developers to build amazing apps.
twitter: @rolandkuhn

[io.akk...@io7m.com]

'Lo.

On Fri, 22 Mar 2013 16:56:15 +0100
Roland Kuhn <goo...@rkuhn.info> wrote:

> Hi M,
>
> the reason for the SSLEngine’s complaint is that you enabled only the
> RSA cipher, but your certificate uses DSA keys.

AH!

Interesting, thank you!

After a bit of trial and error, it seems that both sides will agree to
work with TLS_DHE_DSS_WITH_AES_256_CBC_SHA with these keys. I guess I'll
need to make sure I'm using RSA keys in future (given the lack of
mandatory cipher suites that can work with DSA in TLS 1.2).

> Another thing I noticed: you have set
> akka.actor.serialize-message=on, but the closest existing setting is
> “serialize-messages” (which is purely for testing serializability of
> your own messages and not to be used in production).

Yep, managed to chop off the 's' when I was putting together this
example - nice catch.

Thanks again.
M

[Roland Kuhn]

Great that it works! And on the way we fixed one issue, happy hAkking!