RE: Small memory leak on multithreaded server
I see your point but I cannot have memory allocated when my application shuts down. This constraint is related to the fact that this is an embedded VoIP system. Thanks for the response! Charles A. Barbe Senior Software Engineer Allworx, a Windstream company 245 East Main St | Rochester NY | 14604 charles.ba...@allworx.com | 585.421.5565 From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on behalf of Viktor Dukhovni [openssl-us...@dukhovni.org] Sent: Thursday, November 20, 2014 7:26 PM To: openssl-users@openssl.org Subject: Re: Small memory leak on multithreaded server On Thu, Nov 20, 2014 at 10:19:32PM +, Barbe, Charles wrote: I can do any combination of steps 2,3 and 4 above (ie. leave some of them out) and I always get the same amount of memory left over after I shut down my application. I believe this means that this is some sort of global information that OpenSSL is hanging on to and not something in my SSL connection structure. Specifically I get 20 blocks totaling 253 bytes. I have stack traces of where each block is allocated but I cannot figure out how this memory should be cleaned up. Each of the 20 blocks filter down to 1 of 5 root stack traces. The stack traces are: A fixed amount of memory that is not deallocated and is independent of the number of operations performed, is NOT a memory leak. Librariers to allocate memory for the lifetime of the process during one time initialization or first use of a function. This is normal. Tracking this down is a waste of time IMHO. -- Viktor. __ 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: Small memory leak on multithreaded server
Thanks for the response... here is the code that runs when my connection closes:
void OpensslConnection::cleanup()
{
if(ssl != NULL)
{
if(isConnected)
{
while(SSL_shutdown(ssl) == 0)
;
}
SSL_free(ssl);
ERR_remove_state(0);
ssl = NULL;
}
isConnected = false;
}
And here is the code that runs to shut down my SSL library:
static void
openSslShutdown ()
{
CONF_modules_free();
ERR_remove_state(0);
CONF_modules_unload(1);
ERR_free_strings();
EVP_cleanup();
CRYPTO_cleanup_all_ex_data();
if (opensslLocks != NULL)
{
for(int i = 0; i CRYPTO_num_locks(); i++)
{
PAL_mutexDestroy (opensslLocks[i]);
}
IST_FREE (opensslLocks);
}
}
Also, I have numerous worker threads handling connections and they all do the
following before they exit:
ERR_remove_thread_state(0);
Charles A. Barbe
Senior Software Engineer
Allworx, a Windstream company
245 East Main St | Rochester NY | 14604
charles.ba...@allworx.com | 585.421.5565
From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on
behalf of Jeffrey Walton [noloa...@gmail.com]
Sent: Thursday, November 20, 2014 6:03 PM
To: OpenSSL Users List
Subject: Re: Small memory leak on multithreaded server
Any help would be appreciated.
This could be one of two problems. First, it could be an issue with
your code and the way you handle cleanup. To help diagnose this,
please show us your cleanup code.
Second, it could be the memory leak from the compression methods. This
is a well known problem dating back a few years that has not been
fixed. See, for example,
http://rt.openssl.org/Ticket/Display.html?id=2561user=guestpass=guest.
On Thu, Nov 20, 2014 at 5:19 PM, Barbe, Charles
charles.ba...@allworx.com wrote:
Hello,
I have noticed a small and consistent memory leak in my multithreaded openssl
server and am wondering if somebody can help me figure out what I need to do
to free it when my application closes. I am on OpenSSL version 1.0.1j. Here's
how I reproduce the leak:
1) Start up my server
2) Load my homepage with Chrome
3) Load my homepage with IE
4) Load my homepage with Firefox
I can do any combination of steps 2,3 and 4 above (ie. leave some of them
out) and I always get the same amount of memory left over after I shut down
my application. I believe this means that this is some sort of global
information that OpenSSL is hanging on to and not something in my SSL
connection structure.
Specifically I get 20 blocks totaling 253 bytes. I have stack traces of where
each block is allocated but I cannot figure out how this memory should be
cleaned up. Each of the 20 blocks filter down to 1 of 5 root stack traces.
The stack traces are:
Repeated 6 times:
0x085c519c: asn1_item_ex_combine_new at tasn_new.c:164
0x085c7fd8: ASN1_item_ex_d2i at tasn_dec.c:315 (discriminator 1)
0x085c81dc: asn1_template_noexp_d2i at tasn_dec.c:706
0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616
0x085c7d90: ASN1_item_ex_d2i at tasn_dec.c:195
0x085c80a8: ASN1_item_d2i at tasn_dec.c:136
0x0867b368: X509V3_EXT_d2i at v3_lib.c:177
0x08682f3c: x509v3_cache_extensions at v3_purp.c:464
0x08683698: x509v3_cache_extensions at v3_purp.c:722
(inlined by) X509_check_issued at v3_purp.c:706
0x0866fddc: check_issued at x509_vfy.c:417
0x086716d0: X509_verify_cert at x509_vfy.c:212
0x086967c0: ssl3_output_cert_chain at s3_both.c:387
0x0868ac68: ssl3_send_server_certificate at s3_srvr.c:3365
0x0868b864: ssl3_accept at s3_srvr.c:418
0x086982f4: ssl23_get_client_hello at s23_srvr.c:657
0x08698bb8: ssl23_accept at s23_srvr.c:213
Repeated 6 times:
0x085d12a4: ASN1_STRING_set at asn1_lib.c:389
0x085c715c: asn1_ex_c2i at tasn_dec.c:1056
0x085c7334: asn1_d2i_ex_primitive at tasn_dec.c:836
0x085c7fc8: ASN1_item_ex_d2i at tasn_dec.c:198
0x085c82a0: asn1_template_noexp_d2i at tasn_dec.c:734
0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616
0x085c7a20: ASN1_item_ex_d2i at tasn_dec.c:331
0x085c81dc: asn1_template_noexp_d2i at tasn_dec.c:706
0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616
0x085c7d90: ASN1_item_ex_d2i at tasn_dec.c:195
0x085c80a8: ASN1_item_d2i at tasn_dec.c:136
0x0867b368: X509V3_EXT_d2i at v3_lib.c:177
0x08682f3c: x509v3_cache_extensions at v3_purp.c:464
0x08683698: x509v3_cache_extensions at v3_purp.c:722
(inlined by) X509_check_issued at v3_purp.c:706
0x0866fddc: check_issued at x509_vfy.c:417
0x086716d0: X509_verify_cert at x509_vfy.c:212
0x086967c0: ssl3_output_cert_chain at s3_both.c:387
0x0868ac68: ssl3_send_server_certificate at s3_srvr.c:3365
0x0868b864: ssl3_accept at s3_srvr.c:418
0x086982f4: ssl23_get_client_hello at s23_srvr.c:657
0x08698bb8: ssl23_accept at s23_srvr.c:213
Repeated 6 times:
0x085d13bc: ASN1_STRING_type_new at asn1_lib.c:429
0x085c71f4:
RE: What version(s) of SSL/TLS are supported in openssl 1.0.1g
Thank You for the prompt and insightful response Jeffrey :-) -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Jeffrey Walton Sent: Thursday, November 20, 2014 1:09 PM To: OpenSSL Users List Subject: Re: What version(s) of SSL/TLS are supported in openssl 1.0.1g Would any one be able to let me know what versions of SSL (if applicable) and TLS is supported in openssl 1.0.1g All of them. Its up to you to trim what you don't want. You can remove protocols (and other features) at compile time with, for example: ./config no-ssl2 no-ssl3 no-comp Or, you can remove them at runtime with, for example: const SSL_METHOD* method = SSLv23_method(); SSL_CTX* context = SSL_CTX_new(method); long flags = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_COMPRESSION; SSL_CTX_set_options(context, flags); __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL alert number 51
I posted the certificates. What's next? Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Matt Caswell Sent: Wednesday, November 19, 2014 3:35 PM To: openssl-users@openssl.org Subject: Re: SSL alert number 51 On 19/11/14 22:57, Charles Mills wrote: Dave - Thanks much. Either there's a bug somewhere or you are being attacked (MitM'ed). Unlikely I am being MitM'ed -- the connection is over a VPN. (Why TLS when there is already a VPN in place? I am testing TLS software and the VPN is a fact of life and my only client to server link. Do you mean the server, running 1.0.1h on Win7, produced this error message, or some client talking *to* such a server produced the error? Statement was kind of ambiguous, wasn't it? The server, which is OpenSSL 1.0.1h 5 Jun 2014, produced this message, when the client attempted to connect. The client is application software that uses the IBM GSK crypto library on z/OS. The error message at the client end is Error code 9 returned from GSK function gsk_secure_socket_init(): Cryptographic processing error. It is my code that produces that exact message, but the 9 comes back from the indicated method and the text comes from a system function, gsk_strerror(9). The documentation says 9 Cryptographic processing error. Explanation: An error is detected by a cryptographic function. This error may also occur if key sizes that are non-FIPS are used during an SSL handshake while operating in FIPS mode. My guess is that this last sentence is the cause of your problem. User response: If the error occurred while executing in FIPS mode, check that only FIPS key sizes are used. Collect a System SSL trace containing the error and then contact your service representative. I can connect between the client and the server using the set of parameters under test. They negotiate TLSV1.1 and what you call DHE-RSA-AES256-SHA and FIPS 140-2 places restrictions on the size of the RSA key that you can use. I'm not a FIPS 140-2 expert but I believe you have to be compliant with the various other FIPS standards including FIPS 186-4(?): This Standard specifies three choices for the length of the modulus (i.e.,nlen): 1024, 2048 and 3072 bits. Federal Government entities shall generate digital signatures using one or more of these choices. So how big is your RSA key on the server? Are you able to post the certificate? 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: Small memory leak on multithreaded server
On Fri, Nov 21, 2014 at 02:26:45PM +, Barbe, Charles wrote:
static void
openSslShutdown ()
{
You could try adding:
ENGINE_cleanup();
if that helps.
CONF_modules_free();
ERR_remove_state(0);
CONF_modules_unload(1);
ERR_free_strings();
EVP_cleanup();
CRYPTO_cleanup_all_ex_data();
if (opensslLocks != NULL)
{
for(int i = 0; i CRYPTO_num_locks(); i++)
{
PAL_mutexDestroy (opensslLocks[i]);
}
IST_FREE (opensslLocks);
}
}
You may need to patch the library to add deallocation code for any
one-time allocations not handled by the above.
--
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Small memory leak on multithreaded server
On 21/11/2014 15:26, Barbe, Charles wrote:
Thanks for the response... here is the code that runs when my connection closes:
void OpensslConnection::cleanup()
{
if(ssl != NULL)
{
if(isConnected)
{
while(SSL_shutdown(ssl) == 0)
;
}
SSL_free(ssl);
ERR_remove_state(0);
ssl = NULL;
}
isConnected = false;
}
And here is the code that runs to shut down my SSL library:
static void
openSslShutdown ()
{
CONF_modules_free();
ERR_remove_state(0);
CONF_modules_unload(1);
ERR_free_strings();
EVP_cleanup();
CRYPTO_cleanup_all_ex_data();
if (opensslLocks != NULL)
{
for(int i = 0; i CRYPTO_num_locks(); i++)
{
PAL_mutexDestroy (opensslLocks[i]);
}
IST_FREE (opensslLocks);
}
}
Also, I have numerous worker threads handling connections and they all do the
following before they exit:
ERR_remove_thread_state(0);
From the response by Dr. Henson, maybe you need code to unload your
server certificate and its certificate chain (a STACK of
certificates).
From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on
behalf of Jeffrey Walton [noloa...@gmail.com]
Sent: Thursday, November 20, 2014 6:03 PM
To: OpenSSL Users List
Subject: Re: Small memory leak on multithreaded server
Any help would be appreciated.
This could be one of two problems. First, it could be an issue with
your code and the way you handle cleanup. To help diagnose this,
please show us your cleanup code.
Second, it could be the memory leak from the compression methods. This
is a well known problem dating back a few years that has not been
fixed. See, for example,
http://rt.openssl.org/Ticket/Display.html?id=2561user=guestpass=guest.
On Thu, Nov 20, 2014 at 5:19 PM, Barbe, Charles
charles.ba...@allworx.com wrote:
Hello,
I have noticed a small and consistent memory leak in my multithreaded openssl
server and am wondering if somebody can help me figure out what I need to do to
free it when my application closes. I am on OpenSSL version 1.0.1j. Here's how
I reproduce the leak:
1) Start up my server
2) Load my homepage with Chrome
3) Load my homepage with IE
4) Load my homepage with Firefox
I can do any combination of steps 2,3 and 4 above (ie. leave some of them out)
and I always get the same amount of memory left over after I shut down my
application. I believe this means that this is some sort of global information
that OpenSSL is hanging on to and not something in my SSL connection structure.
Specifically I get 20 blocks totaling 253 bytes. I have stack traces of where
each block is allocated but I cannot figure out how this memory should be
cleaned up. Each of the 20 blocks filter down to 1 of 5 root stack traces. The
stack traces are:
Repeated 6 times:
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: SSL alert number 51
On 21/11/14 14:43, Charles Mills wrote: I posted the certificates. What's next? Charles The key sizes look ok to me. As I said I'm no FIPS expert, but this page http://wiki.openssl.org/index.php/FIPS_mode_and_TLS says the following: The RSA key in the certificate has to be of suitable size (2048 bits minimum) as do all other keys in the chain and none of the CAs can sign using SHA1. But your certificates say: Signature Algorithm: sha1WithRSAEncryption So I'm wondering if that is the problem? Failing that you may need to approach IBM since the alert is being generated from their code. Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Small memory leak on multithreaded server
It sort of makes sense that this is a stack of certs that is left over but what confuses me is that this memory is allocated by calls executed as a result of my calling SSL_accept(ssl). Also, we're talking 253 bytes... i would imagine that stack of certs would be larger than that, wouldn't it? And shouldn't all the memory allocated by SSL_accept be freed when I call SSL_shutdown and SSL_free? What looks suspicious to me is the calls to x509v3_cache_extensions that are in the traces below. This implies to me that openssl is caching something. How do I ask it to clear that cache? If i need to augment the library to do so, where are the pointers to the objects it is caching so I can free it? I tried to trace the code but got lost... i'm sure I can trace it given enough time but thought I'd ask the community first. I also note that I have no indication of any left over memory from my allocation of the certs that I am providing to my SSL_CTX... meaning that I believe I am cleaning my SSL_CTX and associated resources appropriately. The memory in question is definitely allocated by OpenSSL as a result of calling SSL_accept... I just need to figure out how to ask OpenSSL to free it. Thanks so much for the help. Charles A. Barbe Senior Software Engineer Allworx, a Windstream company 245 East Main St | Rochester NY | 14604 charles.ba...@allworx.com | 585.421.5565 From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on behalf of Dr. Stephen Henson [st...@openssl.org] Sent: Thursday, November 20, 2014 9:50 PM To: openssl-users@openssl.org Subject: Re: Small memory leak on multithreaded server On Thu, Nov 20, 2014, Barbe, Charles wrote: Hello, I have noticed a small and consistent memory leak in my multithreaded openssl server and am wondering if somebody can help me figure out what I need to do to free it when my application closes. I am on OpenSSL version 1.0.1j. Here's how I reproduce the leak: 1) Start up my server 2) Load my homepage with Chrome 3) Load my homepage with IE 4) Load my homepage with Firefox I can do any combination of steps 2,3 and 4 above (ie. leave some of them out) and I always get the same amount of memory left over after I shut down my application. I believe this means that this is some sort of global information that OpenSSL is hanging on to and not something in my SSL connection structure. Specifically I get 20 blocks totaling 253 bytes. I have stack traces of where each block is allocated but I cannot figure out how this memory should be cleaned up. Each of the 20 blocks filter down to 1 of 5 root stack traces. The stack traces are: Repeated 6 times: 0x085c519c: asn1_item_ex_combine_new at tasn_new.c:164 0x085c7fd8: ASN1_item_ex_d2i at tasn_dec.c:315 (discriminator 1) 0x085c81dc: asn1_template_noexp_d2i at tasn_dec.c:706 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 0x085c7d90: ASN1_item_ex_d2i at tasn_dec.c:195 0x085c80a8: ASN1_item_d2i at tasn_dec.c:136 0x0867b368: X509V3_EXT_d2i at v3_lib.c:177 0x08682f3c: x509v3_cache_extensions at v3_purp.c:464 0x08683698: x509v3_cache_extensions at v3_purp.c:722 (inlined by) X509_check_issued at v3_purp.c:706 0x0866fddc: check_issued at x509_vfy.c:417 0x086716d0: X509_verify_cert at x509_vfy.c:212 0x086967c0: ssl3_output_cert_chain at s3_both.c:387 0x0868ac68: ssl3_send_server_certificate at s3_srvr.c:3365 0x0868b864: ssl3_accept at s3_srvr.c:418 0x086982f4: ssl23_get_client_hello at s23_srvr.c:657 0x08698bb8: ssl23_accept at s23_srvr.c:213 Repeated 6 times: 0x085d12a4: ASN1_STRING_set at asn1_lib.c:389 0x085c715c: asn1_ex_c2i at tasn_dec.c:1056 0x085c7334: asn1_d2i_ex_primitive at tasn_dec.c:836 0x085c7fc8: ASN1_item_ex_d2i at tasn_dec.c:198 0x085c82a0: asn1_template_noexp_d2i at tasn_dec.c:734 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 0x085c7a20: ASN1_item_ex_d2i at tasn_dec.c:331 0x085c81dc: asn1_template_noexp_d2i at tasn_dec.c:706 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 0x085c7d90: ASN1_item_ex_d2i at tasn_dec.c:195 0x085c80a8: ASN1_item_d2i at tasn_dec.c:136 0x0867b368: X509V3_EXT_d2i at v3_lib.c:177 0x08682f3c: x509v3_cache_extensions at v3_purp.c:464 0x08683698: x509v3_cache_extensions at v3_purp.c:722 (inlined by) X509_check_issued at v3_purp.c:706 0x0866fddc: check_issued at x509_vfy.c:417 0x086716d0: X509_verify_cert at x509_vfy.c:212 0x086967c0: ssl3_output_cert_chain at s3_both.c:387 0x0868ac68: ssl3_send_server_certificate at s3_srvr.c:3365 0x0868b864: ssl3_accept at s3_srvr.c:418 0x086982f4: ssl23_get_client_hello at s23_srvr.c:657 0x08698bb8: ssl23_accept at s23_srvr.c:213 Repeated 6 times: 0x085d13bc: ASN1_STRING_type_new at asn1_lib.c:429 0x085c71f4: asn1_ex_c2i at tasn_dec.c:1032 0x085c7334: asn1_d2i_ex_primitive at tasn_dec.c:836 0x085c7fc8: ASN1_item_ex_d2i at tasn_dec.c:198 0x085c82a0: asn1_template_noexp_d2i at tasn_dec.c:734 0x085c85a0:
Re: Small memory leak on multithreaded server
On Fri, Nov 21, 2014 at 03:21:47PM +, Barbe, Charles wrote: What looks suspicious to me is the calls to x509v3_cache_extensions that are in the traces below. This implies to me that openssl is caching something. How do I ask it to clear that cache? If i need to augment the library to do so, where are the pointers to the objects it is caching so I can free it? I tried to trace the code but got lost... i'm sure I can trace it given enough time but thought I'd ask the community first. This is not a separate cache, the extensions are cached in each certificate structure, and should be freed with that certificate. It just avoids having to decode extensions all over the place, by computing and saving pre-decoded versions. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Where to download OpenSSL FIPS v2.0.9
On 11/18/2014 06:57 PM, Rob Jerdonek wrote: I see on the NIST website that OpenSSL FIPS module v2.0.9 is in the process of FIPS validation. Where can I download the latest v2.0.9 source code and the updated FIPS user guide. I would like to test with this new version. Sorry about the slow response; I've had a surplus of distractions this week. We do not release the OpenSSL FIPS module tarballs prior to formal approval by the CMVP (the bureaucracy responsible for those approvals) because the CMVP has in the past objected strenuously to such premature releases. The concept of open source is still a bit alien to the FIPS 140-2 world. As to when 2.0.9 will be available, that's difficult to predict because the CMVP does not give any estimates or ongoing status information for submissions. The formal paperwork for 2.0.9 was submitted by the test lab earlier this week. We've seen similar change letter approvals take as little as a few weeks (though that was years ago) and as long as six months. My best guest is perhaps three months (taking into account the slowdown over the upcoming holiday season), so I hope to see 2.0.9 out sometime in mid February. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Differences between openssl-fips-2.0.7 and 2.0.8
On 11/19/2014 10:03 AM, Philip Bellino wrote: Hello, I am currently using openssl-fips-2.0.7 and I noticed that 2.0.8 is available on the website. Neither distribution contain a changelog, so I was wondering what changes were made to 2.0.8. Thanks, Phil The relevant differences cam be found in the Modification History section of the Security Policy document. The only relevant difference between 2.0.8 and 2.0.7 source code is the re-removal of Dual EC DRBG. I say re-removal and not removal because Dual EC DRBG was originally removed with revision 2.0.6. However, the 2.0.6 submission languished at the CMVP for six months during which time we added additional platforms to revision 2.0.7, using code which still included Dual EC DRBG as that removal had not yet been approved. As it turns out both 2.0.6 and 2.0.7 were approved in the same week. We had to wait for 2.0.8 to remove Dual EC DRBG again, hopefully permanently this time. If you don't care about the presence of Dual EC DRBG -- which you shouldn't be using and which isn't usable anyway due to a bug discovered by Steve Checkoway et. al. in their analysis of Dual EC DRBG implementations (http://dualec.org/) -- then there is no reason to upgrade to 2.0.8 if 2.0.7 is currently working for you. As a general rule you should use the latest available revision of the OpenSSL FIPS Object module for all new development, as that revision will support all tested platforms. But, there is no need to upgrade already deployed FIPS module instances. Since we are generally not allowed to introduce bugfixes or performance enhancements to already validated FIPS modules, the latest revision is generally not better in any significant sense than earlier revisions. In particular we are generally unable to address vulnerabilities that we know are present in or with the FIPS module (e.g. Lucky 13), so we don't. The revision increment usually only represents the addition of specific new platforms. The exception to that rule is the removal of Dual EC DRBG, which can be considered a bugfix and/or enhancement. Even there the presence of unused Dual EC DRBG code in the older revisions does not *directly* represent a security vulnerability. I say directly because there is an argument, forcefully expressed to me by several stakeholders and interested parties, that the mere presence of latent Dual EC DRBG code is a potential problem. I have discussed that issue in a personal blog entry: http://veridicalsystems.com/blog/immutability-of-fips/ for those who care to stare into that abyss. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL alert number 51
On Fri, Nov 21, 2014, Matt Caswell wrote: On 21/11/14 14:43, Charles Mills wrote: I posted the certificates. What's next? Charles The key sizes look ok to me. As I said I'm no FIPS expert, but this page http://wiki.openssl.org/index.php/FIPS_mode_and_TLS says the following: The RSA key in the certificate has to be of suitable size (2048 bits minimum) as do all other keys in the chain and none of the CAs can sign using SHA1. But your certificates say: Signature Algorithm: sha1WithRSAEncryption So I'm wondering if that is the problem? Failing that you may need to approach IBM since the alert is being generated from their code. The rules changed some time after the release of the current OpenSSL FIPS module. In the original version SHA1 was allowed and keysizes for RSA, DH had to be 1024 bits minimum. The new version disallows SHA1 for digital signatures and has the 2048 bit limit. Depending on the interpretation it might effectively ban anything other than TLS 1.2 (previous versions of TLS use MD5+SHA1 for RSA signatures). 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: Small memory leak on multithreaded server
On Fri, Nov 21, 2014, Barbe, Charles wrote:
Thanks for the response... here is the code that runs when my connection
closes:
void OpensslConnection::cleanup()
{
if(ssl != NULL)
{
if(isConnected)
{
while(SSL_shutdown(ssl) == 0)
;
}
SSL_free(ssl);
ERR_remove_state(0);
ssl = NULL;
}
isConnected = false;
}
And here is the code that runs to shut down my SSL library:
static void
openSslShutdown ()
{
CONF_modules_free();
ERR_remove_state(0);
CONF_modules_unload(1);
ERR_free_strings();
EVP_cleanup();
CRYPTO_cleanup_all_ex_data();
if (opensslLocks != NULL)
{
for(int i = 0; i CRYPTO_num_locks(); i++)
{
PAL_mutexDestroy (opensslLocks[i]);
}
IST_FREE (opensslLocks);
}
}
Also, I have numerous worker threads handling connections and they all do the
following before they exit:
ERR_remove_thread_state(0);
You are calling SSL_CTX_free aren't you?
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: SSL alert number 51
Thanks. I guess I may have to open a problem with IBM. The IBM documentation clearly lists a number of cipher suites (at they call them) that use SHA1 (including the one we (IBM+OpenSSL) default to as being FIPS 140-2 compliant. GSK appears to only support SHA1 and MD5, and MD4 is pretty clearly not FIP 140-2 compliant. Hmm. I had this note partly composed when Dr. Henson's reply came in. I am thoroughly mystified. Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Matt Caswell Sent: Friday, November 21, 2014 7:04 AM To: openssl-users@openssl.org Subject: Re: SSL alert number 51 On 21/11/14 14:43, Charles Mills wrote: I posted the certificates. What's next? Charles The key sizes look ok to me. As I said I'm no FIPS expert, but this page http://wiki.openssl.org/index.php/FIPS_mode_and_TLS says the following: The RSA key in the certificate has to be of suitable size (2048 bits minimum) as do all other keys in the chain and none of the CAs can sign using SHA1. But your certificates say: Signature Algorithm: sha1WithRSAEncryption So I'm wondering if that is the problem? Failing that you may need to approach IBM since the alert is being generated from their code. 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: Small memory leak on multithreaded server
Yes... sorry, forgot to include this part of my shutdown sequence. One thing I
am noticing is that I do not call X409_free on my certs. I even have a comment
in my code saying that I am not freeing them because I think they will be freed
when the SSL_CTX is freed. Is that a correct assumption or should I be calling
X509 free on them explicitly?
Here's the extra code that I forgot to include:
STATUS
SSL_shutDown()
{
// Client
if (clientCtxt != NULL)
{
SSL_CTX_free (clientCtxt);
clientCtxt = NULL;
}
// View
clearCertsVector (getCertCachePointer (SSL_TYPE_VIEW));
if (pViewKeyCache != NULL)
{
EVP_PKEY_free (pViewKeyCache);
pViewKeyCache = NULL;
}
if (viewServerCtxt != NULL)
{
SSL_CTX_free (viewServerCtxt);
viewServerCtxt = NULL;
}
// Web - only if server supports HTTPS
if (supportHTTPS)
{
clearCertsVector (getCertCachePointer (SSL_TYPE_WEB));
if (pPendingWebKeyCache != NULL)
{
EVP_PKEY_free (pPendingWebKeyCache);
pPendingWebKeyCache = NULL;
}
if (pWebKeyCache != NULL)
{
EVP_PKEY_free (pWebKeyCache);
pWebKeyCache = NULL;
}
if (webServerCtxt != NULL)
{
SSL_CTX_free (webServerCtxt);
webServerCtxt = NULL;
}
}
CHECK_911 (BIO_free (out) 0);
openSslShutdown ();
return SUCCESS;
}
static void
clearCertsVector(CERTS_VECTOR* certs)
{
//Not freeing certs because they will be
// freed when context is destroyed
if(certs != NULL)
{
certs-clear();
}
}
Charles A. Barbe
Senior Software Engineer
Allworx, a Windstream company
245 East Main St | Rochester NY | 14604
charles.ba...@allworx.com | 585.421.5565
From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on
behalf of Dr. Stephen Henson [st...@openssl.org]
Sent: Friday, November 21, 2014 12:26 PM
To: openssl-users@openssl.org
Subject: Re: Small memory leak on multithreaded server
On Fri, Nov 21, 2014, Barbe, Charles wrote:
Thanks for the response... here is the code that runs when my connection
closes:
void OpensslConnection::cleanup()
{
if(ssl != NULL)
{
if(isConnected)
{
while(SSL_shutdown(ssl) == 0)
;
}
SSL_free(ssl);
ERR_remove_state(0);
ssl = NULL;
}
isConnected = false;
}
And here is the code that runs to shut down my SSL library:
static void
openSslShutdown ()
{
CONF_modules_free();
ERR_remove_state(0);
CONF_modules_unload(1);
ERR_free_strings();
EVP_cleanup();
CRYPTO_cleanup_all_ex_data();
if (opensslLocks != NULL)
{
for(int i = 0; i CRYPTO_num_locks(); i++)
{
PAL_mutexDestroy (opensslLocks[i]);
}
IST_FREE (opensslLocks);
}
}
Also, I have numerous worker threads handling connections and they all do the
following before they exit:
ERR_remove_thread_state(0);
You are calling SSL_CTX_free aren't you?
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: Small memory leak on multithreaded server
On Fri, Nov 21, 2014, Barbe, Charles wrote: Yes... sorry, forgot to include this part of my shutdown sequence. One thing I am noticing is that I do not call X409_free on my certs. I even have a comment in my code saying that I am not freeing them because I think they will be freed when the SSL_CTX is freed. Is that a correct assumption or should I be calling X509 free on them explicitly? If you have an explicit X509 structure and you call SSL_CTX_use_certificate then the reference count is increased and you have to free up the certificate. However I'm a bit confused by the output. It *looks* like it is associated with a certificate verification operation which could be cached certificates in a store. Do you perform any operations with an X509_STORE structure? 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: SSL alert number 51
On Fri, Nov 21, 2014, Charles Mills wrote: Thanks. I guess I may have to open a problem with IBM. The IBM documentation clearly lists a number of cipher suites (at they call them) that use SHA1 (including the one we (IBM+OpenSSL) default to as being FIPS 140-2 compliant. GSK appears to only support SHA1 and MD5, and MD4 is pretty clearly not FIP 140-2 compliant. Hmm. I had this note partly composed when Dr. Henson's reply came in. I am thoroughly mystified. Could try to connect your client to OpenSSL's s_server utility with the -state (or for 1.0.2 -trace)? If we can find out what message is triggering that error it might give some hints. 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
CVE-0224-2014 CCS byte
Hi, Can a SSL client upgraded with patch for CVE-0224-2014 (say OpenSSL 0.9.8zb) talk to SSL server which does not have this patch (say OpenSSL 0.9.8u) ? Problem I have - Server -Apache 2.2.22 with mod_ssl compiled with OpenSSL 0.9.8u Client - privately maintained PKI code based upon OpenSSL 0.9.8h to which we regularly backport OpenSSL patches. We have backported fix for cve 0224 to this code. This client is rejecting handshake from above Server with error that it received CCS byte early. How do I debug what is going on and solve this problem? Any help is appreciated. Thank you.
RE: SSL alert number 51
Thanks guys for all of the clues! I got it working! Long story. Wow, FIPS is a moving target. I re-did my root CA with SHA 256, and my server certificate. I had to move my testing from z/OS V1R13 to z/OS V2R1 -- *apparently* V1R13 does not support TLS V1.2 which as you intimated at some point may be required for things that FIPS requires. (A corollary would seem to be that z/OS V1R13 does not support current FIPS requirements but don't quote me on that.) Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: Friday, November 21, 2014 11:00 AM To: openssl-users@openssl.org Subject: Re: SSL alert number 51 On Fri, Nov 21, 2014, Charles Mills wrote: Thanks. I guess I may have to open a problem with IBM. The IBM documentation clearly lists a number of cipher suites (at they call them) that use SHA1 (including the one we (IBM+OpenSSL) default to as being FIPS 140-2 compliant. GSK appears to only support SHA1 and MD5, and MD4 is pretty clearly not FIP 140-2 compliant. Hmm. I had this note partly composed when Dr. Henson's reply came in. I am thoroughly mystified. Could try to connect your client to OpenSSL's s_server utility with the -state (or for 1.0.2 -trace)? If we can find out what message is triggering that error it might give some hints. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: CVE-0224-2014 CCS byte
On Sat, Nov 22, 2014, Deepak wrote: Hi, Can a SSL client upgraded with patch for CVE-0224-2014 (say OpenSSL 0.9.8zb) talk to SSL server which does not have this patch (say OpenSSL 0.9.8u) ? Problem I have - Server -Apache 2.2.22 with mod_ssl compiled with OpenSSL 0.9.8u Client - privately maintained PKI code based upon OpenSSL 0.9.8h to which we regularly backport OpenSSL patches. We have backported fix for cve 0224 to this code. This client is rejecting handshake from above Server with error that it received CCS byte early. How do I debug what is going on and solve this problem? There is a bug related to renegotiation and session tickets which can trigger a bogus CCS early error but it wasn't known to affect 0.9.8-0.9.8. I'd suggest you try disabling session tickets to see if that helps. If it does try backporting commit 249a3e362fe406f8bc05cd3 to 0.9.8. 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: Small memory leak on multithreaded server
A fixed amount of memory that is not deallocated and is independent of the number of operations performed, is NOT a memory leak. Languages like Java and C# can continuously load and unload a library. You will see a growth in memory usage because the memory is not reclaimed. Librariers to allocate memory for the lifetime of the process during one time initialization or first use of a function. This is normal. I think this may be an incorrect assumption. Tracking this down is a waste of time IMHO. For a OpenSSL user, its hard to determine the bad leaks (those caused by the user) versus the good leaks (those incumbent to OpenSSL). The good leaks mask out the bad leaks. For the 2561 bug, there's no need to track it down. You've been told where the leak is. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL alert number 51
To set the record straight, I am told that a PTF (IBMese for patch) is required for z/OS V1R13 to support TLS v1.2. Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Charles Mills Sent: Friday, November 21, 2014 12:07 PM To: openssl-users@openssl.org Subject: RE: SSL alert number 51 Thanks guys for all of the clues! I got it working! Long story. Wow, FIPS is a moving target. I re-did my root CA with SHA 256, and my server certificate. I had to move my testing from z/OS V1R13 to z/OS V2R1 -- *apparently* V1R13 does not support TLS V1.2 which as you intimated at some point may be required for things that FIPS requires. (A corollary would seem to be that z/OS V1R13 does not support current FIPS requirements but don't quote me on that.) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Small memory leak on multithreaded server
On Fri, Nov 21, 2014 at 04:13:58PM -0500, Jeffrey Walton wrote: A fixed amount of memory that is not deallocated and is independent of the number of operations performed, is NOT a memory leak. Languages like Java and C# can continuously load and unload a library. You will see a growth in memory usage because the memory is not reclaimed. Unloading of shared libraries is generally unsafe. Loading and unloading of pure of Java packages may work well enough, but I would expect a Java runtime that unloads native libraries to stay running for very long. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Small memory leak on multithreaded server
I did a search through my application code and see no occurrence of the string X509_STORE so I don't believe I'm doing any operations with that type of structure. I am using SSL_CTX_use_certificate and was possibly under the incorrect assumption that my code did not have to explicitly free the X509* that I pass to that argument if I am subsequently calling SSL_CTX_free on the CTX. In retrospect that doesn't sound correct. I will fix my code to free the X509s as well as the CTX and see if that is my issue. Thank you everybody for all of the help! Charles A. Barbe Senior Software Engineer Allworx, a Windstream company 245 East Main St | Rochester NY | 14604 charles.ba...@allworx.com | 585.421.5565 From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on behalf of Dr. Stephen Henson [st...@openssl.org] Sent: Friday, November 21, 2014 1:40 PM To: openssl-users@openssl.org Subject: Re: Small memory leak on multithreaded server On Fri, Nov 21, 2014, Barbe, Charles wrote: Yes... sorry, forgot to include this part of my shutdown sequence. One thing I am noticing is that I do not call X409_free on my certs. I even have a comment in my code saying that I am not freeing them because I think they will be freed when the SSL_CTX is freed. Is that a correct assumption or should I be calling X509 free on them explicitly? If you have an explicit X509 structure and you call SSL_CTX_use_certificate then the reference count is increased and you have to free up the certificate. However I'm a bit confused by the output. It *looks* like it is associated with a certificate verification operation which could be cached certificates in a store. Do you perform any operations with an X509_STORE structure? 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
which cipher was chosen?
Is there a way to query the BIO or SSL object to see which cipher is being used? I have a case where my openssl client's performance is significantly slower when talking to server A vs server B. AFAIK, the only difference between A and B is the level of Windows updates, so I'm suspicious that Windows has started to favor the slower ECC ciphers, but I need a way to prove it. -- Chris Bare
Re: which cipher was chosen?
On Fri, Nov 21, 2014, Chris Bare wrote: Is there a way to query the BIO or SSL object to see which cipher is being used? I have a case where my openssl client's performance is significantly slower when talking to server A vs server B. AFAIK, the only difference between A and B is the level of Windows updates, so I'm suspicious that Windows has started to favor the slower ECC ciphers, but I need a way to prove it. SSL_get_cipher_name(). What do you mean by peformance the initial connection speed or the data transfer rate? With ECC the curve used is also significant: you can query that using OpenSSL 1.0.2+ which allows you to get details of the server temporary key. 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: which cipher was chosen?
Thanks, that's just what I needed. By performance I mean the initial connection speed. It spends 4-5 seconds in ssl3_send_client_key_exchange () in the slow case, vs about 0.1 sec in the fast case. This is on a 200Mhz arm, so it's not a fast machine. On Fri, Nov 21, 2014 at 7:03 PM, Dr. Stephen Henson st...@openssl.org wrote: On Fri, Nov 21, 2014, Chris Bare wrote: Is there a way to query the BIO or SSL object to see which cipher is being used? I have a case where my openssl client's performance is significantly slower when talking to server A vs server B. AFAIK, the only difference between A and B is the level of Windows updates, so I'm suspicious that Windows has started to favor the slower ECC ciphers, but I need a way to prove it. SSL_get_cipher_name(). What do you mean by peformance the initial connection speed or the data transfer rate? With ECC the curve used is also significant: you can query that using OpenSSL 1.0.2+ which allows you to get details of the server temporary key. 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 -- Chris Bare
