Re: Problem with cipher suite ECDHE-ECDSA-AES256-SHA384
You don't need to change OpenSSL; TLSv1_2_server_method() replaces SSLv23_server_method() in your own code. k On Fri, Jun 7, 2013 at 10:17 AM, mehroz mehroz.ashra...@gmail.com wrote: Hi, Could you help where do i need to change the method from TLSv1_2_server_method() to SSLv23_server_method() . Which files(s) need to be addresses? -- View this message in context: http://openssl.6102.n7.nabble.com/Problem-with-cipher-suite-ECDHE-ECDSA-AES256-SHA384-tp42229p45461.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Problem with cipher suite ECDHE-ECDSA-AES256-SHA384
Hi, Could you help where do i need to change the method from TLSv1_2_server_method() to SSLv23_server_method() . Which files(s) need to be addresses? -- View this message in context: http://openssl.6102.n7.nabble.com/Problem-with-cipher-suite-ECDHE-ECDSA-AES256-SHA384-tp42229p45461.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Problem with cipher suite ECDHE-ECDSA-AES256-SHA384
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 debug.bad_handshake Description: Binary data debug.good_handshake Description: Binary data debug.s_server_handshake Description: Binary data
Re: Problem with cipher suite ECDHE-ECDSA-AES256-SHA384
On Fri, Nov 09, 2012, Karel Sedl??ek wrote: 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. 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Problem with cipher suite ECDHE-ECDSA-AES256-SHA384
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); On Fri, Nov 9, 2012 at 5:32 PM, Dr. Stephen Henson st...@openssl.org wrote: On Fri, Nov 09, 2012, Karel Sedl??ek wrote: 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. 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Problem with cipher suite ECDHE-ECDSA-AES256-SHA384
On Fri, Nov 09, 2012, Karel Sedl??ek wrote: 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); 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Problem with cipher suite ECDHE-ECDSA-AES256-SHA384
I was using secp521r1, but secp384r1 has the same behavior. Here is the output with -state: CONNECTED(0003) SSL_connect:before/connect initialization write to 0x7fe008426dd0 [0x7fe008810800] (165 bytes = 165 (0xA5)) - 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 ...cL...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)) - 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 On Fri, Nov 9, 2012 at 6:07 PM, Dr. Stephen Henson st...@openssl.org wrote: On Fri, Nov 09, 2012, Karel Sedl??ek wrote: 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); 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Problem with cipher suite ECDHE-ECDSA-AES256-SHA384
On Fri, Nov 09, 2012, Karel Sedl??ek wrote: I was using secp521r1, but secp384r1 has the same behavior. Here is the output with -state: 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: 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Problem with cipher suite ECDHE-ECDSA-AES256-SHA384
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 On Fri, Nov 9, 2012 at 7:44 PM, Dr. Stephen Henson st...@openssl.org wrote: On Fri, Nov 09, 2012, Karel Sedl??ek wrote: I was using secp521r1, but secp384r1 has the same behavior. Here is the output with -state: 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: 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org