Problem with cipher suite ECDHE-ECDSA-AES256-SHA384

Discussion:

(too old to reply)

Karel Sedláček

2012-11-09 14:34:35 UTC

This problem is related to an issue I have been experiencing with a
piece of bespoke software I am writing that uses OpenSSL to terminate
SSL/TLS connections, using non-blocking I/O.

Observations:
- My server's TLS handshake for cipher ECDHE-ECDSA-AES256-GCM-SHA384 fails.
- If I use ALL for my server cipher list and specify no cipher list
for `openssl s_client`, `openssl s_client` successfully negotiates
ECDH-ECDSA-AES256-SHA.
- `openssl s_client` is able to successfully negotiate
ECDHE-ECDSA-AES256-GCM-SHA384 with `openssl s_server` and the same
certificate, key, and CAfile.

Attached are outputs from `openssl s_client` as follows:
- debug.bad_handshake: connecting to my server with `openssl s_client
-debug -key key/cli.key.pem -cert key/cli.crt.pem -CAfile
key/trust.pem -cipher ECDHE-ECDSA-AES256-GCM-SHA384 -connect
127.0.0.1:4433`
- debug.good_handshake: connecting to my server with cipher list ALL
on server and `openssl s_client -debug -key key/cli.key.pem -cert
key/cli.crt.pem -CAfile key/trust.pem -connect 127.0.0.1:4433`
- debug.s_server_handshake:
- server: `openssl s_server -debug -nbio -key key/key.pem -cert
key/cert.pem -CAfile key/trust.pem -cipher
ECDHE-ECDSA-AES256-GCM-SHA384`
- client: `openssl s_client -debug -key key/cli.key.pem -cert
key/cli.crt.pem -CAfile key/trust.pem -cipher
ECDHE-ECDSA-AES256-GCM-SHA384 -connect 127.0.0.1:4433`

On the server side I get a dirty failure mode from SSL_get_error(),
when using ECDHE-ECDSA-AES256-GCM-SHA384.

k

Dr. Stephen Henson

2012-11-09 16:32:08 UTC

Permalink

Post by Karel SedlÃ¡Äek
This problem is related to an issue I have been experiencing with a
piece of bespoke software I am writing that uses OpenSSL to terminate
SSL/TLS connections, using non-blocking I/O.
- My server's TLS handshake for cipher ECDHE-ECDSA-AES256-GCM-SHA384 fails.
- If I use ALL for my server cipher list and specify no cipher list
for `openssl s_client`, `openssl s_client` successfully negotiates
ECDH-ECDSA-AES256-SHA.

Have you set up appropriate ECDH temporary key parameters in the server ? If no
ECDH temporary parameters are set up then ECDHE ciphersuites are disabled by
the server.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org

Karel Sedláček

2012-11-09 16:38:06 UTC

Permalink

I have; following is the relevant snippet:

int nid = OBJ_sn2nid(ECDHE_CURVE);
if (NID_undef == nid)
goto err_obj_sn2nid;

EC_KEY *ecdh = EC_KEY_new_by_curve_name(nid);
if (NULL == ecdh)
goto err_ec_key_new;

SSL_CTX_set_tmp_ecdh(tls_ctx, ecdh);

Post by Dr. Stephen Henson

Have you set up appropriate ECDH temporary key parameters in the server ? If no
ECDH temporary parameters are set up then ECDHE ciphersuites are disabled by
the server.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org

Dr. Stephen Henson

2012-11-09 17:07:21 UTC

Permalink

Post by Karel SedlÃ¡Äek
int nid = OBJ_sn2nid(ECDHE_CURVE);
if (NID_undef == nid)
goto err_obj_sn2nid;
EC_KEY *ecdh = EC_KEY_new_by_curve_name(nid);
if (NULL == ecdh)
goto err_ec_key_new;
SSL_CTX_set_tmp_ecdh(tls_ctx, ecdh);

That should be OK as long as you're using a standard curve like P-256
(NID_X9_62_prime256v1) or P-384 (NID_secp384r1).

Do you get any errors server side? Do you get any alerts visible when you add
the -state option to s_client? Something like no shared cipher would be
expected if the server had (for some reason) decided ECDHE was not usable.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org

Karel Sedláček

2012-11-09 17:41:46 UTC

Permalink

I was using secp521r1, but secp384r1 has the same behavior. Here is
the output with -state:

CONNECTED(00000003)
SSL_connect:before/connect initialization
write to 0x7fe008426dd0 [0x7fe008810800] (165 bytes => 165 (0xA5))
0000 - 16 03 01 00 a0 01 00 00-9c 03 03 50 9d 3f 85 bf ...........P.?..
0010 - f8 e2 cf 63 c0 12 15 ee-4c ab 95 c5 4a 71 31 31 ...c....L...Jq11
0020 - 4e f5 c3 42 aa 38 be 33-7c bb 27 00 00 04 c0 2c N..B.8.3|.'....,
0030 - 00 ff 01 00 00 6f 00 0b-00 04 03 00 01 02 00 0a .....o..........
0040 - 00 34 00 32 00 0e 00 0d-00 19 00 0b 00 0c 00 18 .4.2............
0050 - 00 09 00 0a 00 16 00 17-00 08 00 06 00 07 00 14 ................
0060 - 00 15 00 04 00 05 00 12-00 13 00 01 00 02 00 03 ................
0070 - 00 0f 00 10 00 11 00 23-00 00 00 0d 00 22 00 20 .......#.....".
0080 - 06 01 06 02 06 03 05 01-05 02 05 03 04 01 04 02 ................
0090 - 04 03 03 01 03 02 03 03-02 01 02 02 02 03 01 01 ................
00a0 - 00 0f 00 01 01 .....
SSL_connect:SSLv2/v3 write client hello A
read from 0x7fe008426dd0 [0x7fe008815e00] (7 bytes => 7 (0x7))
0000 - 15 03 01 00 02 02 28 ......(
SSL3 alert read:fatal:handshake failure
SSL_connect:error in SSLv2/v3 read server hello A
140735101956572:error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake
failure:s23_clnt.c:741:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 165 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

k

Post by Dr. Stephen Henson

That should be OK as long as you're using a standard curve like P-256
(NID_X9_62_prime256v1) or P-384 (NID_secp384r1).
Do you get any errors server side? Do you get any alerts visible when you add
the -state option to s_client? Something like no shared cipher would be
expected if the server had (for some reason) decided ECDHE was not usable.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org

Dr. Stephen Henson

2012-11-09 18:44:27 UTC

Permalink

Post by Karel SedlÃ¡Äek
I was using secp521r1, but secp384r1 has the same behavior. Here is
SSL_connect:error in SSLv2/v3 read server hello A
140735101956572:error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake

Hmmm... without a server error message it isn't posible to be sure but I'd
guess it is complaining about no shared ciphers. That shouldn't happen unless
you've got some custom way of adding the necessary algorithms instead or
you've changed the default cipherstring.

OK there are three components that might be failing, GCM, EECDH and SHA384.
I'd suggest seeing if you can connect with ciphersuites that don't use all of
them to see which part is causing the problem. For example:

ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES256-SHA384
ECDH-ECDSA-AES256-GCM-SHA384

With the server ciphersring as the default in each case.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org

Karel Sedláček

2012-11-09 18:55:16 UTC

Permalink

Just discovered the culprit. I had configured the server using
TLSv1_server_method(), going from
<http://www.openssl.org/docs/ssl/SSL_CTX_new.html> and assuming TLSv1
encompasses v1.{1,2}. Stumbled on this by chance by experimenting with
forcing TLSv1.2 (of which the desired cipher suite is a part) and
getting output about an incorrect version. Tried out
SSLv23_server_method() and it worked, then (assuming the correct id by
extrapolation) TLSv1_2_server_method() and everything works great.
Some doc updates here would probably be welcome to the next guy.

k

Post by Dr. Stephen Henson

Hmmm... without a server error message it isn't posible to be sure but I'd
guess it is complaining about no shared ciphers. That shouldn't happen unless
you've got some custom way of adding the necessary algorithms instead or
you've changed the default cipherstring.
OK there are three components that might be failing, GCM, EECDH and SHA384.
I'd suggest seeing if you can connect with ciphersuites that don't use all of
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES256-SHA384
ECDH-ECDSA-AES256-GCM-SHA384
With the server ciphersring as the default in each case.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org