Winsock2 out-of-the-box support
Hi all, Are there any plans to support linking against Winsock 2 out-of-the-box for Windows builds? perhaps as a configure option? I can certainly hack the makefile myself to do what I want, but we have our users download and build OpenSSL themselves and it would be nice if it were as easy as possible for them. Does anyone else see this as a useful idea? Regards, Mike Zeoli Rogue Wave Software __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
SSL_dup() memory leak?
Hi all, I think I've found a memory leak in SSL_dup() and I'd like some confirmation from someone who know the code well. (This is for OpenSSL 0.9.6 on Win2000 btw) SSL_dup calls SSL_new with the original SSL*'s context. SSL_new calls ssl_cert_dup to duplicate the memory pointed to by context-cert, and assigns that new block (we'll call it block A) to the new SSL's -cert pointer. Later, continuing in SSL_dup, ssl_cert_dup is called again to copy the original SSL*'s cert , this block is then assigned to the SSL (now called ret) 's -cert pointer thus causing the block A (above) to no longer have any references to it, thus leaking the memory. The net effect is that any EVP_PKEY's and X509's associated with the context never get freed because the leaked CERT (above) still holds a reference to them. A possible solution: in SSL_dup, before copying the original SSL*'s -cert pointer, check if one has been copied already (from the context) and free that memory before doing the ssl_cert_dup. Is this a legitimate leak, or am I missing something? What is the philosophy behind the code? I mean, should the -cert data from the original SSL* take precidence over the -cert data from the context? I'm going to hack a temporary fix in so purify doesn't bark at me anymore. Regards, Mike __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: SSL_dup() memory leak?
Sorry about replying to myself, but here is the fix I propose:
in SSL_dup (ssl_lib.c), add the lines with //MPZ after them.
if (s-session != NULL)
{
/* This copies session-id, SSL_METHOD, sid_ctx, and 'cert'
*/
SSL_copy_session_id(ret,s);
}
else
{
/* No session has been established yet, so we have to expect
* that s-cert or ret-cert will be changed later --
* they should not both point to the same object,
* and thus we can't use SSL_copy_session_id. */
ret-method = s-method;
ret-method-ssl_new(ret);
// FIX in this statement
if (s-cert != NULL)
{
if(ret-cert != NULL) { // MPZ
ssl_cert_free(ret-cert); // MPZ
} // MPZ
ret-cert = ssl_cert_dup(s-cert);
if (ret-cert == NULL)
goto err;
}
//Original Code
// if (s-cert != NULL)
// {
// ret-cert = ssl_cert_dup(s-cert);
// if (ret-cert == NULL)
// goto err;
// }
SSL_set_session_id_context(ret,
s-sid_ctx, s-sid_ctx_length);
}
Regards,
Mike
-Original Message-
From: Mike Zeoli [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 11, 2000 6:12 PM
To: OpenSSL Users List (E-mail)
Subject: SSL_dup() memory leak?
Hi all, I think I've found a memory leak in SSL_dup() and I'd
like some
confirmation from someone who know the code well. (This is
for OpenSSL 0.9.6
on Win2000 btw)
SSL_dup calls SSL_new with the original SSL*'s context. SSL_new calls
ssl_cert_dup to duplicate the memory pointed to by context-cert, and
assigns that new block (we'll call it block A) to the new SSL's -cert
pointer.
Later, continuing in SSL_dup, ssl_cert_dup is called again to copy the
original SSL*'s cert , this block is then assigned to the SSL
(now called
ret) 's -cert pointer thus causing the block A (above) to no
longer have
any references to it, thus leaking the memory.
The net effect is that any EVP_PKEY's and X509's associated
with the context
never get freed because the leaked CERT (above) still holds a
reference to
them.
A possible solution: in SSL_dup, before copying the original
SSL*'s -cert
pointer, check if one has been copied already (from the
context) and free
that memory before doing the ssl_cert_dup.
Is this a legitimate leak, or am I missing something?
What is the philosophy behind the code? I mean, should the
-cert data from
the original SSL* take precidence over the -cert data from
the context? I'm
going to hack a temporary fix in so purify doesn't bark at me anymore.
Regards,
Mike
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Certificate Chains server vs client/server authentication
Hello Everyone, I have a chain of version 1 certificates. "Root CA" signs "Intermediate CA", which signs "client1" and "server1" certificates. I also have two example client/server pairs. The first example only does server authentication. The other example does both client and server authentication. The server authentication example works just fine, but the client/server authentication fails when trying to verify the server1 certificate chain. Here's the actual example (this is the client with the info callback tracking the progress) before/connect initialization before/connect initialization SSLv2/v3 write client hello A SSLv3 read server hello A SSLv3 read server certificate B SSLv3 read server certificate B SSLv3 read server certificate B Here is the error stack. 1068:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:.\ssl\s3_clnt.c:764: As stated before, this same certificate chain gets verified just fine when doing server authentication only. I have debugged into the library and know the following additional information: - In x509_vrfy.c:check_chain_purpose(), in the server auth. only example, ctx-last_trusted is set to 1, while for my client and server authentication example, it is set to 2. The function is dying on my intermediate certificate. if last_trusted == 1. it just checks the validity of the server certificate, but when last_trusted==2, it assumes that my intermediate certificate is also untrusted, this causes X509_check_purpose() to return 1 which then sets ctx-error to X509_V_ERR_INVALID_CA. Also, I do use load_verify_locations to load a trusted certificates file which contains both the root and intermediate CA certificates. Any help would greatly appreciated. Thanks, Mike Zeoli __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
