Hello.

I am having a problem with establishing SSL connection between an Apache proxy and Nginx, connection fails during handshake with Alert 21 message.
Other clients have no problem connecting to Nginx, only proxy does.
I have tried to make sense of the tcpdump output but would appreciate your help in finding out why Nginx rejects the connection.

Nginx info:

nginx version: nginx/1.8.1
built with OpenSSL 1.0.1f 6 Jan 2014


Client Hello:

Secure Sockets Layer
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 91
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 87
Version: TLS 1.2 (0x0303)
Random
GMT Unix Time: Jul 28, 1975 11:49:59.000000000 CET
Random Bytes: 5803affbe1677147d908839b735d75f93cd7ba62030d8e8a...
Session ID Length: 0
Cipher Suites Length: 28
Cipher Suites (14 suites)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
Cipher Suite: TLS_FALLBACK_SCSV (0x5600)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Compression Methods Length: 1
Compression Methods (1 method)
Compression Method: null (0)
Extensions Length: 18
Extension: elliptic_curves
Type: elliptic_curves (0x000a)
Length: 8
Elliptic Curves Length: 6
Elliptic curves (3 curves)
Elliptic curve: secp256r1 (0x0017)
Elliptic curve: secp384r1 (0x0018)
Elliptic curve: secp521r1 (0x0019)
Extension: ec_point_formats
Type: ec_point_formats (0x000b)
Length: 2
EC point formats Length: 1
Elliptic curves point formats (1)



Server response:

Secure Sockets Layer
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Length: 2
Alert Message
Level: Fatal (2)
Description: Handshake Failure (40)


I have tested the issue with a default nginx configuration and with a specific set of ciphers but with no success.
Server is on a private network with no access to Internet and I control only the server with nginx.

Any help would be appreciated.

Also, the nginx log excerpt:

2016/04/30 14:36:55 [info] 25632#0: *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: y.y.y.y:443

Maybe this http://stackoverflow.com/questions/33806038/nginx-error-no-shared-cipher-but-there-are

---
nginx for Windows http://nginx-win.ecsds.eu/

Thanks for the suggestion.
Unfortunately, the issue persists.

According to tcpdump output and RFC (if I interpreted it correctly), the issue occurs because the client and the server cannot agree about communication algorithms, conversation does not even reach the certificate exchange stage.

"
https://tools.ietf.org/html/rfc5246#section-7.4.1.2

In the event that a client requests additional functionality using extensions, and this functionality is not supplied by the server, the client MAY abort the handshake. A server MUST accept ClientHello messages both with and without the extensions field, and (as for all other messages) it MUST check that the amount of data in the message precisely matches one of these formats; if not, then it MUST send a fatal "decode_error" alert.
"

"
https://tools.ietf.org/html/rfc5246#section-7.4.1.3

The server will send this message in response to a ClientHello message when it was able to find an acceptable set of algorithms. If it cannot find such a match, it will respond with a handshake failure alert.
"

Excerpt from a successful ServerHello on the same server (localhost request):

TLSv1.2 Record Layer: Handshake Protocol: Server Hello
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 94
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 90
Version: TLS 1.2 (0x0303)
Random
GMT Unix Time: Jan 29, 2038 13:50:53.000000000 CET
Random Bytes: a5c11896aed0b85c783524c7921518e9c6f6cb4f1f5ed28e...
Session ID Length: 32
Session ID: c949118cdcc40d69afd8675a7c6471b61b041a71d4fd3e8f...
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Compression Method: null (0)
Extensions Length: 18
Extension: renegotiation_info
Type: renegotiation_info (0xff01)
Length: 1
Renegotiation Info extension
Extension: ec_point_formats
Type: ec_point_formats (0x000b)
Length: 4
EC point formats Length: 3
Elliptic curves point formats (3)
Extension: Heartbeat
Type: Heartbeat (0x000f)
Length: 1
Mode: Peer allowed to send requests (1)


In regards to requirements sent by the proxy, openssl does not show an issue:

# openssl ciphers | grep -q ECDHE-RSA-AES256-GCM-SHA384; echo $?
0

# openssl ecparam -list_curves | grep -e secp256r1 -e secp384r1 -e secp521r1
secp384r1 : NIST/SECG curve over a 384 bit prime field
secp521r1 : NIST/SECG curve over a 521 bit prime field


Maybe I am overthinking this and there is a simple reason for failure in communication between the two servers but I just do not see it.