Re: 1.0.1i breaks SRP
Hello Steve, Reverting the below commit is necessary but not sufficient. There are also references to aSRP in s3_clnt.c and ssl_lib.c that must be deleted to get OpenSSL to build. SRP functions correctly once that has been done. Norm On 8/7/14, 19:21, Dr. Stephen Henson wrote: On Thu, Aug 07, 2014, Norm Green wrote: Any idea where to begin debugging this? Any and all help is appreciated. The cause is incorrect handling of new SRP authentication type which was added to correct a bug where SRP authentication was incorrectly classified as NULL authhentication. A temporary workaround is to revert the addition of the SRP authentication type in commit 18c7f2fce8a82b13506cac7ca69fc333baf76408: https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=18c7f2fce8a82b13506cac7ca69fc333baf76408 I'm working on the proper fix. 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: 1.0.1i breaks SRP
On 08/08/14 19:33, Norm Green wrote: Hello Steve, Reverting the below commit is necessary but not sufficient. There are also references to aSRP in s3_clnt.c and ssl_lib.c that must be deleted to get OpenSSL to build. SRP functions correctly once that has been done. Those were introduced as part of the fix to CVE-2014-5139 (commit 83764a989)...deleting them may be unwise. Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: 1.0.1i breaks SRP
Then what would you suggest? SRP is completely broken for us with 1.0.1i Norm On 8/8/14, 11:51, Matt Caswell wrote: On 08/08/14 19:33, Norm Green wrote: Hello Steve, Reverting the below commit is necessary but not sufficient. There are also references to aSRP in s3_clnt.c and ssl_lib.c that must be deleted to get OpenSSL to build. SRP functions correctly once that has been done. Those were introduced as part of the fix to CVE-2014-5139 (commit 83764a989)...deleting them may be unwise. Matt __ 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: 1.0.1i breaks SRP
On Fri, Aug 08, 2014, Norm Green wrote:
Then what would you suggest? SRP is completely broken for us with 1.0.1i
Please try the attached patch against 1.0.1i.
[BTW removing the aSRP references is fine as long as you don't delete the kSRP
references too]
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
diff --git a/ssl/s3_clnt.c b/ssl/s3_clnt.c
index ea0c82d..2ceaa1e 100644
--- a/ssl/s3_clnt.c
+++ b/ssl/s3_clnt.c
@@ -326,9 +326,9 @@ int ssl3_connect(SSL *s)
break;
}
#endif
- /* Check if it is anon DH/ECDH */
+ /* Check if it is anon DH/ECDH, SRP auth */
/* or PSK */
- if (!(s-s3-tmp.new_cipher-algorithm_auth
SSL_aNULL)
+ if (!(s-s3-tmp.new_cipher-algorithm_auth
(SSL_aNULL|SSL_aSRP))
!(s-s3-tmp.new_cipher-algorithm_mkey SSL_kPSK))
{
ret=ssl3_get_server_certificate(s);
@@ -1835,8 +1835,8 @@ fprintf(stderr, USING TLSv1.2 HASH %s\n,
EVP_MD_name(md));
}
else
{
- if (!(alg_a SSL_aNULL) !(alg_k SSL_kPSK))
- /* aNULL or kPSK do not need public keys */
+ /* aNULL, aSRP or kPSK do not need public keys */
+ if (!(alg_a (SSL_aNULL|SSL_aSRP)) !(alg_k SSL_kPSK))
{
SSLerr(SSL_F_SSL3_GET_KEY_EXCHANGE,ERR_R_INTERNAL_ERROR);
goto err;
diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
index 4835bef..c5f3e93 100644
--- a/ssl/s3_lib.c
+++ b/ssl/s3_lib.c
@@ -3824,6 +3824,8 @@ SSL_CIPHER *ssl3_choose_cipher(SSL *s,
STACK_OF(SSL_CIPHER) *clnt,
#ifndef OPENSSL_NO_SRP
mask_k=cert-mask_k | s-srp_ctx.srp_Mask;
emask_k=cert-export_mask_k | s-srp_ctx.srp_Mask;
+ mask_a=cert-mask_a | s-srp_ctx.srp_Mask;
+ emask_a=cert-export_mask_a | s-srp_ctx.srp_Mask;
#endif
#ifdef KSSL_DEBUG
diff --git a/ssl/s3_srvr.c b/ssl/s3_srvr.c
index 2867501..b0538d1 100644
--- a/ssl/s3_srvr.c
+++ b/ssl/s3_srvr.c
@@ -412,7 +412,7 @@ int ssl3_accept(SSL *s)
/* normal PSK or KRB5 or SRP */
if (!(s-s3-tmp.new_cipher-algorithm_auth SSL_aNULL)
!(s-s3-tmp.new_cipher-algorithm_mkey
SSL_kPSK)
-!(s-s3-tmp.new_cipher-algorithm_auth
SSL_aKRB5))
+!(s-s3-tmp.new_cipher-algorithm_auth
(SSL_aKRB5|SSL_aSRP)))
{
ret=ssl3_send_server_certificate(s);
if (ret = 0) goto end;
@@ -515,7 +515,9 @@ int ssl3_accept(SSL *s)
* (against the specs, but s3_clnt.c accepts
this for SSL 3) */
!(s-verify_mode
SSL_VERIFY_FAIL_IF_NO_PEER_CERT)) ||
/* never request cert in Kerberos ciphersuites
*/
- (s-s3-tmp.new_cipher-algorithm_auth
SSL_aKRB5)
+ (s-s3-tmp.new_cipher-algorithm_auth
SSL_aKRB5) ||
+ /* don't request certificate with SRP auth */
+ (s-s3-tmp.new_cipher-algorithm_auth
SSL_aSRP)
/* With normal PSK Certificates and
* Certificate Requests are omitted */
|| (s-s3-tmp.new_cipher-algorithm_mkey
SSL_kPSK))
@@ -1846,7 +1848,7 @@ int ssl3_send_server_key_exchange(SSL *s)
n+=2+nr[i];
}
- if (!(s-s3-tmp.new_cipher-algorithm_auth SSL_aNULL)
+ if (!(s-s3-tmp.new_cipher-algorithm_auth
(SSL_aNULL|SSL_aSRP))
!(s-s3-tmp.new_cipher-algorithm_mkey SSL_kPSK))
{
if
((pkey=ssl_get_sign_pkey(s,s-s3-tmp.new_cipher,md))
Re: 1.0.1i breaks SRP
Hi Steve, That patch works! We will go with that one instead of rolling back the commit mentioned in your previous message. Thanks very much for your help!!! Norm On 8/8/14, 12:25, Dr. Stephen Henson wrote: On Fri, Aug 08, 2014, Norm Green wrote: Then what would you suggest? SRP is completely broken for us with 1.0.1i Please try the attached patch against 1.0.1i. [BTW removing the aSRP references is fine as long as you don't delete the kSRP references too] 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
1.0.1i breaks SRP
I just upgraded our product to 1.0.1i and logins via SRP are now broken. Shown below are the SSL calls made from both the client and server. Everything worked perfectly under 1.0.1h. Bot sides set the cipher list to 'SRP' via calls to SSL_CTX_set_cipher_list(), so the no shared cipher complaint after line 31 on the server side is clearly bogus. Any idea where to begin debugging this? Any and all help is appreciated. Norm Green Server Side: [ 1] SSL call: SSL_load_error_strings with args: NONE (nothing returned) [ 2] SSL call: ERR_load_crypto_strings with args: NONE (nothing returned) [ 3] SSL call: OpenSSL_add_all_ciphers with args: NONE (nothing returned) [ 4] SSL call: OpenSSL_add_all_digests with args: NONE (nothing returned) [ 5] SSL call: SSL_library_init with args: NONE result=1 [ 6] SSL call: RAND_status with args: NONE result=1 [ 7] SSL call: TLSv1_1_server_method with args: NONE result=0x7f1407999040 [ 8] SSL call: SSL_CTX_new with args: 0x7f1407999040 result=0x1f8a8e0 [ 9] SSL call: SSL_CTX_ctrl with args: 0x1f8a8e0 33 4 (NULL) result=4 [ 10] SSL call: SSL_CTX_set_verify with args: 0x1f8a8e0 0 (NULL) (nothing returned) [ 11] SSL call: SSL_CTX_set_cipher_list with args: 0x1f8a8e0 'SRP' result=1 [ 12] SSL call: SSL_CTX_set_srp_strength with args: 0x1f8a8e0 1024 result=1 [ 13] SSL call: BN_init with args: 0x7f14197a3a88 (nothing returned) [ 14] SSL call: BN_init with args: 0x7f14197a3aa0 (nothing returned) [ 15] SSL call: BN_init with args: 0x7f14197a3ab8 (nothing returned) [ 16] SSL call: BN_init with args: 0x7f14197a3ad0 (nothing returned) [ 17] SSL call: SRP_get_default_gN with args: '1024' result=0x7f14079adb50 [ 18] SSL call: BN_copy with args: 0x7f14197a3ab8 0x7f14079adaa0 result=0x7f14197a3ab8 [ 19] SSL call: BN_copy with args: 0x7f14197a3ad0 0x7f14079ad980 result=0x7f14197a3ad0 [ 20] SSL call: BN_bin2bn with args: 0x7fff686674c0 128 0x7f14197a3aa0 result=0x7f14197a3aa0 [ 21] SSL call: BN_bin2bn with args: 0x7fff686674c0 20 0x7f14197a3a88 result=0x7f14197a3a88 [ 22] SSL call: SSL_CTX_set_verify with args: 0x1f8a8e0 0 (NULL) (nothing returned) [ 23] SSL call: SSL_CTX_set_cipher_list with args: 0x1f8a8e0 'SRP' result=1 [ 24] SSL call: SSL_CTX_set_srp_cb_arg with args: 0x1f8a8e0 0x7f14197a3a80 result=1 [ 25] SSL call: SSL_CTX_set_srp_username_callback with args: 0x1f8a8e0 0x7f1418ab6d26 result=1 [ 26] SSL call: SSL_new with args: 0x1f8a8e0 result=0x1f8b680 [ 27] SSL call: SSL_set_fd with args: 0x1f8b680 5 result=1 [ 28] SSL call: SSL_get_fd with args: 0x1f8b680 result=5 [ 29] SSL call: ERR_clear_error with args: NONE (nothing returned) [ 30] SSL call: SSL_accept with args: 0x1f8b680 result=-1 [ 31] SSL call: SSL_get_error with args: 0x1f8b680 -1 result=1 error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1358: [ 32] SSL call: ERR_clear_error with args: NONE (nothing returned) [ 33] SSL call: SSL_accept with args: 0x1f8b680 result=-1 [ 34] SSL call: ERR_clear_error with args: NONE (nothing returned) [ 35] SSL call: SSL_accept with args: 0x1f8b680 result=-1 [ 36] SSL call: ERR_clear_error with args: NONE (nothing returned) [ 37] SSL call: SSL_accept with args: 0x1f8b680 result=-1 SSL_accept() failed after 4 tries [ 38] SSL call: SSL_free with args: 0x1f8b680 (nothing returned) [ 39] SSL call: SSL_CTX_free with args: 0x1f8a8e0 (nothing returned) Client Side: [ 1] SSL call: SSL_load_error_strings with args: NONE (nothing returned) [ 2] SSL call: ERR_load_crypto_strings with args: NONE (nothing returned) [ 3] SSL call: OpenSSL_add_all_ciphers with args: NONE (nothing returned) [ 4] SSL call: OpenSSL_add_all_digests with args: NONE (nothing returned) [ 5] SSL call: SSL_library_init with args: NONE result=1 [ 6] SSL call: RAND_status with args: NONE result=1 [ 7] SSL call: TLSv1_1_client_method with args: NONE result=0x76460a40 [ 8] SSL call: SSL_CTX_new with args: 0x76460a40 result=0x62f150 [ 9] SSL call: SSL_CTX_ctrl with args: 0x62f150 33 4 (NULL) result=4 [ 10] SSL call: SSL_CTX_set_verify with args: 0x62f150 0 (NULL) (nothing returned) [ 11] SSL call: SSL_CTX_set_cipher_list with args: 0x62f150 'SRP' result=1 [ 12] SSL call: SSL_CTX_set_srp_strength with args: 0x62f150 1024 result=1 [ 13] SSL call: SSL_CTX_set_srp_username with args: 0x62f150 'SystemUser' result=1 [ 14] SSL call: SSL_CTX_set_srp_password with args: 0x62f150 'swordfish' result=1 [ 15] SSL call: SSL_new with args: 0x62f150 result=0x62f990 [ 16] SSL call: SSL_set_fd with args: 0x62f990 6 result=1 [ 17] SSL call: SSL_get_fd with args: 0x62f990 result=6 [ 18] SSL call: ERR_clear_error with args: NONE (nothing returned) [ 19] SSL call: SSL_connect with args: 0x62f990 result=0 [ 20] SSL call: SSL_get_error with args: 0x62f990 0 result=1 error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1275:SSL
Re: 1.0.1i breaks SRP
On Thu, Aug 07, 2014, Norm Green wrote: I just upgraded our product to 1.0.1i and logins via SRP are now broken. Shown below are the SSL calls made from both the client and server. Everything worked perfectly under 1.0.1h. Bot sides set the cipher list to 'SRP' via calls to SSL_CTX_set_cipher_list(), so the no shared cipher complaint after line 31 on the server side is clearly bogus. Well maybe, maybe not. Just because a ciphersuite is included in the cipherlist doesn't mean it is included or could be selected. For example if you set a ciphersuite which uses ECDSA authentication it wont be selected if the server doesn't include an ECDSA certificate. That might be what is happening here: the ciphersuite is being (incorrectly) excluded either client or server side. Any idea where to begin debugging this? Any and all help is appreciated. Can you reproduce this with s_client and s_server? Can you try a 1.0.1i client versus a 1.0.1h server and vice-versa? 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: 1.0.1i breaks SRP
On Thu, Aug 07, 2014, Norm Green wrote: I just upgraded our product to 1.0.1i and logins via SRP are now broken. Shown below are the SSL calls made from both the client and server. Everything worked perfectly under 1.0.1h. Bot sides set the cipher list to 'SRP' via calls to SSL_CTX_set_cipher_list(), so the no shared cipher complaint after line 31 on the server side is clearly bogus. Any idea where to begin debugging this? Any and all help is appreciated. Hmm... think I can reproduce it now. There is a problem with some ciphersuites. Looking into it. 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: 1.0.1i breaks SRP
On Thu, Aug 07, 2014, Norm Green wrote: Any idea where to begin debugging this? Any and all help is appreciated. The cause is incorrect handling of new SRP authentication type which was added to correct a bug where SRP authentication was incorrectly classified as NULL authhentication. A temporary workaround is to revert the addition of the SRP authentication type in commit 18c7f2fce8a82b13506cac7ca69fc333baf76408: https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=18c7f2fce8a82b13506cac7ca69fc333baf76408 I'm working on the proper fix. 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: 1.0.1i breaks SRP
Thanks for tracking it down so fast Steve. I will revert the mods in that commit and try it again tomorrow. Norm On 8/7/2014 7:21 PM, Dr. Stephen Henson wrote: On Thu, Aug 07, 2014, Norm Green wrote: Any idea where to begin debugging this? Any and all help is appreciated. The cause is incorrect handling of new SRP authentication type which was added to correct a bug where SRP authentication was incorrectly classified as NULL authhentication. A temporary workaround is to revert the addition of the SRP authentication type in commit 18c7f2fce8a82b13506cac7ca69fc333baf76408: https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=18c7f2fce8a82b13506cac7ca69fc333baf76408 I'm working on the proper fix. 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
