SSL hanshake failure

[slandelle]

Hi there,

Please consider this sample.

It always crashes when trying to connect to "https://netty.io".

Issue was originally reported against AHC, see AsyncHttpClient/async-http-client#1252.

It doesn't seem to be actually related to SNI, as the sample works fine against "https://github.com" that has SNI enabled too.

Am I missing something?

Regards

[slandelle]

Additional comment: issue doesn't happen with ACH1 that runs on Netty 3 instead of 4.0.

[normanmaurer]

Will check

[slandelle]

Thanks. I had a quick look at the ssl debug log, it looked like the engine wasn't getting fed enough bytes. Sadly, I won't be able to investigate myself for quite some time :(

[Scottmitch]

I think it may be a server issue. Your example is able to connect to other well known hosts without issue. Also openssl's s_client also detects an error:

$ openssl s_client -host netty.io -port 443 -tls1
CONNECTED(00000003)
139673537627792:error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:s3_pkt.c:1472:SSL alert number 80
139673537627792:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1474746497
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

[slandelle]

But I have no problem with Chrome, Firefox and curl.

[slandelle]

@Scottmitch Actually, you could be right. I forced SSLEngine to use the same cipher suite as curl, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and it worked.

[normanmaurer]

So can we close this one ?

On 24 Sep 2016, at 13:21, Stephane Landelle notifications@github.com wrote:

@Scottmitch https://github.com/Scottmitch Actually, you could be right. I forced SSLEngine to use the same cipher suite as curl, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and it worked.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub #5859 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AAa0QkcsI-xvEHuaZ0bBKt_KoyMk5r1Zks5qtYZagaJpZM4KFYo5.

[joymufeng]

@slandelle This issue is indeed caused by the servers of CloudFlare, because they only support the following Cipher Suites:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)   ECDH secp256r1 (eq. 3072 bits RSA)   FS  128
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)   ECDH secp256r1 (eq. 3072 bits RSA)   FS  128
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)   ECDH secp256r1 (eq. 3072 bits RSA)   FS 128
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)   ECDH secp256r1 (eq. 3072 bits RSA)   FS  256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)   ECDH secp256r1 (eq. 3072 bits RSA)   FS  256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)   ECDH secp256r1 (eq. 3072 bits RSA)   FS 256
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)   ECDH secp256r1 (eq. 3072 bits RSA)   FS    112
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)   ECDH secp256r1 (eq. 3072 bits RSA)   FS    256P
OLD_TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc14)   ECDH secp256r1 (eq. 3072 bits RSA)   FS    256P

This test result is reported by ssllabs.

[Scottmitch]

I will close for now @slandelle please re-open if you feel there is a Netty component to this issue.

[slandelle]

Honestly, it bugs me that Netty fails by default where other user-agents (tested with Chrome, FireFox and curl) succeed.
By default, JdkSslHandler only enables the following 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

CloudFlare supports none of them.

Is there a good reason for Netty to be more strict than the rest of the world when it comes to cipher suites, and in the end, not be compatible? Why is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 good enough for CloudFlare and not good enough for Netty?

[joymufeng]

@normanmaurer Is it possible for netty to support more cipher suites?

[Scottmitch]

AFAIK there is no reason why we can't add a few more cipher suites to the default set. It has been a while since we have re-visited this. Any objections to the following approach for starters:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

and removing (older cipher using 3des):

SSL_RSA_WITH_3DES_EDE_CBC_SHA

[Scottmitch]

Is it possible for netty to support more cipher suites?

Just to clarify @joymufeng you are free (and generally encouraged if your use case requires it) to specify your own list of ciphers via SslContextBuilder#cihpers(..).

[joymufeng]

@Scottmitch Great! Thanks for reminding!