Re: Crash in openSSL 1.0.1g
Update : Crashes are seen only on MAC OS X and not seen on windows. Thanks Regards, -NK From: Cisco Employee navne...@cisco.commailto:navne...@cisco.com Reply-To: openssl-dev@openssl.orgmailto:openssl-dev@openssl.org openssl-dev@openssl.orgmailto:openssl-dev@openssl.org Date: Tuesday, 10 June 2014 11:20 AM To: openssl-dev@openssl.orgmailto:openssl-dev@openssl.org openssl-dev@openssl.orgmailto:openssl-dev@openssl.org Subject: Crash in openSSL 1.0.1g Hello Team, We have recently done the upgrade to openSSL version 1.0.1g and facing many crashes in below code path. Crashes are seen consistently. Any pointer on what went wrong will be really helpful. Thanks for your time !! ==Crash stack trace= (lldb) bt * thread #30: tid = 0x6fdcc, 0x97f34a6a libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT frame #0: 0x97f34a6a libsystem_kernel.dylib`__pthread_kill + 10 frame #1: 0x911a2b2f libsystem_c.dylib`pthread_kill + 101 frame #2: 0x911d95f3 libsystem_c.dylib`__abort + 199 frame #3: 0x911d952c libsystem_c.dylib`abort + 232 frame #4: 0x911c3227 libsystem_c.dylib`szone_error + 443 frame #5: 0x911c4482 libsystem_c.dylib`free_list_checksum_botch + 50 frame #6: 0x911c7a43 libsystem_c.dylib`tiny_malloc_from_free_list + 458 frame #7: 0x911c811a libsystem_c.dylib`szone_malloc_should_clear + 880 frame #8: 0x911bda9e libsystem_c.dylib`szone_malloc + 24 frame #9: 0x911bb5ab libsystem_c.dylib`malloc_zone_malloc + 75 frame #10: 0x911bbfe7 libsystem_c.dylib`malloc + 53 frame #11: 0x0026100d libxxcrypto.dylib`default_malloc_ex + 45 frame #12: 0x0026190f libxxcrypto.dylib`CRYPTO_malloc + 175 frame #13: 0x002766e0 libxxcrypto.dylib`pkey_hmac_init + 48 frame #14: 0x002f4159 libxxcrypto.dylib`int_ctx_new + 601 frame #15: 0x002f460c libxxcrypto.dylib`EVP_PKEY_CTX_new_id + 44 frame #16: 0x002f66cf libxxcrypto.dylib`EVP_PKEY_new_mac_key + 63 frame #17: 0x004a3b07 libxxssl.dylib`tls1_P_hash + 423 frame #18: 0x004a42d2 libxxssl.dylib`tls1_PRF + 770 frame #19: 0x004a6119 libxxssl.dylib`tls1_final_finish_mac + 633 frame #20: 0x00496fea libxxssl.dylib`ssl3_do_change_cipher_spec + 394 frame #21: 0x00496b23 libxxssl.dylib`ssl3_read_bytes + 3347 frame #22: 0x0049829e libxxssl.dylib`ssl3_get_message + 334 frame #23: 0x0049795a libxxssl.dylib`ssl3_get_finished + 90 frame #24: 0x0048700f libxxssl.dylib`ssl3_connect + 3103 frame #25: 0x004b8463 libxxssl.dylib`SSL_connect + 51 frame #26: 0x00031bcf x`boost::asio::ssl::detail::engine::do_connect(this=0xb12c8a54, =0x, =0) + 19 at engine.ipp:272 frame #27: 0x000bee79 x`boost::asio::ssl::detail::engine::perform(this=unavailable, data=unavailable, length=unavailable, ec=unavailable, bytes_transferred=unavailable, op=unavailable)(void*, unsigned long), void*, unsigned long, boost::system::error_code, unsigned long*) + 73 at engine.ipp:215 =End == Thanks Regards, -NK
Re: Locking inefficiency
Geoffrey Thorpe ge...@geoffthorpe.com: So I'm going to propose that we initially put this patch into the development head only, and defer a decision on whether to cherry-pick it into stable branches until that testing is in place. Sure, sounds right. (Will you go ahead and handle the patch?) I certainly don't want us to replace the mutex-using code with something that uses mutex *or* rwlock depending on whether OPENSSL_PTHREADS_SUCK is defined or not. BTW, I mention this because NPTL headers apparently cage the rwlock definitions in some #ifdef-ery that I think we want to avoid in the mutex-rwlock changes in openssl. Rather than grappling with the will-some-platform-fail-in-some-subtle-way issues, I prefer that we rely on the short-term arrival of platform coverage/testing to detect the issue if there is one to cater for. OK. For future work, a lock-free approach (using thread-local storage?) certainly might make sense, but switching to read-write locks in the default callbacks should be a tiny change with significant benefits to multithreaded applications. Yeah, but a couple of things come to mind. (1) rwlocks (under optimised conditions anyway) seem to be essentially lock free in the fast-path case anyway, ie. for the read-lock/no-contention case, due to futex magic. That means no context-switch (to the kernel or otherwise) in that by-far-the-most-common case. So I think a change to rwlocks is likely to eliminate the observable syscall and contention overheads anyway. Yes, that's what I'm thinking too. However, for those cases that actually do use the write lock (and remember that it's not *only* about CRYPTO_ERR, so merely avoiding errors doesn't resolve the issue :-) ), the current array of global locks is certainly generally not ideal. Bodo
Query reg multiple CA-Cert in list with same subject
Hi, I have a query for Ca-Cert list. If at gateway we have configured two CA-certs A1 and A2 both having same subject and content except time-stamp of generation. If peer sends Cert matching to A2, gateway tries to validate it with A1(subject being same and configured first in list) and validation fails. 1. is there a way to avoid addition of cert in store if subject and all contents are same except timestamp generation. 2. Or if not 1st, is there way to validate incoming cert with both cert configured in store. Thanks
Re: Crash in openSSL 1.0.1g
You should be using 1.0.1h. Also, not familiar with MacOS X heap checking, but it looks like heap corruption, which may or may not be OpenSSL's fault. Probably hard to diagnose without a test case! On 10 June 2014 07:25, Navneet Kumar (navneeku) navne...@cisco.com wrote: Update : Crashes are seen only on MAC OS X and not seen on windows. Thanks Regards, -NK From: Cisco Employee navne...@cisco.com Reply-To: openssl-dev@openssl.org openssl-dev@openssl.org Date: Tuesday, 10 June 2014 11:20 AM To: openssl-dev@openssl.org openssl-dev@openssl.org Subject: Crash in openSSL 1.0.1g Hello Team, We have recently done the upgrade to openSSL version 1.0.1g and facing many crashes in below code path. Crashes are seen consistently. Any pointer on what went wrong will be really helpful. Thanks for your time !! ==Crash stack trace= (lldb) bt * thread #30: tid = 0x6fdcc, 0x97f34a6a libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT frame #0: 0x97f34a6a libsystem_kernel.dylib`__pthread_kill + 10 frame #1: 0x911a2b2f libsystem_c.dylib`pthread_kill + 101 frame #2: 0x911d95f3 libsystem_c.dylib`__abort + 199 frame #3: 0x911d952c libsystem_c.dylib`abort + 232 frame #4: 0x911c3227 libsystem_c.dylib`szone_error + 443 frame #5: 0x911c4482 libsystem_c.dylib`free_list_checksum_botch + 50 frame #6: 0x911c7a43 libsystem_c.dylib`tiny_malloc_from_free_list + 458 frame #7: 0x911c811a libsystem_c.dylib`szone_malloc_should_clear + 880 frame #8: 0x911bda9e libsystem_c.dylib`szone_malloc + 24 frame #9: 0x911bb5ab libsystem_c.dylib`malloc_zone_malloc + 75 frame #10: 0x911bbfe7 libsystem_c.dylib`malloc + 53 frame #11: 0x0026100d libxxcrypto.dylib`default_malloc_ex + 45 frame #12: 0x0026190f libxxcrypto.dylib`CRYPTO_malloc + 175 frame #13: 0x002766e0 libxxcrypto.dylib`pkey_hmac_init + 48 frame #14: 0x002f4159 libxxcrypto.dylib`int_ctx_new + 601 frame #15: 0x002f460c libxxcrypto.dylib`EVP_PKEY_CTX_new_id + 44 frame #16: 0x002f66cf libxxcrypto.dylib`EVP_PKEY_new_mac_key + 63 frame #17: 0x004a3b07 libxxssl.dylib`tls1_P_hash + 423 frame #18: 0x004a42d2 libxxssl.dylib`tls1_PRF + 770 frame #19: 0x004a6119 libxxssl.dylib`tls1_final_finish_mac + 633 frame #20: 0x00496fea libxxssl.dylib`ssl3_do_change_cipher_spec + 394 frame #21: 0x00496b23 libxxssl.dylib`ssl3_read_bytes + 3347 frame #22: 0x0049829e libxxssl.dylib`ssl3_get_message + 334 frame #23: 0x0049795a libxxssl.dylib`ssl3_get_finished + 90 frame #24: 0x0048700f libxxssl.dylib`ssl3_connect + 3103 frame #25: 0x004b8463 libxxssl.dylib`SSL_connect + 51 frame #26: 0x00031bcf x`boost::asio::ssl::detail::engine::do_connect(this=0xb12c8a54, =0x, =0) + 19 at engine.ipp:272 frame #27: 0x000bee79 x`boost::asio::ssl::detail::engine::perform(this=unavailable, data=unavailable, length=unavailable, ec=unavailable, bytes_transferred=unavailable, op=unavailable)(void*, unsigned long), void*, unsigned long, boost::system::error_code, unsigned long*) + 73 at engine.ipp:215 =End == Thanks Regards, -NK __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3384] Patch: add ECC strings to ciphers(1), point out difference between DH and ECDH
- Original Message - From: Hubert Kario via RT r...@openssl.org Cc: openssl-dev@openssl.org Sent: Monday, June 9, 2014 2:12:28 PM Subject: Re: [openssl.org #3384] Patch: add ECC strings to ciphers(1), point out difference between DH and ECDH - Original Message - From: Matt Caswell via RT r...@openssl.org To: hka...@redhat.com Cc: openssl-dev@openssl.org Sent: Monday, June 9, 2014 1:01:05 AM Subject: [openssl.org #3384] Patch: add ECC strings to ciphers(1), point out difference between DH and ECDH * The patch as it is at the moment is only relevant to master. It can't be backported to earlier branches because it includes info on stuff not in those branches. In particular kDHE, DHE, ECDHE, kECHDE etc. If you want to merge something for those branches you might want to provide a second pull. Sure, I'll provide backports for 1.0.1 and 1.0.2. 1.0.1-stable: https://github.com/openssl/openssl/pull/129 1.0.2-stable: https://github.com/openssl/openssl/pull/130 Note that I've included also few other simple changes already present in master that are applicable to either the 1.0.1 or 1.0.2 code base. The differences between master and 1.0.x which I taken into account while backporting: * aRSA, kRSA and RSA groups behave differently in master and 1.0.x * no support for profiles (seclevels) in 1.0.x * no support for standard cipher suites names in 1.0.x * no support for kDHE, kECDHE, DHE, ECDHE aliases in 1.0.x * lack of support for static DH in 1.0.1 -- Regards, Hubert Kario __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3384] Patch: add ECC strings to ciphers(1), point out difference between DH and ECDH
- Original Message - From: Hubert Kario via RT r...@openssl.org Cc: openssl-dev@openssl.org Sent: Monday, June 9, 2014 2:12:28 PM Subject: Re: [openssl.org #3384] Patch: add ECC strings to ciphers(1), point out difference between DH and ECDH - Original Message - From: Matt Caswell via RT r...@openssl.org To: hka...@redhat.com Cc: openssl-dev@openssl.org Sent: Monday, June 9, 2014 1:01:05 AM Subject: [openssl.org #3384] Patch: add ECC strings to ciphers(1), point out difference between DH and ECDH * The patch as it is at the moment is only relevant to master. It can't be backported to earlier branches because it includes info on stuff not in those branches. In particular kDHE, DHE, ECDHE, kECHDE etc. If you want to merge something for those branches you might want to provide a second pull. Sure, I'll provide backports for 1.0.1 and 1.0.2. 1.0.1-stable: https://github.com/openssl/openssl/pull/129 1.0.2-stable: https://github.com/openssl/openssl/pull/130 Note that I've included also few other simple changes already present in master that are applicable to either the 1.0.1 or 1.0.2 code base. The differences between master and 1.0.x which I taken into account while backporting: * aRSA, kRSA and RSA groups behave differently in master and 1.0.x * no support for profiles (seclevels) in 1.0.x * no support for standard cipher suites names in 1.0.x * no support for kDHE, kECDHE, DHE, ECDHE aliases in 1.0.x * lack of support for static DH in 1.0.1 -- Regards, Hubert Kario __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Locking inefficiency
On Mon, Jun 09, 2014 at 09:15:15PM +0200, Bodo Moeller wrote: Geoffrey Thorpe ge...@geoffthorpe.com: First, you're right, pthreads_locking_callback() is collapsing everything to a mutex. I was well aware of this and thought we did this for compatibility reasons (because I couldn't think of any other reasonable explanation, I guess). If actual read-write locks are just as portable, I think it's a no-brainer that we should switch to them. (After all, our code is already prepared for that, for applications that provide appropriate custom callbacks. It's just the default that falls behind.) Read-write locks are much more expensive. It would be unwise to convert to them where you cannot document a need to do so. Thor __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Locking inefficiency
Thor, can you quantify what you mean by much more expensive? (And qualify it - what platform, what operations?) The way we use the locks, in heavily multi-threaded applications, you can have a lot of contention with mutexes that wouldn't exist with read/write locks, because often all threads would only require the read locks (However, a lot of the remaining contention is unnecessary because we're using a fixed array of global locks where, in theory, we could be using per-object locks rather than these per-type locks.)
Re: [openssl] OpenSSL source code branch OpenSSL_1_0_2-stable updated. OpenSSL_1_0_2-beta1-172-ge3beef1
Can we imply from this commit that the 1.0.2 release is imminent? If
not, can anyone provide a rough estimate on when 1.0.2 will be released
(1 month, 3 months, 6 months from now)?
On 06/10/2014 10:17 AM, Dr. Stephen Henson wrote:
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project OpenSSL source code.
The branch, OpenSSL_1_0_2-stable has been updated
via e3beef1e1bdd70031d009dc61ab88b74a4c884c8 (commit)
via cea5a1d5f255a6a186cd7944c4a312612da965f3 (commit)
from f472ada00681d0de7c68d13ecbd404d822afa8b1 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit e3beef1e1bdd70031d009dc61ab88b74a4c884c8
Author: Dr. Stephen Henson st...@openssl.org
Date: Fri Jun 6 18:56:24 2014 +0100
Remove experimental DANE code.
Remove experimental DANE/dnssec code: not ready for use in an
official release yet.
commit cea5a1d5f255a6a186cd7944c4a312612da965f3
Author: Dr. Stephen Henson st...@openssl.org
Date: Tue Jun 10 14:47:29 2014 +0100
Fix null pointer errors.
PR#3394
(cherry picked from commit 7a9d59c148b773f59a41f8697eeecf369a0974c2)
---
Summary of changes:
Configure |3 +-
crypto/ocsp/ocsp_ht.c |3 +
ssl/Makefile | 23 +
ssl/d1_both.c |2 +
ssl/dnssec.c | 182 --
ssl/ssl_cert.c| 264
-
ssl/ssl_lib.c | 38 ---
ssl/ssl_locl.h| 11 ---
util/mk1mf.pl |1 -
9 files changed, 8 insertions(+), 519 deletions(-)
delete mode 100644 ssl/dnssec.c
diff --git a/Configure b/Configure
index ca45eb2..885e341 100755
--- a/Configure
+++ b/Configure
@@ -724,7 +724,6 @@ if (exists $ENV{FIPSDIR})
# All of the following is disabled by default (RC5 was enabled before 0.9.8):
my %disabled = ( # what = comment [or special keyword
experimental]
- dane = experimental,
ec_nistp_64_gcc_128 = default,
gmp= default,
jpake = experimental,
@@ -744,7 +743,7 @@ my @experimental = ();
# This is what $depflags will look like with the above defaults
# (we need this to see if we should advise the user to run make depend):
-my $default_depflags = -DOPENSSL_NO_DANE -DOPENSSL_NO_EC_NISTP_64_GCC_128
-DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE -DOPENSSL_NO_LIBUNBOUND -DOPENSSL_NO_MD2
-DOPENSSL_NO_MULTIBLOCK -DOPENSSL_NO_RC5 -DOPENSSL_NO_RFC3779
-DOPENSSL_NO_SCTP -DOPENSSL_NO_SSL_TRACE -DOPENSSL_NO_STORE;
+my $default_depflags = -DOPENSSL_NO_EC_NISTP_64_GCC_128 -DOPENSSL_NO_GMP
-DOPENSSL_NO_JPAKE -DOPENSSL_NO_LIBUNBOUND -DOPENSSL_NO_MD2
-DOPENSSL_NO_MULTIBLOCK -DOPENSSL_NO_RC5 -DOPENSSL_NO_RFC3779
-DOPENSSL_NO_SCTP -DOPENSSL_NO_SSL_TRACE -DOPENSSL_NO_STORE;
# Explicit no-... options will be collected in %disabled along with the
defaults.
# To remove something from %disabled, use enable-foo (unless it's
experimental).
diff --git a/crypto/ocsp/ocsp_ht.c b/crypto/ocsp/ocsp_ht.c
index a053047..bac35f8 100644
--- a/crypto/ocsp/ocsp_ht.c
+++ b/crypto/ocsp/ocsp_ht.c
@@ -571,6 +571,9 @@ OCSP_RESPONSE *OCSP_sendreq_bio(BIO *b, const char *path,
OCSP_REQUEST *req)
ctx = OCSP_sendreq_new(b, path, req, -1);
+ if (!ctx)
+ return NULL;
+
do
{
rv = OCSP_sendreq_nbio(resp, ctx);
diff --git a/ssl/Makefile b/ssl/Makefile
index b1d20b0..be14603 100644
--- a/ssl/Makefile
+++ b/ssl/Makefile
@@ -30,7 +30,7 @@ LIBSRC= \
ssl_lib.c ssl_err2.c ssl_cert.c ssl_sess.c \
ssl_ciph.c ssl_stat.c ssl_rsa.c \
ssl_asn1.c ssl_txt.c ssl_algs.c ssl_conf.c \
- bio_ssl.c ssl_err.c kssl.c t1_reneg.c tls_srp.c t1_trce.c dnssec.c
+ bio_ssl.c ssl_err.c kssl.c t1_reneg.c tls_srp.c t1_trce.c
LIBOBJ= \
s2_meth.o s2_srvr.o s2_clnt.o s2_lib.o s2_enc.o s2_pkt.o \
s3_meth.o s3_srvr.o s3_clnt.o s3_lib.o s3_enc.o s3_pkt.o s3_both.o
s3_cbc.o \
@@ -41,7 +41,7 @@ LIBOBJ= \
ssl_lib.o ssl_err2.o ssl_cert.o ssl_sess.o \
ssl_ciph.o ssl_stat.o ssl_rsa.o \
ssl_asn1.o ssl_txt.o ssl_algs.o ssl_conf.o \
- bio_ssl.o ssl_err.o kssl.o t1_reneg.o tls_srp.o t1_trce.o dnssec.o
+ bio_ssl.o ssl_err.o kssl.o t1_reneg.o tls_srp.o t1_trce.o
SRC= $(LIBSRC)
@@ -288,25 +288,6 @@ d1_srvr.o: ../include/openssl/ssl3.h
../include/openssl/stack.h
d1_srvr.o: ../include/openssl/symhacks.h ../include/openssl/tls1.h
d1_srvr.o: ../include/openssl/x509.h ../include/openssl/x509_vfy.h
Re: [openssl] OpenSSL source code branch OpenSSL_1_0_2-stable updated. OpenSSL_1_0_2-beta1-172-ge3beef1
On Tue, Jun 10, 2014, John Foley wrote: Can we imply from this commit that the 1.0.2 release is imminent? If not, can anyone provide a rough estimate on when 1.0.2 will be released (1 month, 3 months, 6 months from now)? A 1.0.2-beta2 release will happen shortly (the next day or so). So please test the latest snapshots and report any problems and preferably fixes. The actual 1.0.2 release timing will depend on any critical issues reported in beta2. I'd hope for a 1.0.2 release less than a month from now though. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl] OpenSSL source code branch OpenSSL_1_0_2-stable updated. OpenSSL_1_0_2-beta1-172-ge3beef1
Thanks for the guidance, much appreciated. On 06/10/2014 10:31 AM, Dr. Stephen Henson wrote: On Tue, Jun 10, 2014, John Foley wrote: Can we imply from this commit that the 1.0.2 release is imminent? If not, can anyone provide a rough estimate on when 1.0.2 will be released (1 month, 3 months, 6 months from now)? A 1.0.2-beta2 release will happen shortly (the next day or so). So please test the latest snapshots and report any problems and preferably fixes. The actual 1.0.2 release timing will depend on any critical issues reported in beta2. I'd hope for a 1.0.2 release less than a month from now though. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3384] Patch: add ECC strings to ciphers(1), point out difference between DH and ECDH
On Tue, Jun 10, 2014 at 02:33:00PM +0200, Hubert Kario via RT wrote: Note that I've included also few other simple changes already present in master that are applicable to either the 1.0.1 or 1.0.2 code base. The differences between master and 1.0.x which I taken into account while backporting: * aRSA, kRSA and RSA groups behave differently in master and 1.0.x Which differences did you have in mind specificically for the above? (I am aware of the differences noted below...) * no support for profiles (seclevels) in 1.0.x * no support for standard cipher suites names in 1.0.x * no support for kDHE, kECDHE, DHE, ECDHE aliases in 1.0.x * lack of support for static DH in 1.0.1 -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3384] Patch: add ECC strings to ciphers(1), point out difference between DH and ECDH
- Original Message - From: Viktor Dukhovni openssl-us...@dukhovni.org To: openssl-dev@openssl.org Sent: Tuesday, June 10, 2014 4:54:26 PM Subject: Re: [openssl.org #3384] Patch: add ECC strings to ciphers(1), point out difference between DH and ECDH On Tue, Jun 10, 2014 at 02:33:00PM +0200, Hubert Kario via RT wrote: Note that I've included also few other simple changes already present in master that are applicable to either the 1.0.1 or 1.0.2 code base. The differences between master and 1.0.x which I taken into account while backporting: * aRSA, kRSA and RSA groups behave differently in master and 1.0.x Which differences did you have in mind specificically for the above? On second look, there is no difference in behaviour between 1.0.2 and master. I meant the change introduced by ffa45796 that made following update to ciphers(1): -=item BkRSA, BRSA +=item BkRSA, BaRSA, BRSA -cipher suites using RSA key exchange. +cipher suites using RSA key exchange, authentication or either respectively. I've assumed that it is correct with regards to master and just this functionality was not implemented in 1.0.1 or 1.0.2 (where I checked it). So this looks like a bug either in cipher suite parsing or in ciphers(1) man page, since kRSA == RSA, even in master branch. -- Regards, Hubert Kario __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3384] Patch: add ECC strings to ciphers(1), point out difference between DH and ECDH
- Original Message - From: Viktor Dukhovni openssl-us...@dukhovni.org To: openssl-dev@openssl.org Sent: Tuesday, June 10, 2014 4:54:26 PM Subject: Re: [openssl.org #3384] Patch: add ECC strings to ciphers(1), point out difference between DH and ECDH On Tue, Jun 10, 2014 at 02:33:00PM +0200, Hubert Kario via RT wrote: Note that I've included also few other simple changes already present in master that are applicable to either the 1.0.1 or 1.0.2 code base. The differences between master and 1.0.x which I taken into account while backporting: * aRSA, kRSA and RSA groups behave differently in master and 1.0.x Which differences did you have in mind specificically for the above? On second look, there is no difference in behaviour between 1.0.2 and master. I meant the change introduced by ffa45796 that made following update to ciphers(1): -=item BkRSA, BRSA +=item BkRSA, BaRSA, BRSA -cipher suites using RSA key exchange. +cipher suites using RSA key exchange, authentication or either respectively. I've assumed that it is correct with regards to master and just this functionality was not implemented in 1.0.1 or 1.0.2 (where I checked it). So this looks like a bug either in cipher suite parsing or in ciphers(1) man page, since kRSA == RSA, even in master branch. -- Regards, Hubert Kario __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3384] Patch: add ECC strings to ciphers(1), point out difference between DH and ECDH
On Tue, Jun 10, 2014 at 12:10:23PM -0400, Hubert Kario wrote: * aRSA, kRSA and RSA groups behave differently in master and 1.0.x Which differences did you have in mind specificically for the above? On second look, there is no difference in behaviour between 1.0.2 and master. I meant the change introduced by ffa45796 that made following update to ciphers(1): -=item BkRSA, BRSA +=item BkRSA, BaRSA, BRSA -cipher suites using RSA key exchange. +cipher suites using RSA key exchange, authentication or either respectively. I've assumed that it is correct with regards to master and just this functionality was not implemented in 1.0.1 or 1.0.2 (where I checked it). So this looks like a bug either in cipher suite parsing or in ciphers(1) man page, since kRSA == RSA, even in master branch. I think this is a documentation bug, since indeed kRSA == RSA (which is a subset of aRSA, because kRSA requires RSA auth keys) in each of 0.9.8, 1.0.0, 1.0.1, 1.0.2 and master. If the intention was to have RSA be the larger aRSA, rather than the smaller kRSA, then it is a long-standing implementation bug, which probably needs to stay that way now, for backwards compatibility. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3380] OpenSSL 1.0.1h on SGI IRIX
Hi Pieter Can you confirm that this resolves your problem: https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=5a0d057e49a6f7b5ee5ff6f8af5ae395abc7b918 Thanks Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3395] Can’t Compile 0.9.8za FIPS on Win 7 32 Bit w/ Visual Studio 2010.
OpenSSL Support; I issued the command ms\do_fips (also tried w/ ‘no-ec’ option,) it compiles for about 5 minutes, and then throws this error… Creating library tmp32dll\junk.lib and object tmp32dll\junk.exp fipscanister.lib(rsa_oaep.obj) : error LNK2019: unresolved external symbol _CRYPTO_memcmp referenced in function _RSA_padding_check_PKCS1_OAEP out32dll\fips_test_suite.exe : fatal error LNK1120: 1 unresolved externals First stage Link failure at util\fipslink.pl line 42. NMAKE : fatal error U1077: 'C:\Perl\bin\perl.EXE' : return code '0x60' Stop. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3396] SRP and aNULL
RFC5054 says: Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS require the server to send a certificate message containing a certificate with the specified type of public key, and to sign the server key exchange message using a matching private key. Cipher suites that do not include a digital signature algorithm identifier assume that the server is authenticated by its possession of the SRP verifier. So why do I get this: $ openssl ciphers -v aNULL | grep SRP SRP-AES-256-CBC-SHA SSLv3 Kx=SRP Au=None Enc=AES(256) Mac=SHA1 SRP-3DES-EDE-CBC-SHA SSLv3 Kx=SRP Au=None Enc=3DES(168) Mac=SHA1 SRP-AES-128-CBC-SHA SSLv3 Kx=SRP Au=None Enc=AES(128) Mac=SHA1 If the server is authenticated by its possession of the SRP verifier? Steve Henson says: Looks like the SRP cipher decriptions are broken and we need an SSL_aSRP to do the same as SSL_aPSK. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3396] SRP and aNULL
On Tue, Jun 10, 2014 at 09:02:18PM +0200, Matt Caswell via RT wrote: Steve Henson says: Looks like the SRP cipher decriptions are broken and we need an SSL_aSRP to do the same as SSL_aPSK. Also looks like he already fixed the issue in 1.0.0 and later. Which is all the branches that have SRP (there is no SRP support in 0.9.8). -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3198] [PATCH] Fix missing NULL pointer checks and memory leaks in crypto/asn1 files
On 13/12/13 11:54, The default queue via RT wrote: In attachment you can find 7 patches against git master (generated via git format-patch) to fix a number of memory leaks (in case of failures) and missing NULL pointer checks (generally for malloc results) for source files under crypto/asn1. I've tried to follow the coding conventions of the surrounding code. I have about 50 more similar patches to various other parts of OpenSSL, but I'll wait with submitting them in case you'd like something different about the way I'm grouping/formatting/splitting them. I've rebased those 7 patches and all of my other similar patches against current git HEAD and pushed them to a fork on github. I've created a pull request for them at https://github.com/openssl/openssl/pull/131 Jonas __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3198] [PATCH] Fix missing NULL pointer checks and memory leaks in crypto/asn1 files
On Tue, Jun 10, 2014 at 09:48:19PM +0200, Jonas Maebe via RT wrote: On 13/12/13 11:54, The default queue via RT wrote: In attachment you can find 7 patches against git master (generated via git format-patch) to fix a number of memory leaks (in case of failures) and missing NULL pointer checks (generally for malloc results) for source files under crypto/asn1. I've tried to follow the coding conventions of the surrounding code. I have about 50 more similar patches to various other parts of OpenSSL, but I'll wait with submitting them in case you'd like something different about the way I'm grouping/formatting/splitting them. I've rebased those 7 patches and all of my other similar patches against current git HEAD and pushed them to a fork on github. I've created a pull request for them at https://github.com/openssl/openssl/pull/131 So that actually contains 57 commits. It's going to take some time for someone to review it. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3384] Patch: add ECC strings to ciphers(1), point out difference between DH and ECDH
Hi Hubert Many thanks for your contribution. I have merged all 3 of your pull requests. Nice work! https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=343e5cf194b7baf244ed24efa4b8e6d9fc5d4921 https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4ceddeea6c626a922e1b8f54b6fe1d2b89f8ef90 https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=87887a7a658bf305bfe6619eedcbc6c3972cc188 Viktor said on openssl-dev: On 10 June 2014 17:25, Viktor Dukhovni openssl-us...@dukhovni.org wrote: I think this is a documentation bug, since indeed kRSA == RSA (which is a subset of aRSA, because kRSA requires RSA auth keys) in each of 0.9.8, 1.0.0, 1.0.1, 1.0.2 and master. If the intention was to have RSA be the larger aRSA, rather than the smaller kRSA, then it is a long-standing implementation bug, which probably needs to stay that way now, for backwards compatibility. Historically the documentation was correct (up until 1.0.2). Steve changed it in master. I think the corrected version makes much more sense, so I assume that is how it *should* work. Whether it should be fixed or not, I'm not sure. I'll raise it with Steve. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Another security bug, this time in MAC verification...
http://opensslrampage.org/post/88383880093 I don't know if this has in fact been given to the OpenSSL team yet. I am not jsing, and I am not involved in the OpenBSD audit. However, this is important. If MD5 passes, but SHA1 fails, then the MAC verification will pass. This reduces the security of the handshake to MD5. I don't know where ssl3_final_finish_mac() is called from, if it's limited to SSLv3 or if it's also called from TLS. -Kyle H smime.p7s Description: S/MIME Cryptographic Signature
[openssl.org #3384] Patch: add ECC strings to ciphers(1), point out difference between DH and ECDH
Should have added: I did not include the issue around SRP and aNULL. I thought this was a bit odd myself, so after a bit of investigation have decided this is a bug. Raised as #3396 Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3198] [PATCH] Fix missing NULL pointer checks and memory leaks in crypto/asn1 files
On 10/06/14 21:59, Kurt Roeckx via RT wrote: On Tue, Jun 10, 2014 at 09:48:19PM +0200, Jonas Maebe via RT wrote: On 13/12/13 11:54, The default queue via RT wrote: In attachment you can find 7 patches against git master (generated via git format-patch) to fix a number of memory leaks (in case of failures) and missing NULL pointer checks (generally for malloc results) for source files under crypto/asn1. I've tried to follow the coding conventions of the surrounding code. I have about 50 more similar patches to various other parts of OpenSSL, but I'll wait with submitting them in case you'd like something different about the way I'm grouping/formatting/splitting them. I've rebased those 7 patches and all of my other similar patches against current git HEAD and pushed them to a fork on github. I've created a pull request for them at https://github.com/openssl/openssl/pull/131 So that actually contains 57 commits. It's going to take some time for someone to review it. Yes, sorry. I was originally planning on submitting them piecemeal, but as nothing happened with the initial batch I kind of lost motivation... Jonas __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: Another security bug, this time in MAC verification...
http://opensslrampage.org/post/88383880093 The rampager is wrong; see Adam Langley's comments on twitter; https://twitter.com/agl__/status/476420434095648768 /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Another security bug, this time in MAC verification...
On Tue, Jun 10, 2014 at 01:03:17PM -0700, Kyle Hamilton wrote:
http://opensslrampage.org/post/88383880093
I don't know if this has in fact been given to the OpenSSL team yet. I
am not jsing, and I am not involved in the OpenBSD audit.
However, this is important. If MD5 passes, but SHA1 fails, then the MAC
verification will pass. This reduces the security of the handshake to MD5.
I don't know where ssl3_final_finish_mac() is called from, if it's
limited to SSLv3 or if it's also called from TLS.
As far as I can see this is SSLv3 only, and only about the Finish
message.
So it seems that function return the length of the digest, and in
some error cases 0. We'll end up with a wrong value in
(peer_)finish_md_len.
It should then result in this error:
if (i != n)
{
al=SSL_AD_DECODE_ERROR;
SSLerr(SSL_F_SSL3_GET_FINISHED,SSL_R_BAD_DIGEST_LENGTH);
goto f_err;
}
So at first look there doesn't seem to be anything wrong with the
current code. But their patch doesn't do anything wrong either.
Kurt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: Another security bug, this time in MAC verification...
On Tue, Jun 10, 2014 at 10:33:32PM +0200, Kurt Roeckx wrote:
On Tue, Jun 10, 2014 at 01:03:17PM -0700, Kyle Hamilton wrote:
http://opensslrampage.org/post/88383880093
I don't know if this has in fact been given to the OpenSSL team yet. I
am not jsing, and I am not involved in the OpenBSD audit.
However, this is important. If MD5 passes, but SHA1 fails, then the MAC
verification will pass. This reduces the security of the handshake to MD5.
I don't know where ssl3_final_finish_mac() is called from, if it's
limited to SSLv3 or if it's also called from TLS.
As far as I can see this is SSLv3 only, and only about the Finish
message.
So it seems that function return the length of the digest, and in
some error cases 0. We'll end up with a wrong value in
(peer_)finish_md_len.
It should then result in this error:
if (i != n)
{
al=SSL_AD_DECODE_ERROR;
SSLerr(SSL_F_SSL3_GET_FINISHED,SSL_R_BAD_DIGEST_LENGTH);
goto f_err;
}
So at first look there doesn't seem to be anything wrong with the
current code. But their patch doesn't do anything wrong either.
So to clarify this a little more. ssl3_final_finish_mac() returns
0 on an internal error, or the length of the digest. In case of SSLv3
it's both an MD5 and SHA1. In ssl3_final_finish_mac() they only
get calculated and the length is returned. The check that they
are correct happens just after the if I quoted above.
Kurt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
NPE on malloc in ssl/d1_both.c, ssl/s3_enc.c, ssl/sll_ciph.c, ssl/ssl_sess.c, ssl/t1_lib.c
Hello
In version openssl-1.0.h
In case of malloc error, the buffer is not tested here
In ssl/d1_both.c
int
dtls1_process_heartbeat(SSL *s)
{
.
/* Allocate memory for the response, size is 1 byte
* message type, plus 2 bytes payload length, plus
* payload, plus padding
*/
buffer = OPENSSL_malloc(write_length);
bp = buffer;
/* Enter response type, length and copy payload */
*bp++ = TLS1_HB_RESPONSE;
Here neither
In ssl/d1_both.c
int
dtls1_heartbeat(SSL *s)
{
...
buf = OPENSSL_malloc(1 + 2 + payload + padding);
p = buf;
/* Message Type */
*p++ = TLS1_HB_REQUEST;
Here neither in ssl/s3_enc.c
int ssl3_digest_cached_records(SSL *s)
{
/* Allocate handshake_dgst array */
ssl3_free_digest_list(s);
s-s3-handshake_dgst = OPENSSL_malloc(SSL_MAX_DIGEST *
sizeof(EVP_MD_CTX *));
memset(s-s3-handshake_dgst,0,SSL_MAX_DIGEST *sizeof(EVP_MD_CTX *));
Here neither in ssl/ssl_ciph.c
int SSL_COMP_add_compression_method(int id, COMP_METHOD *cm)
{
.
comp=(SSL_COMP *)OPENSSL_malloc(sizeof(SSL_COMP));
comp-id=id;
Here neither in ssl/ssl_sess.c
int SSL_set_session(SSL *s, SSL_SESSION *session)
{
s-kssl_ctx-client_princ = (char
*)OPENSSL_malloc(session-krb5_client_princ_len + 1);
memcpy(s-kssl_ctx-client_princ,session-krb5_client_princ,
session-krb5_client_princ_len);
Here neither in ssl/t1_lib.c
int
tls1_process_heartbeat(SSL *s)
.
buffer = OPENSSL_malloc(1 + 2 + payload + padding);
bp = buffer;
/* Enter response type, length and copy payload */
*bp++ = TLS1_HB_RESPONSE;
Here neither in ssl/t1_lib.c
int
tls1_heartbeat(SSL *s)
.
buf = OPENSSL_malloc(1 + 2 + payload + padding);
p = buf;
/* Message Type */
*p++ = TLS1_HB_REQUEST;
It might be done on purpose ?
Bye
Didier CRUETTE
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: NPE on malloc in ssl/d1_both.c, ssl/s3_enc.c, ssl/sll_ciph.c, ssl/ssl_sess.c, ssl/t1_lib.c
On Tue, Jun 10, 2014 at 11:29:02PM +0200, dcrue...@qualitesys.com wrote: Hello In version openssl-1.0.h In case of malloc error, the buffer is not tested here I think there are already patches available for most of those issues. See github pull request #131. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Another security bug, this time in MAC verification...
On 10 June 2014 21:52, Kurt Roeckx k...@roeckx.be wrote:
As far as I can see this is SSLv3 only, and only about the Finish
message.
So it seems that function return the length of the digest, and in
some error cases 0. We'll end up with a wrong value in
(peer_)finish_md_len.
It should then result in this error:
if (i != n)
{
al=SSL_AD_DECODE_ERROR;
SSLerr(SSL_F_SSL3_GET_FINISHED,SSL_R_BAD_DIGEST_LENGTH);
goto f_err;
}
So at first look there doesn't seem to be anything wrong with the
current code. But their patch doesn't do anything wrong either.
So to clarify this a little more. ssl3_final_finish_mac() returns
0 on an internal error, or the length of the digest. In case of SSLv3
it's both an MD5 and SHA1. In ssl3_final_finish_mac() they only
get calculated and the length is returned. The check that they
are correct happens just after the if I quoted above.
I can't see a way that this could be exploited. It is a bug though.
I've just pushed a fix:
https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=2f1dffa88e1b120add4f0b3a794fbca65aa7768d
Matt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #3380] OpenSSL 1.0.1h on SGI IRIX
... Can you confirm that this resolves your problem: https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=5a0d057e49a6f7b5ee5ff6f8af5ae395abc7b918 ... I applied that patch, which corrected the problem on IRIX and didn't break anything on the other OSes I build on. Thanks, Pieter __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Another security bug, this time in MAC verification...
On Tue, Jun 10, 2014 at 11:35:06PM +0100, Matt Caswell wrote:
On 10 June 2014 21:52, Kurt Roeckx k...@roeckx.be wrote:
As far as I can see this is SSLv3 only, and only about the Finish
message.
So it seems that function return the length of the digest, and in
some error cases 0. We'll end up with a wrong value in
(peer_)finish_md_len.
It should then result in this error:
if (i != n)
{
al=SSL_AD_DECODE_ERROR;
SSLerr(SSL_F_SSL3_GET_FINISHED,SSL_R_BAD_DIGEST_LENGTH);
goto f_err;
}
So at first look there doesn't seem to be anything wrong with the
current code. But their patch doesn't do anything wrong either.
So to clarify this a little more. ssl3_final_finish_mac() returns
0 on an internal error, or the length of the digest. In case of SSLv3
it's both an MD5 and SHA1. In ssl3_final_finish_mac() they only
get calculated and the length is returned. The check that they
are correct happens just after the if I quoted above.
I can't see a way that this could be exploited. It is a bug though.
I've just pushed a fix:
https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=2f1dffa88e1b120add4f0b3a794fbca65aa7768d
Matt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
It's common courtecy to attribute fixes to the original author or at
least the project.
-Otto
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
