Hi Nou,
In that case my third point seems most relevant to you. There are a
whole bunch of structures that are set up to hold and retain the various
pieces of network data, file data, crypto data, certificates and keys
required for SSL. If you are doing a thorough test then you are probably
using a lot of them, have a look in apps/X509.c, which is probably able
to do a lot of the stuff you are doing to test certificates and look at
the structures created and released.
To be more helpful, try and isolate the section in your code that is
failing to identify the structure with the bad data. You might be able
do this by progressively pulling out crypto tests until you found the
test(s) that are dirtying the offending structure.
Good luck
Jeremy
Nou Dadoun wrote:
Thanks for the note, seems like it's even more fundamental than that because
the unit test not only doesn't establish an ssl connection, it doesn't even use
an ssl context! As a certificate unit test, it's *only* testing our various
certificate deployment scenarios to make sure that we retrieve the right CA
certificate and do a verification correctly (we also do a test encrypt/decrypt
on the keys to make sure they're usable).
The "spoiler" crypto tests don't use an ssl context either (they're really just
using test encrypt/decrypts for the various algorithm deployments scenarios) so it's
still a little mysterious why the two would interfere with each other! It would seem to
be right down in the crypto algorithm code because that seems to be all that they have in
common. That's why a total scrub cleanup function would be useful ... N
---
Nou Dadoun
ndad...@teradici.com
604-628-1215
-----Original Message-----
From: jeremy hunt [mailto:jere...@optimation.com.au]
Sent: April 10, 2012 6:11 PM
To: openssl-users@openssl.org
Cc: Nou Dadoun
Subject: Re: openssl/crypto cleanup
On a disconnect check the state of the SSL data structure and call
SSL_free if it is not null.
if (*sslptr != NULL) {
SSL_free (*sslptr);
*sslptr = NULL;
}
Though as you say it is a certificate issue, then perhaps you need to
look at
SSL_CTX_free(*sslctxptr)
Look at the man page for this. Perhaps you are reusing an SSL context
structure. We don't need to call this in our disconnect code, but
testing code may reuse a structure that running code doesn't.
If these don't work for you, then maybe you should look at putting in
some diagnostic printfs to look for where the dirty data is being kept,
you might be reusing something like a DH or X509 structure and you may
need to call a free or cleanup function for that particular structure.
I don't know about the callback function, but I like your guess.
Good Luck,
Jeremy
Nou Dadoun wrote:
Hi, I've looked at the archives and didn't see any apropos discussions
so I thought I'd go straight to the list:
We use the openssl& crypto libraries in several places in our product
both in fips and non-fips modes.
We have a set of unit tests to exercise various portions of our code
to ensure that our implementations using these tools work the way that
they're supposed to.
I've run into an unusual problem, we have a set of crypto
(encrypt/decrypt) tests and a separate set of certificate tests (e.g.
retrieve a certificate and its CA and do a certificate verification).
If I run the certificate tests first and then the crypto tests, all
the tests pass and everything works great.
If I run the crypto tests first and then the certificate test, the
verification fails due to a "signature" failure. This implies to me
that the crypto tests are leaving something in the openssl/crypto
machinery in a funky state which breaks the subsequent certificate
signature computation.
A couple of questions:
What can I do to completely clean the openssl/crypto state to ensure
that this doesn't happen? I've added:
CRYPTO_cleanup_all_ex_data();
ENGINE_cleanup();
But this appears to be inadequate (I suspect necessary but
insufficient), any suggestions?
(I've reordered the tests so that they're passing now but I'd like to
avoid this hack if I can.)
Second question, I added a verification callback routine, e.g.
staticint verify_callback(int ok, X509_STORE_CTX *stor)
{
if(!ok)
{
printf("verify_callback Certificate Verification Error: %s\n",
X509_verify_cert_error_string(stor->error));
}
else
{
printf("verify_callback Certificate Verification Success\n");
}
return ok;
}
I've put a breakpoint in it and noticed that when verifying a
certificate, this callback is called twice,
In the successful order above (cert then crypto tests) both calls have
ok == 1,
In the unsuccessful order (crypto then cert), the first call is 1 and
the second is 0 with a "signature error" reported.
Why is it called twice and what's the difference? (I suspect the
second is signature checking and the first is everything else but I'm
curious).
Thanks in advance ... N
---
Nou Dadoun
ndadoun@teradici.com_
_604-628-1215
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
