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